The Google Nigeria BGP Leak (2018)

On November 12, 2018, at approximately 21:12 UTC, internet traffic destined for Google (AS15169) began taking a bizarre detour. Instead of flowing directly to Google's data centers, packets bound for Google Search, Google Cloud Platform, G Suite, and other Google services were routed from users around the world through Lagos, Nigeria, then onward through mainland China and Russia before either reaching Google or being dropped entirely. The disruption lasted 74 minutes, affected users across multiple continents, and reignited a longstanding debate about the fragility of BGP and whether state-level adversaries could exploit it for surveillance.

The root cause was not a sophisticated cyberattack. It was a configuration error at MainOne Cable Company, a Nigerian ISP, during routine peering setup with a local provider. But the consequences rippled across the global routing table, offering a textbook case study in how a single misconfigured router in one country can hijack traffic for one of the world's largest networks.

The Players

Understanding this incident requires knowing the networks involved and their relationships:

• Google (AS15169) -- the victim. Google operates one of the largest and most well-connected networks on the internet, with direct peering at hundreds of Internet Exchange Points and private interconnections with major ISPs worldwide.
• MainOne Cable Company (AS37282) -- the source of the leak. MainOne is a major West African ISP and submarine cable operator headquartered in Lagos, Nigeria. They operate the MainOne submarine cable connecting West Africa to Europe.
• China Telecom (AS4809) -- a transit provider that propagated the leaked routes. China Telecom is one of China's state-owned telecommunications carriers and operates a global backbone network.
• TransTelecom (AS20485) -- a Russian transit provider that also propagated the leaked routes. TransTelecom operates Russia's railway telecommunications network and provides international transit.

What Happened: A Timeline

The incident began when MainOne was configuring a new BGP peering session with a local Nigerian ISP. During this process, MainOne's routers began announcing Google's IP prefixes as if they were MainOne's own. This is known as a BGP route leak -- MainOne was not the legitimate origin for these prefixes, but because BGP lacks built-in authentication of route announcements, neighboring networks accepted them.

The timeline unfolded as follows:

• ~21:12 UTC -- MainOne's routers begin leaking more-specific Google prefixes to their upstream transit providers. Because the leaked routes were more specific (longer prefix length) than Google's legitimate announcements, they were preferred by BGP's longest-prefix-match rule.
• ~21:13 UTC -- China Telecom (AS4809), acting as a transit provider for MainOne, accepts the leaked routes and propagates them to its own peers and transit customers. The routes begin spreading across China Telecom's global network.
• ~21:14 UTC -- TransTelecom (AS20485) in Russia receives and further propagates the leaked routes. At this point, the leak has escaped the African continent entirely and is spreading through major international transit networks.
• ~21:15-21:20 UTC -- Networks across Europe, Asia, and parts of North America begin routing Google-bound traffic toward MainOne via China Telecom. Users experience severe packet loss, connection timeouts, and complete inability to reach Google services.
• ~22:26 UTC -- The leaked routes are withdrawn. Normal routing resumes. Total disruption: approximately 74 minutes.

The Technical Mechanism: More-Specific Prefix Hijacking

The key technical detail that made this leak so damaging was the use of more-specific prefixes. BGP routers always prefer the longest (most specific) prefix match when making forwarding decisions. This is how the longest-prefix-match rule works:

Suppose Google legitimately announces 216.58.192.0/19. If MainOne announces 216.58.192.0/20 and 216.58.208.0/20 -- two more-specific prefixes that together cover the same address space -- routers receiving both the legitimate /19 and the leaked /20s will prefer the /20s because they are more specific. The legitimate route is effectively overridden, even though Google's announcement is still present in the routing table.

This is the same mechanism behind many of the most damaging BGP hijacks in history. The Pakistan-YouTube incident of 2008 used the same technique: Pakistan Telecom announced a more-specific prefix for YouTube's IP space, and the announcement leaked globally.

The Route Propagation Path

Once MainOne leaked the routes, they did not stay in Nigeria. The propagation path reveals how transit relationships can amplify a local misconfiguration into a global incident:

1. MainOne (AS37282) to China Telecom (AS4809) -- MainOne had a transit relationship with China Telecom. The leaked routes propagated upstream from Lagos to China Telecom's backbone. China Telecom should have filtered these routes, since MainOne had no authority to originate Google's prefixes, but no filters were in place.
2. China Telecom (AS4809) to TransTelecom (AS20485) -- China Telecom further propagated the routes to TransTelecom in Russia, another transit partner. Again, no route filtering prevented the leak from spreading.
3. TransTelecom to the global table -- From TransTelecom, the leaked routes spread to other networks worldwide, attracting Google traffic from across Europe and Asia.

The AS paths observed in the global routing table during the incident looked something like this:

... 20485 4809 37282 15169    (via TransTelecom, China Telecom, MainOne)

Compare this to normal Google routes, which might look like:

... 2914 15169                (via NTT directly to Google)

The hijacked path was longer and passed through networks that had no business carrying Google's traffic. Users whose ISPs selected the leaked route experienced their packets traveling from their local ISP to TransTelecom in Russia, then to China Telecom in China, then to MainOne in Nigeria, before either being forwarded to Google (with massive added latency) or being dropped because MainOne could not actually deliver the traffic to Google's network.

Impact on Google Services

The impact was significant, though not uniform across the globe. Services affected included:

• Google Search -- Users in affected regions could not load search results or experienced extreme slowness.
• Google Cloud Platform (GCP) -- Enterprise customers running workloads on GCP experienced connectivity issues. Spotify, which relied on Google Cloud for backend services, reported degraded performance.
• G Suite (now Google Workspace) -- Gmail, Google Drive, Google Docs, and other productivity tools were disrupted for enterprise users.
• YouTube -- Video streaming was affected in regions where traffic was rerouted.

The severity varied by location and ISP. Networks that had direct peering with Google or used transit providers that did not accept the leaked routes were unaffected. Networks that relied on transit paths through China Telecom or TransTelecom bore the brunt of the disruption.

Google's internal monitoring detected the anomaly quickly, but because the problem was in the global routing table -- not in Google's own network -- there was limited action Google could take unilaterally. They had to wait for MainOne to correct the misconfiguration and for the corrected routes to propagate.

Why the Leak Spread: The Route Filtering Failure

The most important lesson from this incident is not that MainOne made a mistake -- configuration errors happen in every network. The critical failure was the lack of route filtering at multiple points in the chain.

Best practices for BGP route filtering dictate that transit providers should validate the routes they accept from their customers:

