The Day Pakistan Telecom Took Down YouTube: A BGP Hijack Postmortem
A Government Order That Broke the Internet
On Sunday, February 24, 2008, the Pakistan Telecommunication Authority issued an order to the country’s ISPs: block access to YouTube. The reason was a video the government deemed offensive. The block was supposed to be invisible — just a domestic censorship measure, no different from thousands of similar orders issued by governments around the world.
Within 90 seconds of one ISP acting on that order, YouTube was unreachable for a significant portion of the global internet.
What followed became one of the most cited examples in internet history of why BGP’s lack of origin validation is an existential risk to global routing — and why RPKI matters.
The Setup: How Pakistan Was Blocking YouTube
The Pakistan Telecommunication Authority’s order reached Pakistan Telecom (AS17557), one of the country’s largest carriers. Pakistan Telecom engineers needed to block 208.65.153.0/24 — the IP range that www.youtube.com resolved to.
There are two ways to block traffic to an IP range internally:
Method 1 — ACLs: Apply access-control lists on every router interface to drop packets. Effective, targeted, contained to your own network.
Method 2 — Null routing: Create a more-specific BGP route for the target prefix pointing to a null (discard) interface. Traffic destined for that prefix gets black-holed inside your network.
Pakistan Telecom chose method 2. They created a route for 208.65.153.0/24 pointing to Null0 on their internal routers. YouTube’s legitimate prefix — 208.65.152.0/22 — was being announced globally from AS36561 (YouTube). The /24 is more specific than the /22, so any router that received both would always prefer the /24 — a fundamental BGP rule called longest prefix match.
The null route was supposed to stay internal. It did not.
The Leak: 18:47:00 UTC
At 18:47 UTC, a misconfiguration caused Pakistan Telecom’s internal null route for 208.65.153.0/24 to leak outbound — advertised to their upstream provider, PCCW Global (AS3491) in Hong Kong.
What should have happened at this point: PCCW should have had a prefix filter on their customer-facing session with Pakistan Telecom. PCCW knew (or should have known) which prefixes Pakistan Telecom legitimately owned. 208.65.153.0/24 was not one of them — it was YouTube’s address space. A properly configured inbound filter would have dropped the advertisement.
PCCW did not have this filter in place. The route was accepted.
PCCW (AS3491) did not validate Pakistan Telecom’s (AS17557) advertisement for 208.65.153.0/24. By accepting this advertisement and readvertising to its peers and providers, PCCW was propagating the wrong route. Those who saw this route from PCCW selected it since it was a more specific route — YouTube was advertising 208.65.152.0/22 before the event started and the /24 was a smaller and more specific advertisement. According to usual BGP route selection, the /24 was chosen, effectively completing the hijack.
Within two minutes of the first announcement, the bogus route had spread across the internet’s routing tables. Routers globally — following BGP’s longest prefix match rule — began preferring the Pakistan Telecom path for 208.65.153.0/24 over YouTube’s own /22.
YouTube traffic didn’t slow down. It didn’t degrade. It simply stopped reaching YouTube. The packets were being dutifully routed to Pakistan Telecom’s null interface and dropped there.
The Minute-by-Minute Timeline
The RIPE NCC documented the full sequence from their Routing Information Service (RIS):
18:47 UTC — AS17557 (Pakistan Telecom) starts announcing 208.65.153.0/24. AS3491 (PCCW Global) propagates the announcement. Routers around the world receive the announcement and YouTube traffic is redirected to Pakistan.
20:07 UTC — AS36561 (YouTube) starts announcing 208.65.153.0/24. With two identical prefixes in the routing system, BGP policy rules such as preferring the shortest AS path determine which route is chosen. This means that AS17557 (Pakistan Telecom) continues to attract some of YouTube’s traffic.
20:18 UTC — AS36561 (YouTube) starts announcing 208.65.153.128/25 and 208.65.153.0/25. Because of the longest prefix match rule, every router that receives these announcements will send the traffic to YouTube.
YouTube’s recovery strategy was elegant. They couldn’t simply withdraw the Pakistan Telecom route — that’s not how BGP works. Instead they fought specificity with specificity: announcing two /25s that together covered the same address space as the hijacked /24. Under longest prefix match, the more-specific /25s win over the /24, so routers globally switched back to YouTube’s legitimate paths.
By 20:52 UTC, the hijacked route was effectively neutralized. The total disruption lasted approximately two hours for users in the worst-affected regions.
The Collateral Damage to Pakistan Telecom
The outage wasn’t one-directional. Pakistan Telecom inadvertently created a massive traffic attack on itself (and on PCCW) because YouTube is a very popular site getting lots of requests. The amount of traffic made diagnosis difficult because packets from tools like traceroute might not have progressed beyond points of congestion.
Pakistan Telecom’s routers were suddenly receiving a significant fraction of global YouTube traffic — one of the most heavily accessed sites on the internet at the time. All of it was being dropped at the null interface, but the inbound congestion from millions of connection attempts was hammering Pakistan Telecom’s infrastructure. They had accidentally DoS’d themselves while trying to censor a video.
Why BGP Has No Defense Against This
The core problem is that BGP was designed for a cooperative, trust-based internet. When Pakistan Telecom announced 208.65.153.0/24, there was no mechanism for PCCW or any other router to verify: is this ASN authorized to announce this prefix?
BGP operates on transitive trust — you trust your peers, and you trust that your peers have vetted their peers. It takes exactly one provider (PCCW) failing to filter for a bad route to propagate globally.
The technical fixes that existed in 2008 — IRR (Internet Routing Registry) filters, RPSL (Routing Policy Specification Language) — were available but inconsistently deployed. They require ISPs to proactively maintain and enforce prefix filters on every customer session. Many didn’t.
What RPKI Would Have Done
RPKI (Resource Public Key Infrastructure) directly addresses this attack vector. Under RPKI:
- YouTube would have published a Route Origin Authorization (ROA) stating:
AS36561 is authorized to announce 208.65.153.0/22 and its sub-prefixes - No ROA would exist authorizing AS17557 (Pakistan Telecom) to announce
208.65.153.0/24 - PCCW, running RPKI validation, would have received Pakistan Telecom’s announcement and classified it as RPKI-invalid
- PCCW’s routers would have dropped the invalid route rather than propagating it
The route would have been dead on arrival at PCCW. It never reaches the global internet.
In 2008, RPKI was still a proposal in IETF working groups. The root zone wasn’t signed until 2010. Widespread RPKI deployment didn’t begin until the late 2010s, and even today adoption remains incomplete — which is why BGP hijacks continue to occur.
The Lesson That Keeps Repeating
The Pakistan Telecom incident wasn’t novel in 2008. Old hands recognized it as fundamentally the same problem as the infamous AS 7007 incident from 1997, a more recent ConEd mistake of early 2006, and even TTNet’s Christmas Eve incident from 2004.
The same pattern — a more-specific route, an upstream provider that doesn’t filter, global propagation via longest prefix match — has played out dozens of times before and since. The 2010 China Telecom incident. The 2018 Route 53 hijack. The 2019 Rostelecom leak of European prefixes. Each one demonstrates the same fundamental vulnerability.
What changed after 2008 was awareness. The YouTube hijack was visible enough — affecting a mainstream consumer service — that it brought the BGP security problem to a much wider audience. It accelerated RPKI standardization and deployment discussions. It made “BGP hijack” a phrase that executive stakeholders and security teams began to understand.
The fix was already known: deploy RPKI, enforce ROV (Route Origin Validation) at internet exchange points, implement ingress filtering on customer sessions. The incident didn’t create new solutions — it created urgency for solutions that already existed.
What Every Network Operator Should Take Away
Publish ROAs for your prefixes. If you announce IP space, create ROAs in your RIR’s RPKI system. It takes minutes. Once your ROA exists, any RPKI-validating router on the internet will reject unauthorized announcements of your space.
Enforce ROV on your BGP sessions. Don’t just publish ROAs — validate the routes you receive. If a route is RPKI-invalid, drop it. This is how the internet collectively prevents the next Pakistan Telecom incident.
Filter customer-facing BGP sessions. Maintain prefix lists for every customer session. Accept only the prefixes they are legitimately authorized to announce.
Monitor your prefixes. Services like Cloudflare Radar, RIPE Stat, and BGPmon will alert you if someone starts announcing your address space from an unauthorized ASN. The Pakistan Telecom incident was detected within minutes by engineers monitoring routing tables — but YouTube’s response still took over an hour.
The internet’s routing system is only as secure as its least careful operator. RPKI changes that equation — making route origin validation a cryptographic property rather than a cooperative convention.
