Big route leak shows need for routing security
Yesterday saw another significant routing incident in the global BGP routing system, once again highlighting why it’s important for network operators to be implementing good routing security practices.
The following pictures should give you an understanding of what we’re going to be discussing:
Yes, a BGP route leak that was first reported by QRATOR Labs in their blogpost.
“A Brazilian AS 264462 belonging to “Comercial Conecte Sem Fio Ltda me” as it is stated in the whois record for this particular ASN, leaked massive 13046 network prefixes in a networking incident that lasted for 1 hour and 23 minutes, starting at 9.15 UTC and ending at 10.38″.
QRATOR Labs
Looking to find out what actually happened, we see that according to the LACNIC Whois records, AS264462 is registered to “Commercial Conecte Sem Fio Ltda me“. Google unfortunately doesn’t provide any other information about this company.
aut-num: AS264462
owner: Comercial Conecte Sem Fio Ltda me
responsible: walter jorge sampaio
owner-c: WAJSA3
routing-c: WAJSA3
abuse-c: WAJSA3
created: 20141112
changed: 20141112
inetnum: 132.255.52.0/22
inetnum: 2804:2010::/32
They only have an IPv4 /22 prefix and an IPv6 /32 prefix, and are only peering with AS4809 (China Telecom, CN) and AS53158 (Net Turbo Telecom, BR). Looking at the IX.BR Sao Paulo Participants list, it shows that AS264462 is also peering at that IX as well, which has almost 1940 participants.
Looking at the BGPDump from isolario.it, AS264462 only announces their 132.255.52.0/22 and its de-aggregates…
- 132.255.52.0/23 169.254.169.254 origin_as: 264462 as-path[7]: 64515 65534 20473 2914 3356 4809 264462
- 132.255.52.0/24 169.254.169.254 origin_as: 264462 as-path[7]: 64515 65534 20473 17819 4826 6939 264462
- 132.255.53.0/24 169.254.169.254 origin_as: 264462 as-path[7]: 64515 65534 20473 17819 4826 6939 264462
- 132.255.54.0/23 169.254.169.254 origin_as: 264462 as-path[8]: 64515 65534 20473 2914 6453 267056 53158 264462
- 132.255.54.0/24 169.254.169.254 origin_as: 264462 as-path[7]: 64515 65534 20473 17819 4826 6939 264462
- 132.255.55.0/24 169.254.169.254 origin_as: 264462 as-path[7]: 64515 65534 20473 17819 4826 6939 264462
However, on Tuesday, 21 July 2020 at 09:14 UTC, AS264462 started to leak prefixes…
- +|45.160.112.0/22|199036 20811 3356 4809 264462 267522 268400|82.94.230.130|i||||82.94.230.130 199036 41|1595322866|1
- +|45.179.242.0/24 45.179.243.0/24|199036 24679 3356 3356 3356 3356 3356 4809 264462 266154 269144|82.94.230.130|i|||3356:5 3356:22 3356:100 3356:123 3356:790 3356:800 3356:2190 4809:4134 23456:34043 24679:1050 24679:2001|82.94.230.130 199036 36|1595322866|1
- +|138.99.204.0/23 177.67.158.0/23 177.67.156.0/23 170.246.82.0/23 170.246.80.0/23 138.99.206.0/23|199036 24679 3356 3356 3356 3356 3356 4809 264462 52686|82.94.230.130|i|||3356:5 3356:22 3356:100 3356:123 3356:790 3356:800 3356:2190 4809:4134 23456:34043 24679:1050 24679:2001|82.94.230.130 199036 36|1595322866|1
AS264462 doesn’t announce any prefixes other than their own, and as they don’t have any downstream customers with their own ASNs visible on the Internet, then where are they are getting all these prefixes? If you look at AS267522, AS266154 and AS52686, all of them are peering at Sao Paulo IX so it seems AS264462 leaked the routes they were learning from their IX peerings to their upstream providers.
AS264462 have two IPv4 transits, AS53158 (Net Turbo Telecom, BR) and AS4809 (China Telecom Next Generation Carrier Network, CN). But as highlighted in purple above, only AS4809 accepted those announcements from AS264462 and redistributed them globally.
According to QRATOR labs, the announcement ended around 10:38 AM UTC. The RIPE Routing Information Service shows the following:
Type: A > announce Involving: 186.209.38.0/23 Short description: The new route 20205 3356 4809 264462 53158 has been announced Path:20205, 3356, 4809, 264462, 53158, Community: 3356:5,3356:22,3356:100,3356:123,3356:790,3356:800,3356:2190,4809:4134,23456:34043 Date and time: 2020-07-21 09:14:26 Collected by: 00-64.246.96.5
Type: A > reannounce Involving: 186.209.38.0/23 Short description: The route 14061 3356 6762 4809 264462 53158 has been announced again Path:14061, 3356, 6762, 4809, 264462, 53158, Community: 3356:2,3356:86,3356:501,3356:666,3356:2065,6762:1,6762:92,6762:15500,14061:402,14061:2000,14061:2005,14061:4000,14061:4004 Date and time: 2020-07-21 11:58:03 Collected by: 14-198.32.176.147
The withdrawal of the prefixes only started after 11:59 UTC, and the last erroneous announcement from AS264462 was made on Tuesday, 21 July 2020 12:07:10. So the whole incident lasted for a total of 2 hours, 52 minutes and 44 seconds. More than 13000 prefixes were impacted.
+|200.24.66.0/24|199036 50300 3257 3356 4809 264462 61768|82.94.230.130|i||||82.94.230.130 199036 100|1595333230|1
A route leak is where a network operator erroneously announces to an upstream provider that is has a route to a destination through another provider. This can cause Internet traffic to be sent to wrong place or not be delivered at all, or in some cases can be used for traffic reconnaissance purposes. It is therefore extremely important that network operators implement effective route filtering based on verifiable information about which networks are legitimately authorised to originate which number resources (AS numbers and IP prefixes). It is also important that network operators have established and well advertised communication channels in order to quickly resolve issues as and when they do happen.
Mutually Agreed Norms for Routing Security or MANRS is an industry-supported initiative that builds on well-established best practices by bringing together actions that can address most common threats in the global routing system. Network operators, Content Providers and Internet Exchange Points who join the initiative are taking collective responsibility for the resilience and security of a critical part of the Internet infrastructure by agreeing to implement and adhere to these actions that include route filtering, global validation of number resources, coordination and anti-spoofing.
More information on how to implement these actions and join the MANRS initiative is available on the MANRS website.
Leave a Comment