I have the following comments. 1) Section 2.1, in both the text and the diagram, refers to combined-mode algorithms only in relation to ESP. However, RFC 4543 defines the use of AES-GMAC for both ESP and AH. 2) Nit -- there are a few places that don't hyphenate "combined mode" when used as an adjective: "combined mode algorithm[s]" should be "combined-mode algorithm[s]". 3) Section 2.3.1, nit -- "at time" should read "at times". 4) Section 2.3.1, second paragraph -- The first sentence refers to two SA pairs and then the following sentences refer to two SAs. Perhaps we should make this transition less abrupt? I suggest inserting a sentence after the first to indicate that "SA" can be used to refer not only to the unidirectional SA but also to the pair. 5) Section 2.3.1, second paragraph -- Is it worth noting that "phase 1 SA" and "phase 2 SA" are also common names for the IKEv1 SAs? 6) Nit -- there are a couple spots where we have unfortunate widow/orphan lines. E.g., between pp. 13/14 and 15/16. 7) Page 21 -- At the very top, the reference "psecme-2" should read "ipsecme-2". Also, I'm curious why this reference is linked and some earlier ones (e.g., "ipsecme-3") aren't. 8) Section 5.3 -- Under RFC 2404, it mentions that SHA-1 ICVs are truncated to 96 bits for IPsec. We should also mention that this truncation is done for IKEv2 as well. 9) Section 5.3 -- As above, AES-GMAC is a combined-mode algorithm. 10) Section 5.3 -- Under RFC 4543, it mentions that the salt "is generated by IKEv2". Now that there are IANA assignments for IKEv1 to negotiate AES-GMAC for AH/ESP (thanks, Tero!), it seems appropriate to generalize this statement about the salt. 11) Section 5.3 -- Under RFC 2403, as with RFC 2404, IKEv2 truncates the ICV as well. 12) Section 5.4 -- Under RFC 4106, as with RFC 4543 above, we should generalize the statements "is generated by IKEv2" and "IKEv2 negotiations" to refer simply to IKE.
I glossed over some sections that aren't of significant interest to me. Scott Moonen ([email protected]) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Paul Hoffman <[email protected]> To: [email protected] Date: 08/19/2009 02:05 PM Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-roadmap-03 At 12:05 AM +0300 8/11/09, Yaron Sheffer wrote: >This is the beginning of a two-week WG Last Call, which will end August 24. >The target status for this document is Informational (to obsolete RFC 2411). >The current document is at >http://tools.ietf.org/html/draft-ietf-ipsecme-roadmap-03. That was a week ago. >If you have not read the document before now, please do so. Having fresh >eyes on the document often brings up important issues. This document is very >much a survey, so please also review it for completeness: are there >documents that should be mentioned but aren't. Send any comments to the >list, even if they are as simple as "I read it and it seems fine". And, so far, we have heard nothing. *This is bad.* This is a WG document: that means it needs to have rough consensus of the WG. Silence is not consent. >Please clearly indicate the position of any issue in the Internet Draft, and >if possible provide alternative text. Indicate the nature or severity of the >error or correction, e.g. major technical, minor technical, nit, so that we >can quickly judge the extent of problems with the document. ...and do so within the next week. If we do not get enough input during WG Last Call, we will have to reconsider how to handle this and future documents. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
