Implementation of Resource Certification (RPKI) for PI End User Resources
Dear colleagues, In March of this year, the RIPE NCC held a community consultation about the certification of Internet number resources held by non-RIPE NCC members. The discussion that unfolded led to RIPE Policy Proposal 2013-04, "Resource Certification for non-RIPE NCC Members". This proposal reached consensus on 16 October 2013. Now that the Community has decided that certification of non-member resources should be a RIPE NCC service, we would once again like to summarise the three possible implementation options for PI End User resources: 1) A PI End User becomes a RIPE NCC member 2) A PI End User requests a resource certificate through their sponsoring LIR and gets access to the Route Origin Access (ROA) management system themselves, or they delegate management to the sponsoring LIR 3) A PI End User requests a resource certificate directly from the RIPE NCC, without becoming a member, and obtains access to the ROA management system It became apparent from the discussion that PI End Users fall into two groups: - Those who use the sponsoring LIR solely to request the PI resources but manage everything else themselves - Those who rely on the sponsoring LIR for everything, ranging from BGP routing to RIPE Database updates In order to cater to both groups, the feedback so far suggests we facilitate options 2 and 3, while option 1 will continue to remain available at all times. For option 2 (going through the sponsoring LIR) and option 3 (going to the RIPE NCC directly), there is the possibility to provide an automated solution for which only PI End Users who have submitted a 2007-01 End User Assignment Agreement are eligible. This means the RIPE NCC will need to develop a solution where the following informational elements are cross-referenced with each other: a) The authoritative control over the address space (i.e. the ability to authenticate against the relevant objects in the RIPE Database) b) The End User Assignment Agreement that was submitted and verified by the RIPE NCC c) The RIPE NCC Access credentials for accessing the certification management interface In order to offer insight into the resources required for the implementation, the RIPE NCC has provided a cost estimate. One of the clarifications that was given during the discussion is the fact that there is a lot of overlap in the implementation of option 2 and 3, meaning that building both would not result in a significantly higher cost than offering just one of them. The only aspect that remained a discussion point were the requirements that the RIPE NCC should impose on PI End Users when they would like to request a resource certificate directly from the RIPE NCC (option 3). We would like to ask you to provide further feedback on this topic. The issue is: A PI End user must prove to the RIPE NCC that they truly are the legitimate holder of the resources they would like to have a certificate for. What proof do they need to give to the RIPE NCC before we grant them access to the system? While this discussion is ongoing, we would like to propose to start building the framework to offer this functionality, and deliver option 2 as soon as it is ready. We look forward to your feedback. Kind regards, Alex Band Product Manager RIPE NCC P.S. The RIPE NCC has explained the implementation options and associated cost at the following locations: http://www.ripe.net/ripe/mail/archives/ncc-services-wg/2013-March/002145.htm... http://www.ripe.net/ripe/mail/archives/ncc-services-wg/2013-March/002149.htm... http://www.ripe.net/ripe/mail/archives/ncc-services-wg/2013-March/002252.htm... http://www.ripe.net/ripe/mail/archives/ncc-services-wg/2013-March/002256.htm...
Alex, On Tue, 22 Oct 2013, Alex Band wrote:
The issue is: A PI End user must prove to the RIPE NCC that they truly are the legitimate holder of the resources they would like to have a certificate for. What proof do they need to give to the RIPE NCC before we grant them access to the system?
Not having followed all of this discussion, but isn't there an effort going on as result of RIPE-452 (http://www.ripe.net/ripe/docs/ripe-452) for having a contractual relationship between PI end-users and the RIPE-NCC. Isn't this contractual relationship the best proof for being the legitimate holder of the PI resource? Jac -- Jac Kloots Network Services SURFnet bv
On 22 Oct 2013, at 11:06, Jac Kloots <Jac.Kloots@surfnet.nl> wrote:
Alex,
On Tue, 22 Oct 2013, Alex Band wrote:
The issue is: A PI End user must prove to the RIPE NCC that they truly are the legitimate holder of the resources they would like to have a certificate for. What proof do they need to give to the RIPE NCC before we grant them access to the system?
Not having followed all of this discussion, but isn't there an effort going on as result of RIPE-452 (http://www.ripe.net/ripe/docs/ripe-452) for having a contractual relationship between PI end-users and the RIPE-NCC.
Isn't this contractual relationship the best proof for being the legitimate holder of the PI resource?
Allow me to illustrate this using an example scenario, where a PI End User wants a certificate without going through their sponsoring LIR: 1: The PI End User logs in with their RIPE NCC Access account on ripe.net (after creating one) 2: They go to a webpage with a form where they enter the prefix(es) they would like a resource certificate for 3: The background system checks if these prefixes: a) are PI End User resources b) have the status "End User Documents Approved", meaning that a RIPE-452 contract was submitted and verified 4: The PI End User must enter the RIPE Database MNTNER password/key(s) for the inetnum objects of the resources, to prove they have authoritative control over them 5: If this is successful, the RIPE NCC Access credentials, resources and ROA management interface are associated with each other, allowing them to use the system It is up to the Community and membership to decide if this would be an acceptable workflow or if additional steps or checks would need to be added. You should keep in mind that at all times, the sponsoring LIR is the only point of contact the RIPE NCC has, and according to the signed contract they are held responsible for the resources and PI End User relationship. Cheers, Alex
On 22/10/2013 19:55, Alex Band wrote:
4: The PI End User must enter the RIPE Database MNTNER password/key(s) for the inetnum objects of the resources, to prove they have authoritative control over them
you're assuming that the end user maintains their objects. This is not always going to be the case. Nick
On 23 Oct 2013, at 12:41, Nick Hilliard <nick@netability.ie> wrote:
On 22/10/2013 19:55, Alex Band wrote:
4: The PI End User must enter the RIPE Database MNTNER password/key(s) for the inetnum objects of the resources, to prove they have authoritative control over them
you're assuming that the end user maintains their objects. This is not always going to be the case.
I'm not assuming that at all. If the sponsoring LIR manages the RIPE DB objects on behalf of the PI End User, they will be able to authenticate against the inetnum and perform these steps. -Alex
On 22/10/2013 16:12, Alex Band wrote:
The issue is: A PI End user must prove to the RIPE NCC that they truly are the legitimate holder of the resources they would like to have a certificate for. What proof do they need to give to the RIPE NCC before we grant them access to the system?
there's no way of necessarily knowing that the contact info in the ripe database is correct, even if the resources are correctly registered to the legal person described in the organisation object. This means that the RIPE NCC has no real way of knowing if J. Random end user is the correct contact for the PI resource, which means that it needs to devolve the initial stage of this authorisation to the sponsoring LIR. This probably sucks. Nick
Hi, On Wed, Oct 23, 2013 at 05:00:08PM +0800, Nick Hilliard wrote:
there's no way of necessarily knowing that the contact info in the ripe database is correct, even if the resources are correctly registered to the legal person described in the organisation object. This means that the RIPE NCC has no real way of knowing if J. Random end user is the correct contact for the PI resource, which means that it needs to devolve the initial stage of this authorisation to the sponsoring LIR. This probably sucks.
OTOH, for RPKI, do we really need to know *who* the user is? If - as Alex proposes - the system checks "is there an approved contactual relationship for the resource in question, *and* does the user have the necessary credentials to satisfy the mnt-routes: criteria for the object?", the ability to create ROAs would correspond to the ability to create route: objects - and since RPKI isn't certifying identity, but "this person is authorized to authorize routing for the resource", this sounds workable for me. The bit "show me your credentials" is going to be interesting for PGP, but can be done ("show nonce, ask for signature on it, copy back to text field")... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
OTOH, for RPKI, do we really need to know *who* the user is?
well, almost. we need to know that we have the public key corresponding to the private key of the holder of the resource. we do not really need to know _who_ they are in the human/organizational sense any more than to satisfy whatever the ncc's administrative needs are. randy
participants (5)
-
Alex Band -
Gert Doering -
Jac Kloots -
Nick Hilliard -
Randy Bush