Re: [Gen-art] Review: draft-mglt-ipsecme-clone-ike-sa-05.txt

"Joel M. Halpern" <jmh@joelhalpern.com> Thu, 08 October 2015 16:18 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66CFA1A90EE; Thu, 8 Oct 2015 09:18:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.302
X-Spam-Level:
X-Spam-Status: No, score=-0.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_SIDE=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sj0bMvTbk02u; Thu, 8 Oct 2015 09:18:43 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 219E51A90BC; Thu, 8 Oct 2015 09:18:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id E1196960555; Thu, 8 Oct 2015 09:18:42 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id A4B7E1C078C; Thu, 8 Oct 2015 09:18:37 -0700 (PDT)
To: Daniel Migault <daniel.migault@ericsson.com>, "A. Jean Mahoney" <mahoney@nostrum.com>, General Area Review Team <gen-art@ietf.org>, "draft-mglt-ipsecme-clone-ike-sa.all@ietf.org" <draft-mglt-ipsecme-clone-ike-sa.all@ietf.org>
References: <560DAE39.2030307@nostrum.com> <560EBE08.9010008@joelhalpern.com> <2DD56D786E600F45AC6BDE7DA4E8A8C11216C693@eusaamb107.ericsson.se>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <56169759.2000107@joelhalpern.com>
Date: Thu, 08 Oct 2015 12:18:33 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C11216C693@eusaamb107.ericsson.se>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/3vh7dnAVWoS2WVLgUHep6pEov9o>
Cc: Valery Smyslov <svanru@gmail.com>
Subject: Re: [Gen-art] Review: draft-mglt-ipsecme-clone-ike-sa-05.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Oct 2015 16:18:44 -0000

That would work very well for me.  Thank you for addressing my concerns.
Yours,
Joel

On 10/8/15 10:20 AM, Daniel Migault wrote:
> Hi Joel,
>
> Thank you for taking time to review and comment the draft.
>
> We propose to add the following text to clarify the example in section 2 before the two last paragraphs. The following text expects to clarify the following points:
>     - 1) The creation of VPN is a local policy matter
>     - 2) Moving one duplicated VPN to different interfaces may involve multiple MOBIKE operations
>     - 4) There is no needs to create all possible VPNs ( might be similar to item 1)
>
> The following text has been added to our local copy. If you would like us to publish a new version, feel free to let us know. Our intention is to keep the updates local until you ask us to publish the draft.
>
> BR,
> Daniel and Valery
>
> NEW TEXT -- BEGIN
> Note that it is up to host's local policy which additional VPNs to create and
> when to do it. The process of selecting address pairs for migration is
>   a local matter. Furthermore, in the case of multiple interfaces on
>   both ends care should be taken to avoid the VPNs to be duplicated by both ends or moved to the both interfaces.
>
>   In addition multiple MOBIKE operation may be involved from the
>   Security Gateway or the VPN End User.
>   Suppose, as depicted in Figure 3 for example that the cloned VPN is
>   between Interface _0 and Interface_0', and the VPN End User and the
>   Security Gateway wants to move it to Interface_1 and Interface_1'. The
>   VPN End User may initiate a MOBIKE exchange in order to move it to
>   Interface_1, in which case the cloned VPN is now between Interface_1
>   and Interface_0'. Then the Security Gateway may also initiate a MOBIKE exchange in order to move the VPN to Interface_1' in which case the VPN has reached its final destination.
> NEW TEXT -- END
>
> -----Original Message-----
> From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
> Sent: Friday, October 02, 2015 1:25 PM
> To: A. Jean Mahoney; General Area Review Team; draft-mglt-ipsecme-clone-ike-sa.all@ietf.org
> Subject: [Gen-art] Review: draft-mglt-ipsecme-clone-ike-sa-05.txt
>
> I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.
>
> For more information, please see the FAQ at
>
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Document: draft-mglt-ipsecme-clone-ike-sa-05.txt
> Cloning IKE SA in the Internet Key Exchange Protocol Version 2 (IKEv2)
>
> Reviewer: Joel M. Halpern
> Review Date: 2-Oct-2015
> IETF LC End Date: 27-Oct-2015
> IESG Telechat date: N/A
>
> Summary: This document is nearly ready for publication as a Propsoed Standard RFC.
>
> Major issues:
>       The introductory material talks about the case where both sides have multiple interfaces.  It is not clear what will happen with this mechanism in that case.
>       In particular, if I have two systems, with three interfaces, it seems that this will start by creating the S1-D1 Security Association.
> It seems straightforward for each side to create their simple additional assocations (S2-D1, S3-D1, and S1-D2, S1-D3).
>       But the introduction suggests that we also want to create S2-D2, S3-D3, S2-D3, and S3-D2.  With no other guidance, it appears that both sides will try to create all four of those, creating 8 security associations instead of 4.
>       I hope that I have simply missed something in the document that resolves this.
>
> Minor issues:
>
> Nits/editorial comments:
>