North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: BCP38 making it work, solving problems

  • From: Richard A Steenbergen
  • Date: Mon Oct 11 17:43:43 2004

>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 <[email protected]>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)