| Main Archive Page > Month Archives > ipsec archives |
Re: [IPsec] WG Last Call on draft-ietf-ipsecme-failure-detection
From: Yoav Nir <ynir_at_nospam>Date: Sun Jan 30 2011 - 08:00:38 GMT
To: Keith Welter <welterk@us.ibm.com>
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