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

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

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