On Mon, Oct 11, 2004 at 02:58:59AM +0000, Fergie (Paul Ferguson) wrote:
It's better than a sharp stick in the eye, I'll tell ya, lad.
Listen to me: It's called a "best current practice" for a reason -- people should do it. Not sit and around and endlessly discuss it (we've already done that a thousand times).
I wrote it, I stand beside it. I'm sick of hearing why people haven't implemented it yet -- it's almost five years later and there's simply no excuse. It's sickening.
Tell it to the vendors of the layer 3 customer attach devices. I was just speaking about this with a major "up and coming layer 2/3 switch vendor" the other day, who had no implementation or real plans to implement uRPF in the immediate future. It apears that there are no enterprise customers asking for this feature (not a shock), despite the fact that they are probably a leading generator of hacked machines throwing bad packets down reasonably big pipes. uRPF support is hardly universal outside of Cisco and Juniper, and even Juniper didn't add uRPF until semi-recently. I know Foundry still doesn't have support for it (not really anyways, they added something they call uRPF and have you activate through "ip verify unicast reverse-path" but it isn't really uRPF, just a way to prevent outside networks from spoofing local addresses, and you have to manually tag every interface as internal or external or the addresses aren't protected), and I'm pretty sure Extreme doesn't have it (or at least I've never seen anyone use it, but I don't follow 0 day Extreme code). Short of the Cisco L3 switch solutions, I'm not aware of any other vendor with a L3 switch who has uRPF functionality. I can't think of a single web hoster (or at least someone who wasn't a real network operator who got into hosting somehow) who even knows what uRPF is, let alone implements it for their customers. We're counting on their IP providers to filter the bad packets from the hundreds of FE connected servers on burstable GigE pipes out there, but some of them just aren't. I can name several major well-known "cheap" networks who don't do any uRPF filtering of their customers, and a couple more who don't do any real prefix-lists on their BGP speaking customers, only prefix-limits. There are even fewer vendors who are implementing automation for filtering basic BGP speaking customers, such as Juniper's ability (sort-of) to re-use a route filtering prefix-list for source address filtering in a firewall. It's not quite perfect, since you can't do length modifiers (upto /24, etc) in a prefix-list, and since you have to create a seperate policy-statement (with all routes listed in route-filter statements), prefix-list, AND firewall filter for each and every customer, but at least it is a start. If you don't have this, or uRPF at all, you are left trying to script ACLs based on interface configurations, static routes, and/or registered prefixes, and the bottom line is that most networks aren't going to do it if it takes that much work. If and when all the vendors who are making boxes that are supposed to be used for customer aggregation start implementing uRPF, especially considering all the enterprises, universities, and international network using these L3 switches as their sole routing equipment (think price), maybe we'll start seeing some more progress. And of course, those remaining service providers with the gear to implement it who havn't done so need to be yelled at more. Unfortunately, no customer ever complains (or takes their business elsewhere) when their provider doesn't do source address filtering, only when they are getting a DoS attack and their provider can't do anything about it. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)