BGP hijacks and RPKI, the routing security problem

BGP is the protocol that makes the internet work. It's also one of its weakest links: by default, BGP has no authentication. If a router announces "I can reach this prefix," other routers tend to believe it. This has caused outages, redirects, and outright thefts.

This article covers BGP's security history, the major incident categories, and the modern mitigations (especially RPKI). It's a more technical article than most of Series B, but the topic is important enough to deserve depth.

A BGP hijack scenario

Without RPKI, neither peer can tell which announcement is real. With RPKI, the attacker's announcement fails cryptographic origin validation and gets dropped.

The original sin

BGP assumes operators are competent and honest. The protocol verifies neither.

When AS 12345 announces 203.0.113.0/24, no part of standard BGP asks: "is AS 12345 actually authorized to announce this prefix?" Peers will accept the announcement and propagate it. Within minutes, the world believes AS 12345 hosts that prefix.

If AS 12345 doesn't actually host it, traffic destined there now goes to AS 12345. This is a route hijack.

If the real owner of the prefix is still announcing it correctly, you get a "route hijack with split traffic": some paths route to the real owner, some to the hijacker. Depends on BGP's path selection.

If the hijacker announces a more-specific prefix (say 203.0.113.42/32), the hijack will dominate because routers prefer more-specific routes. This is the most common attack pattern.

Incident taxonomy

BGP-related incidents fall into a few categories:

Misconfigurations. An operator typos a prefix, or copies the wrong filter, or forgets to add a peer to a blacklist. Most BGP-related outages are misconfigurations, not malice.

Route leaks. An AS receives routes via one relationship (e.g., from a peer) and announces them via another (e.g., to a transit provider). The protocol doesn't enforce these business-relationship rules. Leaks cause traffic to flow through unintended paths.

Origin hijacks. An AS announces a prefix it doesn't own. The most direct attack.

Path hijacks. A more sophisticated attack: the announcer keeps the correct origin but inserts itself into the path, intercepting traffic.

Sub-prefix hijacks. Announcing a more-specific prefix than the owner is announcing, to override longest-match.

Most documented incidents have been misconfigurations or origin hijacks. Path hijacks are harder to perform and detect.

Famous incidents

1997: The AS 7007 incident. A small Florida ISP misconfigured its routers to leak the entire global routing table back to its upstream as if it originated all of it. Within minutes, much of the internet routed traffic to AS 7007. Recovery took hours. This caused widespread adoption of basic filtering.

2004: TTNet leaks the internet. Turk Telekom's TTNet leaked thousands of routes for prefixes it didn't own. Many networks accepted them. Significant disruption.

2008: Pakistan Telecom and YouTube. Pakistan's government ordered ISPs to block YouTube. Pakistan Telecom did this with a more-specific BGP route. The route leaked to PCCW (their upstream), then globally. YouTube was effectively offline for two hours.

2014: Indosat leaks 320,000 routes. A misconfiguration in Indonesia caused routes for most of the internet to be reannounced through Indosat. Major disruption in Asia.

2017: Russia routes Google through Russia. A small Russian provider briefly attracted Google's traffic. Likely a misconfiguration but the incident raised concerns about politically-motivated possibility.

2018: Amazon Route 53 hijack. Sophisticated attack: hijackers redirected DNS queries for route53.amazonaws.com and then redirected cryptocurrency wallet traffic. About $150,000 stolen.

2020: Various incidents. A Rostelecom incident briefly attracted significant traffic from major US tech companies, raising state-actor concerns.

2022: Twitter hijack. A briefer incident where Twitter (X) traffic was misrouted for ~10 minutes.

The pattern: BGP-related incidents happen regularly, mostly accidentally, occasionally maliciously. The internet usually recovers within an hour as filters kick in or the offending announcement is withdrawn.

Why BGP doesn't authenticate by default

It's an artifact of the era. BGP was designed in the 1980s and updated through the 1990s. At the time:

• The internet had a few hundred ASes, all run by people who knew each other.
• Cryptographic infrastructure for routing security didn't exist.
• The cost of any authentication mechanism in CPU and bandwidth was prohibitive on early routers.

The protocol settled on trust because the alternative was either non-functional or computationally unaffordable. By the time the internet grew to the point where untrusted operators existed, BGP was deeply entrenched and changing it was hard.

Retrofit work over the past two decades has tried to add security without breaking compatibility. RPKI is the most successful effort.

RPKI in detail

RPKI (Resource Public Key Infrastructure, RFC 6480 and related) lets prefix holders cryptographically sign records that say "this prefix should only be announced from these AS numbers." Routers check incoming BGP announcements against these signed records and reject those that don't match.

The pieces:

