Re: Is it time to abandon bogon prefix filters?

["Steven M. Bellovin" <smb () cs columbia edu>]

On Fri, 15 Aug 2008 09:49:38 -0400 (EDT)
Sean Donelan <sean () donelan com> wrote:

> On Fri, 15 Aug 2008, Randy Bush wrote:
> > my read is that the 60% was an alleged 60% of attacks came from
> > *all* bogon space.  this now seems in the low single digit
> > percentge.  of that, the majority is from 1918 space.
>
> Although I've disagreed with Rob about the configuration of bogon
> filters, especially on unmanaged (or semi-managed) routers, it is
> important to remember attacks and bogus packets are not naturally
> occuring phenomenon. The attacker chooses the attack vector and
> target, usually based on effectiveness and vulnerability but often on
> ease for the attacker.
>
> Packet and especially source address hygiene can be very useful for
> highly managed equipement.  However, bogon filters have often become
> more a source of recurring security consultant maintenance revenue
> than effective packet controls.  Understanding the operational
> maintenance demands is also an important part of implementing good
> security controls.
>
> For unmanaged and semi-managed routers, I'd suggest strict out-bound 
> packet controls (i.e. be conservative in what you send) because you 
> already need to make operational updates when they change.  But
> consider using inbound controls that require less extensive recurring
> maintenance, e.g. only filtering martians (i.e. 0/8, 127/8,
> 255.255.255.255/32, etc) instead of updating bogons (i.e. changing
> reserved and unallocated) every few months.
Martians plus 1918 space, I'd say, though that requires knowing which
are border interfaces.

Other than that, I agree 100% -- bogon filters have little security
relevance for most sites.  Furthermore, as the allocated address space
increases, the percentage of actual bogon space decreases and the rate
of false positives -- packets that are rejected that shouldn't be --
will increase.  Security?  Remember that availability is a security
issue, too.


                --Steve Bellovin, http://www.cs.columbia.edu/~smb