skip to content

What does RPKI route origin validation prove about a BGP route, and why does a forged-origin hijack still pass it?

level: seniorimportance: must knowfreq 30%

answer

  1. a signed origin, not a signed path
  2. ROA: prefixes, maxLength, one AS
  3. Valid, Invalid, NotFound
  4. rightmost AS of the final segment
  5. append the authorized origin

basics

~20 s

Origin validation proves only that a route's origin AS, the rightmost AS in its path, is authorized by a ROA to originate that prefix at that length. Nothing checks the rest of the path, so a hijacker who appends the real origin passes.

solid answer

~50 s

In the RPKI, the holder of an address block signs a **ROA** (RFC 9582) naming one AS that may originate its prefixes, optionally up to a `maxLength`. Validating caches turn ROAs into validated payloads and feed them to routers (RFC 8210), and each router labels every route per RFC 6811: **Valid** if some payload covers the prefix with a matching origin AS and allowed length, **Invalid** if some payload covers it but none matches, **NotFound** if none covers it. The origin is the rightmost AS of the `AS_PATH`, and that is all that is checked; RFC 6811 itself warns an attacker need only prepend the valid origin AS. A **forged-origin** hijack announces `64511 64500` for AS 64500's prefix and is Valid. For the exact prefix it is one AS longer and wins only partly; for an unannounced sub-prefix allowed by a loose `maxLength` it wins everywhere, which is why RFC 9319 says to publish minimal ROAs.

code

pseudocode · 14 lines
pseudocode
function validate(route, vrps):
    origin = rightmost AS of final AS_SEQUENCE segment of route.AS_PATH
    if final segment is an AS_SET: origin = NONE
    state = NotFound
    for vrp in vrps:
        if vrp.prefix covers route.prefix:        # same or more specific
            state = Invalid                       # covered, until matched
            if route.length <= vrp.maxLength and origin == vrp.asn:
                return Valid
    return state

# loose VRP (2001:db8::/32, maxLength 48, AS 64500)
# 2001:db8:200::/48 via 64511        -> Invalid
# 2001:db8:200::/48 via 64511 64500  -> Valid  (forged origin)

go deeper

for a junior

Recall that a ROA is a signed statement from the address holder naming which AS may originate its prefix, and that routers label routes Valid, Invalid or NotFound.

for a middle

Walk through the covered and matched tests, including maxLength, and explain why only the rightmost AS of the path is compared.

for a senior

Show how a forged-origin hijack passes, why a loose maxLength turns it into a sub-prefix hijack that wins everywhere, and why NotFound is not dropped.

for a principal

Treat ROV as necessary but partial: budget for minimal ROAs, for the RPKI as a dependency that can cause outages, and for a separate path or leak defence.

