Blackholing: security considerations

Alexander Shikov a.shikov at dtel-ix.net
Thu Mar 6 21:25:20 CET 2014


Hi All,

As usually IXPs do, we also perform route filtering with prefix lists.
In prefix lists we include only those prefixes which have corresponding
"route" objects in RADB/RIPE. We don't accept by default longer prefixes,
i.e. in prefix list we include, for example, 10.0.0.0/21 but not 
10.0.0.0/21+.

With the purposes of blackholing sometimes there is need to accept 
more-specific prefixes, mostly /32, from BGP peers. The easiest way
is just to accept /32 in filter. But the main problem is that any 
peer can announce /32 route to any network, even to unreachable one.
Thus there is need to additionally check /32 routes.

For the first look, we may include longer prefixes to prefix list, and
then check incoming /32 prefix against it. Result will look like:

bird> show route protocol ITCONS
109.68.40.20/32    via 193.25.181.253 on vlan777 [ITCONS 2014-03-06 22:02:42 from 193.25.180.17] * (100) [AS25372i]
109.68.40.0/21     via 193.25.180.17 on vlan777 [ITCONS 2014-03-06 21:45:24] * (100) [AS25372i]

i.e. filtering against [ 109.68.40.0/21+ ].

Now let's assume that 109.68.40.0/21 is reachable via other peer, and we got 
new route, and it is better due to as-path length, and new peer does not want to 
blackhole 109.68.40.20. Then "109.68.40.0/21 via 193.25.180.17" will become 
inactive, but "109.68.40.20/32 via 193.25.181.253 from 193.25.180.17" will
stay best, and new peer will lose traffic to 109.68.40.20.

Thus, it'd be reasonable to compare received /32 against routing table, and
accept it only if there is active less-specific route from same peer.
Personally I was not able to find solution for bird. Now I'm wondering
how do other IXPs perform such filtering?

Any ideas or thoughts are kindly appreciated! Thanks in advance!

-- 
Alexander Shikov
Technical Staff, Digital Telecom IX
http://dtel-ix.net/



More information about the Bird-users mailing list