On Saturday morning, 17 April 2021, I received a ping on Twitter from Doug Madory, Director of Internet Analysis at Kentik, highlighting a major Border Gateway Protocol (BGP) hijack event overnight. My weekend was sorted, but let’s dig into this incident and learn from the lesson.
Large BGP routing leak out of India this morning.— Doug Madory (@DougMadory) April 16, 2021
AS55410 mistakenly announced over 30,000 BGP prefixes causing a 13x spike in inbound traffic to their network according to @kentikinc netflow data.
(cc: @anurag_bhatia, @aftabsiddiqui, @jaredmauch) pic.twitter.com/PQ4iiTKD2Q
AS55410 belongs to Vodafone Idea Ltd. According to APNIC delegation records, this organization has the following address resources allocated to them:
AS134927 peers with AS55410, AS55644, and AS6453 (TataCom). It doesn’t have any downstream peers and originates the following routes:
AS133666 and AS134071 are not used at all, leaving AS55644 and AS55410 the main origin Autonomous Systems for Vodafone Idea Ltd.
AS55644 originates 109 routes and has peering relationships with the upstreams below. It also has 18 downstream peers (customers) according to the CIDR-Report.
AS55410 originates 824 routes and has peering relationships with the upstreams below. It has 155 downstream (232 according to RIPE Stats) peers as well. Out of those downstream peers only 22 peers have AS numbers (ASNs) registered outside India. Adding all of the announcements makes it 2,265 either originating or transiting from AS55410.
At around 13:48 UTC, AS55410 started originating routes that don’t belong to them.
Within a few minutes, AS55410 started originating 31,000+ routes (including their own) but all of them were prepended. A list of all affected routes is available here.
The prefixes belong to Google, Microsoft, Akamai, Cloudflare, Fastly, and many others. Even though AS55410 has multiple upstream peers, all these announcements were exiting via AS9498 (BHARTI Airtel Ltd.). For a searchable list of Indian networks, you can also check Anurag Bhatia’s blog post.
As mentioned in Doug Madory’s tweet, these mass announcements were stopped within a few minutes but some announcements were still making the rounds globally, such as 188.8.131.52/24 (GD MASS Network) announced by AS8972.
What caused the incident?
It’s hard to say that what caused this major incident. AS55410 may be trying some traffic shaping/load balancing or they were testing some BGP optimizer (I hope not).
Clearly, AS9498 should have blocked these announcements easily through AS filtering, knowing AS55410 should not, in any way, originate these prefixes. There should also be a prefix limit as well — when they have never originated that many prefixes, then why, all of a sudden, are they originating 31,000+? Other upstream peers didn’t propagate these erroneous announcements to the global routing table.
This was a route hijack; it means if you had a valid Route Origin Authorization (ROA) for any of these announcements then some of the large network operators must have stopped your announcements.
Around 80% of the hijacked routes had no ROAs (unknown), therefore, those routes must have propagated globally, whereas little more than 7,000 had valid ROAs, meaning anyone else originating those routes made them invalid and must have been filtered out by many network operators.
That’s why it’s key to create ROAs — as it protects your prefixes from such hijack attempts, even if most are unintentional.
It is extremely important that network operators implement effective route filtering based on verifiable information about which networks are legitimately authorized to originate which number resources (ASNs and IP prefixes). It is also important that network operators have established and well-advertised communication channels in order to quickly resolve issues when they happen.
MANRS is an industry-supported initiative that builds on well-established best practices by bringing together actions that can address the most common threats in the global routing system.
By being part of MANRS, more than 600 network operators, Internet Exchange Points, and cloud and content delivery network providers take concrete actions to contribute to the resilience and security of a critical part of the Internet infrastructure. The actions include route filtering, global validation of number resources, coordination, and anti-spoofing.
For more information on how to implement these actions and to join the MANRS initiative, visit the MANRS website.
Aftab Siddiqui is a MANRS Project Lead & Senior Manager, Internet Technology at the Internet Society.
This post originally appeared on the MANRS Blog.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.