[address-policy-wg] [Ticket#2013022101004151] Policy update request on certification of transferred IPv4 allocations

On 25 Feb 2013, at 11:51, Erik Bais <erik at bais.name> wrote:

> Hi, 
> 
>> Some people want to use RPKI. It seems somewhat churlish to prevent them from doing so just because Russian members can't. But as Nick said, this is a different argument for a different time.
> 
>> I'd suggest (as the original author of this particular clause) that we just remove it. Times have changed.
> 
> That means that it is up to the parties themselves to revoke their current certificate (if they have one already) and create a new one if needed.

There is no need for this. The content of the certificate is based on current Registry data. If resources are de-registered from an LIR, a new, updated certificate is automatically issued and any over-claiming ROAs will be invalidated. 

> The only question is how long would it be before the transfer be completed in the RIPE system, to allow the new LIR to setup their new ROA. 

As soon as the Registry is updated and the resources are associated with the new holder, the LIR can optionally request a resource certificate for it. This does mean that a transition is not seamless; there is a gap where there is no certificate and no ROA, which has an effect on the RPKI validity state of the associated BGP announcements. More on that below.

> Technically that shouldn't be an issue, but the selling party might be selling only a part of a certain allocation, leaving that prefix invalid and the new party need to be able to create a new valid ROA directly after the transfer. 

The BGP announcement of a prefix will *not* be invalid in this case (a common misconception). There are three validity states of BGP announcements in relation to ROAs to consider:

- valid (ROA exists)
- invalid (ROA exists for the prefix, but for a different ASN or max prefix length)
- unknown (no ROA exists for the prefix)

So while a transfer is ongoing, the associated BGP announcements will be "unknown" because no ROA exists (yet). If this is a problem, because operators would like a system where any BGP announcement should be "valid" at all times for it to be routed, our system and processes would have to be changed to facilitate that.

> Not sure btw if the current RPKI system implementation checks ROA's for that specific LIR after a transfer is done... ( Alex B might know the answer on that ... )

As said, the process is fully automated so no action is required from the transferring LIR. The LIR who receives the resources is free to request a certificate and create ROAs, if they so choose.

Cheers,

Alex