--- 1/draft-ietf-ipsecme-ikev2-ipv6-config-02.txt 2009-10-26 23:12:13.000000000 +0100 +++ 2/draft-ietf-ipsecme-ikev2-ipv6-config-03.txt 2009-10-26 23:12:13.000000000 +0100 @@ -1,21 +1,21 @@ Network Working Group P. Eronen Internet-Draft Nokia Intended status: Experimental J. Laganier -Expires: February 21, 2010 Qualcomm Inc. +Expires: April 29, 2010 QUALCOMM Inc. C. Madson Cisco Systems - August 20, 2009 + October 26, 2009 IPv6 Configuration in IKEv2 - draft-ietf-ipsecme-ikev2-ipv6-config-02 + draft-ietf-ipsecme-ikev2-ipv6-config-03 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from @@ -34,21 +34,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on February 21, 2010. + This Internet-Draft will expire on April 29, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights @@ -74,45 +74,46 @@ 3.2. Link-Local Addresses . . . . . . . . . . . . . . . . . . . 8 3.3. Interface Identifier Selection . . . . . . . . . . . . . . 8 3.4. Sharing VPN Access . . . . . . . . . . . . . . . . . . . . 9 3.5. General Goals . . . . . . . . . . . . . . . . . . . . . . 9 3.6. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 10 3.7. Additional Information . . . . . . . . . . . . . . . . . . 10 4. Solution Details . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Initial Exchanges . . . . . . . . . . . . . . . . . . . . 11 4.2. Reauthentication . . . . . . . . . . . . . . . . . . . . . 12 4.3. Creating CHILD_SAs . . . . . . . . . . . . . . . . . . . . 13 - 4.4. Relationship to Neighbor Discovery . . . . . . . . . . . . 13 + 4.4. Relationship to Neighbor Discovery . . . . . . . . . . . . 14 4.5. Relationship to Existing IKEv2 Payloads . . . . . . . . . 14 - 5. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 15 - 5.1. INTERNAL_IP6_LINK Configuration Attribute . . . . . . . . 15 - 5.2. INTERNAL_IP6_PREFIX Configuration Attribute . . . . . . . 15 - 5.3. LINK_ID Notify Payload . . . . . . . . . . . . . . . . . . 16 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 - Appendix A. Design Rationale (Non-Normative) . . . . . . . . . . 23 - A.1. Link Model . . . . . . . . . . . . . . . . . . . . . . . . 23 - A.2. Distributing Prefix Information . . . . . . . . . . . . . 24 - A.3. Unique Address Allocation . . . . . . . . . . . . . . . . 24 - A.4. Layer 3 Access Control . . . . . . . . . . . . . . . . . . 25 - A.5. Other Considerations . . . . . . . . . . . . . . . . . . . 26 - A.6. Alternative Solution Sketches . . . . . . . . . . . . . . 28 - A.6.1. Version -00 Sketch . . . . . . . . . . . . . . . . . . 28 - A.6.2. Router Aggregation Sketch #1 . . . . . . . . . . . . . 29 - A.6.3. Router Aggregation Sketch #2 . . . . . . . . . . . . . 30 - A.6.4. IPv4-like Sketch . . . . . . . . . . . . . . . . . . . 32 - A.6.5. Sketch Based on RFC 3456 . . . . . . . . . . . . . . . 33 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 + 5. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 16 + 5.1. INTERNAL_IP6_LINK Configuration Attribute . . . . . . . . 16 + 5.2. INTERNAL_IP6_PREFIX Configuration Attribute . . . . . . . 16 + 5.3. LINK_ID Notify Payload . . . . . . . . . . . . . . . . . . 17 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 + Appendix A. Design Rationale (Non-Normative) . . . . . . . . . . 24 + A.1. Link Model . . . . . . . . . . . . . . . . . . . . . . . . 24 + A.2. Distributing Prefix Information . . . . . . . . . . . . . 25 + A.3. Unique Address Allocation . . . . . . . . . . . . . . . . 25 + A.4. Layer 3 Access Control . . . . . . . . . . . . . . . . . . 26 + A.5. Other Considerations . . . . . . . . . . . . . . . . . . . 27 + A.6. Alternative Solution Sketches . . . . . . . . . . . . . . 29 + A.6.1. Version -00 Sketch . . . . . . . . . . . . . . . . . . 29 + A.6.2. Router Aggregation Sketch #1 . . . . . . . . . . . . . 30 + A.6.3. Router Aggregation Sketch #2 . . . . . . . . . . . . . 31 + A.6.4. IPv4-like Sketch . . . . . . . . . . . . . . . . . . . 33 + A.6.5. Sketch Based on RFC 3456 . . . . . . . . . . . . . . . 34 + Appendix B. Evaluation (Non-Normative) . . . . . . . . . . . . . 35 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 1. Introduction and Problem Statement In typical remote access VPN use (client to VPN gateway), the client needs an IP address in the network protected by the security gateway. IKEv2 includes a feature called "configuration payloads" that allows the gateway to dynamically assign a temporary address to the client [IKEv2]. For IPv4, the message exchange would look as follows: @@ -248,21 +249,21 @@ interfaces, and allow them to be used for protocols between the VPN client and gateway. 3.3. Interface Identifier Selection In the message exchange shown in Figure 2, the gateway chooses the interface ID used by the client. It is also possible for the client to request a specific interface ID; the gateway then chooses the prefix part. - This approach complicates the use of Cryptographically Generates + This approach complicates the use of Cryptographically Generated Addresses [CGA]. With CGAs, the interface ID cannot be calculated before the prefix is known. The client could first obtain a non-CGA address to determine the prefix, and then send a separate CFG_REQUEST to obtain a CGA address with the same prefix. However, this approach requires that the IKEv2 software component provides an interface to the component managing CGAs; an ugly implementation dependency that would be best avoided. Similar concerns apply to other cases where the client has some interest in what interface ID is being used, such as Hash-Based @@ -336,24 +337,25 @@ [RFC4877], and the intent of this document is not to change that interaction in any way. 3.7. Additional Information If the VPN client is assigned IPv6 address(es) from prefix(es) that are shared with other VPN clients, this results in some kind of multi-link subnet. [Multilink] describes issues associated with multi-link subnets, and recommends that they should be avoided. - The original 3GPP standards for IPv6 assigned a single IPv6 address - to each mobile phone, resembling current IKEv2 payloads. [RFC3314] - described the problems with this approach, and caused 3GPP to change - the specifications to assign unique /64 prefix(es) for each phone. + The original 3GPP specifications for IPv6 assigned a single IPv6 + address to each mobile phone, resembling current IKEv2 payloads. + [RFC3314] described the problems with this approach, and caused 3GPP + to change the specifications to assign unique /64 prefix(es) for each + phone. Due to similar concerns, the IEEE 802.16 IPv6 Convergence Sublayer [RFC5121] and Proxy Mobile IPv6 [RFC5213] also assign unique prefixes. 4. Solution Details 4.1. Initial Exchanges 1) During IKE_AUTH, the client sends a new configuration attribute, @@ -440,23 +442,37 @@ CP(CFG_REQUEST) = { INTERNAL_IP6_LINK(Client's Link Local Interface ID, IKEv2 Link ID) INTERNAL_IP6_DHCP() } TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> - The gateway uses the Link ID to look up relevant local state, - verifies that the authenticated peer identity associated with the - link is correct, and continues the handshake as usual. + At this point, the gateway MUST verify that the client is indeed + allowed to use the link identified by the IKEv2 Link ID. The same + situation occurs in [IKEv2] when the client wants to continue using + the same IPv4 address with the INTERNAL_IP4_ADDRESS configuration + attribute. Typically, the gateway would use the Link ID to look up + relevant local state, and compare the authenticated peer identity of + the IKE_SA with the local state. + + If the client is allowed to continue using this link, the gateway + replies (see Section 4.1) with the same Gateway's Link-Local + Interface ID and IKEv2 Link ID as used earlier, and sends the IPv6 + prefix(es) associated with this link. Usually, the IPv6 prefix(es) + will also be the same as earlier, but this is not required. + + If the client is not allowed to continue using this link, the gateway + treats it as a request for a new virtual link, selects a different + IKEv2 Link ID value, and replies as in Section 4.1. 4.3. Creating CHILD_SAs When a CHILD_SA is created, the peers need to determine which SPD entries and PAD Child SA Authorization Data entries are used for this CHILD_SA. In the basic client-to-VPN-gateway uses, the situation is simple: all the matching SPD entries and Child SA Authorization Data entries are related to the "virtual link" between the VPN client and the VPN gateway. However, if the same peers are also using IPsec/ IKEv2 for other uses (with addresses not assigned inside IKEv2), they @@ -489,20 +505,34 @@ a point-to-point link. Neighbor Unreachability Detection could be used, but is a bit redundant given IKEv2 Dead Peer Detection. Duplicate Address Detection is not needed, because this is a point- to-point link, where the VPN gateway does not assign any addresses from the global unicast prefixes, and link-local interface identifier is negotiated separately. + Duplicate Address Detection is not needed for global unicast + addresses formed from the global unicast prefix(es) configured as + part of the IKEv2 exchange, because this is a point-to-point link, + where the VPN gateway does not assign any addresses from the global + unicast prefixes. Duplicate Address Detection may be needed for + link-local addresses, e.g., when the client configures a link-local + address as per [RFC4941]. + + Thus, Duplicate Address Detection MAY be skipped for global unicast + addresses formed from the global unicast prefix(es) configured as + part of the IKEv2 exchange. However, Duplicate Address Detection for + link-local unicast addresses MUST be performed as required per some + other specifications, e.g., [RFC4941]. + 4.5. Relationship to Existing IKEv2 Payloads The mechanism described in this document is not intended to be used at the same time as the existing INTERNAL_IP6_ADDRESS attribute. For compatibility with gateways implementing only INTERNAL_IP6_ADDRESS, the VPN client MAY include attributes for both mechanisms in CFG_REQUEST. The capabilities and preferences of the VPN gateway will then determine which is used. All other attributes except INTERNAL_IP6_ADDRESS (and @@ -608,29 +638,32 @@ Value Notify Messages - Status Types Reference ------ ------------------------------- --------- TBD3 LINK_ID [this doc] This document does not create any new namespaces to be maintained by IANA. 7. Security Considerations - Assigning each client a unique prefix makes using randomized - interface identifiers [RFC4941] ineffective from privacy point of - view: the client is still uniquely identified by the prefix. In some - environments, it may be preferable to assign a VPN client the same - prefix each time a VPN connection is established; other environments - may prefer assigning a different prefix every time for privacy - reasons. (This is basically a similar trade-off as in Mobile IPv6 -- - using the same Home Address forever is simpler than changing it - often, but has privacy implications.) + Since this document is an extension to IKEv2, the security + considerations in [IKEv2] apply here as well. + + The mechanism described in this document assigns each client a unique + prefix, which makes using randomized interface identifiers [RFC4941] + ineffective from privacy point of view: the client is still uniquely + identified by the prefix. In some environments, it may be preferable + to assign a VPN client the same prefix each time a VPN connection is + established; other environments may prefer assigning a different + prefix every time for privacy reasons. (This is basically a similar + trade-off as in Mobile IPv6 -- using the same Home Address forever is + simpler than changing it often, but has privacy implications.) 8. Acknowledgments The author would like to thank Patrick Irwin, Tero Kivinen, Chinh Nguyen, Mohan Parthasarathy, Yaron Sheffer, Hemant Singh, Dave Thaler, Yinghzhe Wu, and Fan Zhao for their valuable comments. Many of the challenges associated with IPsec-protected "virtual interfaces" have been identified before: for example, in the context of protecting IPv6-in-IPv4 tunnels with IPsec [RFC4891], Provider @@ -1266,32 +1299,81 @@ implementation dependency for interface ID selection (see Section 3.3), and the multi-link subnet model. A.6.5. Sketch Based on RFC 3456 For completeness: a solution modeled after [RFC3456] would combine (1) router aggregation link model, (2) prefix information distribution and unique address allocation with DHCPv6, and (3) access control enforced by IPsec SAD/SPD. +Appendix B. Evaluation (Non-Normative) + + Section 3described the goals and requirements for IPv6 configuration + in IKEv2. This appendix briefly summarizes how the solution + specified in Section 4 and Section 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 Section 4.3 and + Section 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.) + Authors' Addresses Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland Email: pasi.eronen@nokia.com Julien Laganier - Qualcomm Incorporated + QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121 USA Phone: +1 858 858 3538 Email: julienl@qualcomm.com Cheryl Madson Cisco Systems, Inc. 510 MacCarthy Drive