A major BGP route leak by AS55410

By on 26 Apr 2021

Category: Tech matters

Tags: , , ,

Blog home

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.

AS55410 belongs to Vodafone Idea Ltd. According to APNIC delegation records, this organization has the following address resources allocated to them:

Figure 1 — Address resources allocated to AS55410.
Figure 1 — Address resources allocated to AS55410.

AS134927 peers with AS55410, AS55644, and AS6453 (TataCom). It doesn’t have any downstream peers and originates the following routes:

Figure 2 — AS134927 originates these routes.
Figure 2 — AS134927 originates these 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.

Figure 3 — AS55644 has peering relationships with these upstreams.
Figure 3 — AS55644 has peering relationships with these upstreams.

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.

Figure 4 — AS55410 has peering relationships with these upstreams.
Figure 4 — AS55410 has peering relationships with these upstreams.

At around 13:48 UTC, AS55410 started originating routes that don’t belong to them.

Figure 5 — Route dump, AS55410 originating routes which don’t belong to them.
Figure 5 — Route dump, AS55410 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 5.35.230.0/24 (GD MASS Network) announced by AS8972.

Figure 6 — Route dump, 5.35.230.0/24 announced by AS8972.
Figure 6 — Route dump, 5.35.230.0/24 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.

Looking at the data, the hijacked prefixes were from all across the globe but mostly from the US (according to ASN registration data using teamcymru whois).

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.

Figure 7 — ROA status showing roughly 80% of the hijacked routes had no ROAs.
Figure 7 — ROA status showing roughly 80% of the hijacked routes had no ROAs.

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.

Rate this article

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.

Leave a Reply

Your email address will not be published. Required fields are marked *

Top