BGP Is 35 Years Old and Still Holds the Internet Together — Here's Why That's a Problem

In 1989, two engineers at a meeting sketched out a routing protocol on napkins. The protocol — the Border Gateway Protocol, or BGP — was meant to be a quick solution for the growing problem of how independent networks should tell each other where to send traffic. It was functional, pragmatic, and almost entirely without security. It's now the foundation of the global internet, and it has been for 35 years.
BGP is not software most people interact with. It's the protocol that runs between the routers at the edges of every major network — every internet service provider, every cloud provider, every company with its own IP address space. When you load a webpage, BGP is what ensures your request travels through the right sequence of networks to reach the right server. Without it, the internet is a collection of isolated islands. With it, it's a single reachable address space of roughly 4.3 billion IPv4 addresses.
How BGP Actually Works
The internet is organized into Autonomous Systems (ASes) — independent networks operated by a single organization. Your ISP is an AS. Amazon Web Services is an AS. A university with its own network infrastructure is an AS. Each AS has a number (an ASN, assigned by regional internet registries) and a set of IP prefixes — address ranges it controls.
BGP is the protocol ASes use to announce their prefixes to their neighbors and learn each other's routes. When AS-A wants to reach a prefix owned by AS-Z, it relies on a chain of BGP announcements: AS-A's router knows that AS-B has a path to AS-Z, AS-B knows that AS-C does, and so on. The protocol is built on trust: when an AS announces "I have a path to these IP addresses," neighboring ASes accept that announcement and propagate it further. There is no cryptographic verification. There is no central authority. If an AS announces a prefix it doesn't own, the announcement propagates globally.
This is a BGP hijack. And it happens regularly.
Famous Failures
In 2010, China Telecom announced roughly 15% of the global internet's routes through its network for about 18 minutes. Traffic destined for US military sites, Dell, IBM, and hundreds of other organizations was briefly routed through Chinese infrastructure. The incident was likely accidental — a misconfiguration rather than deliberate interception — but it demonstrated the scale of exposure.
In 2019, a small internet service provider in Pennsylvania accidentally announced 20,000 routes it didn't own, causing traffic for Amazon, Cloudflare, Facebook, and many others to route through a network with insufficient capacity. The result: widespread slowdowns and outages affecting millions of users for several hours.
In 2021, Facebook's own BGP configuration error — combined with a DNS failure — took all of Facebook's services (Facebook, Instagram, WhatsApp) completely offline for six hours. The BGP withdrawal of Facebook's own prefixes meant traffic couldn't reach their infrastructure even if DNS had been working. Restoring service required engineers to physically access data center hardware because the normal remote management tools couldn't connect either.
The pattern across these incidents is consistent: BGP's trust model means that mistakes and malicious announcements propagate at internet speed, and corrections take time to filter through hundreds of autonomous systems.
RPKI: The Fix That's Taking Decades to Deploy
Resource Public Key Infrastructure (RPKI) is the cryptographic framework designed to fix BGP's trust problem. RPKI allows IP address holders to create digitally signed certificates — Route Origin Authorizations (ROAs) — that cryptographically assert which ASes are authorized to originate which prefixes. A router doing RPKI validation can reject announcements that don't have a valid ROA, closing the door on most hijack scenarios.
RPKI has been technically available since the early 2010s. Adoption has been slow for structural reasons: every network needs to do two things — sign its own prefixes (origin validation), and validate announcements from peers (route origin validation). The second step only provides protection proportional to how many networks are doing the first. It's a coordination problem at internet scale.
Progress has accelerated. As of 2026, approximately 40% of the global routing table is covered by valid ROAs. Major networks — Cloudflare (which has been the most vocal RPKI advocate), AT&T, Comcast, Deutsche Telekom, and most of the major cloud providers — now enforce RPKI validation on their peering links. MANRS (Mutually Agreed Norms for Routing Security) tracks compliance, and the percentage of MANRS-compliant networks has grown significantly since 2022.
The remaining 60% of the routing table is a stubborn long tail. Smaller ISPs and regional networks often lack the engineering resources to implement RPKI, or have legacy equipment that doesn't support it. Some have commercial reasons to avoid route filtering (filtering can affect peering revenue). The problem is concentrated in developing regions where ISP modernization is slowest.
Beyond RPKI: BGPsec and Path Validation
RPKI solves origin validation — confirming that the AS announcing a prefix is authorized to do so. It does not solve path validation — confirming that the AS path in a BGP announcement accurately reflects the actual path traffic will take. A more sophisticated attack (or misconfiguration) can still inject false AS path information even with RPKI in place.
BGPsec is the proposed solution: a full cryptographic signing of the entire AS path for each route announcement. It would provide much stronger security guarantees. It would also require every router in the path to support and perform BGPsec validation, create significantly more computational overhead, and require a coordinated global upgrade of routing infrastructure. Consensus among network engineers is that BGPsec is too expensive to deploy at internet scale in the near term.
The practical roadmap is: finish RPKI deployment for origin validation (the next 5 years), then evaluate path security incrementally using a mix of route filtering policies, RPKI, and monitoring infrastructure. Organizations like RIPE NCC and ARIN publish real-time BGP monitoring dashboards that allow operators to detect hijacks within minutes rather than the hours it used to take.
What This Means for Reliability
BGP's fragility is structural, not accidental. The protocol was designed for a different internet — one with a small number of trusted participants connecting universities and research institutions. The decision to extend it to a global commercial infrastructure with hundreds of thousands of participants, many with adversarial incentives, was never a deliberate design choice. It happened by default, because there was no alternative ready when the internet needed to scale.
The internet has been living with that tradeoff for 35 years. The slow deployment of RPKI represents the first systematic effort to add security properties to a protocol that was never designed to have them. It's working — BGP hijack incidents that make headlines today are rarer and shorter-lived than they were in 2015 or 2019, because more networks now reject invalid route announcements automatically. But "less frequent" and "rare" are not the same as "solved," and for an infrastructure that carries the world's commerce, healthcare records, and communications, the gap between those two states still matters.