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

Barry Greene (bgreene) bgreene at cisco.com
Sun Mar 4 15:46:02 UTC 2007


 

> http://www.completewhois.com/hijacked/files/203.27.251.0.txt
> 
> http://www.completewhois.com/hijacked/index.htm
> 
> 
> This can proof the opposite.
> 
> Malware comes from redirected allocated blocks, not from bogons.

I don't think this is proof. The haphazard way that BCP38 and ingress
prefix filtering of Bogon/DUSA make 'spoofing' from these Bogon/DUSA
blocks unprofitable to a miscreant and forces them to work too hard. 

What this data does demonstrate is that hijacking of valid prefixes has
not been mitigated. And, there is most likely an economic motivation to
use the hijacked prefixes. In other words, the miscreants can use the
technique over and over - not get caught - not work too hard - and make
money (the first three and most important principles of miscreants). 

This data points to another problem - where SPs are not putting ingress
prefix filters on their BGP speaking customers. That is another area
where you have a lot of operational entropy issues. OPEX is increased on
the building of the prefix provision tool, the maintenance of the
policy, synchronization of that policy with the peer ingress filters,
and customers calls required when ever the customer gets prefix updates.
Hence many (most) operators rather not do the prefix filters on their
customers (usually 2 to 4 lines of policy on a J & C router). For many,
the OPEX is just too high.




More information about the NANOG mailing list