Comparing Certified Resources to BGP Routing

We have implemented a new feature in the Resource Certification Service that compares the certified resources a Local Internet Registry (LIR) holds and the Route Origin Authorisations (ROAs) they have created with the BGP announcements seen by the RIPE NCC Remote Route Collectors. It will display the validation results, and can notify the user of mismatches and potential hijacking attempts.

The power of the Resource Certification system is that you can always be sure that a valid ROA, stating which Autonomous System (AS) is authorised to originate a certain prefix, can only be created by the registered holder of the address space. However, if ROAs are poorly maintained and don't reflect real-world BGP routing, the system loses its value. This is why we are focusing on data accuracy and completeness, so network operators around the world can base routing decisions on reliable data.

In short, the ROAs you publish using the Resource Certification system should match your intended BGP routing. To make this easier to set up and maintain, we've implemented a feature in the hosted system that shows all BGP announcements that overlap with the certified resources an LIR holds, as seen by the RIPE NCC Remote Route Collectors. This information is displayed on the "My ROA Specfications" page of the Resource Certification service (requires an LIR Portal account and Certification group access).

The new section showing the announcements of certified address space and their validity

Each of the route announcements is validated is against your existing ROAs. The result can be:

VALID: This route announcement is covered by at least one ROA

INVALID: Your prefix is announced from an unauthorised AS or the announcement is more specific than is allowed by the Maximum Length set in a ROA that matches the prefix

UNKNOWN: This route announcement is not covered (or only partially covered) by an existing ROA

It's important to note that the way these validity states are applied to actual routing decisions by network operators is purely a matter of local policy. The general suggestion is that VALID should be preferred over UNKNOWN, which in turn should be preferred over INVALID. But again, it's up to the network operator to make the final decision.

In case of an INVALID state, you did not create a ROA for the combination of the AS and prefix in the announcement, but you did authorise another AS. As a result, the announcement is seen as a hijacking attempt from an unauthorised AS. This shows why you need to be meticulous when creating ROAs.

Another reason for an INVALID announcement is that even though the prefix and ASN match, it is more specific than is allowed by the Maximum Length set in a ROA that matches the prefix. The Maximum Length options determines to which point you authorise the announcement to be deaggregated. If you leave this option blank, you only authorise the entire aggregate to be announced, and anything more specific will be regarded as INVALID.

An UNKNOWN state can occur if you have received new resources from the RIPE NCC for which you have not yet created a ROA, or you have created a ROA which does not completely overlap the route announcement.

In this first release, we chose to only show announcements seen by five or more peers. Also, the data is not real-time, but can be up to nine hours old. This means recent changes might not be reflected. Additionally, you can be notified via email if an announcement of one of your prefixes is INVALID or UNKNOWN according to the validation results. This can be useful in case you have received new resources or you have changed your routing configuration and you haven't yet updated your ROAs. You will also get a notification if there is a hijacking attempt.

We look forward to hearing about your real world experiences with this feature. There are some obvious improvements we can make such as making the notifications near real-time, but we are especially interested in hearing how we can give you more fine-tuned information about the cause of misconfigurations and suggestions on how to solve them.

You can add a comment by filling out the form below. Only plain text is possible. Web and email addresses will be transformed into clickable links. Comments are moderated so they won't appear immediately.

The RIPE NCC uses cookies. Some of these cookies may have been set already. More information about our cookies can be found in our privacypolicy. You can accept our cookies either by clicking here or by continuing to use the site.