[130457] in North American Network Operators' Group
Re: RPKI Resource Certification: building features
daemon@ATHENA.MIT.EDU (Alex Band)
Mon Oct 4 04:58:21 2010
From: Alex Band <alexb@ripe.net>
To: Nanog <nanog@nanog.org>
In-Reply-To: <43675D42-4C2C-4B16-A4DF-46F53DF6E8F7@ripe.net>
Date: Mon, 4 Oct 2010 10:54:50 +0200
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
The thread got a bit torn apart due to some cross posting, so here are =20=
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 =20=
> am not entirely comfortable with the whois/bgp combo being =20
> 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 =20
> certificate(s) or the meaning of 'private key' and the security =20
> 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 =20=
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 =20=
> been held up to now have largely revolved around infrastructure and =20=
> policy topics. I would like to move away from that here and discuss =20=
> what kind of value and which features can be offered with =20
> Certification for network administrators around the world. Because =20
> in the end, the goal is to make Internet routing more robust and =20
> create a more reliable method for network operators to make routing =20=
> decisions.
>
> We all know about the shortcomings of the IRR system and that just =20
> half of all prefixes on the Internet have a route object associated =20=
> with them (http://bgpmon.net/blog/?p=3D140). However, it does mean =20
> that there is ton of valuable information in the IRRs, whereas the =20
> Certification system needs to start from scratch. Based on many =20
> discussion I've had with members and the Community, here is my idea =20=
> for a Route Origin Authorisation** (ROA) wizard that retrieves IRR =20
> information, compares it to real world routing and uses that for the =20=
> creation of ROA Specifications. This has a number of benefits:
>
> - Network operators don't have to create their routing policy in the =20=
> Certification system from scratch
> - Because a comparison between is done the IRR and RIS =
(http://ripe.net/ris/=20
> ), only accurate up-to-date information is added to the =20
> Certification system
> - The accuracy of the IRR is increased as a bonus, and is achieved =20
> without leaving the wizard
>
> Ideally, a network operator should be able to manage and publish =20
> their routing policy =96 both for the IRR and Certification =96 from =
one =20
> single interface.
>
> Here are the basic steps for the wizard after a certificate is =20
> generated:
>
> 1. Start ROA Wizard
>
> 2. Detect IRR information using the AS numbers in the Certificate, =20
> like for example:
> =
http://www.db.ripe.net/whois?searchtext=3DAS286&inverse_attributes=3Dorigi=
n&form_type=3Dsimple
>
> 3: Compare results with RIS using RRCC/Netsense, like for example:
> http://www.ris.ripe.net/cgi-bin/rrccng/query.cgi?target=3DAS286
>
> 4: Allow user to flag which ROA specifications they would actually =20
> 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 =20
> objects are updated/removed/added based on the ROAs that were =20
> created. This makes sure the data in the IRR and the Certification =20
> system is consistent.
>
> 8: Save and publish ROAs and route objects
>
> Do you think there is value in creating a system like this? Are =20
> there any glaring holes that I missed, or something that could be =20
> added? I'm looking forward to your feedback.
>
> Alex Band
> RIPE NCC
> http://ripe.net/certification
>
>
> ** The certification system largely revolves around three main =20
> elements: (1) the Certificate, that offers validated proof of =20
> holdership of an Internet Resource, (2) the Route Orgin =20
> Authorisation Object (ROA), a standardised document that states that =20=
> the holder of a certain prefix authorises a particular AS to =20
> announce that prefix and (3) the Validator, which relying parties, =20
> i.e. your peers, can use to validate certificates and ROAs.
>
