RoVista+: Mapping Real ROV Deployments, Dependencies, and Delays#

Tijay Chung — Virginia Tech

• Why: "Do you filter RPKI-invalids?" has always been hard to answer honestly — prior methods couldn't tell local enforcement from an upstream doing it for you. This work separates the two, and the findings about RP (relying-party) concentration are a systemic-risk result every operator should see.
• What: A measurement framework that runs its own ASN and its own RPKI publication points, serving different test ROAs to specific relying parties, then probing the Internet to see who drops the route. Results across 21,827 measured ASes: 1,127 self-deploy ROV while 1,815 ASes rely entirely on upstream filtering — and 69.6% of those "protected" ASes remain vulnerable to local hijacks. 52% of ROV-deploying ASes depend on exactly one RP server (only 14% use multiple RPs in different ASNs, contra RFC 7115). Router enforcement lags ROA updates by ~37 minutes (60-120 minutes end-to-end). Simulation: ROV in the top 100 ASes protects 27.6% of networks; disabling it in Tier-1s exposes 23.8% to hijacks. ~74% of top-5,000 ASes self-deploy; smaller networks overwhelmingly depend on upstreams.
• How: Dynamic publication points + controlled test-ROA-to-specific-RP delivery + Internet-wide ping/traceroute scanning. Timing-based inference distinguishes upstream filtering (downstreams drop in synchronized clusters when the upstream filters) from self-deployment (independent drop times due to unaligned RTR polling) — validated against Comcast (private RP, synchronized), Cloudflare (public RP, varied), and NTT (both patterns).
• Where applicable: The tooling and datasets are open-sourced, and the operational lessons are immediate for everyone: diversify your RPs across ASNs, and understand your ROV posture may be inherited rather than enforced. The methodology (selectively invalidating to one RP at a time) also generalizes to AS-path exploration. Research-grade but production-relevant.