BGP Deep Dive Part 12: Security, or Why BGP Trusts You Until Proven Otherwise

Every part of this series so far has described BGP as a protocol that works, in the sense that it does exactly what it was designed to do: propagate reachability information between autonomous systems, apply policy to it, and converge on a consistent view of the network. Nothing in RFC 4271 says anything about whether the reachability information a neighbor sends you is true. BGP was designed in 1989, on napkins, by engineers who trusted the other networks on the early internet because there were a small, known number of them and everyone more or less knew everyone else. That assumption was reasonable in 1989. It has not been reasonable for a very long time, and this closing part covers what happens when it’s violated, and what the industry has actually built to catch it.

What a hijack or a leak actually is

A BGP hijack is a router originating an announcement for a prefix it doesn’t own, either accidentally (a misconfiguration) or deliberately (an attack). A route leak is different: it’s a router correctly propagating a route it legitimately learned, but to a peer it shouldn’t have propagated it to, violating the routing policy the two networks agreed to, without ever forging anything. Both produce the same practical symptom: traffic that should have gone to the legitimate destination now goes somewhere else instead, because the best path algorithm covered in Part 4 has no way to know the winning path is illegitimate. If a bogus announcement carries a shorter AS_PATH, or a more specific prefix that wins on longest-match before BGP’s own algorithm ever runs, it wins, exactly the way Part 8 described specificity mattering for entirely legitimate traffic engineering.

Three incidents that shaped how the industry thinks about this

AS7007, April 1997. A router operated by MAI Network Services (AS7007) leaked a large portion of the global routing table, deaggregated into more specific /24 prefixes and with the AS_PATH rewritten to just AS7007. Because more-specific prefixes win on longest-match regardless of AS_PATH length, and because the leaked routes claimed a one-hop path to everything, a huge share of the internet’s traffic was drawn toward AS7007’s router, which had nowhere near the capacity to handle it and dropped nearly all of it. It took roughly two hours to resolve, once upstream providers started filtering the announcement. This is generally regarded as the first major internet disruption caused by a routing leak, not an attack, an accident, and it’s the incident that pushed the industry toward taking prefix filtering and IRR-based route registration seriously as an operational discipline rather than an optional nicety.

Pakistan/YouTube, February 2008. Pakistan’s government ordered Pakistan Telecom to block YouTube domestically. Pakistan Telecom implemented the block by having its router originate a more-specific announcement for YouTube’s address space, intending to black-hole it locally. The announcement leaked to Pakistan Telecom’s international upstream, which propagated it globally, because nothing in BGP validates that an AS is authorized to originate a given prefix. YouTube became unreachable for a large share of the global internet for roughly two hours, not because anyone outside Pakistan wanted it blocked, but because BGP had no mechanism to distinguish “this AS legitimately originates this prefix” from “this AS just said so.”

MyEtherWallet, April 2018. An attacker hijacked the prefix covering Amazon’s Route 53 DNS infrastructure used by MyEtherWallet, redirecting DNS queries to a malicious server that returned a fake site’s IP address, paired with a fraudulently obtained TLS certificate for the domain. Victims who resolved myetherwallet.com during the roughly two-hour window were connecting to an attacker-controlled site with a certificate that made it look legitimate, and lost cryptocurrency directly, not through denial of service, through theft. This is the incident most often cited to make the point that a routing-layer attack isn’t just an availability problem: it’s a foothold that other trust layers, DNS and TLS included, can inherit uncritically once the underlying path has been hijacked.

Read together, these three incidents span three decades and three different causes, an accident, a deliberate censorship measure that spread further than intended, and a deliberate financial attack, but the same underlying gap runs through all of them: nothing in BGP-4 as specified verifies that an AS is authorized to originate a prefix, or that a path is genuinely the path it claims to be.

RPKI and Route Origin Validation: fixing the origin problem

