Hi Keith. Thanks for the comments. My responses inline.
On Jan 19, 2011, at 2:36 AM, Keith Welter wrote: 1. The last paragraph of section 2 seems to be making an argument against supporting QCD. Would it be possible to add a counterpoint or to reword the paragraph? When I got to the end of the document, I found that section A.4 had the counterpoint I was looking for. Perhaps add a reference to section A.4 from the last paragraph of section 2. OK. How about: Some existing IKEv2 implementations already do that (i.e., both shorten timeouts or limit number of retries) based on these kind of hints and also start liveness checks quickly after the other end goes silent. However, see Appendix A.4 for a discussion of why this may not be enough. 2. In section 4.1 (Notification Format) the TOKEN_SECRET_KEY fields size is given as "(16-128 octets)". I suggest replacing this with "(variable)" so that the specific size requirement only appears in one place (section 5): "Tokens MUST be at least 16 octets long, and no more than 128 octets long, to facilitate storage and transmission." OK. 3. In section 4.3, the text "SHOULD soon initiate an INFORMATIONAL exchange as follows" is vague. How soon is soon? How about: "SHOULD initiate an INFORMATIONAL exchange immediately after the CREATE_CHILD_SA exchange as follows". Or, omit "immediately" if that is not strictly necessary. OK, and I went with "immediately". If the initiator doesn't do it, QCD does not work. 4. The final paragraph in section 4.3 mentions "key rollover" and "secret QCD keys" but these concepts have not been defined. It seems like this material would fit better in section 5 (Token Generation and Verification) where the cryptographic mechanism for QCD token generation is recommended. I disagree with this. Section 4 has all the information about using the notification payload. How about if I add a pointer like this: The INFORMATIONAL exchange described in this section can also be used if QCD tokens need to be replaced due to a key rollover. However, since token takers are required to verify at least 4 QCD tokens, this is only necessary if secret QCD keys are rolled over more than four times as often as IKE SAs are rekeyed. See Section 5.1 for an example method that uses secret keys which may require rollover. 5. Similarly, section 4.5 mentions "periodic rollover of the secret used for token generation" but token generation has not yet been covered. Perhaps a better solution than what I recommended in the prior comment would be to move all of section 5 (i.e. 5 through 5.3) before section 4. That way, token generation would be discussed before any mention of token secrets, keys or rollover in sections 4.1 through 4.5. See last remark. 6. The first sentence on page 18 is an orphan. That's just how the xml2rfc utility formats it. When (and if) it gets published, the RFC editor takes care of these stylistic issues. 7. In section 11, "contrinuted" should be "contributed". Will be fixed in -04. 8. Section A.1 says, "The disadvantage here, is that in IKEv2 an authentication exchange MUST have a piggy-backed Child SA set up." RFC 6023 specifies a childless IKE SA initiation so that sentence is not true for implementations that support RFC 6023. True, but since RFC 6023 is experimental, I would like to leave this sentence. Also, the important part is the next paragraph, which says that sometimes setting up a new IKE SA is not possible for the former responder. Thanks, Keith Welter IBM z/OS Communications Server Developer 1-415-545-2694 (T/L: 473-2694) Scanned by Check Point Total Security Gateway. <ATT00001..txt>
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
