Abstract: "It replaces" -> "This specification replaces" (otherwise "it" could refer to the protocol itself).
1: Remove bracketed first paragraph of the Introduction. 1: "IKE message flow" -> "An IKE message flow". 1.1.3: "IPsec- protected" - remove space. 1.2: in the table, add "IKE header (not a payload)" - the other items in the table are all payloads. 1.2: The "E" payload is only mentioned here and in the Next Payload table. It is really the SK payload. I suggest to eliminate the confusing "E" notation, and replace it with SK. 1.3.2: for some reason we support negotiation of DH parameters when rekeying the IKE SA. So we should say that the INVALID_KE_PAYLOAD response is possible here, too. 1.3.3: in the exchange, replace "N" by "N(REKEY_SA)". 1.4: "The processing of an INFORMATIONAL exchange is determined by its component payloads." Adding "The payloads are processed in strict left-to-right order" would make it deterministic, and is probably what people do today. 1.4.1: "in your INFORMATIONAL" -> "in the INFORMATIONAL". In general the section is very wordy yet confusing: if each peer is responsible for deleting (=sending a delete payload for) its own incoming SAs, then why should we say that "one never sends delete payloads for the two sides of an SA in a single message". 1.4.1: the last paragraph springs a surprise by defining the behavior of IKE SA deletion while discussing an unlikely "messing up" of Child SAs. IKE SA deletion deserves its own subsection. 2: the last paragraph, beginning "The UDP payload" is out of place here. 2.1: "allowed to forget response" -> "allowed to forget a response" 2.1: please delete the "zero non-ESP marker" from the list of things that may be mutable. It is kind of funny. 2.1: either here or in 1.5 we should say something about allowing limited retransmission of the rare one-way IKE messages, for reliability. 2.3: do we allow to send SET_WINDOW_SIZE in the initial exchange? We don't say we don't - although we do say that it would only be effective starting with IKE_AUTH. But I believe we should not accept it until both peers are fully authenticated. 2.4: this sentence is inconsistent: "The INITIAL_CONTACT notification, if sent, MUST be in the first IKE_AUTH request or response, not as a separate exchange afterwards; however, receiving parties MAY ignore it in other messages." If it MUST be only at a certain location, then it should be ignored (or even rejected) in others. 2.6, first paragraph: the historical discussion going back to the previous century is very confusing to a newcomer: instead of saying what a cookie is, we tell a story. I suggest to remove this discussion or move it to the end of the section. 2.6: "they used to generate cookies" -> "used to...". 2.6: just a comment - I don't want to reopen this discussion: I think only the SPIi and Ni values should be hashed into the cookie, and not the IP. In particular because only the SPI identifies the SA, and only Ni is needed to identify a half-open SA. 2.6: can we separate the cookie discussion into its own subsection? For two reasons: it is an implementation hint, rather than a specification (as opposed to the normative text on SPIs earlier in 2.6); and it is not very important, given the prevalence of DDos. 2.8: this sentence "It should do so if there has been no traffic since the last time the SA was rekeyed" is useless: it talks about local policy for deletion, which we are not specifying. The policy "delete the SA if there's been no traffic for the last 5 minutes" would be just as valid as this one. 2.8: the sentence "The node that initiated the surviving rekeyed SA should delete the replaced SA after the new one is established." is out of context. 2.8: the sentence beginning "From a technical correctness and interoperability perspective" is not strictly correct: there is still a race condition between the first packets on the SA and the CCSA response. Immediately starting to send is practical but not "technically correct". 2.8: "The responder can be assured that the initiator is prepared to receive messages on an SA if either (1) it has received a cryptographically valid message on the new SA." this should really be "...on the new SA's dual SA" (or better wording thereof) since there's a pair of SAs, and we are determining the state of one based on the other. In general I think we are using the terms SA and SA Pair interchangeably, which is rather confusing. 2.8: "An initiator MAY send a dummy message on a newly created SA if it has no messages queued in order to assure the responder that the initiator is ready to receive messages." A dummy message on an IPsec SA is way out of scope. Whether such messages even exist is a matter of local implementation. We certainly don't have IPsec-level keepalives. Overall, the last 3 paragraphs of 2.8 (starting "There are timing windows") are a mess: you have to read them several times before you realize that this is not normative text, rather it is several implementation alternatives. 2.8.2: this is inconsistent, and probably incorrect - the IKE SA with the lowest nonce wins here, whereas in 2.8.1 the Child SA with the lowest nonce loses. 2.8.2: we should add a sentence on what happens if the peer receives TEMPORARY_FAILURE and does not understand it (because it's new to this spec). 2.9: typo: "wants to sen". 2.9.1: "those traffic" -> "this traffic". 2.12: the sentence "Decisions as to..." is grammatically incorrect. Should be: "Decisions as to whether and when to reuse Diffie-Hellman exponentials are private in the sense that they do not affect interoperability." 2.15: the value GenIKEHDR is confusing, because it is actually NOT including in the calculation. Is suggest to replace it with a clarifying sentence. 2.16: it would be useful if we added the explicit calculation of AUTH. For example, is the padding string required for EAP as well? There are two cases, with MSK and with SK_pi+SK_pr. 2.16: if the responder sends an EAP Failure, is this IKE message acknowledged by the initiator? 2.16: the sentence saying "some simpler variations are documented here and in Section 3.16" may have been true once; it isn't now. In particular in view of my next comment. 3.16: I suggest to remove the table quoted from the EAP RFC. There are dozens of methods now in the IANA registry, many of which are preferable to the ones mentioned here.
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
