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

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Thu, 18 Oct 2012 13:04:04 +0000

Sriram,

I read your document and I have a some comments.

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. 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).

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

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

Regards,
Roque

On Sep 22, 2012, at 1:19 AM, Sriram, Kotikalapudi wrote:

> This submission is an informative design discussion document that provides insights 
> into the operation of multiple alternative methods for replay-attack protection. 
> We hope that the SIDR WG will take the insights and trade-offs presented here as input 
> for deciding on the choice of a mechanism for protection from replay attacks.
> It is meant to be a companion document to the standards track 
> I-D.-ietf-sidr-bgpsec-rollover that will specify a method to be used 
> with BGPSEC for replay-attack protection.
> 
> A set slides with figures that is referenced in the document can be found at:
> http://www.nist.gov/itl/antd/upload/replay-discussion.pdf 
> (the figures are helpful but not necessary to read the document).
> 
> Comments welcome.
> 
> Sriram
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Friday, September 21, 2012 7:01 PM
> To: [email-masked]
> Cc: Montgomery, Douglas; Sriram, Kotikalapudi
> Subject: New Version Notification for draft-sriram-replay-protection-design-discussion-00.txt
> 
> 
> A new version of I-D, draft-sriram-replay-protection-design-discussion-00.txt
> has been successfully submitted by Kotikalapudi Sriram and posted to the IETF repository.
> 
> Filename:	 draft-sriram-replay-protection-design-discussion
> Revision:	 00
> Title:		 Design Discussion and Comparison of Replay-Attack Protection Mechanisms for BGPSEC
> Creation date:	 2012-09-22
> WG ID:		 Individual Submission
> Number of pages: 17
> URL:             http://www.ietf.org/internet-drafts/draft-sriram-replay-protection-design-discussion-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-sriram-replay-protection-design-discussion
> Htmlized:        http://tools.ietf.org/html/draft-sriram-replay-protection-design-discussion-00
> 
> 
> Abstract:
>   The BGPSEC protocol requires a method for protection from replay
>   attacks, at least to control the window of exposure.  In the context
>   of BGPSEC, a replay attack occurs when an adversary suppresses a
>   prefix withdrawal (implicit or explicit) or replays a previously
>   received BGPSEC announcement for a prefix that has since been
>   withdrawn.  This informational document provides design discussion
>   and comparison of multiple alternative replay-attack protection
>   mechanisms weighing their pros and cons.  It is meant to be a
>   companion document to the standards track I-D.-ietf-sidr-bgpsec-
>   rollover that will specify a method to be used with BGPSEC for
>   replay-attack protection.
> 
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Fri, 19 Oct 2012 07:55:41 +0000

Sriram,

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.

Regards,
Roque

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Fri, 19 Oct 2012 12:36:13 -0400

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. 

> 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 o…

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 ce…

I agree.

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

Regards,
Sriram

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Mon, 22 Oct 2012 08:56:39 +0000

Sriram,

Let me re-comment on some of the points.

(skip)

> so we will be happy to relook at that.

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

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.

> to implement a hybrid of PKR and EKR. Let me take that up in a separate thread.

(Roque) ok, I will take a look at that other email.

> "The ET and PKR method are on par in terms of preventing huge update workloads ......"  

(Roque) Again, the problem that the WG was concerned about when studying the ET value (and that was not covered in your document) was not the changes "on the wire" (although some discussion happened on who had control over the expiration time) but rather the changes on the BGP logic that has been around for decades. This point is not covered in your document.

> and that is not a desirable feature.

(Roque) The need for the router (if the certificate signing requests are originated by the router) to keep track of the NotValidAfter time is ONLY for its own certificates. We covered this in our draft, particularly when we express as an advantage that the AS that wants to protect itself against a replay attacks pays most of the "Administrative cost" (Steve later corrected us that Relying Parties also pay a tax which will be included in our next release). Now, to keep track of the "NotValidAfter" time for the rest of the BGPSEC certificates you follow the traditional RPKI process: the caches fetch the repositories, if a certificate is not longer valid, they send a withdrawn to the routers for that SKI. The routers do not need to keep track of it because the cache will do it.

Moreover, we mention in the draft that the automatic process to make this to work (certificate provisioning, changes to the RTR protocol and how a router should react to a SKI withdrawn message) are not yet documented but we worked under the assumption that it would be shortly. We understand that other members of the SIDR WG are working on this piece and that is why we did not cover it. 

> we do not focus at all on the rollover of the "origin" certificate key. 

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

> 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).

> or re-propagated at that router. I hope this explanation helps.

(Roque) Sorry but I am still confused. In my view an emergency or a periodic key rollover will have the same effect on the BGPSEC layer with the difference that in the emergency case you may not have the chance to wait for the RPKI information to be propagated and thus you risk that the new BGP UPDATES do not validate.

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Tue, 23 Oct 2012 17:24:32 -0400

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

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Wed, 24 Oct 2012 08:08:34 +0000

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

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Wed, 24 Oct 2012 11:48:12 -0400

Roque,

Thanks. Some new observations below.

Sriram

>
>The problem I have with the way you described EKR is that it suppose that there is
>

The description of EKR is based how it was discussed at the Feb. 2012 SIDR interim
in San Diego. The meeting notes didn't capture the description well, but
it is there (also didn't refer to it as EKR at the time): 
http://www.ietf.org/mail-archive/web/sidr/current/msg04000.html 
 
>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.
>

You are right, but there is a reverse trust issue as well (with PKR). 
I suspect that PKR and EKR may co-exist in the BGPSEC network for the following reasons:
It is known that 84% of all ASes are stubs. 
Over some time initially (during BGPSEC adoption), some or many of the stub ASes 
may participate in BGPSEC but not operate PKR as expected of them. 
They may be wary or clueless about rolling their certs every 24 hours or so. 
So they might just set their cert NotValidAfter time to some large value, and 
perhaps not want to be bothered with doing the rollover frequently.
If a transit provider suspects that may be happening, then they would want to
play it safe (i.e., avoid liability) and rollover their transit cert (i.e., perform EKR) whenever 
they have topology change or policy change in their AS that affects transit prefixes.
This way they can be sure they are doing what is in their control to 
provide some protection from replay attacks for their transit prefixes
even if some origin ASes may be negligent.

It seems to me that the hooks needed to implement EKR are a subset 
of those needed for PKR. So the operators may choose to do EKR anyway 
until they are certain that  there is close to full participation in PKR by origin ASes.

Sriram