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

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 02 October 2015 17:25 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 CAF4B1A873D; Fri, 2 Oct 2015 10:25:35 -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 l_yVgymg5Ddu; Fri, 2 Oct 2015 10:25:34 -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 D88E71A1B8B; Fri, 2 Oct 2015 10:25:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id C070D680037; Fri, 2 Oct 2015 10:25:31 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (unknown [88.131.67.22]) (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 DB8D71C0493; Fri, 2 Oct 2015 10:25:30 -0700 (PDT)
To: "A. Jean Mahoney" <mahoney@nostrum.com>, General Area Review Team <gen-art@ietf.org>, draft-mglt-ipsecme-clone-ike-sa.all@ietf.org
References: <560DAE39.2030307@nostrum.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <560EBE08.9010008@joelhalpern.com>
Date: Fri, 02 Oct 2015 13:25:28 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <560DAE39.2030307@nostrum.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/or_sn3S5QL5osJkodz-SUa1sFUw>
Subject: [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: Fri, 02 Oct 2015 17:25:35 -0000

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: