Re: [IPsec] IKEv2-bis -09 (review of "diffs")

Paul Hoffman <paul.hoffman@vpnc.org> Tue, 13 April 2010 17:12 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 C0D6D3A6A5A for <ipsec@core3.amsl.com>; Tue, 13 Apr 2010 10:12:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.799
X-Spam-Level:
X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=0.247, 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 YKzOKhmt9mLg for <ipsec@core3.amsl.com>; Tue, 13 Apr 2010 10:12:15 -0700 (PDT)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 5B9F43A6A4A for <ipsec@ietf.org>; Tue, 13 Apr 2010 10:12:15 -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 o3DHC5dT073055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Apr 2010 10:12:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p06240801c7ea53780708@[10.20.30.158]>
In-Reply-To: <1271172988.4237.74.camel@yaronf-linux>
References: <1271172988.4237.74.camel@yaronf-linux>
Date: Tue, 13 Apr 2010 10:12:03 -0700
To: Yaron Sheffer <yaronf.ietf@gmail.com>, ipsec@ietf.org
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [IPsec] IKEv2-bis -09 (review of "diffs")
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, 13 Apr 2010 17:12:17 -0000

At 6:36 PM +0300 4/13/10, Yaron Sheffer wrote:
>Here's a quick review of the numerous changes between -08 and -09. Let's get these things resolved  and move the doc to the IESG.
>
>I'm a bit uneasy with the use of "Notify error message" instead of the simpler (and admittedly a bit vague) "notification". After all, these are not messages!

They are notifications that have meaning. The meaning makes them a message to the implementation. I think the new wording is better than just "notification", particularly because there are two types of Notify payloads.

>2.4: For the sake of editing you eliminated a MUST NOT, I suggest to put it back. The original text had: "An implementation MUST NOT continue sending on any SA if some failure prevents it from receiving on all the associated SAs".

As Tero pointed out, this 2119 language only applied to a teeny subset of implementers, and even then I do not think it is actionable by itself. The replacement language is better.

>"Two expected attacks", but then "this attack" in the following sentence. I think -08 had it right, and this should be singular. Also, the word "if" slipped from the 2nd sentence.

Good catch; fixed in the editorial-only -10.

>"The preferred key size MUST be used as the length of SK_d, SK_pi, and SK_pr" - this is a new MUST, are we all happy with it?

It was strongly implied before.

>2.21.2: "Extension documents may define new error notifications with these semantics, but MUST NOT use them unless the peer has been shown to understand them using the Vendor ID payload." The VID payload is one possibility, but there may be others (e.g. an earlier status notification). So I suggest to add "e.g. using the Vendor ID payload".

Agree.

>This text was removed from 2.23: "IKE MUST respond to the IP address and port from which packets arrived". Is this requirement covered elsewhere?

Yes, many places.

>If you insist on changing NATs to NAT's in 2.23.1, you should make it NATs'.

Agree.

>In Sec. 4, I don't think we want to say "these are some of the features that can be omitted", implying that there are more. Why not "these are features"?

Agree.

--Paul Hoffman, Director
--VPN Consortium