Why does a more-specific BGP hijack draw traffic from nearly every network that hears it, while an exact-prefix origin hijack captures only part of the Internet?
answer
- two prefixes never compete
- same prefix: each AS decides
- longest match at forwarding time
- a 2008 video-platform outage
- /24 and /48 acceptance practice
basics
~20 sAn exact-prefix hijack competes with the real route in each AS's best-path decision, so the Internet splits between them. A more-specific is a different prefix with no rival, and longest-prefix match forwards to it wherever it is accepted.
solid answer
~50 sWhen a hijacker originates the **same** prefix as the victim, every AS that hears both routes runs its own best-path decision: policy preference first, then `AS_PATH` length, so networks topologically closer to the hijacker, or preferring the neighbour that delivered it, choose the false route and the rest keep the real one. When the hijacker announces a **more-specific** prefix inside the victim's block, nothing competes: BGP treats it as a separate route, both are installed, and the router's longest-prefix match sends traffic for that slice to the hijacker everywhere the more-specific was accepted. In 2008 a national ISP announced a /24 inside a video platform's /22 and made the service unreachable almost everywhere for about two hours. The victim can answer with equal or longer prefixes, but networks commonly refuse IPv4 prefixes longer than /24 and IPv6 longer than /48.
go deeper
Remember that a more specific prefix wins at forwarding time, so a smaller slice announced by the wrong network attracts traffic for that slice.
Explain why two routes for one prefix compete through preference and path length while a sub-prefix and its covering prefix are both installed and never compared.
Predict which networks a hijack captures, choose the counter-announcement, and know the /24 and /48 acceptance practice that limits both attacker and victim.
Weigh announcing your space as one aggregate against announcing the more-specifics yourself, and which ROAs keep a sub-prefix hijack from being accepted at all.
## Two kinds of contest BGP (RFC 4271) selects routes **per prefix**. Two announcements of exactly the same prefix are rivals: each receiving AS keeps one as its best path. Two announcements of different prefixes, even if one sits inside the other, are not rivals at all: both are installed, and the router's forwarding lookup picks the **longest matching prefix** for each packet. That single distinction explains why the two hijack shapes behave so differently. ## Exact-prefix origin hijack: the Internet splits Suppose AS 64500 holds and originates `2001:db8::/32`, and AS 64511 falsely originates the same `2001:db8::/32`. Every AS that hears both runs the decision process: 1. **Degree of preference** first. Many networks prefer routes learned from customers over routes from peers or providers, so an AS whose customer delivered the false route may pick it even if it is longer. 2. **Shortest `AS_PATH`** next. Among equally preferred routes, the one crossing fewer ASes wins, so networks a few AS hops from the hijacker tend to choose it. 3. Later tie-breakers settle the rest. The result is a split: one region of the Internet sends traffic to AS 64511, the rest keeps reaching AS 64500. | Network | Hears real route | Hears false route | Typical choice | |---|---|---|---| | One AS away from AS 64511 | path of 3 ASes | path of 2 ASes | false route, if preferences tie | | Directly connected to both | path of 1 AS | path of 1 AS | its own policy decides | | One AS away from AS 64500 | path of 2 ASes | path of 4 ASes | real route, if preferences tie | RFC 9319 makes the same point about a forged-origin hijack of an announced prefix: the false path is one AS longer than the real one, so it attracts less traffic. ## More-specific hijack: no contest at all Now AS 64511 originates `2001:db8:100::/48`, which sits inside `2001:db8::/32`. No AS compares the two: the /48 is a new prefix with exactly one origin. Every router that accepts it installs it next to the /32, and for any address in `2001:db8:100::/48` the longest match is the hijacker's route. Path length, preference and proximity are irrelevant. Only networks that **refuse** the /48, by filtering or by validation, keep sending that traffic to AS 64500. ## The 2008 incident, by mechanism 1. A video platform originated a /22. 2. A national ISP, intending to block the platform for its own users, originated a /24 inside that /22. 3. Its upstream provider did not filter the announcement and propagated it to the rest of the Internet. 4. Because the /24 was more specific, routers worldwide sent the platform's traffic toward the ISP, where it was dropped; the service was unreachable almost everywhere. 5. The platform announced the same /24 itself, to compete on equal terms, and then more-specific halves of it to win by longest match wherever those were accepted. 6. The incident ended after about two hours, when the upstream stopped propagating the false route. The lesson interviewers want: an announcement meant to have a local effect leaked because no one between the ISP and the world checked it. ## Fighting back, and the limits - **Re-announce the same more-specific.** It turns the hijack into an exact-prefix contest, which the victim wins in part. - **Announce longer prefixes still.** This wins by longest match, but RFC 7454 cites community practice that IPv4 prefixes longer than /24 and IPv6 longer than /48 are generally neither announced nor accepted, so a victim that already originates a /24 cannot go longer. The same practice stops a hijacker from going longer than /24. - **Make the more-specific Invalid in advance.** A ROA for the /22 without a `maxLength` makes any /24 originated by another AS fail origin validation, wherever invalid routes are dropped. - **Rely on upstream filtering of customers.** Configuring those filters belongs to route policy; the strategy point is that the hijacker's first upstream is the cheapest place to stop it. ## What to say in an interview - Same prefix: a contest decided by each AS's policy and path length, so the hijack is partial. - More-specific: no contest, longest match wins, so the hijack is near-global among accepting networks. - Defence is announcing the prefix you would lose to, plus ROAs and upstream filters.
- Why can a network that originates only a single IPv4 /24 not win back a hijacked /24 by announcing two /25s?Because many networks neither announce nor accept IPv4 prefixes longer than /24, a practice RFC 7454 cites, so the /25s would not propagate far. The victim can still announce its /24, turning the incident into an exact-prefix contest it wins in part. The same practice protects it: a hijacker cannot use a /25 to out-specify the /24 either.
- How would a ROA have changed the outcome of a more-specific hijack?If the holder publishes a ROA for its /22 with no maxLength, a /24 inside it originated by another AS is covered but not matched, so origin validation marks it Invalid. Every network that drops Invalid routes refuses it, and only non-validating networks are hijacked. A ROA with a loose maxLength gives that protection away to a forged-origin announcement.
saying these in an interview costs you the question
- A hijacker must beat the real route on AS_PATH length to attract traffic.
- An exact-prefix origin hijack always captures all of the victim's traffic.
- The covering prefix wins because it was announced first.
- Announcing a /25 is a universal fix for a hijacked IPv4 /24.
- RPKI rejecting the false route ended the 2008 hijack.