an effect of ignoring BCP38

Pekka Savola pekkas at netcore.fi
Thu Sep 11 17:59:39 UTC 2008


On Thu, 11 Sep 2008, Jo Rhett wrote:
> On Sep 11, 2008, at 10:10 AM, Valdis.Kletnieks at vt.edu wrote:
>> By the time you walk our list of upstreams to any of the '5 biggest 
>> anything', you've gotten to places where our multihomed status 
>> means you can't filter our source address very easily (or more 
>> properly, where you can't filter multihomed sources in general).
>
> I don't agree with this statement.  I hear this a lot, and it's not really 
> true.  Being multihomed doesn't mean that your source addresses are likely to 
> be random.  (or would be valid if they were)
>
> A significant portion of our customers, and *all* of the biggest paying ones, 
> are multihomed.  And they might have a lot of different ranges, but we know 
> what the ranges are and filter on those.

If you can manage ACLs for these customers, that's fine.  But maybe 
your multihomed customers and '5 biggest anything' customers are 
different.  Maybe your multihomed customer has 5 prefixes.  The big 
ones could have 5000.  That's a pretty big ACL to manage.

This is where Strict URPF (+feasible paths) helps a lot because in 
some cases you don't need to manage those ACLs by hand.  But this gets 
broken if the customer advertises more specific routes from another 
provider, but doesn't advertise these to you -- your route to those 
more specifics goes through another ISP, and if the site is sourcing 
packets from those more specifics through you, the strict uRPF would 
drop them.

There are ways to work around this, e.g. by requiring that the 
customers advertise the more specifics to you as well but mark them so 
that you don't propagate them, but I suspect this is not feasible in 
the higher tiers of ISP business.

http://tools.ietf.org/html/draft-savola-bcp84-urpf-experiences Section 
3 discusses this a bit.

FWIW: we use feasible-paths strict uRPF on all customer and LAN 
interface without exception.  Multihomed ones as well, though it's a 
bit more work.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings




More information about the NANOG mailing list