Hi Erik, Thanks for the review which I believe the draft version 06 addresses them. Please find the details inline below.
Yours, Daniel [abstract] [nit] * "Some constrains include" -> "Some constraints include" > done [S1] [comment] * Someone will inevitably point out that requirements terminology don't belong in an Informational document. Suggest removing this and lowercase all the terms throughout the document. I know it doesn't seem ideal, but I don't think it really lowers the value of any of the recommendations in the doc. > I am a bit surprised by such a rule. While I might be missing the rationale, but it seems to me that informational documents are also concerned with interoperability and the 2119 language has been introduced to make implementation interoperable. At least that was my understanding. That said, I proceeded as follows: SHOULD NOT: 2 SHOULD: 1 MUST NOT: 3 MUST: 10 RECOMMENDED: 10 MAY: 3 and committed in case we need to reverse it back ;-) [S2] [nit] * "and limited traffic flow confidentiality" seems to be redundant with "provide confidentiality" earlier in the sentence. (It also raises the question of "in what way is it limited?", which just seems like an unnecessary digression.) > limited traffic flow confidentiality in fact designates some padding and the feature is often designated as TFC. It is defined in RFC4303 section 2.7 and the section title mentions padding, so I "padding" was missing, and I also added the acronyme TFC. so the final text is: "and limited traffic flow confidentiality (TFC) padding." I think that addresses the confusion, but we can also point to the specific section of RFC4303. [S3] [nit] * "used internal" -> "used internally" > done * ", checks does not fall" -> "and checks it does not fall" > done [S3.1] [question] * "proceed to clean key update" What does this mean? "clean"? > "clean key" update means that there is a mechanism that enables a peer to say which key is being used. In other words, there is not a set a keys to test. I propose the following change. OLD: SPI can typically be used to proceed to clean key update and the SPI value may be used to indicate which key is being used. This can typically be implemented by a SPI being encoded with the Security Association Database (SAD) entry on a subset of bytes (for example 3 bytes), while the remaining byte is left to indicate the rekey index. NEW: SPI can typically be used to implement a key update with the SPI indicating the key is being used. For example, a SPI might be encoded with the Security Association Database (SAD) entry on a subset of bytes (for example 3 bytes), while the remaining byte indicates the rekey index. * "use of randomly generated SPI" -> "use of randomly generated SPIs" > done * "leakage or privacy or security related information" -> "leakage of privacy or security related information" > done [S4] [question] * When too many packets are dropped (due to "out of window" conditions), does this cause the session to be renegotiated? > SN is checked as the first operation- prior integrity check. If taken into account, these could easily be used to trigger the rekey. In fact the consecutive failed authentication is used to trigger a rekey. RFC 4303, does not mandate any other parameters than consecutive authentication failure to be considered for the trigger, but does not prevent others to be considered and it is worth noticing that out of windows SN are auditable events. So I think that suggesting to consider out of windows event are a bit out of scope of the minimal esp implementation. That said, we may add that when removing the mechanism we should consider that additional integrity checks might be performed. I suggest the following text: OLD: As a result, some implementations MAY drop a non required anti replay protection especially when the necessary resource involved overcomes the benefit of the mechanism. NEW: As a result, some implementations MAY drop a non required anti replay protection especially when the necessary resource involved overcomes the benefit of the mechanism. These resources need also to balance that absence of anti-replay mechanism, may lead to unnecessary integrity check operations that might be significantly more expensive as well. If so, is it important to weight the computational impact of reestablishing IPsec crypto state relative to trying to maintain better record of the previously seen SNs? [S4] [nit] * "drop an non required anti replay protection" -> "drop a non-required anti-replay protection" > done * "the support ESN is not" -> "the support of ESN is not" >done [S5] [nit] * "that were rely on" -> "that were relying on" > done * "rather when" -> "rather than when" > done [S6] [nit] * "generate and receive dummy packet" -> "generate and receive dummy packets" > done * "fix value" -> "fixed value" > done ( 2 times) [S8] [nit] * "provided as indicative" -> "provided as information"? > done: provided as informational * "Constraint devices" -> "Constrained devices" > done * "energy associated to it" -> "energy associated with it" > done [S10] [nit] * "associated to the management" -> "associated with the management" > done * "This usually include mechanisms to prevent a nonce to repeat for example." "This usually includes mechanisms to prevent a nonce from repeating, for example." > done * "in conjunction of" -> "in conjunction with" > done * "responsible to negotiate" -> "responsible for negotiating" -- Daniel Migault Ericsson
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
