From: Sean Donelan (no email)
Date: Thu Mar 01 2007 - 17:31:04 EST
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.
|
|
|