BGP: The Trust-Based System That Routes the Entire Internet

Every packet that leaves your ISP’s network is routed by a protocol whose core design assumption is that networks tell the truth about what they own. BGP has no built-in way to verify that. The internet works because of filtering, contracts, reputation and a bolt-on cryptographic layer that is roughly half deployed — not because the protocol checks anything.

Autonomous systems: the units the internet is made of

The internet is not one network. It is a mesh of independently administered ones — ISPs, universities, content providers, banks, cloud operators — each an autonomous system with its own number. The CIDR Report, which tracks the global routing table from a set of vantage points, listed roughly 1.08 million IPv4 prefixes originated by about 79,000 unique AS numbers in early September 2026.

Inside an AS, the operator can use whatever routing protocol it likes. Between autonomous systems there is exactly one: BGP, specified in RFC 4271, published in January 2006. Two routers in different organisations open a TCP session and exchange reachability information — this block of addresses is reachable through me, and here is the list of autonomous systems the traffic will cross to get there.

Path-vector routing means nobody sees the map

An interior protocol like OSPF gives every router a complete map of the network and lets each one compute shortest paths. BGP does nothing of the kind. A BGP router knows only what its direct neighbours have told it, and each announcement carries an AS_PATH — the ordered list of autonomous systems the route has traversed.

That path serves two purposes. It prevents loops, because a router seeing its own AS number in a path discards the announcement. And it is the raw material for policy: an operator decides which routes to accept, prefer and pass on to whom, based on business relationships the protocol knows nothing about. A shorter AS path is a tie-breaker, not a rule.

One mechanism deserves attention because it appears in nearly every incident: longest prefix match. If one network announces 203.0.113.0/24 and another announces 203.0.113.0/25, every router prefers the /25 for the addresses it covers, regardless of AS path length, business relationship or who owns the space. A more specific prefix beats everything.

The part with no authentication

RFC 4271 defines message formats, a finite state machine, error handling and path attributes. What it does not define is any way to verify that the network announcing a prefix is entitled to it, or that an AS_PATH reflects a route that exists. The session between routers can be authenticated; the routing information carried over it cannot.

The practical defence has always been prefix filtering: a transit provider keeps a list of what each customer may announce and drops everything else. This works when it is done, and it is done least reliably at exactly the interconnection points with the largest blast radius.

Leak versus hijack

The two failure modes are worth separating. A route leak is usually an accident of policy: a network that should announce its customers’ routes to its transit providers instead announces its providers’ routes to everyone, and traffic that had no business crossing it suddenly does. A hijack is an announcement of address space you do not hold. The protocol behaves identically in both cases, because it cannot tell them apart.

Three incidents that are worth naming

Pakistan Telecom and YouTube, 24 February 2008

The canonical case, documented by the RIPE NCC’s Routing Information Service. Ordered by its regulator to block YouTube domestically, Pakistan Telecom (AS17557) announced 208.65.153.0/24 — more specific than YouTube’s own route — at 18:47 UTC. The announcement was meant to stay inside Pakistan. Its upstream, PCCW Global (AS3491), passed it to the world.

Because of longest prefix match, a large share of global YouTube traffic went to Pakistan and was discarded. YouTube (AS36561) fought back at 20:07 UTC with two /25s, more specific still. It ended at 21:01 UTC when PCCW withdrew everything Pakistan Telecom had originated: about two hours and fourteen minutes, caused by a domestic censorship configuration that escaped.

Amazon Route 53 and MyEtherWallet, 24 April 2018

This one was deliberate and it monetised. Beginning around 11:05 UTC, eNet (AS10297) announced more-specific /24s carved out of Amazon’s 205.251.192.0/23 and neighbouring blocks — address space belonging to Amazon (AS16509) and hosting Route 53 authoritative DNS servers. Peers including Hurricane Electric propagated them.

The result was a routing attack used to mount a DNS attack. Resolvers trying to reach Route 53 for myetherwallet.com reached the attackers’ nameserver instead and received a fraudulent address; the fake site harvested wallet credentials. The Internet Society’s analysis is blunt about the cause: prefix filtering at the networks that accepted and propagated the announcements would have stopped it. It ran roughly two hours, ending around 12:55 UTC. Cloudflare’s own write-up notes that layered application defences — DNSSEC, HSTS so browsers offer no click-through past a certificate warning, encrypted DNS — mattered more to victims on the day than any routing fix.

Facebook, 4 October 2021

Not a hijack, but the clearest demonstration of BGP’s reach. A backbone configuration change disconnected Meta’s data centres; its authoritative DNS servers, designed to withdraw their route advertisements when they cannot reach those data centres, did exactly that. Withdrawing a route removes you from the internet as thoroughly as being hijacked — and removes your own remote access with it.

RPKI: the fix that is half installed

The Resource Public Key Infrastructure lets an address holder publish a signed Route Origin Authorisation — a statement that a given AS number is permitted to originate a given prefix, up to a stated length. Routers can then perform Route Origin Validation, specified in RFC 6811, January 2013, which classifies each received route as Valid, Invalid or NotFound and lets the operator drop the Invalids.

Two things follow. First, RPKI only checks the origin. It would have stopped Pakistan Telecom and eNet, because both announced prefixes they had no authorisation for. It does nothing about a forged AS_PATH or a leak of individually legitimate routes. Path validation exists — BGPsec, RFC 8205, September 2017 — but it requires every AS on a path to sign, which is why it remains essentially undeployed.

Second, RPKI only helps where both halves are done: prefix holders must publish ROAs, and networks must actually reject Invalid routes. NIST’s RPKI Monitor showed over half of IPv4 routes in the global table covered by ROAs by May 2024; MANRS reported in July 2026 that a concerted registration effort in China had lifted ROA coverage across the entire APNIC region from 55% to 77%. Progress is real, but “most routes are signed” is not “all routes are validated”.

MANRS — Mutually Agreed Norms for Routing Security, supported by the Global Cyber Alliance — is the non-cryptographic half of the answer. It asks participating networks to filter route announcements, implement source address validation to stop spoofing, keep contact details reachable, publish routing data others can validate against, and provide monitoring tools. None of it is technically hard. All of it is unenforceable.

What an ordinary user can and cannot do

Honestly: you cannot influence global routing, and no consumer product changes that. A VPN does not help — it re-routes your traffic through a tunnel itself carried over BGP. What you can do is make a successful hijack less useful, because in every case above the routing attack was only the first step.

• Insist on HTTPS and let browsers enforce it. Redirected traffic still has to produce a valid certificate for the domain. HSTS removes the “proceed anyway” button that made the MyEtherWallet theft possible.
• Treat certificate warnings as fatal. On a site holding money or credentials, a warning you did not expect is the exact signature of this attack class.
• Ask your providers. “Do you drop RPKI-invalid routes?” and “are you a MANRS participant?” are reasonable questions for a business ISP or hosting provider, and the answers vary.
• If you run an AS, publish ROAs and validate. This is now a standard feature on mainstream routing platforms and at every regional internet registry.

Inter-domain routing runs on institutional trust reinforced by partially deployed cryptography, and has for decades. It mostly holds. The incidents worth studying are the ones where it did not — and every one was survivable by whoever had a second layer underneath.