Subject: [IPsec] WG Last Call on draft-ietf-ipsecme-failure-detection

From: Paul Hoffman <[email-masked]>
Date: Wed, 12 Jan 2011 09:53:45 -0800

Greetings again. This starts the two-week WG Last Call on 
draft-ietf-ipsecme-failure-detection, currently the -03 draft. There has 
been very little comment on this document lately, but please not that 
issue #202 (see <http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/202>) 
is still open. Also note that our virtual interim meeting, which is 
meant to focus on this document, happens the day before this WG LC 
closes. If there continues to be little comment on the document or on 
issue #202, that will be a very short meeting.

--Paul Hoffman, Director
--VPN Consortium

---

From: Keith Welter <[email-masked]>
Date: Tue, 18 Jan 2011 16:36:49 -0800

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.
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."
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.
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.
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.
6. The first sentence on page 18 is an orphan.
7. In section 11, "contrinuted" should be "contributed".
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.

Thanks,

Keith Welter
IBM z/OS Communications Server Developer
1-415-545-2694 (T/L: 473-2694)

---

From: Keith Welter <[email-masked]>
Date: Tue, 18 Jan 2011 16:43:50 -0800

> 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. 

I just noticed that the category of RFC 6023 is Experimental so this 
comment can probably be ignored.

Thanks, 

Keith Welter

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 27 Jan 2011 08:42:16 -0800

This message closed out the WG LC. There remains one open issue, #202. 
Based on Scott Moonen's suggestion, he and David Weirbowski will propose 
wording for combining sections 9.2 and 9.4 into a single discussion that 
will close this issue. They can bring this proposal to the mailing list 
and, assuming there is general agreement, the authors will put out a 
final version with it in it and we can move the document to our Area 
Director.

--Paul Hoffman, Director
--VPN Consortium

---

From: Yoav Nir <[email-masked]>
Date: Thu, 27 Jan 2011 23:47:07 +0200

I'd like to also point out that Scott and Keith have pointed out some nits in the spec (on the 12th and 19th of January respectively), which will also be included in the final version.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Sun, 30 Jan 2011 10:00:38 +0200

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.

That's just how the xml2rfc utility formats it. When (and if) it gets published, the RFC editor takes care of these stylistic issues.

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

Scanned by Check Point Total Security Gateway.

<ATT00001..txt>