Case Study 1: BGP Hijacking — Pakistan/YouTube and China Telecom Route Leaks

Part I: The Protocol That Runs on Trust

What Is BGP?

The Border Gateway Protocol (BGP) is the routing protocol that holds the internet together. While most users interact with the internet through web browsers, email clients, and apps, all of that traffic is routed between networks using BGP. Every internet service provider, every cloud provider, every major enterprise, and every content delivery network uses BGP to announce which IP address ranges they are responsible for and to learn how to reach IP address ranges managed by others.

BGP is often called the "postal service" of the internet. Just as the postal service routes letters based on addresses and ZIP codes, BGP routes internet traffic based on IP address prefixes. And just as a postal worker trusts that the address on a letter is valid, BGP routers trust that the route announcements they receive from their peers are legitimate.

This trust is the fundamental problem. BGP was designed in 1989 (BGP-4, the current version, was standardized in 1995) during an era when the internet was a small, collegial network of universities and research institutions. The designers knew each other, trusted each other, and saw no need for authentication or verification of route announcements. There were no mechanisms to prevent a network from announcing routes it had no right to announce, and no mechanisms for other networks to verify that an announcement was legitimate.

Three decades later, BGP still works the same way. The internet has grown from a few hundred networks to over 70,000 autonomous systems (ASes), but the trust model has not changed. Any AS can announce any route, and other ASes will accept and propagate it. This design flaw has enabled some of the most dramatic and consequential internet outages in history.

Part II: The Pakistan/YouTube Hijack (2008)

The Incident

On February 24, 2008, the Pakistan Telecommunication Authority (PTA) ordered Pakistan's internet service providers to block YouTube within Pakistan. The reasons were political: the Pakistani government wanted to prevent citizens from accessing videos that it deemed blasphemous.

Pakistan Telecom (AS17557) attempted to comply with the government's order by creating a BGP route for YouTube's IP prefix (208.65.153.0/24) that pointed to a null route — essentially a digital black hole. Any traffic destined for YouTube's IP addresses that reached Pakistan Telecom would be dropped.

However, Pakistan Telecom made a critical error: the route was not contained within Pakistan's borders. Instead of advertising the null route only to its own internal network, Pakistan Telecom's BGP routers leaked the announcement to PCCW, Pakistan Telecom's upstream internet provider. PCCW, following standard BGP behavior, accepted the announcement and propagated it to the global internet.

Why the Hijack Worked

The hijack succeeded because of a fundamental BGP principle: more specific routes win. YouTube's IP addresses were part of a larger prefix (208.65.152.0/22, a /22 block) announced by YouTube's actual network. Pakistan Telecom announced a more specific prefix (208.65.153.0/24, a /24 block within the /22). Because BGP routers prefer more specific (longer prefix) routes, routers around the world began forwarding YouTube traffic to Pakistan Telecom instead of to YouTube.

Within minutes, YouTube was effectively offline for a significant portion of the internet. Users in Asia, the Middle East, and parts of Europe and Africa found that YouTube was unreachable. The outage lasted approximately two hours before YouTube's engineers, working with upstream providers, were able to announce even more specific routes (/25 blocks) to reclaim their traffic.

The Response

The incident triggered immediate alarm in the internet engineering community. RIPE NCC (the Regional Internet Registry for Europe, the Middle East, and parts of Central Asia) published a detailed analysis of the hijack. The incident became a canonical example of BGP's vulnerability and was cited in numerous academic papers, conference presentations, and policy discussions.

YouTube and its parent company Google implemented additional protective measures, including more specific route announcements and monitoring for unauthorized announcements of their prefixes.

Part III: China Telecom Route Leaks

Pattern of Incidents

While the Pakistan/YouTube hijack was a single, dramatic incident, China Telecom has been associated with multiple BGP route anomalies over a longer period, raising more complex questions about intent and attribution.

April 2010: The 18-Minute Hijack. On April 8, 2010, China Telecom (AS4134 and AS4837) announced routes for approximately 37,000 IP prefixes belonging to networks in the United States, South Korea, Japan, and other countries. For approximately 18 minutes, traffic destined for these networks was routed through China Telecom. The affected prefixes included IP address blocks belonging to the U.S. military, the Department of Defense, the Senate, NASA, the Department of Commerce, and numerous Fortune 500 companies.

The incident was documented by the U.S.-China Economic and Security Review Commission, which noted that the diversion could have enabled traffic inspection, interception, or manipulation during the 18-minute window.

2018-2019: Persistent Route Leaks. Research by Oracle's Internet Intelligence team and the U.S. Naval War College documented persistent BGP anomalies involving China Telecom over an extended period. These incidents involved China Telecom announcing routes for European mobile operators, North American networks, and other non-Chinese IP space. While smaller in scale than the 2010 incident, these route leaks occurred repeatedly and affected diverse targets.

Intent vs. Accident

