July 11, 2026
RPKI validation in plain English (and why “unknown” still keeps me up)
People hear “RPKI” and picture HTTPS. It is closer to a signed hall pass. A Route Origin Authorization says: this ASN is allowed to originate this prefix, up to this max length. RPKI validation is just comparing the BGP announcement you see against that hall pass.
Valid means the pass matches. Invalid means someone is announcing a prefix they were not signed for — or they were signed, and they announced a more-specific the ROA forbids. Unknown means there is no pass at all. Unknown is the one that still keeps me up, because most of the internet is still unknown, and hijackers know it.
The three states, without the RFC voice
Valid is the only state I happily put in a customer report. Invalid should be dropped by anyone who claims to care about routing security. Unknown is “we have no cryptographic opinion.” A lot of operators treat unknown as valid. That is how a hijack of an unsigned /24 still travels.
If you announce space, sign it. If you accept routes, drop invalids. Those two sentences are the entire deployment strategy, and we are still arguing about them in 2026 because the second one loses someone a session once and they roll it back.
maxLength is where good networks shoot themselves
Say you have 198.51.100.0/22 and you TE with /24s. Your ROA must allow those /24s or your own more-specifics become invalid the moment a neighbor starts dropping. The lazy fix is maxLength 24 on the /22. The safer fix is one ROA for the /22 (max 22) plus explicit ROAs for each /24 you actually announce.
Why safer? Because a hijacker who more-specifies inside a loose maxLength is still valid. You signed the knife. I have watched a network do this, then spend a weekend explaining to their own security team why RPKI “didn’t work.” It worked. They authorized the steal.
How I actually check a prefix
I do not start in a validator UI. I start with the announcement. Who is originating it, and what is the AS path? Then I run RPKI validation for that ASN + prefix pair. If the tool says valid and the origin is not who I expected, I look at the ROA set — maybe the holder authorized two ASNs, or a merger left a stale one alive.
If it says invalid, I still do not celebrate. I check whether the collectors I trust are discarding it. An invalid route that is still in half the world’s tables is a political problem, not a cryptographic one.
If it says unknown, I treat the prefix as unverified and I go to IRR and WHOIS like it is 2014. That is not romantic. That is the job when the holder never stood up a CA.
What RPKI does not do
RPKI does not prove the path is honest. A valid origin can still be reached through a lying transit. That is ASPA’s problem, and ASPA is not evenly deployed. RPKI also does not replace an IRR lookup. Filtering on IRR and validating with RPKI are two different fences. I want both, the same way I want a lock and a camera.
It also does not fix your stale ROAs. I have seen production prefixes go invalid because someone returned a /24 to the RIR and forgot to rip the ROA. Neighbors that drop invalids will blackhole you with a smile. Set a calendar reminder. Better: monitor ROA expiry and origin changes so a human does not have to remember.
A note for people who “will do it next quarter”
Next quarter is when someone originates a more-specific of your unsigned space and your looking glass lights up on a Friday. Signing a ROA is not a research project. If you can create an IRR route object, you can create a ROA. Do the /24s you actually announce. Check them in the validator. Then decide, as a network, whether you drop invalids or just paint them pretty colors.
Pretty colors do not stop a hijack. Drops do. Unknown still keeps me up because drops cannot help a prefix nobody signed.