RPKI Resource Certification: building features

[Alex Band <alexb () ripe net>]

Most of the discussions around RPKI Resource Certification that have been held up to now have largely revolved around 
infrastructure and policy topics. I would like to move away from that here and discuss what kind of value and which 
features can be offered with Certification for network administrators around the world. Because in the end, the goal is 
to make Internet routing more robust and create a more reliable method for network operators to make routing decisions.

We all know about the shortcomings of the IRR system and that just half of all prefixes on the Internet have a route 
object associated with them (http://bgpmon.net/blog/?p=140). However, it does mean that there is ton of valuable 
information in the IRRs, whereas the Certification system needs to start from scratch. Based on many discussion I've 
had with members and the Community, here is my idea for a Route Origin Authorisation** (ROA) wizard that retrieves IRR 
information, compares it to real world routing and uses that for the creation of ROA Specifications. This has a number 
of benefits:

- Network operators don't have to create their routing policy in the Certification system from scratch
- Because a comparison between is done the IRR and RIS (http://ripe.net/ris/), only accurate up-to-date information is 
added to the Certification system
- The accuracy of the IRR is increased as a bonus, and is achieved without leaving the wizard

Ideally, a network operator should be able to manage and publish their routing policy – both for the IRR and 
Certification – from one single interface. 

Here are the basic steps for the wizard after a certificate is generated:

1. Start ROA Wizard

2. Detect IRR information using the AS numbers in the Certificate, like for example:
http://www.db.ripe.net/whois?searchtext=AS286&inverse_attributes=origin&form_type=simple

3: Compare results with RIS using RRCC/Netsense, like for example:
http://www.ris.ripe.net/cgi-bin/rrccng/query.cgi?target=AS286

4: Allow user to flag which ROA specifications they would actually like to create, based on the IRR and RRCC/Netsense 
results.

5: Allow user to create additional ROA Specifications

6: Detect which maintainer is used for the route objects in the IRR

7: Allow user to specify maintainer password/pgp key, so all route objects are updated/removed/added based on the ROAs 
that were created. This makes sure the data in the IRR and the Certification system is consistent. 

8: Save and publish ROAs and route objects

Do you think there is value in creating a system like this? Are there any glaring holes that I missed, or something 
that could be added? I'm looking forward to your feedback.

Alex Band
RIPE NCC
http://ripe.net/certification


** The certification system largely revolves around three main elements: (1) the Certificate, that offers validated 
proof of holdership of an Internet Resource, (2) the Route Orgin Authorisation Object (ROA), a standardised document 
that states that the holder of a certain prefix authorises a particular AS to announce that prefix and (3) the 
Validator, which relying parties, i.e. your peers, can use to validate certificates and ROAs.