Thank you for the response, I just published a new version with the mentioned text.
Thank you again for the comments! Yours, Daniel On Fri, Oct 18, 2019 at 3:43 PM Benjamin Kaduk <[email protected]> wrote: > On Thu, Oct 17, 2019 at 10:37:10PM -0400, Daniel Migault wrote: > > Hi Benjamin, > > Thanks you for the comments. Please see in line my responses. > > Yours, > > Daniel > > On Wed, Oct 16, 2019 at 11:30 PM Benjamin Kaduk via Datatracker > > <[email protected]> wrote: > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-ipsecme-implicit-iv-08: No Objection > > > > When responding, please keep the subject line intact and reply to > all > > email addresses included in the To and CC lines. (Feel free to cut > this > > introductory paragraph, however.) > > > > Please refer to > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ > > > > > ---------------------------------------------------------------------- > > COMMENT: > > > ---------------------------------------------------------------------- > > > > Thanks for addressing my Discuss! > > > > A few new comments on the -08: > > > > Abstract > > > > If we're going to differentiate between nonce and IV, I think that > > the algorithms require a unique but not necessarily unpredictable > > *nonce*, > > rather than *IV*. > > > > I would preferred to have IV instead of nonce is that IPsec provides > > constraints on the IV, not the nonce. I expected to have switched from > > algorithms to their implementations by writing "when used with IPsec" > in > > the previous sentence. In order to flip-flop from algorithm to their > > implementations with IPsec, I propose to clarify this as follows: > > OLD: > > These > > algorithms require a unique IV but do not require an unpredictable IV. > > NEW: > > This IV must be unique but can be predictable. > > Thanks! > > > > > Section 2 > > > > nit: s/Initialize/Initialization/ > > > > Fixed > > > > nit: s/similar mechanism/similar mechanisms/ plural > > > > Fixed > > > > > > Section 7 > > > > My previous ballot was trying to note that the sender/receiver > counters > > MUST be reset (as noted here) even without this document, as part of > > the core ESP requirements. So we don't need to use the "MUST" here > as > > if it's a new requirement; we can just say that this behavior is > already > > present due to the preexisting requirements > > > > Well, the reason I included it was that - at least my reading of ESP > - ESP > > seems to require key to be rekeyed when the SN reaches its limit only > when > > anti-replay is activated. In our case, we need to have this property > even > > without anti replay protection. Here is the text I considered rfc4303 > > section 2.2 > > """ > > > > The sender's counter and the receiver's counter are initialized to 0 > > when an SA is established. (The first packet sent using a given SA > > will have a sequence number of 1; see Section 3.3.3 for more details > > on how the sequence number is generated.) If anti-replay is enabled > > (the default), the transmitted sequence number must never be allowed > > to cycle. Thus, the sender's counter and the receiver's counter MUST > > be reset (by establishing a new SA and thus a new key) prior to the > > transmission of the 2^32nd packet on an SA. > > > > """ > > Ah, it seems I was reading too quickly and missed the precondition. > Thanks for the attention to detail! > > -Ben > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
