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
