I'm not done my review, but here are the observations -- all minor -- that I've got so far:
Section 1.2, paragraph 2 -- "the identities are hidden from eavesdroppers". Is it worth noting that a man-in-the-middle could intrusively discover the initiator's identity? Section 1.3.1 -- "When an IKE SA is not created, the error message return SHOULD NOT be encrypted because the other party will not be able to authenticate that message." First, this seems out of place, since this section talks about CREATE_CHILD_SA for Child SAs. Second, assuming this is talking about IKE_AUTH, I think this contradicts what we'd earlier agreed to -- and what section 1.2 now seems to suggest -- in that the IKE_AUTH response should normally be encrypted and MACed even on failure. Section 1.3.2 -- "New initiator and responder SPIs are supplied in the SPI fields of the SA payload." I think we should change this to read "A new initiator SPI is supplied ..." Perhaps we should add something about the responder choosing an SPI to the paragraph beginning "The responder replies ..." Section 2.8 -- Note that, when rekeying, the new Child SA SHOULD NOT have different traffic selectors and algorithms than the old one." This sentence appears within a paragraph that is otherwise entirely about rekeying IKE SAs. I think it should probably be moved to the end of the preceding paragraph. Section 2.21.2 -- We need to remember to remove the "NOTE FOR WG DISCUSSION". Scott Moonen (smoo...@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Yaron Sheffer <yar...@checkpoint.com> To: "ipsec@ietf.org" <ipsec@ietf.org> Date: 12/10/2009 04:05 AM Subject: [IPsec] Working Group LC: draft-ietf-ipsecme-ikev2bis-06 (yes, IKEv2-bis!) This is to begin a 4 week working group last call for draft-ietf-ipsecme-ikev2bis-06. The target status for this document is Proposed Standard, obsoleting RFC 4306 and RFC 4718. Please send your comments to the ipsec list by Jan. 5, 2010, as follow-ups to this message. This is a large document, and arguably the most important document this WG is entrusted with. The LC period is longer than usual but will include vacation time for most of us. Nevertheless, please make an effort to review the entire document, or at least large portions of it. Feel free to post multiple partial reviews. In this particular case, we are starting the review with a few open issues . We will make an effort to close them during the WG LC period. As a reminder regarding the document’s scope (and our constraints while reviewing it), I will quote from my mail of Aug. 2008: General: The goal of the IKEv2 bis document is to clarify the protocol. The goal is not to extend it. Specifically: * The document will combine RFC 4306 (IKEv2) and RFC 4718 (IKEv2 clarifications), but no other RFCs. * The document will add clarifications based on the community's deployment experience. * It is OK to correct minor technical errors and contradictions in the source documents. Any such corrections will be pointed out explicitly - preferably in an appendix (so that people using the old documents can scan it to discover problem areas). * The document will not add any "nice to have" extensions, no matter how much technical sense they make. Please clearly indicate the position of any issue in the Internet Draft, and if possible provide alternative text. Please also 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. The document can be accessed here: http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2bis-06 Thanks, Yaron_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
