The Traffic Light System
When a router receives a BGP announcement, it checks the RPKI validator cache and assigns one of three validation states. Understanding these states — and the operational implications of each — is essential for deploying RPKI correctly.
State 1: Valid (Green)
A ROA exists that matches this announcement. The Origin ASN matches the ROA, and the announced prefix length is within the Max Length. This route is cryptographically verified. Accept it with full confidence.
State 2: Invalid (Red)
A ROA exists for this IP block, but something does not match: either the announcing ASN is wrong, or the prefix is more specific than the Max Length allows. This is a confirmed discrepancy — either a hijack or a serious misconfiguration. Drop this route. This is the one state where RPKI gives you a definitive answer.
State 3: NotFound / Unknown (Yellow)
No ROA exists for this prefix. The prefix has not been registered in RPKI at all. This is the current state of a large portion of the internet — as of 2024, roughly 40–50% of global prefixes have ROAs, though coverage is growing.
The Operational Reality of NotFound:
You cannot simply drop all NotFound routes — the internet would break. The standard practice is:
- Accept NotFound routes (treat them like pre-RPKI BGP).
- Prefer Valid routes over NotFound routes when both exist.
- Drop Invalid routes unconditionally.
This means RPKI provides strong protection only for prefixes that have ROAs. An attacker targeting a prefix with no ROA is still undetectable by RPKI alone. This is why ROA adoption matters — every prefix without a ROA is a gap in the defense.
Configuring Route Origin Validation (Conceptual):
On a router supporting RPKI (e.g., Juniper, Cisco IOS-XR, FRRouting), you configure a session to your RPKI validator, then apply a routing policy:
# Pseudocode policy logic
if route.rpki_state == INVALID:
reject route
elif route.rpki_state == VALID:
set local-preference 200 # prefer valid routes
elif route.rpki_state == NOTFOUND:
set local-preference 100 # accept but deprioritize
A common interview question is: "What happens to NotFound routes in an RPKI-enforcing network?" Many candidates incorrectly say they are dropped. The correct answer is that NotFound routes are typically accepted — dropping them would break connectivity to the large portion of the internet that has not yet deployed RPKI. Only Invalid routes should be dropped. This distinction is critical for understanding RPKI's incremental deployment model.