Where are static bogon filters appropriate? was: 96.2.0.0/16 Bogons

Fri Mar 2 14:04:12 UTC 2007

On Mar 2, 2007, at 4:12 AM, Robert E. Seastrom wrote:

uRPF isn't always adequate for all antispoofing cases, as you know.   
What about iACLs?

> bogon
> filtering by end sites is the sort of thing that is recommended by
> "experts" for whom "security" is an end in and of itself, rather than
> a component of the arsenal you bring forth (backups, DR, spares,
> multihoming, etc) to improve uptime and business availability and
> decrease potential risk.

I don't claim to be an 'expert' at anything, but I most certainly - 
do- recommend bogon filtering, along with multihoming, infrastructure  
self-protection measures (iACLs, rACLs, CoPP, core-hiding, et. al.),  
various antispoofing techniques (all the way down to layer-2 where  
possible), instrumentation and telemetry, anomaly-detection, reaction  
tools, layer-7 things like backup and DR, layer-8 things like  
sparing, and so forth.  And my goal isn't 'security', it's a  
resilient Internet infrastructure which keeps the packets flowing so  
that the users can access the applications which are the point of the  
whole exercise.

I'm not the only one who thinks like that, either.  So, painting us  
all with the same broad brush hardly seems fair, does it?

Rejecting bogon filtering out of hand because it isn't effortless to  
maintain doesn't make much sense to me.  After all, if one's being a  
good Internet neighbor, one's doing ingress filtering (routes and  
packets) from one's customers and egress filtering (routes and  
packets) to one's peers/transits/customers, anyways; one will see  
more churn there than in the bogon lists.

It's also part of the very basic protections which ought to be  
provided to one's customers.  No, the SP can't be the 'Internet  
firewall' for customers, and, no, the SP can't be expected to keep  
the customer magically protected from all the Bad Things which can  
happen to him (and for free, naturally), but protecting one's  
customers from being spammed/packeted from purported source addresses  
which are by definition nonsensical (as well as protecting everyone  
else's customers from same) doesn't seem much to ask.

What's needed here are better/easier/less brittle mechanisms for  
same.  Until such time as they're invented and deployed, let's not  
make the perfect the enemy of the merely good, yes?

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at cisco.com> // 408.527.6376 voice

           The telephone demands complete participation.

                       -- Marshall McLuhan