Case Studies: Documented Routing Incidents

Author

K19G

Updated

October 31, 2026

Case Studies: Documented Routing Incidents

Analyzing historical routing incidents reveals how protocol vulnerabilities, operator errors, and intentional exploits manifest in real-world networks. These landmark case studies shaped the modern routing security landscape and demonstrate why specific defense layers were developed.

Pakistan Telecom YouTube Hijack (February 24, 2008)

The 2008 YouTube hijack remains the classic textbook demonstration of a subprefix origin hijack:

+---------------------------------------------------------------+
|                    The 2008 YouTube Hijack                    |
|                                                               |
|  [YouTube (AS36561)]                                          |
|  - Announces legitimate covering aggregate: 208.65.152.0/22   |
|                                                               |
|  [Pakistan Telecom (AS17557)]                                 |
|  - Government censorship order: block YouTube domestically    |
|  - Configured internal blackhole null route: 208.65.153.0/24  |
|  - Omitted export filter! Leaked /24 to PCCW Global (AS3491)  |
|                                                               |
|  [PCCW Global (AS3491)]                                       |
|  - Accepted announcement without customer prefix filtering    |
|  - Propagated /24 to global Tier-1 transit backbones          |
|                                                               |
|  [Global Outcome]                                             |
|  - 208.65.153.0/24 (LPM) won against YouTube's /22 globally   |
|  - YouTube went completely dark worldwide for nearly 2 hours  |
+---------------------------------------------------------------+
  1. Context: Following a domestic censorship order by the Pakistan Telecommunication Authority to block YouTube video clips, engineers at Pakistan Telecom (AS17557) configured an internal null route on an edge router for YouTube’s IP block: 208.65.153.0/24.
  2. The Mechanism: YouTube legitimately originated the covering /22 aggregate: 208.65.152.0/22. Pakistan Telecom originated the /24 subprefix. Crucially, Pakistan Telecom accidentally leaked this /24 advertisement to its international transit provider, PCCW Global (AS3491).
  3. The Failure: PCCW Global accepted the announcement without enforcing an inbound customer prefix-list, and propagated the /24 to its global transit peers.
  4. The Impact: Because /24 is a longer prefix than /22, Longest Prefix Match directed global Internet traffic for YouTube into Pakistan Telecom’s network, instantly saturating its international links and knocking YouTube completely offline globally for nearly two hours.
  5. Mitigation: YouTube engineers resolved the outage by disaggregating their space, announcing two matching /24 prefixes to compete, and broadcasting emergency out-of-band requests to PCCW Global to filter Pakistan Telecom’s session.

Safe Host / China Telecom Route Leak (June 6, 2019)

On June 6, 2019, a Swiss data center provider caused a massive European and international traffic disruption through a Customer-Provider Route Leak:

  1. The Mechanism: Safe Host (AS21217), a Swiss hosting company, received full Internet routing tables from its upstream providers. Due to a configuration error during maintenance, Safe Host re-announced approximately 70,000 global prefixes to China Telecom (AS4134).
  2. The Failure: China Telecom accepted the leaked routes and, because they were learned from a customer session, assigned them high preference and propagated them to other international transit networks.
  3. The Impact: Over 70,000 prefixes—including critical IP blocks belonging to European mobile operators (Swisscom, Bouygues Telecom) and major European cloud services—were detoured through China Telecom’s internal network in China. Massive packet loss, severe latency spikes, and complete connection drops lasted for over two hours.
  4. Root Cause: Complete absence of basic export filtering at Safe Host, combined with the lack of RFC 9234 Only to Customer (OTC) enforcement at China Telecom.

Cloudflare 1.1.1.1 Incident (June 27, 2024)

Even modern, highly protected Anycast DNS resolvers remain vulnerable to misrouting anomalies when upstream transit providers misbehave:

  1. The Incident: On June 27, 2024, a regional ISP in Asia accidentally originated 1.1.1.0/24—the primary IP address of Cloudflare’s public DNS service.
  2. The Defense in Action: Cloudflare had published a valid, exact-match ROA: (1.1.1.0/24, maxLength=24, Origin=AS13335).
  3. The Divergence:
    • Tier-1 and Tier-2 networks that had deployed RPKI Route Origin Validation immediately flagged the regional ISP’s announcement as Invalid and dropped it, keeping DNS reachability clean for their users.
    • However, networks and ISPs that had not deployed ROV accepted the illegitimate announcement, directing user DNS queries into a blackhole.
  4. Key Takeaway: ROV successfully protected adopters, but highlighted that incomplete global deployment leaves non-adopting networks exposed to disruptions.

3ve BGP Hijacking Campaign (2018)

In 2018, the US Department of Justice unsealed indictments against the operators of 3ve, a massive international cybercrime syndicate that stole tens of millions of dollars through fraudulent digital advertising:

  1. The Mechanism: The 3ve syndicate used compromised routing infrastructure and rogue BGP speakers to hijack hundreds of dormant, unannounced IP blocks (bogon and legacy address space) from legitimate corporate holders who were not actively using them.
  2. The Exploitation: The attackers registered fraudulent route objects in permissive third-party IRR databases (such as RADB) to convince transit providers to accept the routes. They then announced the hijacked blocks and used them to host thousands of fake websites and botnet servers, generating billions of fraudulent ad impressions.
  3. The Catalyst for RPKI: The 3ve campaign served as the wake-up call for the global advertising and financial industries, proving that dormant IP blocks could be weaponized indefinitely unless cryptographically protected by RPKI ROAs.

Comparative Analysis: What Changed, What Remained Vulnerable

Incident Year Attack / Fault Type Would RPKI ROV Prevent It? Modern Prevention Mechanism
Pakistan Telecom 2008 Subprefix Origin Hijack (/24 vs /22) YES (Dropped as Invalid) RPKI ROV + Minimal ROA (RFC 9319)
Safe Host 2019 Customer-Provider Route Leak NO (Origin was valid) RFC 9234 OTC + ASPA
Cloudflare 1.1.1.1 2024 Exact-Match Origin Hijack YES (For networks with ROV) Universal ROV enforcement
3ve Syndicate 2018 Dormant Prefix Hijacking via Fake IRR YES (If ROA published) RPKI ROAs + Authoritative IRR cleaning