[151656] in North American Network Operators' Group
Re: BCP38 Deployment
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Wed Mar 28 12:17:12 2012
Date: Wed, 28 Mar 2012 09:16:10 -0700
From: Leo Bicknell <bicknell@ufp.org>
To: NANOG list <nanog@nanog.org>
Mail-Followup-To: NANOG list <nanog@nanog.org>
In-Reply-To: <D57C460F-FEC9-4E63-91F0-171D6A9A3C2A@virtualized.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--T4sUOijqQbZv57TR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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 po=
ints 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.
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
--T4sUOijqQbZv57TR
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
iQIVAwUBT3M5SbN3O8aJIdTMAQLXXg/+IJCTHwVxQEt6oHBlD4mHlAoMC8R01YId
1cZgEpoFAwlfsZmsFl6iSejwe6by1I+746jjQiCoR7gNLKi9P5eWtsxyQrINVJ0k
8soO7rJvIo99qRXZ6hb4dpT1pftN5+e5IF3kYLQj6bpgAy2NQRVV264hK/W9sLm+
sxSmkwD9PW8aTYAm4A7eGqkEf64MeQ0+ZbVamwO6/a7iijJSHurWrGfg5Aj8r7X4
CidtTcsEPeO3UOAE28zngZUFy6wZKS1Fztcc3znJNvCnD12LzPOv/Jb5gETHTGEc
xo4Ldfe2+/mU8wsIvEqCF/mFLaAQsmoyRuO9D92nHNRo+stSYXCwi6jyGRYggknI
6JYWAZLegXIXlBrDBSbn1Ew+YmtByM6W50u8aRwareeUmurve7cwNdRGMZpeCFqO
XToQ/mq6yzTnJ+m5dLvsyS2nemuV0Y7pcSMS3BsAYaNrwbkvq+uiX2VmcBG3ZOxC
8uvxKkUqwuF5rggNoMoIRMAJ86oMznRQiaMcnSlagl/xBD7qiJm5Yq6K32/EERWo
7JnYdLuh2P/iULDZCcOjvepNogZxQHYIKoAT7HJX3SfmCa/89wHqoxkTEtKpqbRw
1P6rr0A9A5vrda/T9uJZvdeu4sCG+AlZbdVWsGI8fjSXokm4o8qtGHs3OD/NxGmT
KnVL0k8tJBg=
=WjGp
-----END PGP SIGNATURE-----
--T4sUOijqQbZv57TR--
