At 12:55 PM +0100 3/6/10, <Pasi.Eronen@xxxxxxxxx> 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 _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf