Why Rostelecom’s Route Hijack Highlights the Need for BGP Security

On April 1, 2020, at approximately 7:30 PM UTC, JSC Rostelecom perpetrated a large-scale BGP hijack involving more than 8,000 prefixes, including those belonging to Google, Facebook, Akamai, Cloudflare and Amazon. The hijacking occurred when Rostelecom began announcing more specific routes for these and other services, causing traffic to be diverted to its network, which was subsequently blackholed by the provider.

ThousandEyes observed many of the route changes and their subsequent impact on users, services, and other telecom providers. For example, Figure 1 shows a legitimate announcement by Cloudflare of its Anycast prefix 104.16.48.0/20.

Cloudflare Announcing 20 Prefix
Figure 1. Cloudflare announcing a /20 prefix

At 7:30 PM UTC, JSC Rostelecom briefly announced a more specific /21 route to Cloudflare’s services. The announcement was accepted by Level 3 and Hurricane Electric and propagated to other ISPs, such as GTT, who also accepted the route.

Rostelecom Revoking 20 Prefix
Figure 2. Rostelecom revoking a /21 prefix announced to its peers

For some users whose traffic passed through the involved ISPs, their traffic was diverted from Cloudflare towards Rostelecom’s network, where it was dropped.

Cloudflare Traffic Dropped Rostelecom
Figure 3. Traffic intended for Cloudflare is dropped at Rostelecom’s border

While the route was quickly withdrawn by Rostelecom, it caused significant traffic disruption. During the hijacking, ThousandEyes Internet Insights™ detected traffic terminating before reaching services, such as Cloudflare, whose routes had been hijacked.

Cloudflare Traffic Disrupted
Figure 4. Traffic intended for Cloudflare is disrupted

By 12:35 PM, all illegitimate routes were withdrawn, and traffic was flowing normally to affected services.

Root Cause and BGP Route Security

This hijacking incident does not appear to be malicious, as the illegitimate announcements were quickly revoked, and the nature of the announcements—for example, a /21 advertised for Cloudflare, who typically advertise a /20—suggest leaked routes created by a BGP optimizer as the root cause. However, the announcements alone would not have steered traffic to Rostelecom if some of its peers, specifically Level 3 and Hurricane Electric, had not accepted the routes and propagated them to their peers. Several ISPs that support RPKI, including Telia and NTT, did not accept the routes and continued to route traffic to the appropriate origin ASes, effectively limiting the scope of Rostelecom’s announcement errors.

A similar incident occurred in 2019 when DQE leaked BGP optimizer routes through one of its customers, which were then accepted and broadly propagated by Verizon. While BGP optimizer software was criticized at the time by Cloudflare and others, the leaked routes would not have had a significant impact if Verizon and other ISPs validated ROA (Route Origin Authorization) records. ROA records associate an IP block with an ASN, ensuring only announcements from an ASN authorized to originate a route are accepted.

In this hijacking incident, Telia, NTT and other RPKI-supporting ISPs were able to preserve healthy routing through their networks, while providers such as Level 3, Hurricane Electric and GTT were not. As RPKI adoption increases, the impact of BGP route security incidents, either accidental or malicious, will likely diminish. In the meantime, visibility into the integrity of routing to one’s services is critical to ensuring both internal and customer security.

Read the Internet Outages Survival Guide to understand the common causes of Internet outages and how to troubleshoot them effectively.

Subscribe to the Internet and Cloud Intelligence Blog!
Subscribe
Back to ThousandEyes Blog