The China Telecom BGP Hijack (2010)

On April 8, 2010, China Telecom (AS4134) announced approximately 50,000 IP prefixes belonging to networks it had no authority over. For roughly 18 minutes, traffic destined for the US Department of Defense, the Senate, NASA, the Department of Commerce, and dozens of Fortune 500 companies was rerouted through Chinese infrastructure. The incident remains one of the largest and most consequential BGP hijacks in internet history, and it exposed just how vulnerable the global routing system is to nation-state-level disruption.

What Happened on April 8, 2010

At approximately 15:50 UTC, a router within China Telecom's network began originating BGP announcements for roughly 50,000 prefixes that belonged to other networks around the world. These were not obscure or unused address blocks. They included prefixes assigned to:

• US military networks (.mil address space)
• US government agencies (.gov address space), including the Senate, NASA, NOAA, the FAA, and the Department of Commerce
• Major corporations including Dell, IBM, Microsoft, and Yahoo
• Networks in Australia, France, Germany, India, Japan, and dozens of other countries
• Tier 1 transit providers and backbone networks

The hijacked prefixes were propagated globally by China Telecom's upstream peers and transit providers. Because BGP routers accept announcements from their neighbors on trust, networks around the world updated their routing tables to send traffic for these prefixes toward AS4134 rather than the legitimate origins.

The event lasted approximately 18 minutes before the erroneous announcements were withdrawn and normal routing was restored.

The Scale of the Hijack

To understand why this incident was so alarming, consider its sheer scope. Previous high-profile BGP hijacks had typically involved a single prefix or a small handful of routes. The 2008 Pakistan Telecom/YouTube incident involved one prefix. The China Telecom event involved approximately 50,000 prefixes simultaneously, spanning networks across every populated continent.

According to the US-China Economic and Security Review Commission's 2010 annual report to Congress, China Telecom's AS4134 announced prefixes covering approximately 15% of the internet's routable address space during the incident. The affected prefixes included routes from at least 170 countries, though the heaviest concentration was in US address space.

The report documented specific categories of affected networks:

• US military — Networks operated by the Army, Navy, Air Force, Marine Corps, and the Department of Defense's Network Information Center (AS721)
• US government civilian — The Senate, NASA, the National Oceanic and Atmospheric Administration (NOAA), the Bureau of Industry and Security, the FAA, and multiple other agencies
• Intelligence community — Address space associated with intelligence-related functions, though the specifics remain classified
• Commercial — Dell, IBM, Microsoft (AS8075), Yahoo, and numerous Fortune 500 companies
• Allied governments — Networks belonging to government agencies in Australia, France, the UK, and other countries

How the Hijack Worked Technically

The mechanism behind the hijack was a straightforward exploitation of BGP's trust model. Here is how it unfolded, step by step:

Step 1: Prefix Origination

A router within China Telecom's autonomous system (AS4134) began originating BGP announcements for approximately 50,000 prefixes. In BGP terms, "originating" means the router advertised these prefixes as if AS4134 were the authoritative source — the network that legitimately owned those IP address blocks.

Step 2: Propagation via Peers and Transits

China Telecom is one of the largest ISPs in the world, with extensive peering relationships and transit connections to major international carriers. When AS4134 announced these prefixes, its peers and transit providers accepted the announcements and propagated them further. Each network that received the routes added its own ASN to the AS path and forwarded the announcements to its own peers.

Within minutes, the false routes had propagated across significant portions of the global routing table. Networks in the US, Europe, and Asia updated their forwarding tables to direct traffic for the hijacked prefixes toward China Telecom.

Step 3: Traffic Redirection

Once the hijacked routes were installed in routers worldwide, traffic that would normally flow directly between US networks — or between any two networks outside China — was instead routed through China Telecom's infrastructure. A user in Washington, DC, attempting to reach a DoD server in Virginia might have had their packets travel across the Pacific to China and (possibly) back.

Step 4: Withdrawal

After approximately 18 minutes, the erroneous announcements were withdrawn. BGP routers globally converged back to the legitimate routes over the following minutes. Because BGP convergence is not instantaneous, some traffic may have continued to take suboptimal paths for a short period after the withdrawal.

Why BGP Made This Possible

The fundamental vulnerability that enabled this hijack is BGP's lack of authentication. When BGP was designed in 1989, the internet was a small, collegial network of academic and government institutions. The protocol was built on the assumption that every network operator could be trusted to announce only the prefixes they legitimately controlled.

Three properties of BGP made this particular hijack effective:

• No origin verification — BGP has no built-in mechanism to check whether an AS is authorized to originate a given prefix. Any AS can announce any prefix, and its peers will accept it unless they have manually configured filters.
• Transitive trust — When a peer propagates a route, its own peers trust that propagation. The hijacked routes spread globally because each network along the chain accepted them from a trusted neighbor.
• Preference for specificity — BGP routers always prefer the most specific (longest) prefix match. If China Telecom announced more-specific prefixes than the legitimate origins, those more-specific routes would win at every router that received both.

