Summary
- RIPE NCC's RIPE 93 update put two different numbers side by side: nearly 100% validity among observed announcements already covered by ROAs, and about 37% of ROA AS-prefix definitions with no matching BGP observation.
- Some unseen definitions protect backup routes. Others may remain after an announcement stops, leaving an authorization that can make a forged origin look RPKI-valid.
The permission that outlives the route
Network teams get a clear signal when they create a Route Origin Authorization. The announcement begins, the origin is signed into the public record, and a relying network can check whether the prefix and origin ASN match. Removing that permission after the route disappears is quieter work. No route is waiting to fail while the tidy-up goes undone.
At RIPE 93 on 28 October, RIPE NCC’s RPKI lead Tim Bruijnzeels described that imbalance with two views of the same system. Globally, he said, roughly 73% of prefixes had ROAs when IPv4 and IPv6 were counted together. Among announced prefixes that were already covered by a ROA, nearly 100% were ROV-valid. Operators quickly repair or filter Invalid routes, he said, so the visible announcements improve fast.
Then he reversed the view. About 37% of the AS-prefix definitions inside ROAs were not actually seen in BGP. That is an authorization-side count, not a measure of routes, traffic, address space or ROA objects. A single ROA can describe more than one prefix-origin definition; the number is about those definitions.
The transcript gives no numerator, denominator inputs, snapshot date, observation window or calculation method. Those details would show how much of the 37% is truly retired permission rather than a quiet route with a job still to do.
Some of those quiet routes are deliberate. A resource holder can authorize a route before bringing it up, or keep an alternate origin ready for a failure. Bruijnzeels specifically said some unseen definitions could be backup routes. RIPE NCC’s dashboard compares ROAs with announcements seen by its RIS collectors; the RIPE NCC RPKI Management API says those observations update every eight hours. The blank in a current view is evidence about what the collectors saw, not a historical verdict on what the holder intends.
Other definitions may be leftovers. Bruijnzeels described the asymmetry plainly: operators have a strong reason to create a ROA when they start announcing a route, and much less reason to remove it after the announcement stops. The payoff from removal is less immediate than the payoff from creation, so the object can remain in the repository.
That residue has a technical consequence. BGP Origin Validation checks whether the route’s prefix and origin ASN match an authorizing ROA. It does not authenticate the entire path. If someone announces the prefix while impersonating an origin still authorized by an old ROA, validators can classify that announcement as Valid. A signature that once described a real operating route can keep vouching for an origin after the operational reason for it has gone.
The obvious response is a warning beside every ROA that is not currently seen. RIPE NCC says that signal already exists in the interface, though users have to look for it, and it wants to make the mismatch clearer and extend alerts. Bruijnzeels also said a user should be able to mark an intentional backup so the system stops nagging. That second control matters as much as the warning. Delete every silent definition and an operator may discover during an outage that the backup path they meant to preserve has been erased.
The useful product is a review queue, not a red counter with a delete button. Each mismatch needs the observed prefix, origin ASN, last-seen time, RIS data age and a choice the holder can own: active, planned, backup or retired. A holder can then update a route, keep a documented standby authorization or remove a permission that no longer belongs. That turns “not seen” into a question the operator can answer, rather than a verdict the dashboard invents.
RIPE NCC’s number makes a real gap visible. A clean validity rate among observed routes can coexist with an untended pile of permissions outside the current routing table. The next useful figure is not a lower 37% produced by deleting everything. It is the share of unobserved definitions that holders classify as backup, planned, active or retired—and how many retired permissions they actually remove.
Sources
RIPE 93 Routing Working Group transcript · RIPE NCC RPKI Management API · RIPE NCC BGP Origin Validation · RFC 6811, BGP Prefix Origin Validation · RFC 6482, A Profile for Route Origin Authorizations
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance





