Subject: [sidr] comments on draft-ietf-sidr-bgpsec-rollover

From: "Murphy, Sandra" <[email-masked]>
Date: Fri, 11 Oct 2013 18:50:08 +0000

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

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Mon, 14 Oct 2013 20:08:50 +0000

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

> 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 t…

(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…

(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 mo…

(Roque) We need to update the document.

> 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

> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr