[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