You are here: Home > Publications > RIPE Labs > Paul Palse > Serving ROAs as RPSL route[6] Objects from the RIPE Database

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

Paul Palse — Jun 2010
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

 

 

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.

 

 

5 Comments

Anonymous says:
01 Jun, 2010 10:26 AM

Great idea, but would it be possible to use a dedicated attribute for this instead of overloading "descr:", which is a generic text field?  Maybe "rpki:" or "rpki-url:"?  Adding support for this into the various rpsl parsers is not a big deal, and it would keep the spec much cleaner.  I'd be happy to add something into irrtoolset for this purpose.
 
-nick

Anonymous says:
02 Jun, 2010 03:50 PM

 

Thank you Nick for your suggestion and the offer.

Indeed, some of the ROA fields are encoded in the "description:" or "remarks:" attributes and some of them are even dropped. The idea of the prototype was to replicate most common use cases of the traditional IRR in RPKI, so that the new facility can be utilised without modification to existing tools.

Our assumption, for instance, was the a possible "rpki-url:" would be of a limited use, mainly for human inspection and for debugging purposes. Because if one is prepared to do the validation themselves, it probably makes more sense to get the original data from a RPKI repository directly.

There is another ROA attribute, that has more operational significance. It is the maxLength of the prefix, which we encoded in the "remarks:" filed. But again, this feature doesn't exist in today's IRRs, so we didn't work on that functionality.

The goal of the prototype is to understand to what extend such functionality is useful and allow people play with it. I am reluctant to suggest this, but perhaps in the meantime simple hacks can be applied to IRRToolset, before we go ahead and modify the standard. We can make these fields more parseable.

 

Regards,

 

Andrei

Anonymous says:
08 Jun, 2010 01:40 PM

OK, I had incorrectly assumed that the remarks: attribute was a canonical pointer rather than just a text indicator.  I guess I'll just have to sit down and understand the rpki structure a lot more.  As you hint, there are very sound reasons for not duplicating data like this.

 

Nick

Roque says:
21 Nov, 2011 10:08 AM
Is this service still running? The domain name seams to be deleted:
Roque:~ rogaglia$ dig whois-rpki-irr.db.ripe.net

; <<>> DiG 9.7.0-P1 <<>> whois-rpki-irr.db.ripe.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41155
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
Alex Band says:
22 Nov, 2011 12:07 PM
Hi Roque, this service is no longer available due to a lack of interest. BGPMon has a similar service running you can query for ad-hoc information: http://bgpmon.net/blog/?p=414

If you want to set up something more structured, you are better off using our validation tool and export the ROA information in a CSV that you can roll into an existing RPSL based workflow. You can grab the latest pre-release here:
https://certification.ripe.net/[…]/rpki-validator-app-1.0.14-bin.zip

We should have a production release in the beginning of December.
Add comment

You can add a comment by filling out the form below. Comments are moderated so they won't appear immediately. If you have a RIPE NCC Access account, we would like you to log in.