In 2010, RPKI was still in its infancy. Almost no networks had deployed Route Origin Authorizations (ROAs) for their prefixes, and even fewer networks were performing Route Origin Validation (ROV) on incoming routes. There was essentially no automated mechanism to detect or prevent this kind of mass hijack in real time.

The Debate: Accident or Intentional?

The nature and intent of the incident remain contested. There are two primary interpretations:

The "Accidental Leak" Theory

China Telecom and some network engineers argued that the incident was a routing leak — an internal route table or BGP configuration was accidentally propagated to external peers. This kind of accident is not uncommon in BGP operations. Internal routing policies, traffic engineering configurations, or static route entries can be inadvertently redistributed into eBGP sessions due to misconfiguration or software bugs.

Proponents of this theory point out that:

• BGP misconfigurations happen routinely across the internet, sometimes affecting thousands of prefixes
• The incident lasted only 18 minutes, consistent with an operator noticing and correcting a mistake
• China Telecom is a massive network where configuration errors can have outsized impact
• There was no publicly demonstrated evidence that traffic was intercepted or tampered with

The "Intentional Hijack" Theory

The US-China Economic and Security Review Commission took a different view. Their 2010 report stated that China Telecom "ichanneled roughly 15 percent of the world's Internet traffic through Chinese servers for about 18 minutes." The report raised the possibility that the redirection could have been used to:

• Conduct surveillance — Inspect the contents of unencrypted traffic flowing through Chinese routers
• Perform traffic analysis — Even for encrypted traffic, metadata (source, destination, timing, volume) is visible to any network operator in the path
• Test capabilities — Demonstrate or validate the ability to reroute global traffic through Chinese infrastructure on command
• Map network dependencies — Observe which prefixes and networks generated traffic during the redirection window

Skeptics of the accidental theory note that 50,000 prefixes is an unusually large number for an accidental leak, and that the specific set of prefixes included a disproportionate share of sensitive US government and military address space.

The Technical Reality

From a purely technical standpoint, it is difficult to distinguish an intentional hijack from a large-scale accidental leak. Both look identical in BGP data: an unauthorized AS originating prefixes it does not own. The intent is unknowable from the protocol data alone. What is indisputable is that the traffic was rerouted, and that AS4134 did announce prefixes it had no authority to announce.

Security Implications

Regardless of intent, the incident demonstrated several alarming capabilities and vulnerabilities:

Unencrypted Traffic Was Fully Exposed

In 2010, a large fraction of internet traffic was still unencrypted HTTP. Any unencrypted traffic that was rerouted through China Telecom's infrastructure could have been read, copied, or modified by any system with access to those routers. Email, web traffic, file transfers, and DNS queries were all potentially visible.

Even Encrypted Traffic Leaks Metadata

Even encrypted traffic (HTTPS, VPN tunnels, SSH) reveals metadata to the networks carrying it: source and destination IP addresses, packet sizes, timing patterns, and connection durations. A state-level actor with access to traffic flowing through its routers could perform traffic analysis to map communication patterns between sensitive networks without needing to break encryption.

A Man-in-the-Middle Position

If the rerouted traffic was forwarded to its original destination (rather than blackholed), the hijacking network would occupy a classic man-in-the-middle position. For unencrypted protocols, this allows reading and modification. For encrypted protocols with weak certificate validation, it could enable interception. Even for properly encrypted traffic, the ability to inject delays, drop specific packets, or perform selective denial of service exists.

No Detection Mechanism

Most end users and even many network operators had no real-time indication that their traffic was being rerouted. BGP monitoring services like RIPE RIS and RouteViews recorded the anomalous announcements, but there was no automated alerting system that notified affected prefix holders in real time. The incident was largely identified through retrospective analysis of BGP data archives.

The US-China Economic and Security Review Commission Report

The US-China Economic and Security Review Commission (USCC) highlighted the incident in their 2010 Annual Report to Congress. The commission's analysis raised it as a case study in the vulnerability of critical US communications infrastructure to disruption by foreign actors. Key points from the report included:

• The incident "could have enabled surveillance of specific users or sites" and "could have disrupted data transactions"
• China Telecom has the ability to "ichannol" (reroute) traffic through its networks, and the 2010 event demonstrated this capability at scale
• The US government lacked adequate monitoring tools to detect such incidents in real time
• BGP's trust-based architecture represents a structural vulnerability that cannot be fixed through incremental patches

The report recommended that the US government invest in BGP security research and develop capabilities to detect and respond to routing anomalies affecting government networks.

China Telecom's Response

China Telecom denied any intentional wrongdoing and characterized the incident as a routing error. The company did not publish a detailed technical postmortem, which is common in BGP incidents — many network operators treat internal routing configurations as proprietary information and do not disclose the root cause of routing incidents publicly.

It is worth noting that AS4134 (CHINANET) is one of the largest autonomous systems in the world, serving hundreds of millions of users across China. Networks of this scale have complex internal routing configurations, and accidental leaks of internal routes into the global routing table, while serious, are a known failure mode in BGP operations.

