RPKI Resource Certification: building features

Mon Oct 4 08:54:50 UTC 2010

The thread got a bit torn apart due to some cross posting, so here are  
Randy and Owen's replies to keep it all together:

On Oct 3, 2010, at 7:26 PM, Randy Bush wrote:
>> Do you think there is value in creating a system like this?
>
> yes. though, given issues of errors and deliberate falsifications, i  
> am not entirely comfortable with the whois/bgp combo being  
> considered formally authoritative. but we have to do something.
>> Are there any glaring holes that I missed
>
> yes. the operator should be able to hold the private key to their  
> certificate(s) or the meaning of 'private key' and the security  
> structure of the [ripe part of the] rpki is a broken.
> randy
I'll go a step further and say that the resource holder should be the  
ONLY holder of the private key for their resources.
Owen

On 3 Oct 2010, at 19:06, Alex Band wrote:

> 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.
>