[routing-wg] 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.html
http://www.ripe.net/ripe/mail/archives/ncc-services-wg/2013-March/002149.html
http://www.ripe.net/ripe/mail/archives/ncc-services-wg/2013-March/002252.html
http://www.ripe.net/ripe/mail/archives/ncc-services-wg/2013-March/002256.html