[IPsec] IKEv2-bis -09 (review of "diffs")
Yaron Sheffer <yaronf.ietf@gmail.com> Tue, 13 April 2010 15:36 UTC
Return-Path: <yaronf.ietf@gmail.com>
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 D3E703A694C for <ipsec@core3.amsl.com>; Tue, 13 Apr 2010 08:36:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 6B4HpHcvhEaI for <ipsec@core3.amsl.com>; Tue, 13 Apr 2010 08:36:41 -0700 (PDT)
Received: from mail-bw0-f217.google.com (mail-bw0-f217.google.com [209.85.218.217]) by core3.amsl.com (Postfix) with ESMTP id 8E3003A67B3 for <ipsec@ietf.org>; Tue, 13 Apr 2010 08:36:41 -0700 (PDT)
Received: by bwz9 with SMTP id 9so5934927bwz.29 for <ipsec@ietf.org>; Tue, 13 Apr 2010 08:36:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:content-type :date:message-id:mime-version:x-mailer; bh=+5Tj/4YcahshTMPPMX+DQT/h9Z5NBJWaP81niVW5R9E=; b=IPJT0wtjMAmGSF0CZUo86whWZNCZH2DnmZsgXhJB6RlXo1vy8zO0nBfPVe4etI3ume zVRh7aYlQCxp/yFLqaeM0HVrBvltUUAr5dDmOoY0ZUTjYEEiVY96AmXkZsgbDVfh13xA anDQ5TnLxptbr19QcXpRtQvfBIc0mEk2ChHoA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:content-type:date:message-id:mime-version:x-mailer; b=VXAcBFv0U4zuxBJM5RXge7k8O2p/rp2Ja07iac5wPwbcyJGXH5Htn3EKJz+YEmcx8d teS4Mhx4cTOGnRyZLh2CEFHvLqDvNHrP59JPIaA3YGbADZfxFq4gCUmDMcso3RIzHmtk orRTL6sTtCm8V6g7v5WqoBiYIDnlaos9YjCQg=
Received: by 10.204.138.79 with SMTP id z15mr6598363bkt.59.1271172991774; Tue, 13 Apr 2010 08:36:31 -0700 (PDT)
Received: from [10.0.0.4] ([109.67.14.147]) by mx.google.com with ESMTPS id 14sm2438661bwz.2.2010.04.13.08.36.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 13 Apr 2010 08:36:31 -0700 (PDT)
From: Yaron Sheffer <yaronf.ietf@gmail.com>
To: ipsec@ietf.org
Content-Type: multipart/alternative; boundary="=-ZTTP/JxnIRT9R1R4JWP5"
Date: Tue, 13 Apr 2010 18:36:27 +0300
Message-ID: <1271172988.4237.74.camel@yaronf-linux>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.1
Subject: [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 15:36:42 -0000
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! * 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". * "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. * "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? * 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". * 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? * If you insist on changing NATs to NAT's in 2.23.1, you should make it NATs'. * 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"? Thanks, Yaron
- [IPsec] IKEv2-bis -09 (review of "diffs") Yaron Sheffer
- Re: [IPsec] IKEv2-bis -09 (review of "diffs") Paul Hoffman