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

Barry Greene (bgreene) bgreene at cisco.com
Thu Mar 2 11:37:42 UTC 2006

Here are some facts:

-> In the US, of the top 10 us provider (using the Skitter metric), 1/2
are doing full BCP 38. 

-> BCP 38 works with multihomed networks - including networks that are
using uRPF Strict Mode

-> Many broadband companies are slowly rolling out BCP38 with the
anti-MAC Spoofing AND recoloring the packets. 

-> BCP 38 is not really controversial. It is a matter of how easy it can
be deployed in a network, what is the cost of that deployment, and how
much interest the operator has in tackling this one of their many
network issues. 

-> There are many ways to achieve BCP 38. Off the top of my head, we
have the following:

	+ iACLs
	+ uRPF Strict Mode
	+ uRPF VRF Mode
	+ uRPF Feasible Path
	+ Radius ACLs
	+ IP Source Guard (Src IP and Src MAC check)
	+ DHCP Lease Query (Src IP and Src MAC check)

Do we have a lot of work to do in the BCP38 global deployment? Yes. Is
it really a accepted "BCP?" In the SP community, yes. 

> -----Original Message-----
> From: dns-operations-bounces at mail.oarc.isc.org 
> [mailto:dns-operations-bounces at mail.oarc.isc.org] On Behalf 
> Of Sam Norris
> Sent: Wednesday, March 01, 2006 4:15 PM
> To: dns-operations at mail.oarc.isc.org
> Subject: [dns-operations] SAC004 & BCP38 [was: DNS deluge for 
> x.p.ctrc.cc]
> I'm starting a new thread to talk specifically about the subject.
> * Paul Vixie wrote:
> > # > ... there is no valid reason to spoof so blocking that 
> 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 header 
> 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 it 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 "A" 
> using source
>    addresses that were assigned by upstream "B".  In this 
> case, upstream
>    "A" must be prepared to accept source addresses in address 
> 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 
> slight 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 has a 
> route object and prefix filters, etc... Are there any 
> resources out there on how to accomplish BCP38 and keep your 
> multihomed customers flowing?  BCP38 was written in 2000 and 
> is not very popular I take it.  Can this 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