Re: [sidr] FW: New Version Notification for draft-sriram-replay-protection-design-discussion-00.txt

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

>(Roque) As expressed in our document, there are many reasons to do key rollover
>for BGPSEC certificates, just like in any PKI. Using your taxonomy, can we consider
>EKR as emergency rollovers due to a key been compromised, changes on the
>certificate information or local policies?

[Sriram] I think your description EKR above is different from how we described it 
in section 5.2 of our document:
http://tools.ietf.org/html/draft-sriram-replay-protection-design-discussion-00#section-5.2  
EKR is *Event-driven Key Rollover*, and an "event" here is described as
peering relationship discontinuation, policy change (e.g., change in how
prepending was done for TE purpose, compromised key, etc.). 
But there is more to clarify about EKR. Please see below.

>( Roque) In my mind, the only thing that we we need to care about is if we follow the
>periodic scheduled periodic rollover process or an emergency rollover. In general
>the difference between the two is that in the emergency case there may not be
>the time to wait for the RPKI process to propagate the information.

[Sriram] In EKR, there is preparedness for reaction to an "event" so that the affected router 
can limit the window of exposure to replay attack. 
In our description of EKR, it is NOT used in combination with PKR. 
In the EKR, there are always 'Current' and 'Next' transit keys provisioned 
(in addition to 'Current' and 'Next' origin keys); but this process is not periodic.
All these keys have long NotValidAfter time in the EKR method. 
Since 'Next' transit key is propagated in advance, there is no need to wait 
for the RPKI process to propagate that information after an event has happened.
So in EKR, when an event occurs, the router can immediately start
signing with the 'Next' key and the receiving routers already have
the corresponding pub key so they can validate the new updates. 
The router which experienced an event and hence rolled the transit key
will propagate a new 'Next' transit key to be prepared for any future event as well. 
Subsequently, it will also issue a CRL for the previous cert. 
So EKR is a complete method in itself and can be an alternative to PKR. 
The trade-off is that EKR produces a churn only when events happen which are presumably rare,  
but PKR produces update churn and RPKI churn in the background 
plus it also produces update churn when events happen but less than that for EKR.
(Side note: It is true that even in PKR, rollover of transit keys happens for maintenance 
purpose once in long time (years); but we are focused here on the replay protection issue.)      
>
-- snip --
>
>(Roque) Ok, so you are focussing on the "transit" certificate rollover. This means
>that this is a different discussion and has nothing to do with the re-play attack as
>the technique we are pushing forward to control the windows of exposure are
>periodic rollovers of "origin" certificates keys. Is the goal then to compare the
>router's behavior when dealing with periodic vs emergency rollovers?
>
[Sriram] No. We were comparing the amount of update churn that is created when 
*an event happens* (as described above) in PKR vs. EKR. 
I hope this should be clear now that I did described "event" and EKR above. 
What we have shown is that for the same event happening, EKR generally has 
higher (or much higher in many cases) update churn than PKR 
for the same event happening. (OTOH, PKR has the downside of producing 
some update/RPKI churn all the time in the background.) 

-- snip --

>> what we consider in slides 6-8 is that when the event occurs, in the PKR method
>no cert is rolled (by design).
>
>(Roque) I do not understand your comment " in the PKR method no cert is rolled
>(by design)". The transit certificate, as any PKI certificate, will need to be rollover
>due to two possible reasons: periodically (it has a long validity period but one day
>it will expire) and emergency (particularly key compromised). Now, in each of
>these cases, you need to perform a rollover process and you want to "do before
>break" (sometimes in emergency process you do not have this option and you
>break).
>
[Sriram] I agree with your observation. But as I said we are focused here on replay protection
and events that are of the nature of peering relation discontinuation, policy change, etc.
Note that I did say "when the event occurs, in the PKR method no cert is rolled (by design)."
You have also stated that the transit cert in not rolled in PKR when these "events" happen.

Sriram