Paul Palse

Serving ROAs as RPSL route[6] Objects from the RIPE Database

Paul Palse

3 min read

0 You have liked this article 0 times.
5

During the last RIPE Meeting, discussions took place around Resource Public Key Infrastructure (RPKI) in association with routing. To give you an idea how an Internet Routing Registry generated from RPKI repositories may look like, we published a prototype of a RIPE Database instance that will serve route[6] objects in RPSL format which are generated from collected ROAs published around the globe.


Introduction

Following the recent RIPE 60 meeting, we looked at  some of the common themes and discussions that came up during the meeting. One of the more lively discussions took place around Resource Public Key Infrastructure (RPKI) in association with routing.

In particular, a question arose whether a policy proposal suggesting mapping the content RPKI repositories to objects in the Internet Routing Registry (IRR) ( http://www.ripe.net/ripe/policies/proposals/2008-04.html ) should be implemented or withdrawn. And although the decision was to withdraw the proposal, a few people were interested in pursuing this idea.

Currently, there are a few pilot RPKI repositories published which include Route Origin Authorization (ROA) objects. To give you an idea how an IRR generated from these repositories may look like and whether this is useful or not, we decided to publish a prototype of a RIPE Database instance that will serve route[6] objects in RPSL format which are generated from collected ROAs published around the globe. 

How we construct the RPKI IRR

 

userfiles-image-RDB-RPKI-Construction-Diagram(1).png

 

Some of my colleagues at the RIPE NCC have written a “Certification Validator” tool that we used to validate ROA objects coming from the trust anchors published at the APNIC, ARIN and RIPE databases.

A separate pubication dedicated to the “Certification Validator” tool will be released on RIPE Labs soon!

The “Certification Validator” tool’s output is a file containing validated caches of ROA objects. We then turn the ROA objects into route[6] objects and feed these into the RPKI IRR instance of the RIPE Database server.

This sequence is repeated periodically to refresh the RPKI IRR instance of the RIPE Database and keep it in sync with the ROAs published at the various trust anchors. 

How does it work?

The RPKI IRR instance is published at whois-rpki-irr.db.ripe.net . Using the RIPE Whois client, the following command will retrieve a route object:

 

  whois –h whois-rpki-irr.db.ripe.net –T route 85.118.184.0/21
 

The RPKI instance of the RIPE IRR will return the object that looks like this:

   route:          85.118.184.0/21
descr:          rsync://certrepo.ripe.net/certrepo/c2/dc..c3/1/5FPi-j_228WTXOSTn3S8BR3bNak.roa
origin:         AS33764
remarks:        85.118.184.0/21-24
mnt-by:         RPKI-MNT
source:         RPKI # ripe
  

As you can see, this is a route object in RPSL format. This way, existing tools like the IRRToolset can interact with the RPKI system.

In order to turn ROA data into RPSL, we mapped ROA attributes into RPSL attributes in the following way: 

ROA attribute RPSL attribute
URI descr:
ASN origin:
IP Prefix route[6]:
Max Length remarks: Concatenate [IP Prefix]-[Max Length]
Not Before Discard
Not After Discard

What’s next?

We will be keeping the RPKI IRR in sync with the ROA publication points, and add new publication points as they become available.

As always, we are very interested in your feedback.

 

 

0 You have liked this article 0 times.
5

About the author

Comments 5