ipsec October 2009 archive
Main Archive Page > Month Archives  > ipsec archives
ipsec: [IPsec] Closing the IKEv2bis open issues

[IPsec] Closing the IKEv2bis open issues

From: Paul Hoffman <paul.hoffman_at_nospam>
Date: Tue Oct 20 2009 - 16:19:15 GMT
To: IPsecme WG <ipsec@ietf.org>


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



IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec