Is it time to abandon bogon prefix filters?
Patrick W. Gilmore
patrick at ianai.net
Thu Aug 7 17:16:21 CDT 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
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. :-)
More information about the NANOG