RPKI Resource Certification: building features

Mon Oct 4 09:04:19 UTC 2010

And here is my reply to them...

On Mon, October 4, 2010 04:38, Owen DeLong wrote:
>
> 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.

But blindly considering whois/BGP authoritative is not what I am
proposing. I want to confront the network operator with what is  
registered
in the IRR and what is seen in BGP, and let the human element make
decisions and corrections, improving data quality in the process.

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

In the hosted implementation the RIPE NCC currently has, only a  
registered
contact for an LIR with whom we have a business relationship has  
access to
the secured LIR Portal in which the Certification system is embedded.

The reason to offer a hosted system initially, is to take away the  
burden
from an LIR of having to run their own Certificate Authority. We offer a
service that makes the entry barrier for Certification as low as  
possible.
Properly running your own CA, with all the crypto aspects, is no small
feat for a lot of LIRs (technically, but perhaps more psychologically).
You may argue that it's easy and cheap to do yourself, but just look at
adoption rates and levels of IPv6 and DNSSEC *at an LIR level* to see  
what
reality is like.

After the production launch on 1 January 2011, the next step we will  
take
is to implement the up/down protocol, allowing people to run their own
Certificate Authority if they choose to do so. We plan to roll this  
out in
the first half of 2011. We'll go one step further by having our software
certified by an external independent company, and releasing it as open
source to the Community, so they can be sure they adopt a robust  
system if
they choose our package.

So in the end our implementation is not 'broken' as you say, it is in he
middle of a planned, phased approach. Not everything is possible yet and
that is a deliberate decision.

> 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

If you're saying that ISPs can only participate in an RPKI scheme if  
they
run their own Certificate Authority, then I think that would practically
ruin the chances of Certification actually ever taking off on a large
scale.

-Alex

On 4 Oct 2010, at 10:54, Alex Band wrote:

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