• Prefix filtering -- A transit provider should maintain a list of prefixes that each customer is authorized to announce and reject anything else. MainOne's transit providers should have known that MainOne was not authorized to announce Google's prefixes.
• AS path filtering -- Transit providers can filter routes based on the AS path, rejecting routes where the origin AS does not match the expected originator for a given prefix.
• IRR-based filtering -- Internet Routing Registry databases (like RIPE's IRR, ARIN's WHOIS, or RADb) contain records of which ASes are authorized to announce which prefixes. Automated tools can generate prefix filter lists from IRR data.
• RPKI Route Origin Validation -- If China Telecom and TransTelecom had been performing RPKI validation, the leaked routes would have been flagged as RPKI-invalid (since Google's ROAs authorize only AS15169 to originate those prefixes) and could have been rejected or deprioritized.

In this case, none of these filtering mechanisms were in place -- or if they were, they were not enforced strictly enough. China Telecom, in particular, has been repeatedly cited by researchers for propagating route leaks. A 2018 paper by researchers at the U.S. Naval War College and Tel Aviv University documented multiple incidents where China Telecom's network carried traffic that should never have transited through China.

The China Question: Accident or Espionage?

The involvement of China Telecom in propagating the leaked routes sparked immediate speculation about whether the interception was intentional. Security researchers and government officials raised several concerning points:

• China Telecom's history -- This was not the first time China Telecom had been implicated in suspicious route propagation. In April 2010, China Telecom announced approximately 50,000 prefixes belonging to U.S. networks for about 18 minutes, briefly rerouting traffic for the U.S. Senate, the Department of Defense, NASA, and other government agencies through China. The U.S.-China Economic and Security Review Commission documented this incident in its annual report to Congress.
• Surveillance capability -- When traffic transits through a country's network infrastructure, that country's intelligence agencies have the technical capability to inspect, copy, or modify the traffic. While HTTPS and TLS encryption protect the content of most traffic, metadata (source and destination IPs, traffic volume, timing patterns) is visible.
• Plausible deniability -- Route leaks provide perfect cover for traffic interception. Because configuration errors are common and because BGP offers no built-in authentication, it is extremely difficult to prove that a given route leak was intentional versus accidental.

Google stated that the incident was the result of an accidental leak by MainOne, and MainOne acknowledged the configuration error. There is no public evidence that the leak was deliberately orchestrated. However, the incident demonstrated that even accidental leaks can route sensitive traffic through adversary networks, and that the lack of route filtering makes it impossible to distinguish between an accident and an attack.

How RPKI Would Have Helped

RPKI (Resource Public Key Infrastructure) is the most direct defense against this type of incident. Google publishes Route Origin Authorizations (ROAs) for its prefixes, cryptographically asserting that only AS15169 is authorized to originate routes for Google's IP space.

If China Telecom and TransTelecom had been performing RPKI Route Origin Validation (ROV), the leaked routes would have been evaluated as follows:

• The leaked routes originated from AS37282 (MainOne).
• Google's ROAs specify that only AS15169 may originate these prefixes.
• Origin AS37282 does not match the ROA -- the route is RPKI Invalid.
• Networks performing ROV would reject or deprioritize the invalid route, falling back to Google's legitimate announcement.

In 2018, RPKI adoption was still in its early stages. Today, adoption is significantly higher -- over 40% of global prefixes have valid ROAs, and many major transit networks perform ROV. But adoption is still not universal, and incidents like this one are a primary motivation for pushing broader RPKI deployment.

Aftermath and Industry Response

The incident prompted several responses from the networking community:

• MainOne acknowledged the error and stated they had corrected their BGP configuration. They attributed the leak to a misconfiguration during a routine peering setup.
• Google confirmed the disruption and stated their monitoring systems detected the issue quickly. Google has been a strong advocate for RPKI adoption and publishes ROAs for its address space.
• MANRS (Mutually Agreed Norms for Routing Security) -- The Internet Society's initiative for routing security saw increased interest following this incident. MANRS promotes four key actions: filtering, anti-spoofing, coordination, and global validation.
• Renewed calls for RPKI deployment -- The incident became a frequently cited example in arguments for universal RPKI adoption. If all major transit networks performed ROV, this class of incident would be largely mitigated.

Lessons for Network Operators

The Google-MainOne incident provides several concrete lessons for network operators at every tier:

For Customer-Facing Transit Providers

Always maintain strict prefix filters on customer BGP sessions. Use IRR data and RPKI ROAs to build and automatically update these filters. Never accept more prefixes from a customer than they are authorized to announce. Automated tools like bgpq4 can generate prefix lists from IRR data, and RPKI-based filtering adds a cryptographic layer of verification.

For Networks Announcing Routes

Publish ROAs for all your prefixes via RPKI. Set appropriate maximum prefix lengths in your ROAs to prevent more-specific hijacks. Monitor external looking glasses and route collectors (like RIPE RIS and RouteViews) for unauthorized announcements of your prefixes. Services like BGPStream and Cloudflare Radar provide real-time alerts when anomalous routes are detected.

For Everyone

Implement the MANRS recommendations. Test your BGP configurations in a lab environment before deploying them in production. Ensure that changes to peering sessions do not inadvertently leak the full routing table or specific prefixes from other peers.

The Bigger Picture: BGP's Trust Problem

The Google-MainOne-China Telecom incident is one entry in a long list of BGP routing incidents that have disrupted the internet. The fundamental issue is that BGP was designed in an era of implicit trust. When the protocol was specified in 1989, the internet consisted of a small number of cooperating academic and government networks. The idea that a network might announce prefixes it didn't own -- whether through malice or error -- was not a primary design concern.

Three decades later, the internet consists of over 75,000 autonomous systems operated by organizations with vastly different levels of technical competence and vastly different motivations. The trust model that worked for a few hundred networks breaks down at this scale.

RPKI addresses the origin validation problem -- verifying that the AS originating a route is authorized to do so. But it does not address path validation -- verifying that the AS path in a BGP announcement is legitimate. Work on BGPsec (full path validation) and ASPA (Autonomous System Provider Authorization, which validates provider-customer relationships in the path) continues, but deployment remains limited.

Until these technologies achieve universal adoption, the internet remains vulnerable to the same class of incident that disrupted Google in November 2018. A single misconfigured router in any country can, if the right transit relationships exist and the right filters are absent, redirect traffic for any network on the internet.

Explore the Networks Involved

You can use the looking glass to explore the networks involved in this incident and see their current BGP state:

• AS15169 -- Google's autonomous system: see all of Google's announced prefixes and peering
• AS37282 -- MainOne Cable Company: the Nigerian ISP that originated the leak
• AS4809 -- China Telecom: the transit provider that propagated the leaked routes
• AS20485 -- TransTelecom Russia: further propagated the leak globally
• 8.8.8.8 -- Google's public DNS: check the current BGP route and RPKI status