[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