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

From: Yaron Sheffer <[email-masked]>
Date: Tue, 13 Apr 2010 18:36:27 +0300

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

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 13 Apr 2010 10:12:03 -0700

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