skip to content

Your AS plans to drop RPKI-invalid BGP routes at every eBGP edge; what does that buy, what can it break, and how would you roll it out?

level: principalimportance: should knowfreq 15%

answer

  1. VRP: prefix, max length, origin
  2. Valid, Invalid, NotFound
  3. origin only, not the path
  4. stale ROAs make real routes Invalid
  5. observe, then drop in stages

basics

~20 s

Dropping RPKI-invalid routes rejects wrong-origin and too-specific announcements wherever ROAs exist, but proves nothing about the path; it can cut reachability to holders with stale ROAs, so sign your own space, observe first, then enforce in stages.

solid answer

~40 s

Route origin validation (RFC 6811) compares each route's origin AS and length to Validated ROA Payloads from your caches: Valid if one matches, Invalid if one covers but none matches, NotFound if none covers. Dropping Invalid stops mis-originations and unauthorised more-specifics in signed space; merely lowering their preference fails, because longest-prefix match still uses an Invalid more-specific. It does not validate the path, so leaks and forged-origin paths stay Valid, and NotFound must still be accepted. It breaks reachability to holders whose ROAs are stale. Roll out by publishing minimal ROAs for your own prefixes (RFC 9319), running at least two caches, tagging validation state and measuring affected traffic, then dropping Invalid on peers and upstreams before customers, with a reviewed, expiring exception list.

go deeper

for a junior

Recall that RPKI lets an address holder sign which AS may originate its prefix, and routers can check announcements against that.

for a middle

Explain the three validation states, how covering and matching are decided, and why NotFound must still be accepted.

for a senior

Show why dropping beats depreferencing, what ROV cannot see about paths, and how stale ROAs and cache outages behave in production.

for a principal

Own the posture: sign your own space first, stage enforcement by session type, measure the traffic at risk, and run a time-limited exception process.

## What route origin validation actually checks **RPKI** (RFC 6480) is a certificate hierarchy that follows IP address allocation. An address holder signs **Route Origin Authorizations** (ROAs, RFC 9582) saying "AS X may originate this prefix, up to this maximum length". Validating caches fetch and verify ROAs; routers receive the results — **Validated ROA Payloads** (VRPs: prefix, maximum length, origin AS) — over the RPKI-to-Router protocol (RFC 8210, version 1). RFC 6811 then classifies each route: - the **route origin ASN** is the rightmost AS when the path's final segment is an `AS_SEQUENCE`; if it ends in an `AS_SET`, the origin is "NONE" and can never match; - a VRP **covers** a route if its prefix equals or contains the route's prefix; - a VRP **matches** if it covers the route, the route's length is within the maximum length, and the origin ASNs are equal. | State | Condition | |---|---| | **Valid** | at least one VRP matches | | **Invalid** | at least one VRP covers, none matches | | **NotFound** | no VRP covers the prefix | RFC 6811 says an implementation "MUST NOT exclude a route" because of its state "unless explicitly configured to do so", and MUST let route policy match on the state. Dropping Invalid is therefore a policy decision your AS makes. ## What dropping Invalid buys — and what it does not **Buys:** routes with the wrong origin, or more-specific than the ROA allows, are discarded wherever the holder published ROAs — mis-originations from a typo, and sub-prefix announcements from an unauthorised AS. **Does not buy:** - **Path validity.** ROV checks only the last AS. An announcement that appends the legitimate origin to a forged path is Valid; checking paths is the job of BGPsec (RFC 8205) and ASPA (still an Internet-Draft). - **Leak protection.** A leaked route keeps its genuine origin and stays Valid. - **Unsigned space.** NotFound must be accepted, or every prefix without a ROA disappears. RFC 7454 (2015) suggested accepting NotFound at low preference. - **Depreference is not a substitute for dropping.** Giving Invalid routes a low `LOCAL_PREF` fails against a more-specific: if the only route for a /24 is Invalid, longest-prefix match still sends that /24's traffic to it. ## What it can break 1. **Other people's stale ROAs.** A holder that moves a prefix to a new origin AS, or announces a /24 while its ROA allows only /22, makes its own route Invalid. You drop it; your users cannot reach that destination unless a covering Valid route exists. 2. **Your own ROAs.** Publish wrong ROAs and every validating network drops you. RFC 9319 says to use **minimal ROAs** and to avoid maximum length except in specific cases, and to re-review ROAs whenever origination changes. 3. **Cache failure.** Routers may keep using VRPs only until RFC 8210's Expire Interval (600 seconds to 2 days, set by the cache) runs out; if every cache is unreachable for longer, the VRP set empties and routes become NotFound — the design fails open, so the risk is losing protection silently, not losing routes. ## A rollout an AS can defend 1. **Sign first.** Publish minimal ROAs for all your own announcements, including more-specifics, and check them against what you originate. 2. **Run at least two validating caches** on separate infrastructure, and monitor VRP counts and freshness on every router. 3. **Observe without acting.** Mark validation state on import — RFC 8097's validation-state extended community carries it inside the AS and is not sent to eBGP peers by default — and measure how much of your traffic goes to Invalid routes. 4. **Drop Invalid in stages:** upstream and peer sessions first, then customer sessions, where RFC 8893 also covers validating what you export. 5. **Own the exceptions.** Keep a short, reviewed allow-list for verified-legitimate Invalids, contact the holders, and expire each entry. ## The judgment Dropping Invalid is cheap insurance against origin errors in signed address space, and it proves nothing about paths. The principal-level answer weighs the small, mostly self-inflicted breakage against the protection, insists on fixing your own ROAs before enforcing on others, and treats ROV as one layer above IRR-generated prefix filters, not a replacement for them.

  • Why is lowering LOCAL_PREF on Invalid routes not an acceptable substitute for dropping them?
    Preference only decides between routes for the same prefix. A typical origin error or hijack announces a more-specific; if that /24 exists only as an Invalid route, it has no competitor, and routers forward on the longest matching prefix anyway. The traffic still goes to the wrong origin. Only removing the Invalid route lets the covering Valid aggregate take over.
  • What happens to filtering if all of a router's RPKI caches become unreachable?
    The router keeps its VRPs until RFC 8210's Expire Interval runs out, then discards them. With no VRPs, nothing covers any prefix, so every route becomes NotFound and is accepted. Routing continues but protection is gone, so monitor cache reachability and VRP freshness rather than assume enforcement is live.
  • Why does RFC 9319 discourage a maximum length in your own ROAs?
    A ROA for a /22 with maximum length 24 authorises your ASN for every /23 and /24 inside, including ones you never announce. Someone can announce one of those unannounced /24s with your ASN appended as origin; it is Valid and wins by longest-prefix match. Listing only the prefixes you announce removes that surface.

saying these in an interview costs you the question

  • A Valid RPKI state proves the whole AS path is legitimate.
  • Routes in NotFound state should be dropped along with Invalid ones.
  • Giving Invalid routes a low LOCAL_PREF is as effective as dropping them.
  • If the RPKI caches go down, the router drops all routes.
  • A generous maximum length in your ROAs is harmless future-proofing.
  • RFC 6811 requires routers to drop Invalid routes by default.