BCP38 making it work, solving problems

Mon Oct 11 22:03:08 UTC 2004

At 05:41 PM 10/11/2004, Richard A Steenbergen wrote:

> >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.

I've removed the rest of your message, talking about which vendors do or 
don't have what capabilities. While I agree it'd be nice if more vendors 
offered automated tools for implementing ingress filtering, such tools are 
unnecessary in most corporate network cases, thus the lack of corporate 
customers asking for the feature. In reality every device offering access 
control lists capable of filtering on source IP address can and does have 
sufficient capability to implement BCP38.

While I appreciate the desire to have a single switch solution, like was 
possible with BCP34, it's a bit more complex to do in this case. It is, 
however, disingenuous to say that devices don't support BCP38 because they 
don't have an automated widget to implement it. Keep in mind that uRPF is 
an implementation of BCP38 capability, and other implementations are 
entirely possible.

This was probably obvious to you, but others reading might find the 
clarification useful. 