The Pakistan YouTube BGP Hijack (2008)
On February 24, 2008, YouTube disappeared from the internet. Not because of a server failure at Google, not because of a DDoS attack, but because a small telecom operator in Pakistan announced a BGP prefix it did not own. Within minutes, traffic destined for YouTube was flowing into a black hole in Islamabad. The incident lasted roughly two hours and affected users worldwide. It remains one of the most cited examples of how fragile the internet's routing system can be, and it became the catalyst for serious investment in RPKI and route origin validation.
Background: Pakistan Orders YouTube Blocked
The Pakistan Telecommunication Authority (PTA) ordered all ISPs in the country to block access to YouTube. The reason was a specific video that the Pakistani government deemed blasphemous. Blocking websites is a routine operation for national censors, and the standard approach is to configure something at the network edge -- DNS manipulation, IP blackholing, or HTTP filtering -- that prevents domestic users from reaching the target.
Pakistan Telecom (AS17557) chose a particularly aggressive method: rather than filtering traffic at the edge of their own network, they injected a BGP route for YouTube's IP space. The idea was simple: if Pakistan Telecom's routers believed they owned YouTube's address space, traffic from their customers would be routed to a null interface and dropped. YouTube would appear unreachable to Pakistani users. This technique is sometimes called BGP blackholing, and when done correctly -- with routes confined to the internal network -- it works as intended.
But Pakistan Telecom's route was not confined to their internal network.
The Technical Details
YouTube's primary address space at the time included the prefix 208.65.152.0/22, originated by AS36561 (YouTube, later merged into Google's AS15169). This /22 covers 1,024 IP addresses: 208.65.152.0 through 208.65.155.255.
Pakistan Telecom announced a more specific prefix: 208.65.153.0/24. This /24 is a subset of YouTube's /22, covering just the 256 addresses from 208.65.153.0 to 208.65.153.255. The announcement claimed AS17557 (Pakistan Telecom) as the origin.
This is where BGP's longest-prefix-match rule becomes critical. When a router has two routes for overlapping prefixes, it always prefers the more specific (longer) prefix. A /24 is more specific than a /22. So any router that received both YouTube's legitimate /22 and Pakistan Telecom's fraudulent /24 would prefer the /24 for any address in the 208.65.153.0 range -- sending that traffic toward Pakistan instead of YouTube.
How the Hijack Went Global
The route should never have left Pakistan Telecom's network. In a properly configured setup, the blackhole route would have been tagged with a no-export community or filtered at the border. But Pakistan Telecom leaked the 208.65.153.0/24 announcement to its upstream provider, PCCW (AS3491), a major international transit carrier based in Hong Kong.
PCCW did not filter the announcement. It accepted the route and, because PCCW is a global transit provider with extensive peering and customer relationships, propagated it to the rest of the internet. Within minutes, routers around the world had learned that the best path to 208.65.153.0/24 was through PCCW and then Pakistan Telecom.
The propagation followed the standard BGP mechanics: PCCW announced the route to its peers and customers, who announced it to their peers and customers, and so on. Each autonomous system along the way made a rational decision based on the information available -- the /24 was more specific than YouTube's /22, and the AS path through PCCW was plausible.
Timeline of the Incident
The entire incident unfolded and was resolved within a few hours, but each minute represented global YouTube downtime affecting hundreds of millions of users.
Why BGP Accepted the Fake Route
BGP was designed in the late 1980s, when the internet was a small network of trusted academic and government institutions. The protocol's core design reflects that era: BGP announcements are accepted on trust. When an autonomous system announces a prefix, neighboring ASes generally accept it and propagate it without verifying whether the announcer actually controls that address space.
This trust model works most of the time. The vast majority of BGP announcements are legitimate, and the system's simplicity is part of what allowed the internet to scale from dozens of networks to over 75,000 autonomous systems. But it means there is no built-in mechanism to prevent what Pakistan Telecom did -- announce a prefix belonging to someone else.
Three properties of BGP made this hijack particularly effective:
- Longest prefix match -- Routers always prefer the most specific (longest) prefix. Pakistan Telecom's /24 was more specific than YouTube's /22, so it won unconditionally on any router that received both.
- No origin authentication -- In 2008, there was no widely deployed mechanism to verify that AS17557 was authorized to originate
208.65.153.0/24. Today, RPKI provides exactly this, but it did not exist at the time. - Rapid global propagation -- BGP updates propagate quickly. A new, more-specific prefix can reach the global routing table within seconds to minutes, depending on the announcing AS's connectivity. PCCW's position as a major transit provider meant the hijacked route reached most of the internet very quickly.
The Impact
The consequences were severe and immediate:
- YouTube was unreachable worldwide for approximately two hours. Users in every country saw connection timeouts or errors when trying to access the site.
- Traffic was black-holed. Packets sent to
208.65.153.0/24were routed to Pakistan Telecom, which had no actual YouTube servers. The traffic simply vanished -- Pakistan Telecom's routers either dropped the packets at a null route or sent back ICMP unreachable messages. - Legitimate YouTube traffic was affected asymmetrically. Some users could reach YouTube via IP addresses outside the hijacked /24 range (within the broader /22), but the most commonly used addresses were in the hijacked block.
- Pakistan Telecom's own network was overwhelmed. A significant fraction of global YouTube traffic suddenly converged on a telecom operator in Pakistan that was not equipped to handle it, causing collateral damage to Pakistan Telecom's other services.
How It Was Fixed
The fix involved coordinated action between YouTube (Google), PCCW, Pakistan Telecom, and the broader operator community:
Step 1: Detection and Alerting
Network operators monitoring BGP looking glasses and route collectors noticed the origin change for YouTube's prefix. RIPE's Routing Information Service (RIS) and the University of Oregon's RouteViews project both recorded the anomaly. Mailing lists like NANOG (North American Network Operators Group) lit up with reports.
Step 2: YouTube Announces More-Specific Prefixes
YouTube's engineers (by this time part of Google) responded by breaking their /22 into even more specific prefixes. They announced two /25 prefixes: 208.65.153.0/25 and 208.65.153.128/25. A /25 is more specific than a /24, so routers that received both the hijacked /24 and the legitimate /25s would prefer the /25s, routing traffic back to YouTube.
However, many networks filter prefixes longer than /24 for IPv4 (a common practice to limit routing table growth), so the /25 strategy was not universally effective. It helped in some parts of the internet but not everywhere.
Step 3: PCCW Filters the Hijacked Route
The definitive fix came when PCCW was contacted and agreed to filter Pakistan Telecom's announcement of 208.65.153.0/24. Once PCCW stopped propagating the hijacked route, it was withdrawn from the global routing table. Pakistan Telecom also withdrew the route on their end.
Step 4: Verification and Recovery
BGP convergence takes time. Even after the hijacked route was withdrawn, it took several minutes for all routers worldwide to learn the updated routes and switch back to the legitimate path. Service was gradually restored over the following hour.
Lessons: What This Incident Revealed
The Pakistan-YouTube incident exposed several systemic weaknesses in how the internet's routing system operated in 2008:
1. No Origin Authentication
Any autonomous system could announce any prefix with impunity. There was no cryptographic mechanism to verify that AS17557 was not authorized to announce 208.65.153.0/24. Routers simply trusted the announcement because it came from a recognized neighbor.
2. Inadequate Prefix Filtering
PCCW, as Pakistan Telecom's upstream provider, should have had filters in place limiting which prefixes AS17557 was allowed to announce. If PCCW had maintained a prefix list for its customer, only allowing AS17557 to announce its own legitimately allocated address space, the hijacked route would never have left Pakistan. This practice, known as customer prefix filtering or route filtering based on Internet Routing Registry (IRR) data, was well understood in 2008 but not universally applied.
3. No Automated Detection
The hijack was detected by humans monitoring mailing lists and looking glasses. There was no automated system that could detect the origin change and alert affected parties in real time. The detection-to-mitigation time was measured in hours, not seconds.
4. The "More-Specific" Attack is Hard to Defend Against
Even if YouTube had been monitoring its own routes, the only immediate technical response was to announce even more specific prefixes -- a game of specificity escalation. This is not sustainable, and many networks filter prefixes longer than /24, placing limits on how far you can go.
Defenses That Exist Today
The Pakistan-YouTube hijack was a turning point. It demonstrated in vivid, public terms what the network operations community had long warned about, and it accelerated the development and deployment of several key defenses:
RPKI (Resource Public Key Infrastructure)
RPKI directly addresses the origin authentication problem. With RPKI, YouTube (Google) can create a Route Origin Authorization (ROA) that cryptographically declares: "Only AS36561 (or AS15169) is authorized to originate prefixes within 208.65.152.0/22, with a maximum prefix length of /24." Any network performing Route Origin Validation (ROV) would see Pakistan Telecom's announcement as RPKI-invalid and either reject it outright or deprioritize it.
RPKI deployment has grown substantially since 2008. Major networks including Cloudflare, Google, Amazon, and most large transit providers now perform ROV. Over 40% of global prefixes have valid ROAs. Had RPKI been deployed in 2008, the hijack would have been contained to the small number of networks that do not validate routes.
Prefix Filtering and IRR
Transit providers are now more rigorous about filtering customer announcements. Best practices documented in standards like BCP 38 and MANRS (Mutually Agreed Norms for Routing Security) call for transit providers to maintain strict prefix lists for their customers, only allowing them to announce address space they are registered to hold.
BGP Monitoring and Alerting
Services like BGP looking glasses, RIPE RIS, BGPStream, and commercial monitoring tools now provide real-time alerts when a prefix's origin AS changes unexpectedly. Network operators can configure alerts for their own prefixes and be notified within seconds of an anomalous announcement, rather than discovering it hours later on a mailing list.
BGP Communities and Blackhole Communities
The original intent of Pakistan Telecom's action -- blocking YouTube domestically -- could have been achieved safely using BGP blackhole communities. A blackhole community is a signal attached to a BGP announcement that tells the receiving router to drop traffic. By tagging the route with a no-export community, Pakistan Telecom could have contained the blackhole to their own network. Modern best practices for internal traffic management rely heavily on communities rather than uncontrolled prefix origination.
ASPA (Autonomous System Provider Authorization)
RPKI validates the origin of a route but does not verify the full AS path. ASPA is a newer mechanism where ASes publish their authorized upstream providers. If AS17557's only authorized provider was PCCW, and PCCW had ASPA data, it could verify that the route from AS17557 was plausible in terms of the business relationship, but additional path validation could detect if the route was being propagated in unexpected ways.
Could It Happen Again?
Yes, but with diminished impact. BGP hijacks still occur regularly -- some accidental, some deliberate. In 2018, a Russian ISP briefly hijacked Amazon and Google prefixes. In 2019, a Swiss data center accidentally rerouted European mobile traffic through China. In 2020, Rostelecom hijacked prefixes belonging to Akamai, Cloudflare, and other major CDNs.
The difference today is:
- RPKI adoption means a growing fraction of networks will reject invalid announcements automatically.
- Monitoring is faster. Anomalies are detected in seconds to minutes, not hours.
- Operator awareness is higher. The Pakistan-YouTube incident, along with subsequent events, has made prefix filtering and route validation standard practice at well-run networks.
- Major prefixes are protected. High-profile targets like Google, Cloudflare, and Amazon all have ROAs in place, meaning their prefixes are validated by any network performing ROV.
However, RPKI adoption is not universal. As of 2026, a significant minority of networks still do not perform route origin validation, and many prefixes still lack ROAs. The internet's routing security has improved dramatically since 2008, but it remains a work in progress.
What the Routing Table Looked Like
If you had queried a BGP looking glass during the incident, you would have seen something like this for 208.65.153.0/24:
The presence of both the legitimate /22 and the hijacked /24 in the routing table is characteristic of a more-specific hijack. The legitimate route was still there -- it was just being overshadowed by the more specific bogus announcement for the contested range.
A Lasting Legacy
The 2008 Pakistan-YouTube incident is now a textbook case in network engineering courses and security conferences. It demonstrated that a single misconfigured router in one country can take down a global service, that BGP's trust model is both its greatest strength (enabling the internet's growth) and its greatest weakness (enabling hijacks), and that the only real solution is cryptographic verification of route origins.
The incident directly accelerated the development and deployment of RPKI. The first ROAs were created in 2011, and adoption has grown steadily since. While the internet's routing security is far from complete, every network that deploys RPKI route origin validation makes the next Pakistan-YouTube incident harder to pull off.
You can verify the current routing security status of any prefix or autonomous system using a BGP looking glass. Try looking up Google's AS15169 to see the RPKI status of their current prefixes, or check any IP address to see whether its route is cryptographically validated: