[IPsec] Closing the IKEv2bis open issues

Paul Hoffman <paul.hoffman@vpnc.org> Tue, 20 October 2009 16:19 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C8C528C17B for <ipsec@core3.amsl.com>; Tue, 20 Oct 2009 09:19:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.32
X-Spam-Level:
X-Spam-Status: No, score=-5.32 tagged_above=-999 required=5 tests=[AWL=0.726, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrtydQI0lXbv for <ipsec@core3.amsl.com>; Tue, 20 Oct 2009 09:19:11 -0700 (PDT)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 2BB8A28C12B for <ipsec@ietf.org>; Tue, 20 Oct 2009 09:19:11 -0700 (PDT)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n9KGJH5o050457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ipsec@ietf.org>; Tue, 20 Oct 2009 09:19:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p06240849c7039304f1d1@[10.20.30.158]>
Date: Tue, 20 Oct 2009 09:19:15 -0700
To: IPsecme WG <ipsec@ietf.org>
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="us-ascii"
Subject: [IPsec] Closing the IKEv2bis open issues
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Oct 2009 16:19:12 -0000

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