The Border Gateway Protocol is the routing protocol that makes the internet work. It's how autonomous systems - the networks operated by ISPs, cloud providers, universities, and governments - tell each other which IP address ranges they can reach. BGP is also, famously, held together by trust. A network that announces it can reach an address range is taken at its word, and traffic is routed to it accordingly. This design assumption - that participants in the global routing system are honest - has produced a category of attacks with no clean fix: BGP hijacking.

How BGP Works

Every organization connected to the internet has an Autonomous System Number (ASN) and a set of IP prefixes they're authorized to announce. When your ISP's router receives a packet for, say, 8.8.8.8 (Google's DNS), it looks up the best path to that address by checking the BGP routing table - a list of announcements from neighboring networks saying which prefixes they can reach. The router picks the best path (usually the most specific prefix, shortest AS path) and forwards the packet.

The problem is that nothing verifies an announcement is legitimate. If a network announces it can reach 8.8.8.0/24, routers that hear the announcement will start sending Google DNS traffic to that network instead. Some networks filter announcements from neighbors based on known good prefixes (this is called a BGP filter or route filter), but many don't, and the global coverage of filtering is incomplete.

[TECHNICAL NOTE]
BGP was designed in 1989 by Yakov Rekhter and Kirk Lougheed over lunch, sketched on "three napkins." The original RFC explicitly noted it was not designed for security - it was designed to make routing work in a cooperative internet. The same fundamental design is still in production today, connecting over 75,000 autonomous systems.

China Telecom 2010: Routing the World's Internet Through China

On April 8, 2010, China Telecom advertised 37,000 IP prefixes belonging to US government agencies, military contractors, and major internet companies - including the US Senate, US Army, Navy, Marine Corps, Department of Defense, and commercial providers like IBM and Microsoft. For 18 minutes, traffic destined for these addresses was routed through China Telecom's infrastructure.

China Telecom attributed the incident to a "mistake" by a smaller Chinese ISP whose announcement China Telecom accepted and propagated. The US-China Economic and Security Review Commission documented the incident in a 2010 report, noting that while the event was difficult to distinguish from an accidental misconfiguration, the potential for traffic interception was real. Encrypted traffic in transit cannot be decrypted without the key, but metadata - source, destination, timing - can be logged. TLS session initiation involves key exchange that, if recorded, could be useful for later cryptanalysis if the keys are ever obtained.

This incident was not the first or last BGP hijack attributed to China Telecom. Similar events were documented in 2019 (routing European traffic through China), 2020, and multiple times since.

The Pakistan Telecom / YouTube Outage (2008)

On February 24, 2008, Pakistan Telecom - attempting to comply with a government order to block YouTube within Pakistan - announced a more specific prefix for YouTube's IP ranges (208.65.153.0/24 instead of /22). The announcement escaped Pakistan Telecom's upstream provider (PCCW, a Hong Kong ISP) and propagated globally. Within minutes, YouTube traffic from much of the world was routing to Pakistan Telecom, which dropped it. YouTube was unreachable for approximately two hours.

This is the canonical accidental hijack: a misconfiguration intended to cause a localized block became a global outage because the upstream provider did not filter what it accepted and propagated. The fix required manual intervention by YouTube's network team, Pakistan Telecom, and PCCW, coordinated in real time.

[WARNING]
BGP hijacking can be either accidental (misconfiguration) or intentional (malicious route announcement). The technical mechanism is identical. Determining intent requires context: who announced the prefix, for how long, and what happened to the traffic. Intentional hijacks can be designed to look like accidents.

Cryptocurrency Theft via BGP (2018)

In April 2018, attackers hijacked Amazon Web Services' Route 53 DNS resolver IP range (205.251.196.0/24) by announcing it from AS10297, a network in Columbus, Ohio that had no legitimate claim to those addresses. For approximately two hours, DNS queries from some networks went to attacker-controlled servers instead of Amazon's infrastructure.

The attackers used this to intercept DNS queries for MyEtherWallet.com, a popular Ethereum wallet interface. Users who typed myetherwallet.com were sent to a phishing site with a fake SSL certificate (from a free certificate authority). The site collected private keys and drained wallets. Approximately $17 million was stolen in the window before the hijack was corrected.

The attack demonstrated that BGP hijacking could be weaponized for direct financial theft with relatively modest technical requirements. The specific prefix hijacked, the timing (early morning, minimizing observer coverage), and the immediate monetization suggest careful planning.

RPKI: The Technical Fix That's Deployed Partially

The internet routing community has a technical solution to BGP hijacking: Resource Public Key Infrastructure (RPKI). RPKI allows IP address block holders to cryptographically sign route origin authorizations (ROAs) - statements that say "AS X is authorized to announce prefix Y." Routers that implement RPKI validation can reject announcements that contradict published ROAs.

RPKI was standardized by IETF in 2012. Adoption has been gradual and uneven. As of 2024, roughly 40-50% of global internet prefixes have published ROAs, and a smaller percentage of networks actually perform RPKI validation before accepting routes. Major cloud providers and large ISPs have deployed RPKI; many smaller networks and internet exchanges have not.

The deployment gap is a classic coordination problem. RPKI validation protects you from sending traffic to hijacked networks; it doesn't protect your prefixes from being hijacked. To protect your own prefixes, you need to publish ROAs, but your traffic is only protected if the networks in the path are validating. Neither alone is sufficient; both together is.

BGPsec and Partial Fixes

RPKI validates route origins (which AS is allowed to originate a prefix) but not the path (the sequence of ASes the route passes through). Path manipulation - where an attacker injects their AS into the BGP path to intercept or manipulate traffic mid-path - requires BGPsec, which adds cryptographic signatures to path attributes. BGPsec is specified in RFC 8205 but has seen minimal deployment due to performance overhead and the coordination requirements.

Practical BGP security currently relies on a combination of: RPKI with ROAs (partial global coverage), IRR (Internet Routing Registry) filters maintained by network operators, bilateral agreements between peering networks, and anomaly detection tools that alert on suspicious route announcements. None of these individually is sufficient; together they reduce but do not eliminate the attack surface.

Intentional State-Level Hijacks

Beyond the documented accidental and financially-motivated hijacks, BGP manipulation is a credible state intelligence technique. The capability to route internet traffic through your own infrastructure gives you traffic metadata, TLS handshake data, and any unencrypted traffic that passes through. For bulk collection purposes - the kind of intelligence collection revealed in the Snowden documents - this capability is significant.

Attribution of intentional hijacks is difficult because the technical event looks identical to accidental misconfiguration. The China Telecom incidents have the highest profile, but any network with sufficient upstream reach could accomplish similar routing manipulation. State-level actors with presence in major internet exchange points or large transit networks have structural positions that make prefix hijacking difficult to distinguish from normal routing churn.

The internet's routing system was built on the assumption that participants want packets to reach their destinations. That assumption is correct for most participants most of the time. But the small percentage of the time where it's wrong - accidents, financial fraud, intelligence collection - is sufficient to make BGP manipulation a persistent and underappreciated threat to internet infrastructure.