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.
Comments 5
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.
Anonymous •
<div class="content legacycomment"> <p> </p> <p> 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. <br /> <br /> -nick </p> </div>
Anonymous •
<div class="content legacycomment"> <p> </p> <p> Thank you Nick for your suggestion and the offer. </p> <p> 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. </p> <p> 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. </p> <p> 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. </p> <p> 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. </p> <p> </p> <p> Regards, </p> <p> </p> <p> Andrei </p> </div>
Hide replies
Anonymous •
<div class="content legacycomment"> <p> 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. </p> <p> </p> <p> Nick </p> </div>
Roque •
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
Hide replies
Alex Band •
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/content/public-repo/releases/net/ripe/rpki-validator/rpki-validator-app/1.0.14/rpki-validator-app-1.0.14-bin.zip We should have a production release in the beginning of December.