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