## The question RPKI answers BGP has no built-in way to check who may originate a prefix. The **Resource Public Key Infrastructure (RPKI)**, described in RFC 6480, adds one outside the protocol: certificates that follow the allocation of address space, so the holder of a block can sign statements about it. The statement used for routing is the **Route Origin Authorization (ROA)**, now specified by RFC 9582, which obsoletes RFC 6482. A ROA says: *this AS may originate these prefixes*, each optionally with a `maxLength`, the longest prefix length the AS may announce within that block. ## From ROA to validation state 1. The holder publishes ROAs in the RPKI. 2. A **validating cache** (a relying party) collects and checks the signatures, producing **validated ROA payloads (VRPs)**: prefix, maximum length, origin AS. 3. Routers download VRPs from the cache over the RPKI-to-Router protocol (RFC 8210); they do not verify signatures themselves. 4. For each route, the router takes the **route origin AS**: the rightmost AS of the final `AS_SEQUENCE` segment, or the value `NONE` if the path ends in an `AS_SET`. 5. It compares the route with every VRP, per RFC 6811: | State | Condition | |---|---| | **Valid** | at least one VRP covers the prefix, allows its length and names the same origin AS | | **Invalid** | at least one VRP covers the prefix, but none matches | | **NotFound** | no VRP covers the prefix | "Covers" means the route's prefix equals or sits inside the VRP prefix. RFC 6811 makes the state a label: an implementation must not drop a route because of it unless configured to. Operators commonly drop Invalid and accept NotFound, since a prefix with no ROA at all is still a normal route. ## A worked validation Take a **loose** ROA: `2001:db8::/32`, `maxLength 48`, AS 64500. AS 64500 announces only the /32. | Route | `AS_PATH` | State | |---|---|---| | `2001:db8::/32` | `64496 64500` | Valid | | `2001:db8:200::/48` | `64511` | Invalid: covered, wrong origin | | `2001:db8:200::/48` | `64511 64500` | **Valid**: origin 64500, length allowed | | `2001:db8::/32` | `64511 64500` | **Valid**, but one AS longer | | `203.0.113.0/24` | `64511` | NotFound: no ROA covers it | The third row is the problem: the forged route is Valid, more specific than anything AS 64500 announces, and therefore unopposed. The fourth row is the same lie aimed at the announced /32, where it has to compete with the real, shorter path. ## What Valid does not mean - **The path is not checked.** RFC 6811 says an attacker "need only prepend the 'valid' source AS" to defeat it, and that it gives no path validation. - **Leaks stay Valid.** A leaked route keeps its genuine origin, so origin validation never flags a leak. - **The database is a dependency.** RFC 6811 warns that injecting or removing records can make a good route Invalid; dropping Invalids makes the RPKI a possible denial-of-service lever. ## The forged-origin hijack RFC 9319 describes two forms. In a **forged-origin prefix hijack** the attacker announces the victim's announced prefix with a path ending in the victim's AS: it is Valid, but one AS longer than the real route, so it captures only part of the traffic. In a **forged-origin sub-prefix hijack** the attacker announces a more-specific that the loose ROA allows but the holder never announces: it is Valid, it has no rival, and longest-prefix match hands it the traffic everywhere it is accepted. RFC 9319 reports that, in 2017 measurements, 84% of prefixes in ROAs using `maxLength` were exposed this way. ## Closing the gap - **Minimal ROAs.** RFC 9319 (BCP 185) says operators SHOULD authorize only prefixes actually originated in BGP and SHOULD generally avoid `maxLength`. With a ROA for just the /32, the forged /48 above becomes Invalid, leaving only the weaker prefix form. - **Path checks.** BGPsec (RFC 8205) signs the path itself, but needs every AS on it to take part; ASPA, still an IETF draft, checks the path against registered provider lists. ## What to say in an interview - ROV answers one question: is this origin AS allowed to originate this prefix at this length? - The origin is just the last number in a path anyone can write, so a forged origin passes. - Minimal ROAs shrink the damage; path security needs something else.

  • Should a router drop routes in the NotFound state as well as Invalid ones?
    Usually not. NotFound only means no ROA covers the prefix, and many legitimate prefixes have no ROA, so dropping them would cut reachability. Invalid means a holder published a ROA that this route contradicts, which is strong evidence of a hijack or a mistake. RFC 6811 leaves the action to local policy; dropping Invalid and accepting NotFound is the common choice.
  • Does RPKI origin validation stop route leaks?
    No. A leaked route keeps its genuine origin and path, so it validates as Valid. Leaks need checks on the relationships a route has crossed: BGP Roles with the Only-to-Customer attribute (RFC 9234) stop or detect them between compliant networks, and ASPA, still an IETF draft, verifies the path against each AS's registered providers.

saying these in an interview costs you the question

  • An RPKI-Valid route has an authenticated, genuine AS path.
  • NotFound means the route failed validation and must be dropped.
  • A generous maxLength in a ROA is a harmless convenience.
  • RPKI origin validation also catches route leaks.
  • Routers verify ROA signatures themselves for every UPDATE they receive.