General Interview: How Would You Explain RPKI and BGP Route Origin Validation?

Prompt and applicable context

An interviewer describes a prefix announced by the wrong AS and asks how you would determine whether that announcement is authorized by the address holder. Explain RPKI, Route Origin Authorizations (ROAs), and BGP Prefix Origin Validation (ROV), while stating that ROV validates the origin AS rather than the entire AS_PATH. This fits networking, CDN, cloud-platform, and infrastructure roles.

What the interviewer is testing

A strong answer starts with “which AS is authorized to originate which prefix,” rather than calling RPKI encrypted BGP. The candidate should explain how VRPs are compared with a BGP route prefix and origin AS to produce Valid, Invalid, or NotFound; how policy consumes those states; why caches can disagree; and why filtering Invalid can still cause collateral damage. “RPKI prevents every hijack” shows that the candidate has missed the boundary.

Questions to clarify first

• Are we protecting prefix origin or validating the complete AS_PATH? ROV answers only the former.
• Are we discussing ROA publication, router validation, or inbound policy filtering? They are different control points.
• Do we have redundant ROA caches and a clear cache-outage policy? A cache outage should not suddenly make every route Invalid.
• Is the priority security, reachability, or rollback speed? Strict filtering needs a change window and observability.

A 30-second answer

“I would have the prefix holder publish a ROA authorizing an origin AS and a maximum prefix length. A validator processes the signed objects into VRPs, and a BGP speaker compares a route prefix and the origin AS at the right side of ASPATH: covering and matching is Valid, covering but not matching is Invalid, and no covering VRP is NotFound. Policy can reject Invalid and handle NotFound separately, but this protects origin, not every ASPATH hop. Before rollout I would check ROA coverage, cache freshness, rollback, and reachability because a distributed cache can be temporarily inconsistent.”

Step-by-step deep answer

1. Define the authorization. A ROA is a signed object binding an IP prefix, a maximum prefix length, and an authorized origin AS. It says who may originate which prefix; it does not sign every BGP attribute.
2. Build validation data. RPKI relies on resource certificates, signed objects, and distributed repositories. Validators fetch and verify them periodically to build local VRPs; BGP speakers use a local cache instead of performing full certificate validation for each route.
3. Compute the three states. A route is Valid when a VRP covers its prefix and matches its origin AS; Invalid when a covering VRP exists but no one matches; and NotFound when no VRP covers the prefix. A more-specific route still has to satisfy the ROA maximum length.
4. Connect policy. An inbound policy can match the state: commonly reject Invalid, log or lower trust for NotFound, and accept Valid. Keep the policy reversible so a mistaken ROA or cache problem does not create a large outage.
5. State the cache boundary. RFC 6811 describes global RPKI as a loosely consistent distributed view; caches can temporarily differ because they refresh at different times. Monitor VRP timestamps, cache sessions, and state distribution rather than labeling one route alert an attack immediately.
6. Explain the protection boundary. ROV can mitigate incorrect origins and some hijacks; NIST describes it as a standards-based platform for reducing related misconfiguration and malicious attacks. It does not prove that intermediate ASes behaved correctly and cannot by itself stop every route leak.
7. Plan a safe rollout. Start in observation mode, inspect Invalid and NotFound, and enable rejection for a small neighbor set. Before each change, verify ROA maximum lengths, redundant announcements, and rollback commands. Afterward watch reachability, Invalid volume, cache health, and alert delay.

High-quality sample answer

“I would split the problem into authorization, validation, and policy. The prefix holder publishes a ROA naming the permitted origin AS and maximum prefix length. An RPKI validator checks the signed objects and produces VRPs; a BGP speaker compares each received prefix with the origin AS from ASPATH. Covering and matching is Valid, covering but not matching is Invalid, and no covering object is NotFound. The router can reject Invalid and treat NotFound as a separate policy choice, but that does not validate the whole ASPATH or solve every route leak. I would roll this out in observation mode, verify ROA coverage and maximum lengths, monitor cache freshness and reachability, then enable filtering gradually with a rollback.”

Common mistakes

• Symptom → “RPKI validates the entire AS_PATH.” Why it fails → RFC 6811’s state compares prefix coverage and origin AS. Fix → Call ROV origin validation and name separate controls for path integrity.
• Symptom → “A route without a ROA is malicious.” Why it fails → NotFound means there is no covering data, not that the announcement is false. Fix → Treat NotFound and Invalid as distinct policy inputs.
• Symptom → “A cache outage makes every route Invalid.” Why it fails → Distributed caches can be unavailable or stale; abrupt filtering can enlarge the incident. Fix → Describe cache health checks, safe stale-data handling, and rollback.
• Symptom → “Set any ROA maximum length.” Why it fails → Too short invalidates legitimate more-specific announcements; too long expands authorization. Fix → Derive maxLength from the real announcement set.

Follow-up questions and responses

Why is a route without a ROA NotFound rather than Invalid?

Invalid requires a covering VRP whose authorized origin does not match. With no covering VRP the state is NotFound. Policy may choose how to treat missing evidence, but absence of evidence is not proof of a bad origin.

What happens when a ROA is published incorrectly?

Legitimate routes can become Invalid and be rejected by strict neighbors. Revoke or correct the ROA, then wait for repository and cache refresh; monitor the state change and keep a temporary policy rollback path.

Can RPKI stop a route leak?

Not necessarily. ROV checks whether the origin AS is authorized; that AS can still propagate a prefix to an unauthorized neighbor. Prefix filters, neighbor roles, and export policy are needed to reduce leaks.

How would you verify that filtering did not break reachability?

Start in logging mode and compare Valid, Invalid, and NotFound with the routing table, sampling ROAs and maximum lengths. Enable rejection in batches, watch reachability probes, cache health, neighbor sessions, and Invalid volume, and roll back the policy if any signal degrades.