Cloning the IKE Security Association in the Internet Key Exchange Protocol Version 2 (IKEv2)
draft-mglt-ipsecme-clone-ike-sa-09

[Ballot comment]

- General: What'd happen if I used MPTCP with this? In particular
with the multiple client i/f version. It should work I guess but I
wonder if anyone's thought about any corner case issues (e.g.
timing) that might come up?

- section 4: "would be deleted" is too vague really - what did
you want to see happen?

- section 2: I don't get the last paragraph. What's that mean?

nits:

- General: There are many minor grammatical issues, e.g. cases of
missing "an" or "the." It'd be nice to fix those before the RFC
editor has to.

- section 2: typo: "with with"

[Ballot comment]
I don't have any substantive comments, but do have a number of editorial comments:

- Abstract:
-- The abstract seems unnecessarily long, can it be edited down? I suggest moving most of the text into the introduction and creating a much shorter abstract.
-- 2nd paragraph, second sentence: "... using multiple interfaces requires to set up an IKE SA..."
There appears to be a missing word after "requires". That is, requires _what_ to set up the SA?  (Alternately, "...requires an IKE SA to be set up...")
-- Please expand MOBIKE on first use (both in the abstract and in the body).

- Section 2, 2nd paragraph after Figure 3:
-- s/"In case of IPsec it means..."/"In the case of IPSEC, this means..."
-- s/"drawback of such approach"/"drawback of such an approach"
-- What does "transactionally" mean in context of "transactionally synchronized"? Is that different than just "synchronized"?
-- s/"The drawback of such  approach is that it requires new IKE SA"/"The drawback of such _an_approach is that it requires new IKE SA"

- 2, third paragraph from end:  "the VPN End User and the Security Gateway wants to move"
s/wants/want

-4, first paragraph:
-- The language "The goal of the document..." makes it sound like there is a chance the document might fail to achieve the goal. I assume that is not the intent. I suggest reformulating along the lines of "This document specifies..."
-- "without performing an authentication."
without performing a _new_ authentication?

- 5.2, 2nd paragraph from end:
I don't understand the phrase "If the CREATE_CHILD_SA request concerns an IKE SA rekey ..." Maybe s/concerns/requests?

-5.3, 4th paragraph:
s/"In some cases responder..."/"In some cases, the responder..."

- 8, third paragraph:
Does this talk about resource exhaustion in general, or a resource exhaustion _attack_?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-mglt-ipsecme-clone-ike-sa-05. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which must be completed.

In the IKEv2 Notify Message Types - Status Types subregistry of the Internet Key Exchange Version 2 (IKEv2) Parameters registry located at:

http://www.iana.org/assignments/ikev2-parameters/

two new status types are to be registered as follows:

Value: [ TBD-at-Registration ]
NOTIFY MESSAGES - STATUS TYPES: CLONE_IKE_SA_SUPPORTED
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
NOTIFY MESSAGES - STATUS TYPES: CLONE_IKE_SA
Reference: [ RFC-to-be ]

We've asked the IESG-designated expert for the registry to review and approve these registrations. As the registration procedure for IKEv2 Notify Message Types - Status Types is "Expert Review," as defined by RFC 5226, we can't complete this action without his approval.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Cloning IKE SA in the Internet Key Exchange Protocol Version 2 (IKEv2)) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'Cloning IKE SA in the Internet Key Exchange Protocol Version 2
(IKEv2)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-10-27. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document considers a VPN End User establishing an IPsec SA with
  a Security Gateway using the Internet Key Exchange Protocol Version 2
  (IKEv2), where at least one of the peers has multiple interfaces or
  where Security Gateway is a cluster with each node having its own IP
  address.

  With the current IKEv2 protocol, the outer IP addresses of the IPsec
  SA are determined by those used by IKE SA.  As a result using
  multiple interfaces requires to set up an IKE SA on each interface,
  or on each path if both the VPN Client and the Security Gateway have
  multiple interfaces.  Setting each IKE SA involves authentications
  which might require multiple round trips as well as activity from the
  VPN End User and thus would delay the VPN establishment.  In addition
  multiple authentications unnecessarily increase the load on the VPN
  client and the authentication infrastructure.

  This document presents the solution that allows to clone IKEv2 SA,
  where an additional SA is derived from an existing one.  The newly
  created IKE SA is set without the IKEv2 authentication exchange.
  This IKE SA can later be assigned to another interface or moved to
  another cluster mode using MOBIKE protocol.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-mglt-ipsecme-clone-ike-sa/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-mglt-ipsecme-clone-ike-sa/ballot/


No IPR declarations have been submitted directly on this I-D.