Is it time to abandon bogon prefix filters?

Thu Aug 7 22:16:21 UTC 2008

On Aug 7, 2008, at 5:35 PM, Robert E. Seastrom wrote:
> Randy Bush <randy at psg.com> writes:
>
>>>> How much does it help to filter the bogons? In one study  
>>>> conducted by
>>>> Rob Thomas of a frequently attacked site, fully 60% of the naughty
>>>> packets were obvious bogons (e.g. 127.1.2.3, 0.5.4.3, etc.)
>>>
>>> Stated another way, you can get 60% success on bogon filtering by
>>> ignoring the free pool
>>
>> if 127.1.2.3 and 0.5.4.3 are in the free pool, we have a few more / 
>> 8s in
>> the bank then we thought, eh? :)
>
> I guess I didn't really word that clearly.
>
> My point was that by not including the free pool in your candidates
> for filtering (i.e., only filtering out packets from addresses that
> will never be allocated or are permanently reserved such as 1918
> space), you're only sacrificing 40% of your likely hits...  and that
> number is going down over time.  Why not just cut to the chase and
> make a filter that will never go stale, take any possible lumps on the
> bogus packet announcement side, and collect handsomely on the
> operational side?

I guess I parsed that differently than you did.  When he said "fully  
60% of the naughty packets were obvious bogons", I read that as  
meaning 60% of all bad packets (bogon-sourced or otherwise) were from  
bogon space.

If my interpretation is correct, you cannot tell anything about which  
% was from permanently bad space vs. unallocated space.

Rob T., could you clarify for us please?

Also, filtering bogons has the same utility / dangers of MD5.  Many  
people think MD5 is a "good thing", even though the amount of downtime  
caused by it is (at least) several orders of magnitude larger than the  
amount of downtime caused by successful RST attacks.  I think the  
danger outweighs the benefit.  If you are arguing the same thing here,  
that's fine with me.  But let's find out what the danger is and make  
the decision.  Oh, and then everyone should take their own advice and  
de-configure MD5. :-)

-- 
TTFN,
patrick