On Tue, 5 Aug 2003, Paul Vixie wrote:
chris@UU.NET ("Christopher L. Morrow") writes:
There are many cases in which the backbone can't determine the 'proper' traffic an edge is sending in.
i'd like to discuss these, or see them discussed. networks have edges, even if some networks are "edge networks" and some are "backbone networks." bcp38 talks about various kinds of "loose" rpf, for example not accepting a source for which there's no corresponding nondefault route.
Sure, rpf (or something akin to it) is included in BCP38... though there are plenty of equipment vendors who's equipment isn't capable of performing even loose-rpf :( Some folks are saddled with such hardware. However, at the lan edge, almost every piece of hardware is capable of filtering with a very simple acl (or urpf even in strict mode). The default configuration placed by CPE users should have this included. This is the right place for these restrictions, beyond the lan edge the decisions about routing become much more complex.
Not to mention the problems of filtering on an edge device with 100's or 1000's of interfaces. The proper and simple place for this filtering is as close to the end device as possible. Backbones just aren't made to filter traffic, edge networks are.
so, the problem is transitive. you might have a multihomed customer whose
Yes, its transitive.
but they might have the same situation with their downstream. and you're not requiring them to do edge filtering as a contract/peering term, nor are you requiring them to require their downstreams to do so. this means the
Certianly.. I don't write contracts or make sales... though I'm sure someone in the sales department, or likely 'contracts' or 'legal' would be happy to entertain this idea. I can say that the technology is, and has been for 2 years, included in basic customer CPE configs when they are sent out by our install group. (for UUNET atleast) Other providers might do the same, I've got little visibility into that arena.
problem goes from "transitive" to "laundered" in about one AS hop or so. i don't consider this a healthy situation, and i'd like to hear you list the kinds of rpf you know of and why none can be used on a "backbone".
1) by access-list (strict this is called by some?) ip verify unicast reverse-path <100-199> without knowing all networks the customer has this has problems :( you don't HAVE to know all networks your customer owns, some they might not want transiting your network :( 2) by interface (strict I'd call this too) ip verify unicast source reachable-via rx This has the same problems as 1... again, perhaps your customer doesn't want to return transit traffic across your network for this? 3) loose mode ip verify unicast source reachable-via any This is more workable, though some providers use 1918 space internally so this won't help these networks, nor will it help if you are using that dead ip space for other purposes :( It's helpful for blackholing sources and getting backscatter though :) Note, all urpf have the same problems on some platforms, places where the urpf is done as a process-switched solution are a problem (e0 cards on cisco 12000's for example). There are still ALOT of problematic hardware platforms out there, and as near as I can tell this is only really supported on cisco and juniper gear, no? -Chris