Your Route Was Dropped—But Where and Why? Closing RPKI's Operational Feedback Gap#

Min Suk Kang – KAIST

• Why: ROV's silent-drop model gives prefix owners no visibility into errors, attacks, or their own urgent operational actions — a research contribution (USENIX Security 2026) brought explicitly to operators for feedback.
• What: Three characterized gaps: no error visibility (typos silently filtered), no attack visibility (owners unaware of hijacks), and defense incompatibility — DDoS-scrubber traffic redirection gets ROV-filtered for tens of minutes (with Lumen's own FAQ and RFC 9319 §5.1 quoted on the timing problem). iROV adds interactivity: a validating AS queries the owner just-in-time and notifies it of the invalid announcement and observed impact; owners can approve urgent changes. Evaluation: urgent route-change reachability rises from 23% baseline to ~90% at full adoption — and even Tier-1-only early adoption reaches 49% (>2×) — with query load bounded to ~1,000 queries per invalid announcement via validity stapling (transitive BGP attribute using RPKI Signed Checklists, RFC 9323), probabilistic querying, and per-owner rate limiting. Prototype on modified BIRD + FORT validator shows negligible overhead under five days of Route-Views traces.
• How: Owner operates a respondent web server whose address is advertised via a ROA extension; responses are stapled and propagate; an RTR extension carries the interaction.
• Where applicable: Not deployable today — needs ROA/RTR extensions and a BGP attribute allocation — but the problem statement is real for every ROV-validating network and every prefix owner that has ever fought a benign-invalid during an incident.