Blackholing: security considerations

[Alexander Shikov]

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/