|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Where are static bogon filters appropriate? was: 96.2.0.0/16 Bogons
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 <[email protected]> // 408.527.6376 voice The telephone demands complete participation. -- Marshall McLuhan
|