Blackholing: security considerations

[Alexander Shikov]

On Fri, Mar 07, 2014 at 10:43:28AM +1300, Andy Linton wrote:
> 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";
>     }
>     ......
> }
It will have the same effect like comparison against prefix list.
192.0.2.0/24 received from some peers may be valid from all of them
But /32 from 192.0.2.0/24 may be received from peer without 192.0.2.0/24 as best path.

 
> 
> 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/
> >

-- 
Alexander Shikov
Technical Staff, Digital Telecom IX
Tel.: +380 44 201 14 07
http://dtel-ix.net/