The number of Resource Certificates and Route Origin Authorizations (ROAs) is steadily growing. However, it remains unclear how widely BGP speakers on the Internet are actually using Route Origin Validation (ROV) to drop or de-preference invalid announcements.
In this post, we briefly describe our methodology to generate and analyze 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 number resources — Autonomous System Numbers (ASNs) and IP address prefixes — to the entity that is the legitimate holder of these resources.
By issuing ROAs, resource holders can then authorize 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 ROVs on incoming BGP advertisements. Invalid advertisements — 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, you need to 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. This means 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 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.
Putting things into 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 authorizing the announcement, making both announcements initially valid.
We then check if the vantage points that belong to ASes that are peers of the PEERING BGP testbed have exported direct routes for both prefixes. Once we confirm this, we revoke the ROA for 147.28.245.0/24 and reissue 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 two 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 valid. 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.243.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.
| Date | Time (UTC) | Collector | VP ASN | VP IP | Prefix | AS Path | RPKI State | |
| 2017-09-01 | 00:00 | rrc00 | 50300 | 176.12.110.8 | 147.28.243.0/24 | 50300 | 47065 | Valid |
| 2017-09-01 | 00:00 | rrc00 | 50300 | 176.12.110.8 | 147.28.245.0/24 | 50300 | 47065 | Valid |
| 2017-09-01 | 08:00 | rrc00 | 50300 | 176.12.110.8 | 147.28.243.0/24 | 50300 | 47065 | Valid |
| 2017-09-01 | 08:00 | rrc00 | 50300 | 176.12.110.8 | 147.28.245.0/24 | No route | Invalid | |
| 2017-09-01 | 16:00 | rrc00 | 50300 | 176.12.110.8 | 147.28.243.0/24 | 50300 | 47065 | Valid |
| 2017-09-01 | 16:00 | rrc00 | 50300 | 176.12.110.8 | 147.28.245.0/24 | 50300 | 47065 | Valid |
In the case of the above experiment (Table 1), we announced both prefixes via the AMS-IX route server, with which AS50300 also peers. We also changed 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 (UTC) 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 were expectedly bleak
We ran multiple experiments, that is to say, multiple pairs of reference and experiment prefixes, each announced to a different set of peers of the PEERING BGP testbed. The results were expectedly bleak:
- Before October 2017, we found only three ASes that had deployed ROV to filter invalid routes.
- In October 2017, 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 an ‘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 ASes 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 ASes peering at the AMS-IX route server also peer with route collectors. Consequently, we can observe the effect of 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 — 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).
What is the ROV Deployment Monitor?
To provide the community with a way to assess the current state of ROV deployment, we have set up a monitoring platform ROV Deployment Monitor.
The platform displays ASes that we have found to be filtering using our experiments. For each AS, it provides information about the specific vantage points belonging to the AS that have been found to be using ROV. This information is updated daily with the latest results from our ongoing experiment.
Figure 2 — Screenshot of the ROV Deployment Monitor. The information is updated daily with the latest results from our ongoing experiment.
For more details about the platform and our methodology, we refer to our publication in ACM CCR [PDF 838 KB] as well as a video of an update on the project that we presented as a Lightning Talk at RIPE 76.
We appreciate any feedback about our monitoring platform!
Acknowledgements
We gratefully acknowledge open discussions about RPKI filters with Job Snijders, Antonio Prado (AS59175), and operators of AS50300. Thanks to CAIDA for organizing the BGP hackathon in 2016, which was important to kick this collaboration off. And thanks to the RIPE NCC for providing us temporary Internet number resources during the beginning of this measurement study and RACI who supported our first results presentation at RIPE 74.
Andreas Reuter is a PhD student and research assistant in the Internet Technologies Working Group at Freie Universität Berlin. He is primarily interested in Internet backbone security, in particular, the RPKI.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.