The internet routes packets using a protocol that was basically built on optimism.

That sounds harsher than it is. In 1989, optimism was not insane. BGP came out of a smaller, more cooperative internet where the number of actors was lower, incentives were simpler, and the protocol’s job was mostly to let autonomous systems say, “I can reach this prefix, and here is the AS path to get there.”

What nobody built into that design was a real way to prove the speaker had any right to make the claim.

So BGP still runs today on a mix of policy, convention, filtering, and good intentions, with cryptographic origin validation bolted on later because eventually the internet had to admit it was no longer a village.

What BGP Actually Does

BGP — Border Gateway Protocol — is how autonomous systems (AS) exchange routing information. An AS is a network under a single administrative entity — an ISP, a cloud provider, a large enterprise, a university.

An AS announces IP prefixes and the path of AS numbers through which those prefixes can be reached. Neighbors receive the announcements, apply local policy, compare path attributes, pick preferred routes, and re-advertise to their own neighbors. Repeat across the global graph and you get the interdomain routing system that moves traffic between networks.

Mechanically, BGP is a path-vector protocol, and the version everyone runs is BGP-4, specified in RFC 4271. Two routers that speak BGP to each other (peers, or neighbors) open a TCP session on port 179 and keep it up for as long as the relationship lasts, sending updates only when something changes. Between different ASes this is called eBGP; inside one AS, where routers share what they’ve learned from the outside, it’s iBGP. BGP doesn’t find paths inside your network. That’s the job of OSPF or IS-IS. BGP decides how your network reaches everyone else’s.

At its heart, a BGP update says: “I know a way to reach this address range, and here is the route.” Neighbors can accept it, modify it, filter it, or pass it along. The system converges because everyone shares what they know and picks the best paths according to local preferences.

There’s no central authority. No global routing table that says “this is correct.” Just tens of thousands of autonomous systems exchanging information and trusting each other to tell the truth.

The Trust Problem

BGP has no built-in mechanism to verify that an AS actually owns the prefix it announces. Any AS can announce any prefix. If AS 12345 announces that it can route traffic for a prefix that actually belongs to AS 67890, neighboring networks will often accept the announcement. Traffic that should reach AS 67890 goes to AS 12345 instead.

This is route hijacking. And it’s terrifyingly easy.

The more specific prefix wins. If the legitimate owner announces 203.0.113.0/24, an attacker can announce 203.0.113.0/25 and 203.0.113.128/25. Routers forward along the most specific matching prefix, so traffic shifts to the attacker without the victim doing anything wrong. (In practice most networks drop IPv4 routes more specific than a /24, so the trick works best against a victim announcing something larger, like a /22 — which is exactly the shape of the YouTube incident below.)

When It Goes Wrong

Pakistan and YouTube (2008). Pakistan Telecom wanted to block YouTube domestically. On February 24, 2008 it announced 208.65.153.0/24, a more specific slice of YouTube’s 208.65.152.0/22, meaning it for its own network. The announcement leaked to the global routing table through its upstream provider, PCCW. For a little over two hours, YouTube was unreachable for a significant portion of the internet because traffic was being routed to Pakistan Telecom, which was dropping it.

The block was deliberate. The global outage wasn’t. An upstream that should have filtered its customer’s announcement passed it along instead, and the whole internet believed it.

Route leaks are the accidental cousin of hijacking. An AS re-announces routes it received but shouldn’t be forwarding. Traffic takes wrong paths, sometimes through networks that lack the capacity to handle it. Route leaks have caused major outages — a single misconfigured router at a transit provider can redirect traffic for thousands of prefixes through a link that can’t handle the load.

Intentional hijacking is harder to attribute but documented. Cryptocurrency theft, traffic interception for surveillance, DNS manipulation — all have been linked to BGP hijacking events. The attacker announces a victim’s prefix, intercepts traffic for minutes or hours, extracts what they need, and withdraws the announcement. By the time anyone notices, it’s over.

Why Hasn’t This Been Fixed?

Partially because of the scale. There are over 75,000 autonomous systems in the global routing table. Deploying any new security mechanism requires adoption across a large fraction of them to be effective. Coordination at that scale is glacial.

Partially because of cost. Filtering announcements and validating routes requires operational investment. Many network operators rely on trust and convention — “my peer wouldn’t announce my prefixes” — because it’s cheaper than building validation infrastructure.

And partially because, honestly, it works most of the time. The internet routes traffic successfully billions of times per day. Hijacking events are notable precisely because they’re exceptions. The system is fragile in theory but surprisingly resilient in practice — held together by convention rather than cryptography.

RPKI: The Fix (in Progress)

RPKI — Resource Public Key Infrastructure — adds cryptographic attestation to route origins. A resource holder (the entity that owns an IP prefix) creates a Route Origin Authorization (ROA) that says: “AS 67890 is authorized to announce prefix 203.0.113.0/24.”

ROAs are signed with the resource holder’s private key and published in a distributed repository. Network operators can run RPKI validators that check incoming BGP announcements against published ROAs. If a ROA covers the prefix but names a different origin AS (or the announcement is more specific than the ROA allows), the route is marked invalid, and the operator can reject it. If no ROA covers the prefix at all, the result is “not found,” and almost everyone still accepts those routes, because rejecting them would cut off a large part of the internet.

Note what RPKI checks: the origin, and only the origin. An attacker who forges a path that ends in the legitimate origin AS still passes. Path validation (BGPsec, which almost nobody deploys, and newer proposals like ASPA) is the next layer, and it is further behind.

RPKI adoption has grown significantly in recent years. Major ISPs and cloud providers now validate routes. NIST and regional internet registries have pushed adoption. But it’s far from universal.

The chicken-and-egg applies here too. ROAs only help if validators are checking. Validators only help if routes are signed. Both sides need to adopt for the system to work. Without universal adoption, an attacker can still hijack prefixes that lack ROAs or target networks that don’t validate.

The Duct Tape Internet

BGP holds the internet together with duct tape and good intentions. The protocol was designed for a world where every network operator was a known, cooperative participant. That world is long gone, but the protocol remains.

RPKI is the right fix — cryptographic proof of authorization. But deploying it universally is the same class of coordination problem that plagues DNSSEC, IPv6, and every other internet-wide upgrade. The technology exists. The adoption lags.

In the meantime, the internet continues to route traffic based on announcements that anyone can make and nobody is required to verify. It usually works. When it doesn’t, the consequences can be global.

That’s BGP. The protocol that runs on trust, in a world that probably shouldn’t.