Measuring the Adoption of RPKI Route Origin Validation

In this post, we briefly describe our methodology to generate and analyse route collector data for the purposes of measuring Autonomous Systems (ASes) that have deployed ROV and are dropping invalid routes, as well as present our public monitoring platform, ROV Deployment Monitor.

Key points:

• To improve the accuracy of how we measure ROV, we injected our own BGP routes into the Internet and then used the resulting route collector data.
• Before October 2017, we found only three ASes had deployed ROV to filter invalid routes; this increased following policy changes made by a major IXP.
• We have developed a monitoring platform, ROV Deployment Monitor, to provide the community with a way to assess the current state of ROV deployment.

Using ROAs to validate route origins

Inter-domain routing has long been plagued by the security-related shortcomings of BGP. The lack of a mechanism to validate incoming BGP Update messages leaves the door wide open for attacks such as prefix hijacks. The Resource Public Key Infrastructure (RPKI), and the mechanisms built on top of it, are designed to address this problem. Through Resource Certificates, the RPKI provides a trusted mapping of Internet resources - Autonomous System Numbers (ASNs) and IP address prefixes - to the entity that is the legitimate holder of these resources. By issuing Route Origin Authorisations (ROAs) resource holders can then authorise a specific AS to legitimately originate their IP prefixes. The information in the ROAs can then, once cryptographically validated, be used by BGP speakers to perform Route Origin Validation (ROV) on incoming BGP advertisements. Invalid advertisements, i.e. advertisements that contradict ROA information, may then be discarded or de-preferenced.

Are there any ASes out there that have already deployed ROV and are dropping invalid routes?

To answer this question we make use of data from BGP route collectors from the RIPE Routing Information Service (RIS) and Route Views projects.

When using data from route collectors, one must be careful when inferring the routing policy of a vantage point. For instance, an absence of invalid routes must not be an indicator that the vantage point is performing ROV to filter them. It might simply not have gotten invalid routes from its neighbours, or chose not to propagate them to the route collector for unrelated reasons. The core of the problem is that we lack control over the data, and thus cannot distinguish between multiple explanations for an observed phenomenon.

In order to gain control, we need to generate our own data. Which means that we must inject our own BGP routes into the Internet, routes that we have control over and can manipulate, and then use the resulting route collector data. 

In the following, we briefly describe our methodology to generate and analyse the data, as well as present our monitoring platform https://rov.rpki.net. For more details about the methodology we refer to our publication in ACM CCR.

Theory

In order to probe whether one of the vantage points uses ROV to drop invalids, we first announce a valid route to the vantage point and make sure that it is exported to the route collector. We then change the ROA for the announced prefix and turn the route invalid and check whether the vantage point has dropped the route. One problem is that if we observe the vantage point exporting the route when it's valid and not exporting when it's invalid, how can we know this is because of the RPKI state and not because of unrelated reasons? To resolve this we need another route, for a different prefix, to serve as a control variable. This control route will always be valid and will allow us to tell whether a vantage point is dropping the invalid route because of its RPKI state or for unrelated reasons.

Practice

Now that we know how we are going to conduct our measurements, it's time to put things into practice! First of all, we need to be able to announce BGP routes to as many ASes that host a vantage point as possible.  For this we can use the PEERING BGP testbed (AS47065), which offers rich BGP connectivity including access to route servers at various IXPs. For the RPKI side of things, we set up our own child certificate authority (CA) using the Dragon Research Labs RPKI toolkit. Once our parent CA has delegated resources to us, we can start issuing ROAs for the prefixes we want to use in our experiments.

We start our experiments by announcing prefix 147.28.243.0/24 as our always-valid, control route and prefix 147.28.245.0/24 as our experiment route that will change from valid to invalid.

For both prefixes we issue a ROA authorising the announcement, making both announcements intially valid. 

We now check if the vantage points that belong to ASes that are peers of PEERING have exported direct routes for both prefixes. Once we confirm this, we revoke the ROA for 147.28.245.0/24 and re-issue a new ROA with a different ASN, turning all routes for that prefix invalid. 

