Blackholing: security considerations

[Mikhail A. Grishin]

Hi Alexander,

Currently we
1) allow prefixes that exist in IRR as route object (exact match with 
109.68.40.0/21)

2) Also we allow 109.68.40.0/21+ in case:
  2.1) if that prefix contains our blackhole community
  2.2) AND if that prefix has size [25 .. 32]

About possibility that "109.68.40.0/21 is reachable via other peer, and 
we got new route" and so on...
For the years we not faces with any problems regarding this.

If there is more elegant solution with BIRD, also interesting to know.

Alexander Shikov wrote, 07.03.2014 0:25:
> 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!
>