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

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

Roque,

>One thing that did not went out well in my previous email is that I really appreciate the time you guys took to look into this issue.

Amendment gladly accepted! Thank you. 
We enjoyed putting in the effort as it was a great learning opportunity for us as well. 
Thanks to you, Brian W. and Keyur for getting the ball rolling initially on this. 

>On Oct 18, 2012, at 3:04 PM, Roque Gagliano (rogaglia) wrote:
> Sriram,
> 
> I read your document and I have a some comments.
>

Let me make the overarching observation upfront that our document 
does NOT seek to promote any one method over another. 

> 
> 1) In general I did not understand the objective of this draft as you are basically re-stating what is already briefly mentioned at draft-ietf-sidr-bgpsec-rollover-00 and no new elements are there for the WG to take an action.
>

At first, your observation seemed like a hastily formed opinion. 
But you seem to have amended it since then. 
Let me make the following points regarding the above:

1.	It is not uncommon to have a rationale / design discussion document 
that complements a design specification document. In the SIDR WG we did that 
with draft-lepinski-bgpsec-protocol (the initial individual I-D), 
when we also submitted draft-sriram-bgpsec-design-choices.

2.	The design specification document is normally brief and to-the-point 
meant for the implementers. The *informational* discussion document should capture 
things like enumerating the alternative design choices that were proposed/considered, 
the pros/cons analysis, example scenarios, and evaluation and comparison of 
design choices under those scenarios, etc. The latter is what we have attempted to do 
in our document and provided several new insights as well.

3.	Even after the design is complete and the WG has finalized a design specification, 
late comers still tend raise questions about alternatives. 
The *informational* discussion document is the place to go to for anyone 
who wants to peruse into history and the design rationale.        
 
>
>Particularly, I was surprised that in your assessment for the PKR method you did not considered the points highlighted in section 4.2 of our draft (Advantages/Disadvantages).
>

In your Section 4.2, you have proposed what looks like a hybrid of PKR and EKR methods
(without using that specific taxonomy). We consider PKR and EKR as separate design choices, 
and hence discussed their pros/cons separately. But I think we have captured many of 
the same advantages/disadvantages you have outlined and some additional ones. 
We are open to taking in comments and revising the document as needed; 
so we will be happy to relook at that.

I have a question for you on your Section 4.2 regarding why you propose 
to implement a hybrid of PKR and EKR. Let me take that up in a separate thread.
     
> 
> 2) Your summary statement: "The Expire Time (ET) method is best" does not represent the WG consensus when our draft was accepted as WG item and when the timestamp field was removed from the Protocol Specification. 
>

We are fully mindful of the WG consensus and we are in no way promoting 
the ET method in the document. You took a piece of the whole statement 
and made it appear like that was the summary of our document. 
The actual statement (in Section 7) in the document is as follows:

"1.  The Expire Time (ET) method is best (on par with the PKR method)
       in terms of preventing huge update workloads during peering and
       policy change events at transit routers with several peers.  It
       has no added RPKI churn.  But the ET method has the disadvantage
       of requiring on-the-wire protocol change if some parameters
       (e.g., the units of beacon interval) change."

The intent here was just to equate the ET and PKR methods in terms of update workload. 
We would change the first sentence (when revised) to read: 
"The ET and PKR method are on par in terms of preventing huge update workloads ......"  

>
>IMHO, the problem with your comparison between ET and PKR is that you did not mentioned that implementing ET introduces important changes to current BGP implementations. The design decision is to either maintain states in every BGP speaker (having to allocate an expiration time to every update and needing to check if that time is old) vs increase the churn at the RPKI repository system and more admin processes in the RPKI. The group took the second path.
>

It depends on how you see it. How would you keep track of the NotValidAfter time 
of update signatures (as determined by the NotValidAfter time of the respective certs) 
in the PKR method? If keeping track of this is done in the router, 
then there is a need to maintain state even in the PKR method. OTOH, 
if the RPKI cache server is sending a withdraw of the public key 
when the cert's NotValidAfter time is reached, even then the BGP process needs 
to scan the update tables and prune out the ones that are affected. 
I think that also implies changes to the current BGP implementations anyway. 
However, we did observe that with the ET method we have the disadvantage 
that the expire-time field is built into on-the-wire BGPSEC protocol 
and that is not a desirable feature.

> 
> 3) Your study of EKR is very bias because the effect of event-driven key rollovers will depends on the event that is driving that key rollover. Particularly, and putting it on the same words that our draft uses, in this particular case you are comparing a rollover of the "transit" certificate key vs a rollover of the "origin" certificate key.
>

I think you are referring to slides 6-8 in
http://www.nist.gov/itl/antd/upload/replay-discussion.pdf
No, we are not comparing apples and oranges here. In these comparisons (see slide 8), 
we do not focus at all on the rollover of the "origin" certificate key. 
That actually has a very minor impact on updates (as illustrated in slide 5) and 
we don't focus on that in the plot in slide 8. Instead, what we consider in slides 6-8 is that 
when the event occurs, in the PKR method no cert is rolled (by design). 
But even then a certain amount of BGPSEC updates would be propagated similar to 
what happens in conventional BGP-4. That is because the router will recompute new best paths 
for the prefixes affected by the event, and those updates need to be propagated 
even though no key has been rolled due to the event. 
In some scenarios such as Scenario 1 in slide #6, no updates are generated in PKR 
under those circumstances. But in another scenario such as Scenario 2 in slide #7, 
a moderate burst of updates is generated in PKR (same number as in BGP-4). 
However, in both scenarios, a huge burst of updates is generated in the EKR method 
due to the transit key rollover which causes all prefix routes to be propagated 
or re-propagated at that router. I hope this explanation helps.

>   
> As you wrote in the document, when you rollover the transit certificate, you gain the possibility to refresh transit policies which is not the case with either ET or only rolling over the origin certificate key using PKR. But rolling over the transit certificate key should be very rare because of the reasons that you and us mention.
> 

I agree.

Thank you once again for reading and commenting on the document.

Regards,
Sriram