The internet's map is assembled from claims. Tens of thousands of independent networks tell their neighbors which addresses they can reach, and for most of BGP's life those neighbors simply believed them. This chapter is about what happens when a claim is wrong, by accident or on purpose, and about the filters, signatures and monitors that now let networks check a claim before they act on it.
Common mix-up: "RPKI-valid" does not mean a route is safe or correct. Route origin validation checks one thing: that the network at the end of the AS path is one the address holder authorized to originate that prefix. It says nothing about the networks in the middle of the path, and an attacker who writes the right origin AS at the end of a forged path passes it. It also encrypts nothing: that is TLS's job.
Read first: this chapter assumes you know how BGP sessions, AS paths and best-path selection work, covered in Dynamic routing: OSPF & BGP, and how a router picks the longest matching prefix, covered in Routing tables & longest-prefix match. Here we go straight to what breaks and how it is defended.
When a network announces a prefix over BGP it is making a statement: "send traffic for these addresses to me, and here is the list of networks it will pass through." The protocol itself, as specified in RFC 4271, has no field that proves the statement. Nothing in a BGP UPDATE says who was given those addresses by a registry, and nothing proves that the networks in the AS path actually agreed to carry the traffic. A router learns what its neighbors tell it, applies its operator's local policy, and passes the result on.
That design made sense in a small research network where every operator knew every other one. It still mostly works, because the great majority of networks are run carefully. But the internet now has tens of thousands of autonomous systems, and the trust is transitive: if your provider believes its peer, and the peer believes a small customer on the other side of the world, then you believe that customer too. One mistyped prefix list can travel a long way in a few minutes.
Routing incidents fall into a few shapes. It is worth naming them precisely, because each one is stopped by a different defense.
| Shape | What the bad announcement says | Why it wins | Main defense |
|---|---|---|---|
| Origin hijack | The same prefix as the real holder, originated by the wrong AS | Some networks are closer to the wrong origin, or prefer the neighbor that heard it | Route origin validation (RPKI), prefix filters |
| More-specific hijack | A smaller slice of the holder's block: a /24 inside a /22 | Longest-prefix match: every router that hears it uses it, whatever the path | ROAs with tight maxLength, prefix filters, the /24 floor |
| Forged origin | The right origin AS, written at the end of a path that does not exist | It passes origin validation; it can still win on path length or relationship | Path validation: ASPA, BGPsec; filtering at the source |
| Route leak | A real route, passed on to a neighbor who should never have received it | Customer routes are preferred, so a leak through a customer is attractive | Export policy, RFC 9234 roles, max-prefix limits, ASPA |
Most incidents are accidents. A router reboots with a half-applied configuration, a test announcement escapes a lab, an operator re-advertises a whole table instead of their own handful of prefixes. Deliberate hijacks happen too, to intercept traffic, to send spam from someone else's addresses, or to impersonate a service long enough to collect something valuable. Defenders do not need to know which it was to respond: the fix for both is to stop believing unverified claims.
The best-documented early example is a pattern case, not a mystery. On 24 February 2008 a network in Pakistan began announcing a /24 that sat inside a /22 belonging to YouTube; one of its upstream providers passed it to the rest of the internet, and YouTube traffic around the world followed the more specific route. The RIPE NCC's case study, built from its public route collectors, times the whole event: the bad /24 appeared at 18:47 UTC, YouTube countered with two /25s at 20:18, and the upstream withdrew the bad route at 21:01. Notice that the /25s were seen by only 21 of the 112 collector peers that saw YouTube's /22. Most of the internet ignores anything smaller than a /24, a convention that becomes important below.
This is a toy internet of sixteen networks, labeled by the last three digits of their documentation AS numbers (AS64496 to AS64511). The three at the top are large transit networks that peer with each other; the middle five buy transit from them; the eight at the bottom are customers. Solid lines run from provider down to customer; dashed lines are settlement-free peering. The victim, AS64504, originates 203.0.113.0/24. Pick a misbehaving network and what it does, then decide which networks run route origin validation. The program runs a simplified BGP decision at every network (prefer a route learned from a customer, then from a peer, then from a provider; then the shorter AS path), then follows a packet addressed to 203.0.113.200 hop by hop, doing a longest-prefix match at every router, and colors each network by where its traffic really ends up.
Key: a filled circle reaches the victim (blue); a filled diamond reaches the misbehaving network (orange); a green square ring marks a network that validates and drops RPKI-invalid routes. Click a network to toggle its validation, or use the chips above. Captured counts the fourteen networks other than the victim and the culprit.
An origin hijack has to compete. Every network that hears both the real announcement and the false one runs its best-path selection, and the outcome depends on where it sits: networks closer to the impostor, or that hear the impostor from a customer, tend to pick it; networks closer to the victim do not. Run Instrument 1 with an origin hijack and you will see the map split, usually somewhere near the middle.
A more-specific hijack does not compete at all. Best-path selection only ever compares routes for the same prefix. A router holding both 203.0.113.0/24 and 203.0.113.128/25 keeps both in its table, and when a packet arrives for an address in the upper half, longest-prefix match sends it along the /25 regardless of AS path length, local preference or anything else. So a more-specific announcement wins at every router it reaches.
The limit on this is social, not technical. Routing tables have to fit in router memory, and if everyone announced every /32 the global table would be unmanageable. So operators converged on a floor: as RFC 7454 notes, citing the RIPE community, IPv4 prefixes longer than /24 and IPv6 prefixes longer than /48 are generally neither announced nor accepted. That is why the 2008 /25 counter-announcements reached only a fraction of the collectors. It also means the most dangerous more-specific hijack is a /24 carved from a larger block. A holder who announces only a /22 has four /24s that anyone can try to claim; a holder who announces /24s has none left to take.
Turn off "drop prefixes longer than /24" in Instrument 1 and choose the /25: the whole map turns orange, because in this toy every network then accepts it. Turn the convention back on and the /25 dies at the culprit's first neighbor.
The 2008 response shows the emergency move: if someone is hijacking your /24, announce something more specific yourself. Inside the /24 floor this only works for networks that accept longer prefixes, and in IPv4 there is nothing more specific than a /24 to fight over. Announcing your space as /24s permanently, instead of one aggregate, closes the more-specific hole in advance but adds entries to every router's table on the internet, which is why RFC 7454 and most operators prefer the defense to come from ROAs and filters rather than from everyone de-aggregating.
Validating networks also suffer a subtle effect you can provoke in Instrument 1: pick the forged-origin /25, a loose ROA, and the /24 floor off, then make only a few networks validate. Some validators still deliver to the culprit, counted as "validators hit anyway." They correctly kept the /24, but forwarded the packet to a neighbor that holds the /25, and that neighbor's longest-prefix match decides. Validation protects the networks downstream of it, not the ones that merely run it.
A route leak carries no lie about who owns the prefix. The route is real; it has simply gone somewhere it should not. RFC 7908 defines a leak as the propagation of routing announcements beyond their intended scope, an announcement from one AS to another that violates the receiver's or the sender's policies or both.
Those policies come from money. Between two networks there are, in the simplest model, two kinds of relationship. A customer pays a provider to carry its traffic to and from the whole internet. Two peers exchange traffic between their own customers for free. Each network wants to carry traffic only when someone pays it to, which gives a simple export rule, often named after Lixin Gao and Jennifer Rexford, who analyzed it:
| Route learned from | Export to customers | Export to peers | Export to providers |
|---|---|---|---|
| My own prefixes | Yes | Yes | Yes |
| A customer | Yes | Yes | Yes |
| A peer | Yes | No: leak | No: leak |
| A provider | Yes | No: leak | No: leak |
Follow that rule everywhere and every legitimate AS path has the same shape: it climbs from the origin up through providers, crosses at most one peering link at the top, and then descends through customers. Drawn with providers above customers, the path is a hill, never a valley. A path that goes down and then up again means somebody in the dip passed a provider's route to another provider. That network is now offering free transit between two large networks over its own, usually small, links, and whatever traffic follows may overwhelm them.
Leaks are dangerous for exactly the reason that makes them tempting to the receiver. In Instrument 1, choose AS64505, a customer of two middle-tier networks, and set it to leak. One of its providers now hears the victim's route from a customer, and customer routes beat peer and provider routes, so that provider and everyone below it start sending the victim's traffic through a small network that never meant to carry it. The readout counts how many networks' traffic now detours through the leaker.
Route origin validation does nothing here: the origin is genuine. The defenses are on the export side (configure what you send, not just what you accept), and in newer protocol work. RFC 8212 changed the default so that an external BGP session with no policy configured sends and accepts nothing, closing the "forgot the filter" class of leak. RFC 9234 (2022) lets two neighbors agree their relationship when the session opens and stamps routes with an Only-to-Customer attribute, so a route that has already started descending cannot be sent back up without the next network noticing.
RFC 7908 classifies leaks so operators can talk about them precisely. Type 1 is the hairpin turn: a multihomed customer passes one provider's full route to its other provider. Type 2 is a lateral leak, a network passing a route from one peer to another peer. Type 3 leaks a provider's routes to a peer, and Type 4 leaks a peer's routes to a provider. Type 5 re-originates a prefix as if it were the leaker's own, with traffic still able to reach the real holder. Type 6 is the accidental leak of internal prefixes or more-specifics that were meant to stay inside a network.
Types 1 to 4 are all valley-free violations and are exactly what Instrument 3 detects. Type 5 looks like an origin hijack to an outside observer, and Type 6 looks like a more-specific announcement, which is why the same monitoring catches all of them.
Build the journey of an announcement across the same toy internet, starting from the network that originates it. Click networks in order on the map (each one must be a neighbor of the last), or pick them from the list and press Add. The checker labels every hop as up (customer to provider), across (peer to peer) or down (provider to customer), applies the valley-free rule, and names the network whose export broke it.
The Resource Public Key Infrastructure, described in RFC 6480, attaches cryptography to the one thing the routing system already has an authority for: who holds which addresses and AS numbers. The five Regional Internet Registries allocate address space; in the RPKI each also issues a resource certificate that says, in signed form, "this key belongs to the holder of these addresses." The holder can then use that key to sign a Route Origin Authorization, a ROA: a small object that lists one or more prefixes, an optional maximum length for each, and the single AS number allowed to originate them.
Routers do not check signatures themselves. A relying party, or validator, is a program the network runs next to its routers. It downloads every published RPKI object from the registries' repositories, walks the certificate chains up to the five registry trust anchors, discards anything expired, revoked or badly signed, and boils what is left down to a flat list of Validated ROA Payloads, or VRPs: (prefix, maxLength, origin AS) triples. It feeds that list to routers over the RPKI-to-Router protocol (RFC 8210). The router then needs only a fast table lookup for each route it hears.
RFC 6811 defines what the router does with that list. For each route it looks at the prefix and the origin AS, the last AS in the path. A VRP covers the route if the route's prefix sits inside the VRP's prefix. A VRP matches if it covers the route, the route is no longer than the VRP's maxLength, and the origin AS is the VRP's AS.
That three-way outcome is the deployment trick that made RPKI practical. Nobody had to sign everything on day one. Each holder who publishes a ROA immediately gains protection at every network that drops Invalid routes, and holders who have not yet published lose nothing. The setting that matters is what operators do with Invalid. RFC 6811 leaves it to local policy; the common modern policy, and the one Cloudflare's public "Is BGP safe yet?" tracker asks networks to adopt, is to reject Invalid routes outright.
A ROA can also say "nobody." A ROA naming AS 0, which can never appear as a real origin, makes every covering announcement Invalid; holders use it for address space they do not route at all, so nobody else can quietly announce it.
maxLength exists for convenience. A holder of a /22 who sometimes announces /24s from it could publish one ROA with maxLength 24 instead of five separate ROAs. But a ROA with maxLength longer than what the holder actually announces authorizes routes that nobody is advertising. That gap is an opening for a forged-origin sub-prefix hijack: an attacker announces one of those unused more-specifics, writes the holder's AS as the origin at the end of the path, and the route comes out Valid. Because it is more specific, it then wins everywhere it is accepted.
RFC 9319 (2022, BCP 185) responds directly: avoid maxLength except in specific cases, and list exactly the prefixes you announce. The arithmetic shows why the habit is risky: a ROA for a /32 with maxLength 48 authorizes 217 − 1 = 131,071 distinct prefixes, almost all of them unannounced. Instrument 2 computes that number for every ROA you type, and its "maxLength trap" preset shows a forged route sailing through as Valid.
Type ROAs on the left, one per line, as prefix maxLength AS (maxLength may be left out, meaning exactly the prefix length). Type announcements on the right as prefix followed by the AS path, nearest network first; the last number is the origin. IPv4 and IPv6 both work. Results update as you type and follow RFC 6811 to the letter; the only addition is that Invalid is split into its two causes, which the RFC treats as one state.
Route origin validation checks the last number in the AS path and nothing else. That was a deliberate first step: the origin is the one fact a registry can vouch for. But it means a careful attacker can defeat it by writing the legitimate origin at the end of a fabricated path. In Instrument 1, choose "Forged origin" and make every network validate: the capture barely changes, because the forged route is Valid. The forged route is one hop longer than the real one, which costs it some networks, but networks that hear it from a customer still prefer it.
Two pieces of work aim at the path itself.
| Defense | Stops | Does not stop | Status |
|---|---|---|---|
| IRR prefix filters | A customer announcing space it was not registered for | Anything from peers or providers you cannot list; stale registry entries | Long-standing practice (RFC 7454) |
| Max-prefix limits | A neighbor suddenly sending far more routes than normal (big leaks) | One bad prefix among normal traffic | Universal router feature |
| ROV (RPKI) | Wrong-origin and too-specific announcements of ROA-covered space | Forged origin, leaks, space with no ROA | Widely deployed; RFC 6811 |
| RFC 9234 roles / OTC | Most leaks, between neighbors that both support it | Hijacks | Published 2022; being implemented |
| ASPA | Most forged paths and valley-shaped leaks | Some short forged paths; ASes that publish nothing | IETF draft (as of Oct 2026) |
| BGPsec | Path forgery along fully signed paths | Paths through any non-BGPsec AS | RFC 8205; little deployment |
No single control above is enough, so routing security in practice is a stack. RFC 7454, "BGP Operations and Security" (BCP 194), is the checklist most operators start from: protect the BGP sessions themselves, filter prefixes on every session (special-purpose and unallocated space, prefixes that are too specific, your own space coming back at you), limit the number of prefixes each neighbor may send, and filter AS paths that make no sense.
MANRS, the Mutually Agreed Norms for Routing Security, turns that into four concrete actions for network operators. Filtering: ensure the correctness of your own announcements and your customers'. Anti-spoofing: validate source addresses, at least for single-homed customers and your own infrastructure (the denial-of-service side of this is in Chapter 09). Coordination: keep contact information current in routing databases so others can reach you during an incident. Global information: publish your routing policy and ROAs so others can validate you.
A customer-facing filter, written in vendor-neutral pseudo-configuration, looks like this. Real syntax varies by router; the logic is the point.
# session with customer AS64505 (pseudo-config, not a real vendor syntax) import from AS64505: reject if prefix length > 24 (IPv4) or > 48 (IPv6) # too specific reject if RPKI state == invalid # ROV accept only prefixes in AS64505's registered IRR set # e.g. 198.51.100.0/24 reject if AS path contains anything but AS64505 # stub customer: no transit max-prefix 10, then shut the session and alert # leak brake export to AS64505: send everything (customers get a full table or a default)
# the leak-shaped mistake: no import or export policy at all neighbor AS64505: (no filters) # RFC 8212 makes this send nothing by default
Detection is the last layer, and the one every prefix holder can do without any router of their own. Public route collectors, such as the RIPE NCC's Routing Information Service, peer with hundreds of networks and record every announcement they hear. Monitoring services built on those feeds keep a baseline of how your prefixes normally look (origin AS, prefix lengths, upstream neighbors) and alert when something new appears: a new origin for your prefix, a more-specific you never announce, or your route suddenly arriving through a network that is not one of your providers. Each of those maps onto a shape in the table at the top of this chapter. The response is mostly human: contact the networks involved, announce more-specifics if you still can, and publish or tighten your ROAs so the next one is dropped automatically.
For each prefix you hold, record the set of origin ASes you expect (usually one), the exact prefix lengths you announce, and your direct upstreams. For every update seen by a collector covering your space: if the origin is not in the expected set, raise a high-priority alert (possible origin hijack or Type 5 leak); if the prefix is more specific than anything you announce, raise one too (possible sub-prefix hijack or Type 6 leak); if the AS just before yours in the path is not one of your upstreams, raise a lower-priority alert (possible forged path or leak). Check the RPKI state of the alerting route as well: an Invalid route that is spreading widely tells you which networks are not yet enforcing validation.
NIST Special Publication 800-189 collects the same controls, origin validation, prefix filtering and leak prevention, into a set of security recommendations for interdomain traffic exchange, which is useful when you need to justify the work to someone who is not an operator.