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

["Roque Gagliano (rogaglia)" <[e-mail]>]

Hi Sriram,

Thanks for your email.

The problem I have with the way you described EKR is that it suppose that there is some sort of "coordination" between ASes in a way that an origin AS has to "trust" that whenever there is a topology change in a path, there will be a rollover by the ASes involved in those changes.

This sort of cooperation assumptions is a non-started IMHO.

All in all, I think we agreed on the path forward.

Roque

On Oct 23, 2012, at 11:24 PM, Sriram, Kotikalapudi wrote:

>> (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
>