On Dec 8, 2012, at 9:25 AM, Sriram, Kotikalapudi wrote: > > Periodic key rollover (PKR) is currently recommended in > [draft-ietf-sidr-bgpsec-rollover] > as evident from the following quote (from Section 4.2): > > “For this reason, it is recommended that routers in this scenario been > provisioned with two certificates: one to sign BGP UPDATES in transit > and a second one to sign BGP UPDATE for prefixes originated in its > AS. Only the second certificate (for prefixes originated in its AS) > should be rolled-over frequently as a means of limiting replay attach > windows. The transit BGPSEC certificate is expected to be longer > living than the origin BGPSEC certificate.”
Note: There are two grammatical errors / typos in _that text fragment. That said, > In the PKR method, the "current" origination cert (and key pair) expires at > periodic intervals > and updates are re-originated signed by the "next" origination cert. OK, this IS _the new added churn I was referring to. This doesn't occur in BGP today. > Just to clarify, *transit* prefixes are not beaconed (i.e., not > "periodically" re-propagated) > by *transit routers* in any of the key rollover methods. > The PKR method has periodic re-origination of origination prefixes only > (i.e., each eBGP router periodically re-originates its origination prefixes). > The EKR method by definition is event-driven, hence does not entail any > periodic re-originations. You're introducing a new "event" here that has an periodic expiry attribute, this IS _the new added churn I was referring to. This doesn't occur in BGP today. > The events (topology changes, etc.) are presumably rare/infrequent. "presumably rare/infrequent" != "does not occur". To that, how was it determined that "Transit cert can have a very large NotValidAter time", what requirement led to this? Again, we can repurpose and reapply terms for beacon/periodic/triggered/event-driven words all we want, but if an intermediate AS needs to retransmit an advertisement because it's forwarding signing "Transit cert" rollover; solely because of some refresh or expiry action related to key rollover then that's something that doesn't occur in BGP today, and yet another place where combinatorial effects of all these "capabilities" give me concern, and represent _the new added churn I was referring to. This doesn't occur in BGP today. Given, leaving the attack window larger for "transit certs" reduces churn, but it should lead one to question the broader objectives and implications. Finally, all these options mean relying parties (i.e., BGPSEC routers) must have all the old and new (and future?) certificates onboard and know which to use at what time for validating which origin_as or transit signature blocks at what times. As Randy points out, we have a hard enough time rolling keys between adjacent BGP speaking routers for transport connection protections. What you're proposing gives me some real concern... -danny _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
