North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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

  • From: Barry Greene (bgreene)
  • Date: Sun Mar 04 10:52:57 2007
  • Authentication-results: sj-dkim-6; [email protected]; dkim=pass ( sig from cisco.com/sjdkim6002 verified; );
  • Dkim-signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1430; t=1173023176; x=1173887176; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; [email protected]; z=From:=20=22Barry=20Greene=20\(bgreene\)=22=20<[email protected]> |Subject:=20RE=3A=20Where=20are=20static=20bogon=20filters=20appropriate? =20was=3A=20=2096.2.0.0/16=20Bogons |Sender:=20; bh=alHBz4CVfonVpaSh3EABGMPa5WyhoYet4JlTuApHGLo=; b=Bdi3XMXwyL4Y+pOwCKdVcky937rXbdLxraMb2D5AxHerfPKMIAWqP+HS3EJ6mnMnPACccUAS j1/+8L4b0fdhojnx6Dlme12RolQX3rpE0qWXD3TIufrwQleLBCQBBv5T;

 

> 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.