Blackholing: security considerations

[Andy Linton]

How about using ROAs?

roa table roa_ 64496 {
        roa 192.0.2.0/24 max 24 as 64497;
}

and then:

filter bgp_in
{
    case roa_check(roa_112, net, bgp_path.first) {
        ROA_INVALID: reject "Blocked - ROA_INVALID for ", net, " ASN ",
bgp_path.first;
        ROA_UNKNOWN: reject "Blocked - ROA_UNKNOWN for ", net, " ASN ",
bgp_path.first;
        ROA_VALID:   accept;
        else:        reject "Blocked - ROA unknown reason";
    }
    ......
}


On Fri, Mar 7, 2014 at 9:25 AM, Alexander Shikov <a.shikov at dtel-ix.net>wrote:

> 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20140307/b6072a34/attachment-0001.html>