This Was Not an Isolated Event

The 2010 incident was not the only time China Telecom's network was associated with routing anomalies. Researchers from the US Naval War College and Tel Aviv University published a paper in 2018 documenting systematic patterns of traffic interception by China Telecom over a period of years. The paper, "China's Maxim: Leave No Access Point Unexploited," documented multiple instances where traffic between North American networks was rerouted through China Telecom's points of presence in North America before being forwarded to China and back.

Some of the documented cases included:

• 2016 — Traffic between Canada and Korean government networks rerouted through China for approximately six months
• 2017 — Traffic to a large Anglo-American bank's Italian headquarters rerouted through China
• Multiple instances — US domestic traffic rerouted through China Telecom's US PoPs (in locations like Los Angeles and New York) into mainland China

These later incidents were more subtle than the 2010 event — involving fewer prefixes over longer durations — but they reinforced the concern that China Telecom's network was being used (intentionally or not) as a waypoint for traffic that had no logical reason to transit Chinese infrastructure.

Lessons for BGP Security

The China Telecom incident of 2010 became a landmark case study in BGP security. It drove several important developments in how the internet community thinks about and defends against routing hijacks:

1. RPKI Gained Urgency

RPKI (Resource Public Key Infrastructure) was already under development in 2010, but the China Telecom incident added urgency to its deployment. RPKI allows prefix holders to cryptographically sign Route Origin Authorizations (ROAs) that specify which autonomous system is authorized to announce their prefixes. Networks that perform Route Origin Validation (ROV) can then reject announcements from unauthorized origins.

If RPKI had been widely deployed in 2010, networks performing ROV would have rejected the hijacked routes because the ROAs for the affected prefixes would not have listed AS4134 as an authorized origin. Today, over 40% of global prefixes have valid ROAs, and major networks like Cloudflare, Google, and many Tier 1 providers enforce ROV.

2. BGP Monitoring Became Essential

The incident underscored the need for real-time BGP monitoring. Services like RIPE RIS, RouteViews, and commercial BGP monitoring platforms now provide alerts when anomalous route announcements are detected. Network operators can configure alerts for their own prefixes to detect hijacks within minutes.

A BGP looking glass is one of the simplest tools for checking whether your prefixes are being announced correctly. By querying a looking glass, you can verify the origin AS and AS path for any prefix and spot unauthorized announcements.

3. Prefix Filtering Practices Improved

The incident highlighted the importance of prefix filtering — the practice of configuring routers to only accept route announcements that are expected and verified. Internet Routing Registry (IRR) databases, which contain records of which ASes are authorized to announce which prefixes, saw increased adoption as operators built automated filter generation systems.

4. The Need for Path Validation

RPKI validates only the origin of a route. It cannot detect a hijack where the attacker includes the legitimate origin AS in a fabricated AS path. Emerging standards like ASPA (Autonomous System Provider Authorization) and BGPsec aim to provide path validation, ensuring that every hop in the AS path is authorized. These are still in early deployment.

Could It Happen Again?

A hijack of the exact same scale and impact would be more difficult today, but not impossible. Several factors have changed since 2010:

• RPKI adoption — Networks performing ROV would reject hijacked routes for prefixes that have valid ROAs. However, roughly 60% of prefixes still lack ROAs, and many networks do not yet enforce ROV.
• Encryption — Over 95% of web traffic now uses HTTPS, meaning that even if traffic is rerouted, the content is encrypted. However, TLS does not protect against traffic analysis, and certificate authority compromises or downgrade attacks remain theoretical risks.
• Monitoring — Real-time BGP monitoring means anomalous announcements would be detected within minutes and publicized immediately. The element of surprise is largely gone.
• Geopolitical awareness — Network operators, particularly those operating sensitive government and military networks, are far more attuned to the risks of BGP hijacking than they were in 2010.

That said, smaller-scale hijacks continue to occur. In 2022 and 2023, there were documented incidents of Russian networks announcing Ukrainian prefixes during the ongoing conflict, and cryptocurrency-related hijacks remain a persistent threat. BGP's trust-based architecture means that any network with upstream connectivity can announce any prefix — the defenses are improving, but the fundamental vulnerability persists.

Explore the Networks Involved

You can use the looking glass to examine the networks involved in the 2010 incident and see their current routing state:

• AS4134 — China Telecom (CHINANET), the AS that originated the hijacked announcements
• AS721 — US Department of Defense Network Information Center
• AS8075 — Microsoft, one of the affected commercial networks
• AS3356 — Lumen/Level 3, a major Tier 1 transit provider that would have propagated routes
• AS2914 — NTT, another major transit provider

Look up any of these ASNs to see their current prefixes, AS paths, RPKI status, and peering relationships. The routing data for these networks today reflects over a decade of security improvements since the 2010 incident — but the underlying protocol remains the same BGP that made the hijack possible.