We now check the route collector data and will observe one of three things:

No change - The first, and most common, occurrence is that nothing has changed. The vantage point still exports a route for both prefixes, seemingly not caring that one of them is not invalid. This does not mean that the vantage point's AS is not using ROV, it simply means our experiment setup did not reveal ROV usage.

No route export - In contrast, the second observation we might make is that the vantage point has not exported a route for 147.28.245.0/24 but still retains the route for 147.28.245.0/24.

This is a clear indicator that this AS has deployed ROV on either the vantage point itself, or another router in the AS that feeds the vantage points the routes for our prefixes. An example of this is AS50300, which hosts a vantage point that peers with the rrc00 collector from RIPE RIS. The table below shows which routes were exported from the vantage point on 2017-09-01. The rrc00 collector dumps its received routes at 00:00, 08:00, and 16:00 UTC:

We announce both prefixes via the AMS-IX route server, with which AS50300 also peers. We change the ROA to invalidate the route for 147.28.245.0/24 between 04:00 UTC and 12:00 UTC. We can see that AS50300 has picked up this change and the vantage point exports no route for 147.28.245.0/24 at the 08:00 dump. After the route becomes valid again, the vantage point exports it once again at 16:00 UTC. To confirm this is not a fluke, we repeat the experiment daily and make sure it stays consistent.

Results

We run multiple experiments, that is to say multiple pairs of reference and experiment prefixes, each announced to a different set of peers of the PEERING testbed. The result are expectedly bleak:

• Before October 2017, we found only three ASes that have deployed ROV to filter invalid routes.
• In October the AMS-IX Route Servers made changes to its filtering policies: prefix filtering based on IRRdb entries and RPKI data was made the new default for all peers, switching away from a 'opt-in' model to an 'opt-out' model. A peer that is signed up for the RPKI filtering option will not receive invalid announcements via the Route Server. While the several hundred AS peering at the Route Server that have not opted out are not actually performing ROV, the effects of the Route Server filtering will be the same.
• Fortunately, a few dozen of the AS peering at the AMS-IX Route Server also peer with route collectors. Consequently, we can observe the effect with our experiment: we pick up 37 new ASes that are 'using ROV' via the AMS-IX Route Server.

We can see the effect of the Route Server filtering our experiment prefix 147.28.245.0/24 in the RIPEstat routing widget:

Figure 1:
Figure 1: Our experiment prefix 147.28.245.0/24 as seen with the RIPEstat routing widget

The numbers of vantage points exporting a route to 147.28.245.0/24 drops when the route becomes invalid (red bars) and rises again when the route becomes valid (yellow bars).

The ROV Deployment Monitor

To provide the community a way to assess the current state of ROV deployment, we have set up a monitoring platform: the ROV Deployment Monitor. The website shows a table with ASes that we have found to be filtering using our experiments, it is updated daily with the latest results. 

For each AS, it provides information about the specific vantage points belonging to the AS which have been found to be using ROV:

Figure 2: Screenshot of the ROV Deployment Monitor. The information is updated daily with the latest results from our ongoing experiment.

We appreciate any feedback about our monitoring platform!

For more details about our platform and the methodology, we refer to our publication:

• Andreas Reuter, Randy Bush, Italo Cunha, Ethan Katz-Bassett, Thomas C. Schmidt, Matthias Wählisch, 
  Towards a Rigorous Methodology for Measuring Adoption of RPKI Route Validation and Filtering, 
  ACM SIGCOMM Computer Communication Review, Vol. 48, No. 1, pp. 19--27, January 2018. (If you refer to this work, please cite.)
  

This work was also presented as plenary talk at RIPE 74, supported by the RIPE NCC's RACI programme. An update was presented as a lightning talk at RIPE 76.

Acknowledgements

We gratefully acknowledge open discussions about RPKI filters with Job Snijders, Antonio Prado (AS59175), and operators of AS50300. Thanks to CAIDA for organising the BGP hackathon in 2016, which was important to kick this collaboration off; and thanks to the RIPE NCC for providing us temporarily Internet resources during the beginning of this measurement study.