Comparing Certified Resources to BGP Routing

Alex Band — Aug 23, 2011 03:25 PM
Filed under: , ,
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).

BGP Announcements and their validity state

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:

  1. VALID: This route announcement is covered by at least one ROA
  2. 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
  3. 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.

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

3 Comments

Sebastian
Sebastian says:
Aug 25, 2011 01:27 PM
Ghe question is why should I use a key to validate my routes when that key is not under my control?

Currently only RIPE can generate keys for me. When will that change?
Alex Band
Alex Band says:
Aug 25, 2011 02:19 PM
The ability to generate and manage your own keys was launched just last week! Try it out and let me know what you think.

http://labs.ripe.net/[…]/local-certification-service-launched
Sebastian
Sebastian says:
Aug 26, 2011 11:19 AM
Wow, I really missed that announcement. Thanks!
Add comment

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.

Related Items
Increased Reach of RIPE Atlas Anchors

Increasing the reach of RIPE Atlas anchors is one of the highest priority goals of RIPE Atlas Team. ...

Proposing Making RIPE Atlas Data More Public

RIPE Atlas is now three years old, and is moving from a prototype to production service. Based on ...

Modifications to the IP Analyser to Reflect New Policy

We are in the process of implementing the policy regarding Post Depletion Adjustment of Procedures ...

RIPE Atlas: Improved Probe Pages

We've made it much easier to get an overview of the history and measurements for all the public ...

Visualising Bandwidth Capacity and Network Activity in RIPEstat Using M-Lab Data

As a result of the cooperation between the RIPE NCC and Measurement Lab (M-Lab), you can now ...

more ...