RoVISTA — Measuring Current ROV Protection

Route Origin Validation (ROV) is a vital part of Resource Public Key Infrastructure (RPKI). Measuring the current ROV deployment status and understanding how the Internet is protected from ROV is challenging without direct access to routers in the wild.

In our paper, ‘RoVista: Measuring and Analyzing the Route Origin Validation (ROV) in RPKI’, we at Virginia Tech, in collaboration with IIJ, RIPE NCC, and the Internet Society, developed RoVISTA, a new platform to measure the ROV protection.

What is RoVISTA and How Can it Help You?

At a high level, RoVISTA:

1. Identifies the living hosts in the wild that are under RPKI-invalid prefixes.
2. Measures the connectivity status between two end hosts remotely using the IP-ID side-channel technique.

While the usual way to measure ROV deployment is to make RPKI-invalid announcements themselves (a famous example is Cloudflare’s invalid.rpki.cloudflare.com), the fixed origin Autonomous Systems (ASes) will impact the measurement results. In RoVISTA, in order to present a closer view of how ROV protects the Internet from invalid prefixes in the real world, we use the in-the-wild RPKI-invalid that is not under our control.

First, we use RouteViews BGP table datasets and validate each routing entry with all Route Origin Authorisations (ROAs). Interestingly, nearly 1% of RPKI-covered IP prefixes in the global Border Gateway Protocol (BGP) table are RPKI-invalid, which indicates that such IP prefixes cannot be reachable from ASes that filter RPKI-invalid prefixes. For those RPKI-invalid prefixes, we try to find hosts with TCP ports open so that we can initiate TCP handshakes — we call such hosts targets.

Now, we want to measure if an AS can reach the target — if so, it may suggest that the AS is not protected by ROV. This methodology would be easily applicable if we could set up our measurement machines in the AS; however, it is not scalable.

To overcome this challenge, we use a technique called IP-ID side-channel, which is used in many other areas for counting hosts behind Network Address Translations (NATs), estimating the traffic from, or detecting censorship. One of the nice applications of the IP-ID side-channel technique is inferring the connectivity between two remote end hosts. With this technique, we can measure the reachability from one host to a target to infer the ROV status of the AS of the host. Then, we calculate what fraction of the targets were unreachable by all hosts in a given AS which we call the ROV ratio.

However, It is worth noting the ROV protection score is not a straightforward indicator of ROV deployment status. This discrepancy arises mainly from RoVista’s approach, which uses TCP packet data from the data plane for its assessments. Meanwhile, the actual ROV decisions take place in the control plane.

What We’ve Found Using RoVISTA

Our team has been running RoVISTA since December 2021 and we collected ROV protection scores for more than 28,000 ASes. The results show:

•  A growth in ASes being protected by ROV in the last two years: more than 64% of ASes have derived benefits from ROV.
• the percentage of ASes that are fully protected from all invalid prefixes is still low (12%) but is growing steadily (Figure 1).

Figure 1 — The percentage of the ASes that are fully protected by ROV (2022-2023).

Large ASes are more likely to deploy ROV 

Among the 17 so-called Tier-1 ASes, RoVista shows that 16 of them filter more than 90% of RPKI-invalid prefixes that we tested (Table 1), confirming that they have all deployed ROV.

Also, if we look at the top 1,000 ranked ASes (according to CAIDA’s ASRank), 24% of them are currently fully protected. See detailed results.

If One ISP Deploys ROV, It’s Customers Are Likely to as Well

Deploying ROV will not only protect networks themselves but can also provide benefits to their customers or peers through in-path filtering. Using RoVista, we can see that KPN (AS 1136), a large Dutch ISP, started deploying ROV on 14 March 2022. During our measurement period, RoVista captured six customers of KPN, four of which (AS 8694, 8737, 21286, and 28685) also simultaneously achieved a 100% ROV ratio — AS 3573 and 15466 remained unchanged which we believe is due to these two ASes having multiple upstreams.

Figure 2 — ROV ratio for KPN and its customers.

Challenges and Future Study

While our results are promising, there are several challenges with validating the methodology. 

Some ASes may also perform ROV selectively depending on where they get announcements from. For example, AT&T (AS7018) was found to be dropping RPKI-invalid routes from peers but not from their customers. As we find more targets from different prefixes, we can characterize the ROV policy of ASes, but it is not trivial.

Also, using the current data-plane measurement makes it hard to identify whether an AS has deployed ROV. Even if we see many hosts in an AS always filtering RPKI-invalid prefixes, it could be due to one of their higher tier providers who has deployed ROV making it unreachable to the target — this is called collateral benefit. 

Our next goal is to measure which ASes are actually deploying ROV, and how they deploy it.

Read our paper and follow our presentation at ACM IMC 2023 to learn more.

Weitong Li is a PhD student in Virginia Tech focusing on Internet measurement and security.