Trust anchors. The five regional internet registries (ARIN, RIPE, APNIC, etc.) each operate a trust anchor. They sign certificates for their members' resources.

Resource certificates. When you get an ASN or prefix from your RIR, the RIR signs a certificate attesting that you hold those resources.

Route Origin Authorizations (ROAs). You publish signed records that say "prefix X may be originated by AS Y, with max prefix length Z."

Validators. Routers (or external validators feeding routers) check announcements against ROAs. Matches are "valid." Conflicts are "invalid." Missing ROAs are "unknown" (sometimes called "not found").

Drop-invalid policy. Modern routers can be configured to drop announcements that are RPKI-invalid. Many major networks now do this.

What RPKI actually catches

RPKI is good at:

• Origin hijacks where an AS announces a prefix it doesn't own.
• Subprefix hijacks where an AS announces a more-specific.
• Misconfigurations that announce the wrong origin AS.

RPKI doesn't catch:

• Path hijacks where the origin AS is correct but the AS path is manipulated.
• Authorized-but-bad announcements (the legitimate owner does something wrong).
• Off-path attacks at lower layers.

It's a meaningful but partial improvement. Together with classical filters (max-prefix limits, IRR-based filters, peer-locking), modern BGP is far more robust than 1990s BGP. Far from perfect.

RPKI adoption status

As of 2026:

• ROA coverage: about 50 to 60 percent of IPv4 prefixes globally have a ROA, varying by region (higher in Europe and Asia, lower in North America).
• Networks that drop invalid: most major Tier 1s and many large content providers. Mid-size networks slower but adopting.
• Documented incidents prevented: many. RPKI has flagged numerous accidental misconfigurations within minutes.

The trajectory is clear: RPKI is becoming default. Networks that don't validate or don't publish ROAs are increasingly anomalous.

For a hosting company, current best practice:

1. Publish ROAs for all your prefixes.
2. Validate RPKI on incoming announcements.
3. Drop RPKI-invalid routes.

This is mostly a one-time setup. Once in place, it runs itself.

Other BGP security measures

Beyond RPKI, several other mechanisms help:

Max prefix limits. Each peer announces an expected maximum number of prefixes. If they suddenly announce way more (a leak), the session is dropped.

Peer locking. Verifying that specific peering links never carry routes from specific ASes. Catches some path-level mistakes.

IRR-based filters. Internet Routing Registry data, where networks declare what they intend to announce. Filtered before propagation. Older than RPKI, less cryptographically rigorous, still useful.

BGPSec. Cryptographically signs the AS path itself, preventing path manipulation. Standardized but very limited deployment due to performance and operational complexity.

MANRS (Mutually Agreed Norms for Routing Security). A community initiative where networks commit to best practices: filter prefixes, prevent spoofing, coordinate, validate. Reputation effect.

Layered defense. Each catches different incidents. None alone is sufficient.

What an operator should do

If you run an AS:

1. Publish ROAs for all your prefixes. Free, takes minutes per prefix.
2. Validate RPKI on incoming announcements. Open-source validators (Routinator, Octorpki, FORT) are well-supported.
3. Drop invalid routes. This is the action that prevents hijacks of your prefixes.
4. Filter what you announce. Don't accidentally leak.
5. Filter what you accept. From transit, only accept defaults or appropriate subsets. From peers, only accept their own prefixes.
6. Set max-prefix limits on each peer session.
7. Monitor your prefixes. Tools like BGPmon, RIPE NCC Looking Glass alert when your prefixes are announced from unexpected origins.

This is the modern operational baseline. Networks that skip these steps are taking unnecessary risks.

What an ordinary user should do

For end users, BGP security is mostly out of your hands. You depend on your ISP and on the services you visit having reasonable BGP hygiene.

What you can do:

• Use HTTPS for sensitive operations. A BGP hijack would still need to overcome HTTPS encryption to actually steal data.
• Be aware that internet outages sometimes have BGP causes. Don't immediately assume "the service is broken" when it might be "BGP is having a moment."
• Read incident postmortems when they're published; they're educational.

A balanced view

It's tempting to read this article and feel that BGP is dangerously broken. It is, but with major caveats:

• Despite the lack of fundamental authentication, the internet works most of the time.
• Operational practice has improved enormously over 30 years.
• RPKI is genuinely making a difference.
• The community responds quickly when incidents happen.

The internet is not a precisely-engineered fortress. It's a working compromise that has been improved iteratively. BGP security is one of those areas where the iteration is ongoing.

Coming up

BGP and RPKI cover the "how do networks decide where things are" layer. The next article moves to the commercial layer: peering and transit, the agreements that determine which paths exist in the first place.