BCP38 Deployment

Wed Mar 28 16:16:10 UTC 2012

In a message written on Wed, Mar 28, 2012 at 08:45:12AM -0700, David Conrad wrote:
> An interesting assertion.  I haven't looked at how end-user networks are built recently.  I had assumed there continue to be customer aggregation points within ISP infrastructure in which BCP38-type filtering could occur.  You're saying this is no longer the case?  What has replaced it?

Well, RFC3704 for one has updated the methods and tactics since BCP38
was written.  Remember BCP38 was before even "unicast RPF" as we know it
existed.

Some relevant points from 3704:

3.  Clarifying the Applicability of Ingress Filtering

   What may not be readily apparent is that ingress filtering is not
   applied only at the "last-mile" interface between the ISP and the end
   user.  It's perfectly fine, and recommended, to also perform ingress
   filtering at the edges of ISPs where appropriate, at the routers
   connecting LANs to an enterprise network, etc. -- this increases the
   defense in depth.

5.  Security Considerations
[snip]
   The closer to the actual source ingress filtering is performed, the
   more effective it is.  One could wish that the first hop router would
   ensure that traffic being sourced from its neighboring end system was
   correctly addressed; a router further away can only ensure that it is
   possible that there is such a system within the indicated prefix.
   Therefore, ingress filtering should be done at multiple levels, with
   different level of granularity

I'm not saying ISP's can't or couldn't do it, what I am saying, and
RFC 3704 is repeating, is that it is cheaper/easier/faster and more
reliable to do it as close to the edge as possible.  "The edge" is
not the edge of the ISP network, it is the edge of the entire
network, that is the /last router in the topology/.  Today that
last router is owned and operated by the customer in most cases.

So if a provider drops off a modem with your service that also does
WiFi and the customer simply uses it, the provider is 100% responsible
for doing BCP 38, in my estimation.  But as soon as the consumer
buys a routing device they become 100% on the hook for now operating
the last mile, and it is that device where the primary filtering
should take place.  ISP's may still filter, for a defense in depth,
but they are no longer the edge of the network and as such their
responsibility is greatly diminished in my view.

BCP38 was written when a point to point handoff to a single customer was
standard, and that's easy to filter.  Today a shared medium (like a
cable modem network) is common and more importantly connects to more
routers (home gateways), rathern than PC's.  That's a funamental change
since BCP38 was written.

I'll also point out that operating systems fill a role here as well.
Many OS's won't let you spoof a layer 2 MAC address (try to write
a packet with a raw interface and it overwrites the source address)
but are happy to let an application send a packet with source layer
3 address that is forged!  Sure, malware could always hack the OS
too, but it raises the bar.  The community should demand that all
OS's default to not allowing L3 sources that aren't configured on
the box from leaving that box.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120328/df625dac/attachment.sig>