Blackholing: security considerations

[Ondrej Zajicek]

On Thu, Mar 06, 2014 at 10:25:20PM +0200, Alexander Shikov wrote:
> 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?

Hello

That is not currently possible, as BIRD processes routes independently.

Also note that you can filter again  [ 109.68.40.0/21, 109.68.40.0/21{32,32} ],
which would allow both 109.68.40.0/21 and 109.68.4X.X/32, but not intermediate
prefixes, but this does not help w.r.t. your main concern - a route from
another peer.

-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20140307/ebe743a5/attachment-0001.asc>