In BGP, what is the difference between a prefix hijack and a route leak, and why do BGP speakers accept either one?
answer
- authority versus intended scope
- the origin is genuine in a leak
- traffic follows announcements in reverse
- RFC 7908's working definition
- RFC 4272's three vulnerabilities
basics
~20 sA prefix hijack announces address space, or a path to it, that the announcer has no right to claim; a route leak passes a genuine route beyond its intended scope. Base BGP verifies neither, so neighbours believe both.
solid answer
~50 sA **prefix hijack** misrepresents who may originate a prefix or how to reach it: an AS originates someone else's prefix, announces a more-specific part of it, or forges an `AS_PATH` that ends at the real origin. A **route leak**, in RFC 7908's working definition, is the propagation of a learned route beyond its intended scope: the origin and the path are real, but an AS passes, say, one provider's route to another provider or to a peer, against the policies of the ASes involved. Both pull traffic the same way, because traffic flows toward whoever announced the route. BGP accepts them because, as RFC 4272 sets out, the protocol itself has no mechanism to validate an AS's authority to announce a prefix or the authenticity of the path attributes; each speaker applies only its local policy to what its neighbours say.
go deeper
Recall the one-line split: a hijack is a false claim about who owns or reaches a prefix, a leak is a true route passed to neighbours who should not receive it.
Explain why both pull traffic: packets follow accepted announcements, and base BGP has no check on who may originate a prefix or whether a path is genuine.
Classify a live incident from the origin, the path shape and the data path, and know that re-origination leaks blur the line between the two families.
Frame the split as two different trust gaps, authority and relationship, which is why no single mechanism fixes both and a routing-security plan needs several.
## Two different failures BGP (Border Gateway Protocol, RFC 4271) is how independently run networks, called **autonomous systems (ASes)**, tell each other which address blocks they can reach. Every announcement carries a **prefix** (an address block such as `203.0.113.0/24`) and an `AS_PATH`, the list of ASes the announcement has crossed; the rightmost AS is the **origin**, the network that claims the prefix. Two families of incident abuse this exchange, and interviewers want them kept apart: - A **prefix hijack** is a false claim. Someone announces a prefix they do not hold, a more-specific slice of it, or a path that makes them look connected to the real holder. - A **route leak** is a true claim sent to the wrong place. RFC 7908 defines it as "the propagation of routing announcement(s) beyond their intended scope": an AS forwards a route it really learned, with its real origin and path, to a neighbour that, under the agreed policies, should never have received it. ## Traffic follows announcements An announcement is an invitation: if AS 64500 tells AS 64501 that it can reach `203.0.113.0/24`, and AS 64501 accepts and prefers that route, AS 64501 sends packets for that block to AS 64500. So any wrong announcement that is accepted pulls real traffic toward the announcer. RFC 4272 lists what can follow: packets dropped by a network that cannot deliver them, packets sent over a far longer path, and packets passing through a network that can read or modify them. ## The hijack family | Shape | What is announced | Why it attracts traffic | |---|---|---| | Exact-prefix origin hijack | the victim's own prefix, with the attacker as origin | competes with the real route; wins where policy and path length favour it | | More-specific (sub-prefix) hijack | a longer prefix inside the victim's block | a different, more specific prefix wins at forwarding time wherever it is accepted | | Forged-origin path hijack | a path such as `64511 64500` ending at the real origin | the origin looks right, so origin checks pass | ## The leak family RFC 7908 sorts observed leaks into six types: 1. **Hairpin turn**: a multihomed AS passes one upstream's route, unchanged, to another upstream. 2. **Lateral ISP-ISP-ISP leak**: a peer passes one peer's routes to another peer. 3. **Transit-provider prefixes to a peer.** 4. **Peer prefixes to a transit provider.** 5. **Re-origination**: the AS strips the received path and announces the prefix as its own, which makes a leak look like an origin hijack. 6. **Internal or more-specific prefixes** that were never meant to leave the AS. Types 1 to 4 differ only in which relationships the route crosses. The best-known early incident, AS 7007 in 1997, mixed both families: a router there re-announced a large part of the Internet's routing table, broken into more-specific /24s with AS 7007 as their origin, and its upstream propagated them, drawing traffic toward a small network that could not carry it. RFC 7908 notes that leaks are usually accidental misconfigurations, while a hijack may be accidental (a typo in a prefix) or deliberate. ## Why BGP believes both RFC 4272 names three fundamental vulnerabilities: 1. No strong built-in protection of the integrity, freshness and peer authenticity of BGP messages on a session. 2. No mechanism within BGP to validate the authority of an AS to announce a prefix. 3. No mechanism within BGP to ensure the authenticity of the path attributes an AS announces. Session protection such as TCP MD5 or its successor TCP-AO addresses only the first: it proves the message came from your neighbour, not that your neighbour's claim is true. Hijacks exploit the second and third. Leaks exploit something subtler: nothing in an `UPDATE` says which business relationships the route has already crossed, and `AS_PATH` loop detection never fires, because no AS sees its own number in the path. ## Telling them apart during an incident - **Look at the origin.** A different origin AS points to a hijack or a Type 5 re-origination; a new more-specific from a different origin points to a sub-prefix hijack, while one from the real origin is more likely a Type 6 internal leak. - **Look at the path shape.** A real origin with an implausible sequence, such as two large providers joined through a small customer, points to a leak. - **Look at the data path.** In a leak the packets often still reach the real destination, only by a longer, congested route; RFC 7908 notes they may instead be dropped when the leaking AS cannot carry the volume. In an origin hijack they usually end at the wrong network. ## What to say in an interview - A hijack lies about authority; a leak tells the truth to the wrong audience. - Both work because BGP trusts neighbours and has no built-in origin or path check. - The defences differ: origin validation targets hijacks, relationship-aware checks target leaks.
- Can a single BGP event be both a route leak and a hijack?Yes. RFC 7908's Type 5 is re-origination: an AS learns a prefix from one upstream, strips the received path and announces the prefix to another upstream as if it originated it. By definition it is a leak of a learned route, but on the wire it looks like an origin hijack. If the AS still has a path to the real origin, packets arrive late; if not, they are dropped there.
- Does authenticating the BGP session with TCP-AO stop hijacks?No. TCP-AO, or the older TCP MD5 option, protects one session: it proves the UPDATE came from the configured neighbour and was not altered in transit. It says nothing about whether the prefix and path inside the UPDATE are true. A neighbour that originates someone else's prefix, or passes on a leaked route, sends perfectly authenticated messages.
A hijack is a stranger putting up a sign that says your house is down their road; a leak is a real courier who knows your address offering to carry every parcel for the whole city through his own small van. The first lies about where you are; the second is truthful but was never meant to be offered.
saying these in an interview costs you the question
- A route leak and a prefix hijack are the same thing under different names.
- A route leak always means someone set out to steal traffic.
- BGP itself checks that the origin AS holds the prefix before using a route.
- AS_PATH loop detection rejects a leaked route.
- A shared key on the BGP session is enough to prevent hijacks.