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 Band wrote:
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
I do prefer this option. Sponsoring LIR does handle the contractual issues with RIPE and I do count rPKI in the same way as allocates. They are tighly coupled.
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?
Use a token running thought the sponsoring LIR. This satisfies the principle of "follow the contracts". Skipping contractual relationship does open a can of layw^Wworms.
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
participants (4)
-
Alex Band -
Jac Kloots -
Lutz Donnerhacke -
Nick Hilliard