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

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: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
> Sent: Friday, September 21, 2012 7:01 PM
> To: sriram.ietf@gmail.com
> 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
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr