Speaking as regular ol' member Some comments on the rollover draft.
The title says "an alternative to beaconing" - the protocol doc no longer talks about beaconing, so this is an alternative to a behavior that no longer exists. I am not certain about the scope of this rollover discussion. The draft intro says the scope is changing the key pair and talks the need to reissue updates because old signatures will be invalid. But section 3 also says the rollover process includes cases where you "generate a new certificate without changing the key pair". And the end of 3.1 says "When a new BGPSEC certificate is generated without changing its key" Section 2 mentions control of the replay window as a primary motivation. But Section 3 does not list that as one of the causes. Section 3.1 mentions that the details of pre-publishing a new cert will vary with circumstances. Should the possible differences be mentioned? For example, one mentioned circumstance is whether the repository is "locally or externally hosted" - I'm not sure what differences that particular circumstance would make. I presume the difference is control of timing, but I'm not sure. Section 3.1 - "in which case routing information may be lost" - why? (I figure I know why, but I'm not so sure I'm thinking what the authors are thinking.) "typical operation of refreshing out-bound BGP policies" - you mean typical as is currently possible in current routers, right? "probably in the order of minutes to avoid reaching any expiration time" - are the authors presuming a order of magnitude for cert expiration times? Are steps 1-5 intended to be sequential? I would expect, but later text takes care to point out that steps 1-2 "could happen ahead of time", which raises the question of timing of the process. Step 2 is not deterministic - there's a good enough staging time but no way to choose a certain maximum staging time. If step 3 reaches a router that has the new key but has not yet been informed that the old key is no longer valid, then the new update will implicitly withdraw the old update. (Right?) If the new key has not reached a router, it will not be able to validate the new update and will (likely?) not propagate the new update. Any thoughts of what that will mean to overall bgp behavior? Section 4 refers to beaconing - which is no longer part of the protocol. "Currently BGPSEC offers a timestamp (expiration time)" - not in the current protocol spec that I could see. Can you be more specific? section 4.2 maybe should list the convergence churn resulting for a new key. section 4.2 says: 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. This was a strategy suggested by Sriram, IIRC. We should be sure that the protocol draft supports this strategy. (Is this the right draft to make this keying suggestion?) --Sandy, speaking as regular ol' member _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
