Re: [sidr] RPKI <-> allocation consistency

[Robert Loomans <[e-mail]>]

On 13/09/2012, at 03:24, Stephen Kent <[e-mail]> wrote:
> Brian,
> 
> Sorry I didn't reply sooner.
> 
> I found it very difficult to follow the details of your example, but I think there is a higher
> level consideration that makes moot a detailed analysis of optimization the you suggest.
> 
> In the early days of RPKI design I raised the same question that you did re allocation uniqueness,
> and suggested that we include RP checks for overlapping allocations in RP software. I was told (by operators) that the old INR holder and the new INR holder would each need to have certs (and ROas) that are valid, and that encompass the INRs being moved, and that persist for some time. That is a fundamental reason that the RPKI does not specify that the allocations are "unique." The term "unique" used to appear in the text of several of the docs, but was removed to accommodate INR transfers.
> 
> I think the primary concern is that one cannot be confident how quickly all RPs will acquire all RPKI data.
> Thus it seems prudent to allow for the old and new INR holders to have certs that contain the INRs being transferred, for these certs overlap in validity, and for both certs to be available via the repository system at the same time, for some overlap period. This enables old and new ROAs, which may point to the same ASN, to exist, avoiding the need for a flag day.

There are related scenarios regarding operational changes even without transfers.

Currently APNIC, for example, only provides a hosted environment for RPKI for our members. They have a web interface from which they can ask for ROAs to be created and published, and we run all of the machinery for them and publish the results in our repositories.

In the future we may allow our members to run their own RPKI installation, connecting to our RPKI service using the provisioning protocol.

I suspect they would prefer to be able to run their new RPKI installation and the hosted service simultaneously for some time, allowing relying parties to pick up the new objects, before switching off the hosted service.

Similarly, when someone wants to wholesale replace their RPKI infrastructure with a new implementation they may choose to run old and new side-by-side.

Rob


-- 
Robert Loomans                         email:       [e-mail]
Senior Software Engineer, APNIC        sip:    [e-mail]
http://www.apnic.net/                  phone:         [phone]