Why we drop RPKI invalid — and what we see when we do
After three months of running invalid-drop on the route servers, we have data. Here is what we filter, and what it tells us about the state of route hygiene.
Three months in, our three Routinator validators are humming along in Falkenstein, Helsinki and Zurich. Every announcement entering the route servers is checked against RPKI, and invalids are silently discarded before they hit the RIB.
The numbers
- ~1.2M routes evaluated daily across the three RS pairs
- ~640 invalid announcements dropped per day
- 0 false positives reported by members in 90 days
That ratio (0.05% invalids) is consistent with public IXP statistics worldwide. The tail is real, though — and it matters.
What kinds of invalids show up
We sampled a week of drops. Roughly:
| Category | Share |
|---|---|
| Forged-origin (different ASN than ROA) | 38% |
| MaxLength too narrow on the ROA | 47% |
| Genuine misconfig (wrong /16 vs /24) | 12% |
| Routing leaks downstream of a partial-deploy peer | 3% |
Most of the maxLength-too-narrow drops are self-inflicted: an operator publishes a ROA with maxLength equal to the aggregate, then later announces a more-specific without updating the ROA. The fix is one click in the RIR portal.
Why we drop, not "accept-with-tag"
Some IXPs accept invalids and tag them with a community for downstream policy. We chose to drop, because:
- Tagging shifts the burden onto every member's ingress filter — most just inherit defaults, so invalids leak through.
- The intent of RPKI is to make a global decision, not a local hint.
- Drops produce instant feedback to the originator, which speeds up cleanup. Tags don't.
What this means for new members
Before turn-up, we ask members to:
- Confirm ROAs cover every prefix they intend to announce.
- Set maxLength only as wide as their actual announcements.
- Test against a public validator (rpki-validator.ripe.net) before bringing up sessions.
We provide a pre-turn-up validation report that flags missing or too-permissive ROAs. Almost every new member has at least one finding.
What's next
ASPA (Autonomous System Provider Authorization) is on our 2026 Q4 roadmap, once the IETF draft becomes RFC. ASPA closes the gap that RPKI ROV doesn't: route-leak detection. We'll write more about that as the standard firms up.