Re: [IPsec] IETFLC comments for draft-ietf-ipsecme-ikev2bis-08

[Paul Hoffman <[e-mail]>]

At 12:55 PM +0100 3/6/10, <[e-mail]> wrote:
>Editorial suggestions/nits:
>
>- Section 2.7, last paragraph, is in wrong place; rest of 2.7 has
>nothing to do with this topic, which is in 2.6. Suggested place: 2.6,
>end of paragraph starting with "In the first message".
>Also, "the responder's SPI will be zero" should be "the responder's
>SPI will be zero also in the response message" (since the responder's
>SPI is always zero in the IKE_SA_INIT request, but that's not what
>this paragraph is about).

Agree.

>- One of the changes is listed in Section 1.7 twice. I'd suggest
>combining
>
>   In section 1.3.2, changed "The KEi payload SHOULD be included" to be
>   "The KEi payload MUST be included".  This also led to changes in
>   section 2.18.
>
>and
>
>   Section 2.18 requires doing a Diffie-Hellman exchange when rekeying
>   the IKE_SA.  In theory, RFC 4306 allowed a policy where the Diffie-
>   Hellman exchange was optional, but this was not useful (or
>   appropriate) when rekeying the IKE_SA.
>
>as follows:
>
>   This document requires doing a Diffie-Hellman exchange when
>   rekeying the IKE_SA (and thus requires including the KEi/KEr
>   payloads).  In theory, RFC 4306 allowed a policy where the
>   Diffie-Hellman exchange was optional (and KEi/KEr payloads could be
>   omitted), this was not useful (or appropriate) when rekeying the
>   IKE_SA.

Disagree. Where possible, I tried to list the actual sections where changes were made, and your proposed rewording loses the two places. The current text is more explicit than the proposed change.

>- Section 2.8.2, last paragraph: it's not quite obvious why this
>should be negotiated (the reason is that this notification was not
>included in RFC 4306, but this section never says that). Suggested
>rephrasing
>
>   The TEMPORARY_FAILURE notification was not included in RFC 4306,
>   and support of the TEMPORARY_FAILURE notification is not negotiated.
>   Thus, older peers (implementing RFC 4306) may receive [... rest
>   of the paragraph unchanged...]

Agree.

>- Section 2.23, paragraph starting: "An initiator can use...".
>IKEv2 packets are always over UDP, so IMHO the text would benefit
>from some more precision when talking about UDP encapsulation.
>Suggested edits:
>
>OLD:
>   An initiator can use port 4500 for both IKE and ESP, regardless of
>   whether or not there is a NAT, even at the beginning of IKE.  When
>   either side is using port 4500, sending with UDP encapsulation is not
>   required, but understanding received IKE and ESP packets with UDP
>   encapsulation is required.  UDP encapsulation MUST NOT be done on
>   port 500.  If NAT-T is supported (that is, if NAT_DETECTION_*_IP
>   payloads were exchanged during IKE_SA_INIT), all devices MUST be able
>   to receive and process both UDP encapsulated and non-UDP encapsulated
>   packets at any time.  Either side can decide whether or not to use
>   UDP encapsulation irrespective of the choice made by the other side.
>   However, if a NAT is detected, both devices MUST send UDP
>   encapsulated packets.
>NEW:
>   An initiator can use port 4500 for both IKE and ESP, regardless of
>   whether or not there is a NAT, even at the beginning of IKE.  When
>   either side is using port 4500, sending ESP with UDP encapsulation
>   is not required, but understanding received UDP encapsulated ESP
>   packets is required. If NAT-T is supported (that is, if
>   NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT), all
>   devices MUST be able to receive and process both UDP encapsulated
>   ESP and non-UDP encapsulated ESP packets at any time.  Either side
>   can decide whether or not to use UDP encapsulation for ESP
>   irrespective of the choice made by the other side.  However, if a
>   NAT is detected, both devices MUST use UDP encapsulation for ESP.

Yes, that's clearer.

>- Section 3.5: "ID_IPV6_ADDR instead of ID_IPV6_ADDR" should
>be "...instead of ID_IPV4_ADDR"?

Yep.

>- Reference [PKIX] should be updated from RFC 3280 to 5280.

Sure.

>- Section 2.23.1, "hve" -> "have"

Done.

--Paul Hoffman, Director
--VPN Consortium