The critical question surrounding the China Telecom incidents is whether they were deliberate (an intentional effort to intercept or redirect traffic) or accidental (the result of misconfigurations in China Telecom's BGP routing). This question is difficult to answer definitively because the technical evidence is consistent with both explanations:

Arguments for intentional hijacking: - The sheer volume and diversity of affected prefixes suggests deliberate targeting. - China Telecom's strategic position and the sensitivity of some affected networks (U.S. military, government agencies) are suggestive of intelligence motivations. - The incidents persisted over years despite public disclosure and criticism, suggesting either intent or negligent indifference.

Arguments for accidental misconfiguration: - Large ISPs like China Telecom manage millions of BGP routes across thousands of routers. Misconfigurations are common and can cause route leaks without malicious intent. - China Telecom's peering relationships and its position as one of the world's largest ISPs make it statistically more likely to be involved in route anomalies simply by virtue of its size. - Intentional traffic interception via BGP would be an extremely noisy intelligence technique, easily detectable by monitoring systems, making it a poor choice for covert surveillance.

The truth is likely nuanced: some incidents may have been accidental, while others may have been deliberate or at least opportunistic. The fundamental problem is that BGP's lack of authentication makes it impossible to distinguish between the two with certainty.

Part IV: The State of BGP Security

Current Defenses

Several technologies and practices have been developed to improve BGP security:

Resource Public Key Infrastructure (RPKI): RPKI allows network operators to cryptographically sign Route Origin Authorizations (ROAs) that specify which ASes are authorized to announce which IP prefixes. Routers that implement Route Origin Validation (ROV) can check incoming BGP announcements against ROAs and reject unauthorized ones.

RPKI adoption has been growing but remains incomplete. As of 2024, approximately 40-50% of IPv4 and IPv6 prefixes have valid ROAs, and a significant percentage of the world's large networks perform ROV. However, adoption is uneven: some regions (notably the Netherlands, Scandinavia, and Japan) have high adoption rates, while others lag behind.

BGPsec (BGP Security): An extension to BGP that provides path validation — the ability to verify not just that the origin AS is authorized to announce a prefix, but that each AS in the path has a legitimate routing relationship. BGPsec is standardized but has seen minimal deployment due to its computational overhead and operational complexity.

Route Filtering and Best Practices: Network operators can implement prefix filtering to reject BGP announcements that are clearly invalid (e.g., announcements for private IP space, overly specific prefixes, or prefixes from known bogon ASNs). The MANRS (Mutually Agreed Norms for Routing Security) initiative promotes filtering best practices.

BGP Monitoring and Alerting: Services like BGPStream, RIPE RIS, and commercial monitoring tools allow network operators to monitor BGP announcements in real time and detect anomalies. These tools cannot prevent hijacking, but they can detect it quickly, enabling faster response.

Why Adoption Is Slow

Despite the clear and present danger of BGP hijacking, security adoption remains slow for several reasons:

  1. Cost and complexity: Implementing RPKI and ROV requires investment in infrastructure, training, and ongoing maintenance.
  2. Collective action problem: BGP security works best when all networks participate. A network that implements ROV is only protected against hijacks of prefixes that have valid ROAs — if the victim network has not signed its prefixes, ROV cannot help.
  3. Operational risk: Implementing route validation creates the risk of incorrectly rejecting legitimate routes, causing self-inflicted outages.
  4. Incentive misalignment: The network that suffers from a BGP hijack is not necessarily the network that needs to implement the fix. The hijacker's upstream providers are the ones that need to filter the false routes, but they bear no direct cost from the hijack.

Impact on Penetration Testing and Security

Why Penetration Testers Should Understand BGP

While penetration testers are unlikely to conduct BGP hijacking attacks (such attacks require control of an AS and are difficult to constrain in scope), understanding BGP vulnerabilities is important for several reasons:

  1. Threat modeling: BGP hijacking is a realistic threat for organizations with internet-facing infrastructure. Understanding how it works helps testers evaluate their clients' exposure.
  2. Detection capability assessment: Can the client's security team detect a BGP hijack? Do they monitor their own prefix announcements? Do they have relationships with their upstream providers for rapid response?
  3. Supply chain risk: Even if a client's own BGP configuration is sound, their traffic may traverse networks that are vulnerable to hijacking. Understanding BGP helps testers assess supply chain risk.
  4. DNS and HTTPS implications: BGP hijacking can be used to redirect traffic to attacker-controlled servers, enabling man-in-the-middle attacks against TLS-protected connections if the attacker can obtain (or forge) valid certificates.

Discussion Questions

  1. Is BGP's trust-based design a fundamental flaw that should be redesigned, or is it a feature that enables the internet's flexibility and resilience? What trade-offs would a more secure routing protocol entail?

  2. How should the international community respond to alleged state-sponsored BGP hijacking? Is it analogous to other forms of espionage, or does it represent a unique threat to the global internet?

  3. What responsibility do individual network operators have for implementing BGP security measures? Should RPKI adoption be mandatory for networks above a certain size?

  4. How could a penetration testing engagement assess a client's vulnerability to BGP hijacking without actually performing a hijack? What controls could be tested?

  5. How does the Pakistan/YouTube incident illustrate the tension between national sovereignty (Pakistan's right to censor content within its borders) and the global nature of internet infrastructure?

Connection to Course Themes

This case study directly illustrates the Attack Surface Evolution theme: BGP's trust-based design was appropriate for the small, collegial internet of the 1980s but is inadequate for today's internet of 70,000+ autonomous systems and nation-state adversaries. The case also connects to the Authorization/Legality theme — BGP hijacking crosses international borders and jurisdictions, raising complex questions about what constitutes an "attack" versus a "misconfiguration" in international law. Finally, the slow adoption of BGP security measures reflects the Human Factor theme: the technical solutions exist, but adoption depends on overcoming economic incentives, organizational inertia, and collective action problems.