>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 _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
