Re: Blackholing: security considerations
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/32via 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!
Re: Blackholing: security considerations
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 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/32via 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/
Re: Blackholing: security considerations
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 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/32via 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/
>
Blackholing: security considerations
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/32via 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/
