Hi Sriram, Thanks for the email.
On Oct 21, 2012, at 9:40 PM, Sriram, Kotikalapudi wrote: > Roque, > > I took another look at Section 4.2. > Can you please clarify if the method you describe in Sec. 4.2 is purely the > PKR method, > or if it has elements of both PKR and EKR in it? (Roque) The proposal in section 4.2 is to use periodic, scheduled key rollovers of the "origin" certificate to limit the windows of exposure to replay attacks. This does not exempt the CA to rollover BGPSEC certificates/keys for any other reason. > Do you roll the transit key when an event (peering discontinuation or policy > change) > happens at a router having transit prefixes? > This is not clear from the wording in Section 4.2. (Roque) No. Section 4.2 introduces the idea of two certificates and rolling over the "origin" certificate to limit the windows of exposure to replays attacks. Of course if there are topology changes inside that windows, replay attacks would be possible. Section 3, is aimed to document a generic rollover process for both "origin" and "transit". In the transit case, we did not studied yet what should trigger rollover processes. My personal opinion is that transit certificates should have long lives and should not be, in general, be mandate to be rollover to enforce topology/policies changes. The origin AS by rolling over its "origin" certificate would control the exposure windows for its own BGP UPDATES. BTW, I am planning to send a new version today adding the comments from Steve and you before WG adoption. Regards, Roque > > Thanks. > Sriram _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