Resource Public Key Infrastructure gives IP address holders a way to cryptographically attest which AS is authorized to originate their prefixes. A Route Origin Authorization (ROA) is a signed object, published by the prefix holder through their regional internet registry, stating “AS X is authorized to originate prefix Y, up to a maximum length Z.” RFC 6811 defines Route Origin Validation: a router fetches the set of validated ROAs (usually via the RPKI-to-Router protocol from a local validator cache, not directly from the RPKI repositories) and checks each received route’s origin AS against them, producing one of three states: Valid (a matching ROA exists), Invalid (a ROA exists for the prefix but names a different origin AS, or the prefix is more specific than the ROA’s max length allows), or NotFound (no ROA exists at all, an unknown, not a failure).

Crucially, RFC 6811 defines the validation states; it does not mandate what a router does with them. Common practice, and what most operators actually configure, is to reject Invalid routes outright while still accepting NotFound routes, since large parts of the internet still have no ROA published for their prefixes and rejecting NotFound wholesale would break reachability to a meaningful fraction of the internet. ROV would have stopped the Pakistan/YouTube incident outright: Pakistan Telecom’s announcement of YouTube’s prefix would have validated as Invalid at any router doing ROV, since Pakistan Telecom was never the authorized origin. It would not, on its own, have stopped MyEtherWallet’s hijack if the attacker had used a valid-looking origin, ROV only validates the origin AS, not the full path, which is exactly the gap BGPsec was designed to close.

BGPsec: cryptographic path validation, and why it hasn’t taken off

RFC 8205 defines BGPsec, which extends ROV’s approach from validating only the origin to validating the entire AS_PATH cryptographically. Each AS that propagates a BGPsec-secured route signs the UPDATE, attesting that it received the route from the AS listed immediately before it in the path and is knowingly propagating it onward. A receiving router can then verify, cryptographically, that the path a route claims to have taken is the path it actually took, closing the gap ROV leaves open: forged or manipulated AS_PATHs.

BGPsec has not seen meaningful production deployment. The reasons are structural rather than technical: full path validation only provides real protection once it’s deployed broadly enough along a path that an attacker can’t simply route around the secured segment, meaning its value to any single early adopter is small relative to its cost, a classic collective-action problem. It also requires signing and verifying every propagated UPDATE, a real computational cost at internet-routing-table scale, and it requires every AS on a path to participate for the guarantee to hold end to end. The industry’s practical response has instead concentrated on ASPA (Autonomous System Provider Authorization), a lighter-weight mechanism for validating provider relationships and catching route leaks specifically, rather than full path cryptography, precisely because it’s incrementally useful even with partial deployment. BGPsec remains specified and implementable, but ROV, not BGPsec, is what has actually seen production adoption across major router vendors and networks.

MANRS: the operational baseline

Where RPKI and BGPsec are protocol mechanisms, MANRS (Mutually Agreed Norms for Routing Security), launched in 2014, is an operational commitment. It defines four concrete actions network operators can adopt: filtering announcements to ensure prefix and AS-path correctness, anti-spoofing via source address validation, maintaining globally accessible and current contact information so problems can actually be reported and reached, and publishing routing information (which in practice today largely means RPKI ROAs) so others can validate against it. None of this is novel technology. It’s the same discipline RFC 7454, already covered in Part 8, recommends, formalized as a set of commitments operators can publicly sign up to and be counted against.

The honest summary

BGP’s security model, thirty-plus years in, is a layered set of partial mitigations rather than a single fix: RFC 7454-style prefix and AS-path filtering at the policy layer, RPKI/ROV catching origin hijacks like Pakistan/YouTube specifically, MANRS as an operational baseline operators can commit to and be held to, and BGPsec sitting mostly unused as the more complete answer nobody has found a practical path to deploying at scale. None of it retroactively makes BGP a protocol that verifies what it’s told. It makes BGP a protocol where a growing share of the internet now checks what it’s told against something a prefix holder actually signed, which is a meaningfully different and better position than 1989’s, or 1997’s, or 2008’s, without being a solved problem.

That closes the theory arc of this series. The next parts turn to implementation: Cisco, Juniper, and FortiOS BGP configuration and troubleshooting on real hardware, and BGP on Linux with FRR, extending the lab this site’s OSPF on Linux series already built. Those parts wait on physical lab prep, but the theory that will make sense of whatever comes out of that hardware is now fully written.