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

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/