Hi Sandra,
Thanks for all your comments. To be honest, we did not updated the document for quite some time waiting for the advancement of the BGPSEC thread/requirements/protocol documents. I agree that we should now update it to be consistent with the changes in the main documents but I believe I will not have cycles to do it before Vancouver deadline. We also have Steven's comments to incorporate to the new version. Sriram made a recommendation about taxonomy (the idea of two different keys was introduced by us in the document) that we also need to incorporate. All in all, please do not expend additional time with this document at its current stage. See more inline. Roque On Oct 11, 2013, at 8:50 PM, "Murphy, Sandra" <[email protected]> wrote: > 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. (Roque) we should add it. > 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. (Roque) We were thinking that the question here is that external hosting could impact if no programmable API is available (manual vs automatised process.) We should be more explicit about it > 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.) (Roque) In an emergency roll-over, there is high probability that RPs did not pre-fetched the new certificate before the old certificate is revoked so the change of only having a revoked certificate is there (although current top-down validation eliminates a big part of this requirement) > > "typical operation of refreshing out-bound BGP policies" - you mean typical > as is currently possible in current routers, right? (Roque) correct. > "probably in the order of minutes to avoid reaching any expiration time" - > are the authors presuming a order of magnitude for cert expiration times? (Roque) This sentence is not about cert expiration times but about avoiding all routers to start signing the UPDATES with the NEW key at the same time. The size of the attack windows is discussed in Section 4. > > 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. (Roque) They are sequential. The comment about steps 1-2 is that an organisation could have pre-publish their NEW keys and wait an unspecified amount of time before moving to the Twilight. > > 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? (Roque) You are correct about the withdraw. If an external router did not receive the new SKI from the validator, it will classify the BGPSEC_PATH as "invalid". If it received the SKI, it will classify the BGPSEC_PATH as "valid". No much to say as there are many different scenarios where one or the other one may happen. > 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? (Roque) We need to update the document. > 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?) (Roque) Sriram recommended changes in the taxonomy that we need to include. Roque > > --Sandy, speaking as regular ol' member > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
