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.