Subject: [IPsec] Closing the IKEv2bis open issues

From: Paul Hoffman <[email-masked]>
Date: Tue, 20 Oct 2009 09:19:15 -0700

Greetings again. There are three open issues for IKEv2bis. I would like to close the three of them so we can move forwards with the document.

Issue #22, Add section on simultaneous IKE SA rekey
<http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/22>
There is no consensus on this issue. Tero Kivinen and David Wierbowski have deep differences of opinion, and almost no one else has participated. I have reviewed the discussion, and I think both people have strong merits to their opinion. Therefore, Yaron and I will try to coordinate a design team effort that includes Tero, David, and any others who have thought about this issue in depth. If that fails to come out with an agreed-to solution, we will probably drop back to adding a short, inconclusive, descriptive note in the IKEv2bis document.

Issue #25, Choice of the right TS when narrowing
<http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/25>
This has not been discussed on the list. I have looked at what we say in RFC 4306, and it matches with the proposed text in the open issue. However, RFC 4718 says what we have in the current IKEv2bis draft. I  believe that the new wording is in fact a technical change, but it has now been out there for many years. Therefore, I will make the following change:
Current ikev2bis wording:
   When narrowing is done, there may be several subsets that are
   acceptable but their union is not.  In this case, the responder
   arbitrarily chooses one of them, and MAY include an
   ADDITIONAL_TS_POSSIBLE notification in the response.
Proposed change:
   When narrowing is done, there may be several subsets that are
   acceptable but their union is not.  In this case, the responder
   SHOULD select the initiator's first choice (to be interoperable
   with RFC 4306), but MAY arbitrarily select any of them,
   and MAY include an
   ADDITIONAL_TS_POSSIBLE notification in the response.

Issue #79, Remove CP from Create_Child_SA ?
<http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/79>
There is no consensus on this issue. There was lively discussion, but there is wide disagreement on how and when CP payloads should be used in the scenarios given, and what would constitute a change to RFC 4306. Therefore, I am adding the following to section 2.19 of IKEv2bis: "All responses that contain CP(CFG_REPLY) payloads apply to all the IPsec SAs that are set up by the exchange."

Comments are welcome if you think they can help bring about rough consensus on these issues.

--Paul Hoffman, Director
--VPN Consortium

---

From: Yoav Nir <[email-masked]>
Date: Wed, 21 Oct 2009 09:46:27 +0200

A few lines above this section it already says "If the responder's  
policy allows it to accept the first selector of TSi and TSr, then the  
responder MUST narrow the traffic selectors to a subset that includes  
the initiator's first choices."

So there is a MUST requirement to select the initiator's first choice  
(if possible), so I don't think the SHOULD and MAY are appropriate  
here. The way I read this section, it only clarifies what to do if the  
initiator traffic selector (first or not) is too broad. In that case,  
we shouldn't mention the initiator's choices.

> Issue #25, Choice of the right TS when narrowing
<snip/>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 21 Oct 2009 13:01:17 -0700

At 9:46 AM +0200 10/21/09, Yoav Nir wrote:
>Content-Language: en-US
>Content-Type: multipart/signed; micalg=sha1;
>	boundary="Apple-Mail-15-778597419"; protocol="application/pkcs7-signature"
>
>A few lines above this section it already says "If the responder's policy allows it to accept the first selector of TSi and TSr, then the responder MUST narrow the traffic selectors to a subset that includes the initiator's first choices."
>
>So there is a MUST requirement to select the initiator's first choice (if possible), so I don't think the SHOULD and MAY are appropriate here. The way I read this section, it only clarifies what to do if the initiator traffic selector (first or not) is too broad. In that case, we shouldn't mention the initiator's choices.

Yeeps, good catch. That will teach me not to read above and below far enough.

Given this, maybe we need to close out this issue with no change, given the disagreement for other additions to the text.

--Paul Hoffman, Director
--VPN Consortium