[130446] in North American Network Operators' Group
RPKI Resource Certification: building features
daemon@ATHENA.MIT.EDU (Alex Band)
Sun Oct 3 13:06:34 2010
From: Alex Band <alexb@ripe.net>
Date: Sun, 3 Oct 2010 19:06:10 +0200
To: Nanog <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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=3D140). 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 =96 both for the IRR and Certification =96 from one =
single interface.=20
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=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 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.=20
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.=
