A Minor Comment: 1. Typo - Section 1 - Introduction - Last Paragraph
In the description that follows, we assume that no errors occur. Modifications to the flow should errors occur are described in Section 2.21. ------------------------ In the description that follows, we assume that no errors occur. Modifications to the flow *when* errors occur are described in Section 2.21. Best regards, Raj On Sat, Mar 6, 2010 at 5:25 PM, <pasi.ero...@nokia.com> wrote: > I've gone through changes from 06 to 07/08, and my earlier > comments, and found one minor bug and couple of small editorial > suggestions/nits. > > The bug first: > > - Section 3.3.6 says "If one of the proposals offered is for the > Diffie-Hellman group of NONE, the responder MUST ignore the > initiator's KE payload and omit the KE payload from the response." > > This seems wrong: it seems to say that if the initiator proposes DH > group NONE, the responder must select it. > > However, negotiation of DH groups and KE payload is already well > described in Sections 1.2 and 1.3 (paragraphs mentioning > INVALID_KE_PAYLOAD), and it seems the last paragraph of 3.3.6 is > completely redundant. Thus, I'd propose just deleting the whole > paragraph. > > > 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). > > - 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. > > - 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...] > > - 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. > > - Section 3.5: "ID_IPV6_ADDR instead of ID_IPV6_ADDR" should > be "...instead of ID_IPV4_ADDR"? > > - Reference [PKIX] should be updated from RFC 3280 to 5280. > > - Section 2.23.1, "hve" -> "have" > > Best regards, > Pasi > _______________________________________________ > IPsec mailing list > ip...@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
