Re: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11

["Sriram, Kotikalapudi" <[e-mail]>]

>So what we need is a third option, that provides better security than 1. and better reachability than 2.
>In other words, "couldn't validate because of certificate lifetime" 
>and "validation failed because of a bad signature or bad certificate chain" 
>are different enough that we need them to have different effects on the forwarding tables.

My thoughts on this:

First:
There should be operational BCP recommendation based on the principle of make-before-break
( in doc like https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-05 ):
1. Certificate should be renewed and pre-published in advance of expiry of the current certificate; 
There should be overlapping validity period bridging the two (current and new certs).
(See https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-rollover-03  and
https://www.ietf.org/proceedings/92/slides/slides-92-sidr-5.pdf  ) 
2. The update for the prefix should be re-originated (by origin AS) or re-propagated (by a transit AS).
Basically, whoever got a new certificate should do this refresh within the above overlap period. 

The above two BCP steps, if followed, will help prevent "couldn't validate because of certificate lifetime".

Second:
The operational BCP can also say:
Allow a certain grace period before you act on the update that became 'Not Valid' due to cert expiry.
(Earlier Sandy also mentioned this.)  

Your other scenario "validation failed because of a bad signature or bad certificate chain" is fine. 
In this scenario, the update is labeled 'Not Valid' for good reason.

Sriram