RPKI origin validation checks whether the AS originating a BGP route is authorized to announce that prefix, using signed records called ROAs. It catches many mis-originations and mistakes. It does not validate the path, so an attacker who keeps the legitimate origin on the path can slip through.
What a ROA says
RFC 6811 describes validated ROA payloads that each hold an IP prefix, a prefix length, a maximum length and an origin AS number. A route's origin AS is the rightmost AS in the final AS_PATH segment when that segment is a sequence.
The three outcomes
The RFC defines the terms precisely:
- Covered. A record covers a route if its prefix length is no longer than the route's and the leading bits match.
- Matched. It matches if it covers the route, the route's prefix length is within the record's maximum length, and the origin AS equals the record's AS.
- Valid. At least one record matches.
- Invalid. At least one record covers the route, but none matches.
- NotFound. No record covers the prefix.
Routes with AS 0 can never match. Results do not depend on the order records are checked, and when the database changes the affected prefixes must be re-validated.
Why maxLength deserves care
A record with a generous maximum length authorizes more specific announcements than you may intend. A more specific prefix wins route selection, so loose maximum lengths can widen what an attacker may forge within the limits. Set maximum length to what you actually announce.
What it does not protect against
The RFC is frank about the gaps:
- Path manipulation. An attacker can prepend the legitimate origin AS to a forged route and pass the check.
- AS in the middle attacks. There is no path validation, only an origin check.
- Database compromise or inconsistency. Its security rests on the underlying data. Someone who can inject or remove records can cause valid routes to look invalid, and caches may briefly disagree.
- Denial of service. Dropping Invalid routes creates a possible attack surface if the database is manipulated.
The RFC concludes it is better viewed as protection against misconfiguration than as strong security. That is a fair way to use it: valuable, cheap, not sufficient. This also explains why it does not fully address route leaks, which are policy violations on routes that keep a valid origin.
Practical steps for address holders
- Create ROAs for every prefix you announce, matching your real origin ASes.
- Set maximum length to the longest prefix you intend to announce.
- Review ROAs when you add or retire address space or a provider.
- Ask your upstream providers whether they drop Invalid routes.
- Keep TLS validation and signed software as your last line of defense.
Where Safeguard fits
Safeguard does not run your DNS, certificates or network routes. It covers the code around them: dependency and SBOM scanning, reachability analysis and policy gates for the libraries your applications use. You can try a free scan at gold.safeguard.sh/scan.
Quick check
What does NotFound mean?
No validated record covers the route's prefix, so the validation neither confirms nor rejects it.
Can RPKI origin validation stop a forged path?
Not by itself. The RFC says an attacker can prepend the legitimate origin to bypass the check.
Sources
Last reviewed: 19 October 2026.
