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 objects in RPSL format which are generated from collected ROAs published around the globe.
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 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 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 188.8.131.52/21
The RPKI instance of the RIPE IRR will return the object that looks like this:
route: 184.108.40.206/21 descr: rsync://certrepo.ripe.net/certrepo/c2/dc..c3/1/5FPi-j_228WTXOSTn3S8BR3bNak.roa origin: AS33764 remarks: 220.127.116.11/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|
|Max Length||remarks: Concatenate [IP Prefix]-[Max Length]|
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.