Hi, Is it possible to add a sentence in the security considerations similar to the following: "Since the draft does not change any current security mechanisms of IKEV2 the only security consideration that should be taken into account is assigning each client...."
The changes that explain how the requirements are met looks good to me. Thanks --Avshalom From: "Laganier, Julien" <[email protected]> To: "[email protected]" <[email protected]>, Avshalom Houri/Haifa/i...@ibmil, "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Date: 28/09/2009 10:05 PM Subject: RE: Gen-ART LC Review of draft-ietf-ipsecme-ikev2-ipv6-config-02 Thanks for the new text Pasi, it looks good to me. --julien From: [email protected] [mailto:[email protected]] Sent: Monday, September 28, 2009 12:18 PM To: [email protected]; Laganier, Julien; [email protected] Cc: [email protected]; [email protected] Subject: RE: Gen-ART LC Review of draft-ietf-ipsecme-ikev2-ipv6-config-02 Thanks for your review, Avshalom! This draft doesn't change how authentication (or re-authentication) works in IKEv2 in any way, and that's why the security considerations text doesn't talk about authentication-related security considerations. I agree that it would be useful to explain how the goals/requirements were actually met. Perhaps something like this? Appendix B. Evaluation (Non-Normative) Section 3 described the goals and requirements for IPv6 configuration in IKEv2. This appendix briefly summarizes how the solution specified in Sections 4 and 5 meets these goals. o (3.1) Assigning addresses from multiple prefixes is supported, without requiring the client to know beforehand how many prefixes are needed. o (3.2) Link-local addresses are assigned, and can be used for protocols between the VPN client and gateway. o (3.3) The entire prefix is assigned to a single client, so the client can freely select any number of interface IDs (which may depend on the prefix). o (3.4) This document does not specify how the VPN client would share the VPN connection with other devices. However, since the entire prefix is assigned to a single client, the client could further assign addresses from it without requiring coordination with the VPN gateway. o (3.5) The solution does not add any new periodic messages over the VPN tunnel. o (3.5) Re-authentication works (see Section 4.2). o (3.5) The solution is compatible with other IPsec uses, since the LINK_ID notification makes it unambiguous which CHILD_SAs are related to the virtual link and which are not (see Sections 4.3 and 5.3). o (3.5) The new mechanisms do not prevent the VPN client and/or gateway from implementing the INTERNAL_IP6_ADDRESS configuration attribute as well; however, the two mechanisms are not intended to be used simultaneously (see Section 4.5). o (3.5) Implementation dependencies are, obviously, implementation dependant (and their cleanliness somewhat subjective). Possible drawbacks of some alternative solutions are discussed in Appendix A.6. o (3.5) The mechanism for configuring the prefixes (configuration payloads) is specific to IKEv2, for reasons described in Appendix A. However, Section 4.1 recommends using DHCPv6 Information-Request message for obtaining other configuration information (such as DNS server addresses). Paul, Julien, Cheryl: does the text look OK to you? Best regards, Pasi From: ext Avshalom Houri [mailto:[email protected]] Sent: 24 September, 2009 17:28 To: Eronen Pasi (Nokia-NRC/Helsinki); [email protected]; [email protected] Cc: Tim Polk; General Area Review Team Subject: Gen-ART LC Review of draft-ietf-ipsecme-ikev2-ipv6-config-02 I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-ipsecme-ikev2-ipv6-config-02 Reviewer: Avshalom Houri Review Date: 2009-09-24 IETF LC End Date: 2009-09-25 IESG Telechat date: (if known) Summary: This draft is almost ready for publication as an experimental standard. Major issues: I am not a security expert but it seems that the security considerations section is too short given that authentication and re-authentications are described in the draft. Minor issues: There should be a section describing how the requirements in section 3 are being addressed by the solution. Nits/editorial comments: None Thanks --Avshalom
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
