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/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/
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@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/
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@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/
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!
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@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."
participants (4)
-
Alexander Shikov -
Andy Linton -
Mikhail A. Grishin -
Ondrej Zajicek