Quality of ROAs in RPKI Repositories

Introduction

Several discussions are going on about RPKI (Resource Public Key Infrastructure) and the use of the Route Origin Authorization files (ROAs) present in the repositories. Overall, the vast majority of ROAs in the repositories are correctly registered and origin-validating BGP announcements, but of course there are also problems.

ROA quality

The purpose of the ROA quality webpage we created is to monitor and show the most "problematic ROAs" of all the Regional Internet Registries' (RIRs') RPKI repositories. Most of these ROAs can easily be fixed by registering new correct ROAs. Our monitoring web page will provide additional information about the underlying problems. See the overview page in Figure 1 below (by clicking on them, you can enlarge the images).

Figure 1: rpki.me ROA quality overview page

You can specify different RIRs and see the quality of the registered ROAs. For each ROA you can see the complete list of all BGP announcements together with the related problem. It is also possible to click on a specific line of the table or to filter all results by a given AS number.

There are four different categories:

• Satisfied ROAs (green): ROAs with all BGP announcements passing validation.

• Questionable ROAs (yellow): When, for a given ROA, some BGP announcements pass validation and others don't (these usually only cause some minor problems).

• Problem ROAs (red): When, for a given ROA, no BGP announcements pass validation.

• Other problem ROAs (grey): ROAs failing the validation of BGP announcements, but we aren't able to classify them. Note that these are far fewer cases than those described above.

You can see an example of problematic ROAs in Figure 2 below.

Figure 2: Zooming into the BGP announcements detail of a problematic ROA

We identified two common cases that can be attributed to the majority of problematic ROAs:

• A ROA is covering some BGP announcements but the maximum length field of the ROA is incorrectly set (and there is no other valid ROA covering the announcement)

• The origin AS of the BGP announcement doesn't match the AS in the ROA, but the correct AS (listed in the ROA) is present in the AS_PATH (and there is no other valid ROA covering the announcement)

The first case most likely represents an error by the operator in creating the correct ROA, or de-aggregating announcements without updating the ROA registered in the repository.

The second case probably represents a provider who registered a ROA for a prefix, but forgot to create a ROA for each customer who is announcing parts of the provider's address space, for example: a provider announces and registers a ROA for 10.0.0.0/16, then a customer announces 10.0.1.0/24 from a different origin AS.

If you hover over the problem detail on the right hand side of the table, you will get additional explanations of the problems we found. This is shown in Figure 3 below.

Figure 3: Problem details explained

Behind the scenes

We take the latest BGP RIB dump from the LINX monitor node of routeviews project and the latest copy of all RPKI repositories from all RIRs validated by rcynic . We origin-validate all BGP announcements in the RIB using all possible ROAs matching the prefix. Then we build a table associating a ROA to all BGP announcements where it is used for validating. Then on the page we show all ROAs with at least one announcement failing validation, classified as explained before.

For showing data on the webpage, we encapsulate all ROAs and related BGP announcements into a JSON file (about ~400KB when served compressed) which is fetched by the web page.
The web page is static, with tables built up from the JSON file using AngularJS . This process is automatically repeated once a day to keep the page updated.

About DNS root servers

Origin validation is an important step for preventing mis-originations on BGP, which may cause serious problems on the Internet. We believe that DNS root servers are a critical service for the Internet, and they should be protected. For this reason we created another page to monitor which DNS root servers are currently protected against mis-originations. So far, only the RIPE NCC's DNS root server is completely RPKI-covered. You can see the current status in Figure 4 below. This page is also updated daily. We hope to expand the coverage of the DNS root server system by collaborating with the root server maintainers .

Figure 4: Status of ROA registration for DNS root servers