[dns-operations] SAC004 & BCP38 [was: DNS deluge for x.p.ctrc.cc]

Ejay Hire ejay.hire at isdn.net
Thu Mar 2 15:19:56 UTC 2006

Disclaimer, I have not read the full source document.

I interpret this section to mean customers that are
Multihomed with reachability from multiple providers.  In
today's internet that means BGP, or coordinated with both

We had an incident where a customer was making a dial-up
connection to another ISP, and then used our upstream
bandwidth to send spam using the dial-up IP.  MCI (our
upstream) caught the "not-technically spoofed, but shouldn't
be on my network" traffic in their ingress filters (facing
us) and dropped the traffic.  The customer reported
reachability issues to us, we investigated, figured it out,
shut them down, and that's when we implemented customer
facing RPF checks.


> -----Original Message-----
> From: dns-operations-bounces at lists.oarci.net 
> [mailto:dns-operations-bounces at lists.oarci.net] On Behalf
> Sam Norris
> Sent: Wednesday, March 01, 2006 6:15 PM
> To: dns-operations at mail.oarc.isc.org
> Subject: [dns-operations] SAC004 & BCP38 [was: DNS deluge
> x.p.ctrc.cc]
> I'm starting a new thread to talk specifically about the
> * Paul Vixie wrote:
> > # > ... there is no valid reason to spoof so blocking
> capability 
> > takes
> > # > nothing away from the internet.
> > #
> > # Unfortunly, that's not true. Spoofing is a common and
wide spread 
> > technique
> > # to simulate multihoming without PI space. This is 
> independant of an own 
> > AS.
> >
> > see [SAC004 5.1] 
> (http://www.icann.org/committees/security/sac004.txt).
> I consider 'spoofing' the practice of forging your IP
> to be someone 
> you are not.  This is a bit different than using your IP
space across 
> multiple providers, however I agree that in most instances
> can be used to 
> describe both.
> In SAC004 I read this:
> 5.1. Multihomed networks who use address space from
multiple upstream
>    providers will occasionally emit packets into upstream
> using source
>    addresses that were assigned by upstream "B".  In this 
> case, upstream
>    "A" must be prepared to accept source addresses in
> space "B",
>    and vice versa.  This is only a slight complication and
does not
>    invalidate the approach.
> I'm wondering if there are any proposed suggestions to the
> complication yet?  This is really the biggest stepping
stone that the 
> industry needs to take to implement this I believe.  There

> are many public 
> databases already in existance that store routing and ip 
> information - can 
> these feasably be used ?  ARIN knows my IP ranges, LEVEL3
> a route object 
> and prefix filters, etc... Are there any resources out
> on how to 
> accomplish BCP38 and keep your multihomed customers
> BCP38 was 
> written in 2000 and is not very popular I take it.  Can
> be implemented 
> with current hardware and infrastructure today without 
> forcing everyone to 
> buy new routing equipment?
> If this is the wrong place for this topic then tell me ...
This whole 
> recursive dns server issue is only 1 of the many that will

> start cropping up 
> and it would be nice to come up with a real solution (
alongside the 
> recursive dns issues at hand ).
> Sam
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.oarci.net
> http://lists.oarci.net/mailman/listinfo/dns-operations

More information about the dns-operations mailing list