Comparing Certified Resources to BGP Routing

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:

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.

Please try out this feature and let us know what you think. You can leave a comment here, or contact us via certification@ripe.net .