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

Thu Mar 1 22:31:04 UTC 2007

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.