JOVANA
Explore Library Glossary Getting Started Three Levels Fields How it works Mission
Join the mission
All guides

When BGP Goes Wrong: Hijacks and Leaks

BGP holds the whole Internet together by trusting whatever each network claims about itself. This last guide in the rung asks the uncomfortable question that trust raises: what happens when a network lies, by accident or on purpose, and the entire Internet quietly believes it?

A protocol built on trust

Across this rung you have watched the Border Gateway Protocol do something quietly astonishing: stitch tens of thousands of separately owned networks into one Internet by having each autonomous system simply announce which destinations it can reach and by what AS path. In the previous guide you saw that BGP picks routes by policy and money, not by shortest distance. But there is a deeper assumption hiding underneath all of it, and this guide drags it into the light: BGP believes what it is told. When a network announces 'I am the home of 203.0.113.0/24', its neighbours have no built-in way to check whether that is true. They just write it down and pass it on.

This is not an oversight; it is the original design from an era when the handful of networks on the early Internet genuinely did trust one another, and adding cryptographic proof to every announcement would have been a heavy burden nobody felt they needed. The result is a global system whose correctness rests on every participant being both honest and careful. Most are. But 'most' is the operative word, and the gap between most and all is exactly where things go wrong, in three flavours we will work through: route flapping (instability), hijacks (a network claiming addresses that are not its own), and leaks (a network passing along routes it should have kept to itself).

Route flapping: a route that cannot sit still

Start with the gentlest failure, because no one is even lying. Route flapping is what happens when a route is announced, then withdrawn, then announced again, over and over, often because a physical link or a router somewhere is unstable, flickering up and down like a loose lightbulb. Each flicker is news, and BGP dutifully spreads news: every flap generates an announcement or a withdrawal that ripples outward across the default-free zone, forcing distant routers to recompute and re-advertise. One twitchy link in one small network can pump a storm of updates through routers an ocean away.

The danger is not any single flap but the multiplier. A router drowning in churn spends its time reprocessing routes instead of forwarding packets, and the instability can amplify rather than settle. The classic defence is route flap damping: a router watches how often a given prefix flaps, gives it a rising penalty score, and once the score crosses a threshold it suppresses that route for a while, deliberately ignoring further news about it until the source proves it has calmed down. It is the network equivalent of telling a panicking friend, kindly but firmly, to go sit down until they can speak in complete sentences.

Hijacking: claiming addresses that are not yours

Now the lie. A BGP hijack is when an autonomous system announces a prefix it has no right to. Suppose a bank really owns 198.51.100.0/24. Some other network, by accident or malice, starts announcing 'I can reach 198.51.100.0/24 too.' Because BGP trusts announcements, that route propagates, and every router that comes to prefer the false path will hand the bank's traffic to the impostor instead. The victim need not even notice their own service still works fine for the people whose routers stuck with the real path; only the misled portion of the Internet is silently sending traffic the wrong way.

Two ingredients make hijacks especially potent. The first is longest-prefix match, the forwarding rule from the addressing rung: a router always prefers the most specific prefix. If the bank announces 198.51.100.0/24 and the attacker announces the narrower 198.51.100.0/25 and 198.51.100.128/25, those more specific routes win everywhere they reach, regardless of policy or AS path length. The second is that the attacker can make the path look legitimate by prepending the real owner's AS number, so the route reads as though it ends at the genuine network. Hijacks have caused real harm: traffic for whole countries has been briefly funnelled through the wrong network, sometimes by mistake, sometimes to eavesdrop or to swallow traffic into a black hole.

Sub-prefix hijack, why the more specific route wins

  Real owner  (AS 64500) announces:  198.51.100.0/24   path: ... 64500
  Attacker    (AS 64999) announces:  198.51.100.0/25   path: ... 64999 64500
                                     198.51.100.128/25  path: ... 64999 64500

  Router forwarding to 198.51.100.42:
    /24  matches  (covers .0  - .255)
    /25  matches  (covers .0  - .127)   <-- more specific
  longest-prefix match => pick the /25 => traffic goes to AS 64999

  Note the forged path ends in 64500, so it *looks* legitimate.
A sub-prefix hijack beats the real route everywhere it reaches, because longest-prefix match ignores AS-path length and policy entirely, and prepending the real owner's AS number disguises the lie.

Leaks: telling the right truth to the wrong neighbour

A route leak is subtler than a hijack, and arguably more common, because nobody claims to own anything they do not. A leak is announcing a route that is true but should not have been passed in that direction. Recall the economics from earlier in this rung: in a provider-customer relationship you pay your provider to carry your traffic to the rest of the world, while with a peer you exchange only each other's customer traffic for free. The unspoken rule that keeps the money sane is the valley-free rule: you advertise your customers' routes to everyone, but you must not re-advertise routes learned from one provider or peer onward to another provider or peer. Do that, and you have just volunteered to carry their traffic for free, and worse, told the Internet you are a shortcut you are not equipped to be.

The damage from a leak is congestion and outage rather than theft. A small regional network mistakenly re-advertises the routes it hears from one big provider to another big provider; suddenly both giants think this tiny network is a viable transit path between them, and they pour traffic through links that can carry a thousandth of it. The little network melts, and so does connectivity for everyone whose traffic got rerouted into the jam. This is essentially a self-inflicted denial of service, and it has taken large chunks of the Internet offline more than once. Leaks are usually honest mistakes, a misconfigured filter, a fat-fingered policy, which is precisely why they are so hard to stamp out: there is no villain to catch, just a missing safety check.

Adding the verification BGP forgot

If the root cause is that BGP accepts claims on faith, the cures all add a way to check claims. The most basic and most effective is prefix filtering: a provider configures its routers to accept from each customer only the prefixes that customer is actually authorised to announce, and rejects everything else. Done diligently by everyone, this would block most leaks and many hijacks at the edge, the trouble is that it relies on every network keeping accurate filters, and one lazy network upstream undoes the diligence of many.

The deeper fix is cryptographic, under the umbrella of the Resource Public Key Infrastructure (RPKI). Address owners publish signed records, Route Origin Authorisations, stating which AS is allowed to originate each prefix. A router can then perform Route Origin Validation, checking an incoming announcement against these signed records and rejecting one whose origin AS does not match. This directly defeats the simplest hijacks. Be honest about its limits, though: origin validation proves who is allowed to announce a prefix, not that the whole AS path is genuine, so a clever attacker who forges a plausible path can still slip through. Closing that last gap needs path validation (the work known as BGPsec), which is far more demanding and barely deployed.

  1. An address holder registers a signed Route Origin Authorisation in the RPKI: 'AS 64500 is authorised to originate 198.51.100.0/24.'
  2. A router receives a BGP announcement for 198.51.100.0/24 and reads the origin AS at the far end of its AS path.
  3. It looks up the prefix in its cache of validated RPKI records and compares the announced origin against the authorised one.
  4. If they match, the route is valid; if the origin is wrong, it is invalid and the router can drop or de-prefer it, stopping the simplest hijacks at this border.
  5. But note the gap: this checks only the origin, not the rest of the path, so a forged-but-plausible AS path can still evade it until path validation is widely deployed.

Step back and the whole rung clicks into place. BGP is the glue of the Internet precisely because it is permissive: any network can join, announce its reachability, and have the world route to it, no central authority required. That same permissiveness is its fragility, the price of a system held together by advertised paths and mutual trust is that a single false or careless announcement can mislead the planet. The Internet does not work because BGP is safe; it works because most operators are careful most of the time, and because, slowly, we are bolting on the verification the protocol never had. Understanding that trade-off, openness bought with fragility, is the real lesson of inter-domain routing.