BGP Route Leak vs Hijack: Differences, Detection and Prevention
Last updated
A BGP hijack and a route leak both send traffic where it should not go, but they break different rules. In a hijack, a network announces IP prefixes it is not authorized to originate, so the origin of the route is wrong. In a route leak, the origin is correct but a network passes the route on to neighbors it should have kept it from, so the path is wrong. RPKI Route Origin Validation detects origin hijacks of prefixes that are covered by ROAs; ASPA is designed to detect route leaks.
What is a BGP hijack?
A hijack is an announcement of address space by a network that has no right to originate it. Because BGP routers believe their neighbors by default, the false route spreads like any other and attracts some or all of the traffic for those addresses. Common forms:
- Exact-prefix origin hijack: the attacker announces the same prefix as the legitimate holder. Networks closer to the attacker prefer the false route; others keep the real one, so the internet is split.
- Sub-prefix hijack: the attacker announces a more-specific prefix inside the victim's block (for example a /24 inside a /22). Longest-prefix match makes almost every network prefer it, so this is the most effective and most dangerous form.
- Forged-origin hijack: the attacker appends the legitimate origin AS to the end of its own announcement, so the origin looks right while traffic still flows to the attacker.
- Squatting: announcing address space that is allocated but not currently routed, often for spam or abuse that should not be traced back.
Most hijacks are accidents: a typo in a static route, a wrong prefix in a redistribution filter, or a test announcement that escapes. One widely documented example is the YouTube incident of 24 February 2008: acting on an order to block YouTube in Pakistan, Pakistan Telecom (AS17557) announced 208.65.153.0/24, a more-specific of YouTube's address space. The announcement leaked to its upstream provider (AS3491), which propagated it worldwide, and YouTube was unreachable from much of the internet for about two hours until the upstream withdrew the route.
What is a route leak?
RFC 7908 defines a route leak as the propagation of routing announcements beyond their intended scope. The route itself is genuine and has the right origin; it simply travels through a network that should not have passed it on. The typical case is a multihomed customer that learns routes from one transit provider and re-announces them to another, turning itself into an unintended transit path for traffic it cannot handle.
The rules being broken are the export rules between customers, providers and peers: routes from providers and peers may only be announced to customers. RFC 7908 classifies leaks into types, among them:
| Type | What happens |
|---|---|
| Hairpin turn | A customer passes a route learned from one provider to another provider. |
| Lateral leak | A network passes a route learned from one peer to another peer. |
| Provider prefixes to peer | A network passes routes learned from a transit provider to a peer. |
| Peer prefixes to provider | A network passes routes learned from a peer to a transit provider. |
| Re-origination | A network re-announces a learned prefix as if it originated it (which also looks like a hijack). |
| Internal or more-specific leak | Prefixes meant only for internal use or traffic engineering escape to the internet. |
Leaks often hit large numbers of prefixes at once, because the leaking network passes on a whole table rather than one route. Optimizer software that creates more-specific routes for internal traffic engineering is a recurring source when those routes escape.
Route leak vs hijack at a glance
| Hijack | Route leak | |
|---|---|---|
| Origin AS | Wrong (or forged) | Correct |
| AS-path | Usually short and new | Contains a network that should not be there |
| Typical cause | Misconfiguration, sometimes attack | Missing export filter |
| Scope | One or a few prefixes | Often hundreds or thousands of prefixes |
| Detected by RPKI ROV | Yes, if the prefix has a ROA (except forged origins) | No, the origin is valid |
| Detected by ASPA | Some forged-origin paths | Yes, where the networks involved publish ASPA |
How they look in BGP data
Suppose AS64500 holds 203.0.113.0/24 and buys transit from AS64501. The normal path seen by a distant network might be:
203.0.113.0/24 64510 64501 64500An exact-prefix hijack by AS64511 shows a different origin. Two origins for the same prefix at the same time is called a MOAS (multiple origin AS) conflict:
203.0.113.0/24 64510 64511A sub-prefix hijack adds a more-specific that did not exist before:
203.0.113.0/25 64512 64511
203.0.113.128/25 64512 64511A route leak keeps the origin but inserts a network that has no business being there - here AS64520, a customer of both AS64501 and AS64530, leaking routes from one provider to the other:
203.0.113.0/24 64530 64520 64501 64500All prefixes and ASNs above are from the documentation ranges. The patterns to watch for are:
- A new origin AS for a known prefix: possible exact-prefix hijack (MOAS).
- New more-specifics of a known prefix: possible sub-prefix hijack.
- An RPKI state change from valid to invalid: wrong origin or prefix length.
- A small network suddenly appearing between two large ones in many paths: possible route leak.
How to detect hijacks and leaks
Detection works best when it combines several signals:
- RPKI ROV: an announcement of a prefix with a ROA from the wrong origin, or longer than the ROA's maxLength, is RPKI-invalid. The BGP statistics page lists RPKI-invalid routes seen in the global table.
- ASPA: a path containing a hop that a published ASPA does not authorize is invalid; see the ASPA check guide for a hop-by-hop example.
- Origin and more-specific monitoring: alert when your prefixes appear with an unexpected origin AS or with new more-specifics.
- Data-plane checks: traceroutes from several locations show whether traffic actually reaches your network.
ipctl tags prefixes involved in suspected hijacks as hijacked or possibly_hijacked. The tags are returned by the API's prefix and threat intelligence endpoints and shown on the lookup pages, including the IP reputation check.
How to prevent them
Protect your own prefixes against hijacks
- Create ROAs for every prefix you announce, with maxLength equal to the announced length, so sub-prefix hijacks are RPKI-invalid.
- Register matching IRR route objects so providers that filter on IRR data accept your real routes.
- Monitor your prefixes for new origins and more-specifics.
Avoid leaking, and stop others' leaks
- Apply explicit export policies on every eBGP session: to providers and peers, announce only your own and your customers' prefixes.
- Use BGP roles and the Only-to-Customer attribute (RFC 9234) where supported, so the session itself enforces the relationship.
- Filter customer announcements by prefix list and set maximum-prefix limits on all sessions.
- Drop RPKI-invalid routes, and publish an ASPA listing your providers so others can detect leaks of your routes.
What to do if your prefix is hijacked
- Confirm it from several vantage points: look up the prefix and its more-specifics and check which origin AS other networks see.
- Make sure your ROAs are correct. If they are, networks that enforce ROV already drop the false route, which limits the damage.
- Contact the network operations center of the announcing AS and of its upstream providers; the upstreams can filter the announcement fastest.
- If the hijack is an exact-prefix one, announcing more-specifics of your own space (no longer than /24 for IPv4, which is the usual filter limit) can win back traffic - create matching ROAs first.
- Report the incident to your own providers and keep timestamps and path data for the post-mortem.
Frequently Asked Questions
What is the difference between a route leak and a BGP hijack?
In a hijack the origin of the route is wrong: a network announces address space it does not hold. In a route leak the origin is right, but the route travels through a network that should not have passed it on.
Does RPKI protect against route leaks?
Not by itself. RPKI Route Origin Validation checks only the origin AS, and a leaked route has the correct origin. ASPA, which also uses the RPKI, is designed to detect leaks.
Are most BGP hijacks malicious?
No. Most are configuration mistakes such as typos in prefix lists or routes meant for internal use escaping. Deliberate hijacks do happen, for example to steal traffic or to send spam from unused address space.
What is a sub-prefix hijack?
An announcement of a more-specific prefix inside someone else's block. Because routers forward on the longest matching prefix, it attracts traffic even where the legitimate, shorter route is also present. A ROA with a tight maxLength makes it RPKI-invalid.
What is a MOAS conflict?
Multiple Origin AS: the same prefix announced by two or more different origin ASes at once. It can be legitimate (anycast, or a provider announcing customer space) or a sign of a hijack.
How can I tell if my network is leaking routes?
Check that your announcements to providers and peers contain only your own and your customers' prefixes. If public route collectors show your ASN in the middle of paths to networks that are neither your customers nor yourself - for example between two of your providers - you are very likely leaking.