Where are static bogon filters appropriate? was: 22.214.171.124/16 Bogons
rdobbins at cisco.com
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?
> 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
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
More information about the NANOG