Summary

  • ROV can reject a route that conflicts with current ROAs without asking the prefix owner. The filtering decision travels through the network; a useful explanation may not travel back.
  • iROV proposes a signed, just-in-time authorization and feedback path. Its reachability gains are simulation results under stated assumptions, not a report of live deployment.

The awkward moment is familiar to anyone who has had to change a route quickly: a prefix owner redirects traffic during an incident, but the new announcement conflicts with the ROA that validators currently hold. ROV does what it was built to do. A validating network marks the route invalid and drops it. The owner may see neither the rejection nor its scope.

That is the gap Younsoo Kim, Seungjin Baek, Weitong Li, Tijay Chung and Min Suk Kang address in their USENIX Security 2026 paper, presented at NANOG 98 by Kang. Their iROV proposal lets a validator query the owner for a signed, just-in-time authorization. The owner’s response can accompany the route as a validity “staple”; a downstream iROV validator can verify it locally instead of asking again. Queries can also be probabilistic, trading faster authorization for lower request load.

The headline result is arresting: the paper reports reachability rising from 23% to nearly 90% for urgent route changes. The number belongs to the authors’ large-scale simulation. Its core scenario fixes iROV adoption among Tier-1 networks at 100%, assigns assumed ROV adoption and query probabilities by network tier, and uses a simplified valley-free propagation and local-preference model. The authors say that model cannot capture the full diversity of real control-plane policies. Their prototype ran modified BIRD and FORT components in a closed testbed. Neither result establishes Internet-wide deployment performance.

The security bargain is legible. An invalid route still needs the owner’s cryptographically verifiable approval; failed or missing responses fall back to ordinary ROV rejection. But new machinery means new duties: someone must run and protect the owner endpoint, maintain signing credentials, choose query policy, triage alerts, and respond when a surge of requests is itself the incident. The authors leave those costs unquantified because they depend on each operator’s environment.

That makes iROV a serious design proposal and a useful operator question, not a switch waiting to be flipped. NANOG’s session asks what feedback ROV should provide and how to add it without unacceptable operational or security risk. The unanswered part is governance in miniature: who gets to set the default, who owns the response burden, and what counts as an emergency exception?

Sources: USENIX Security 2026 paper · NANOG 98 session · RFC 6811: ROV · RFC 6482: ROA. · PDF original