|
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 Thu, 1 Mar 2007, Chris L. Morrow wrote: So... again, are bogon filters 'in the core' useful? (call 'core' some network not yours) The cisco auto-secure feature sure showed some fun effects for this too, eh? We managed to fix that mis-application in later releases, but it has human dependency for that set of releases. http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_field_notice09186a00803e13e9.shtml Like security "experts" the recommend blocking calls in the North American numbering plan to area code 809, or listing individual area codes in PBXs, its not a good idea unless you have full-time telephone LERG engineers. My rule of thumb is networks which use the "default" route probably should not implement bogon filters of reserved for future allocation addresses. Of course, they should still implement postive outbound traffic controls (i.e. BCP38++) on their own traffic. Even if the current engineers are careful, people change, but the new people may not know or forget about updating miscellanous routers especially in networks with "default" routing. Most RFC3330 Special Use Addresses which should not appear on the public Internet probably should be dropped crossing Internet provider boundaries unless specifically allowed, i.e. RFC1918, 127/8, 169.254/16, 224/4, 240/4, etc. That does not include other addresses mentioned in RFC3330 like 14/8, 24/8, 223.255.255.0/24 which are/will be routable on the public Internet. Most backbones already apply some filter like this to their BGP sessions and it can be optimized for hardware support even on very high traffic links. This is pretty low-risk, low-change traffic hygiene. So what about filtering reserved for future use "unallocated" IP addresses between "default-free" backbones? Is it enough of a real problem to overcome the other hurdle of making operational changes/errors in major backbone interconnects. Or is the current practice of whacking the traffic when it causes a problem, whether its from allocated or unallocated space sufficient? Personally, I think the current practice of whacking problem traffic from unallocated IP addresses seems sufficient. If people decide its enough of a problem that backbones must take the operational risk to change filters, then I think IANA must adopt a more predictable schedule. For example, IANA announces future allocations at each IETF meeting which will become allocated for use after the next IETF meeting to give backbones 3-4 months to schedule the change.
|