draft-ietf-ipsecme-ikev2-ipv6-config-00.txt   draft-ietf-ipsecme-ikev2-ipv6-config-01.txt 
Network Working Group P. Eronen Network Working Group P. Eronen
Internet-Draft Nokia Internet-Draft Nokia
Intended status: Standards Track J. Laganier Intended status: Experimental J. Laganier
Expires: May 22, 2009 DOCOMO Euro-Labs Expires: December 19, 2009 DOCOMO Euro-Labs
C. Madson C. Madson
Cisco Systems Cisco Systems
November 18, 2008 June 17, 2009
IPv6 Configuration in IKEv2 IPv6 Configuration in IKEv2
draft-ietf-ipsecme-ikev2-ipv6-config-00 draft-ietf-ipsecme-ikev2-ipv6-config-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 May 22, 2009. This Internet-Draft will expire on December 19, 2009.
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
and restrictions with respect to this document.
Abstract Abstract
When IKEv2 is used for remote VPN access (client to VPN gateway), the When IKEv2 is used for remote VPN access (client to VPN gateway), the
gateway assigns the client an IP address from the internal network gateway assigns the client an IP address from the internal network
using IKEv2 configuration payloads. The configuration payloads using IKEv2 configuration payloads. The configuration payloads
specified in RFC 4306 work well for IPv4, but make it difficult to specified in RFC 4306 work well for IPv4, but make it difficult to
use certain features of IPv6. This document describes the use certain features of IPv6. This document specifies new
limitations of current IKEv2 configuration payloads for IPv6, and configuration attributes for IKEv2 that allows the VPN gateway to
explores possible solutions that would allow IKEv2 to set up full- assign IPv6 prefixes to clients, enabling all features of IPv6 to be
featured virtual IPv6 interfaces. used with the client-gateway "virtual link".
Table of Contents Table of Contents
1. Introduction and Problem Statement . . . . . . . . . . . . . . 4 1. Introduction and Problem Statement . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Current Limitations . . . . . . . . . . . . . . . . . . . . . 7 3. Current Limitations and Goals . . . . . . . . . . . . . . . . 7
3.1. Multiple Prefixes . . . . . . . . . . . . . . . . . . . . 7 3.1. Multiple Prefixes . . . . . . . . . . . . . . . . . . . . 7
3.2. Link-Local Addresses . . . . . . . . . . . . . . . . . . . 7 3.2. Link-Local Addresses . . . . . . . . . . . . . . . . . . . 7
3.3. Receiving Multicast Traffic . . . . . . . . . . . . . . . 7 3.3. Interface Identifier Selection . . . . . . . . . . . . . . 7
3.4. Interface Identifier Selection . . . . . . . . . . . . . . 7 3.4. Sharing VPN Access . . . . . . . . . . . . . . . . . . . . 8
3.5. Sharing VPN Access . . . . . . . . . . . . . . . . . . . . 8 3.5. General Goals . . . . . . . . . . . . . . . . . . . . . . 8
3.6. Additional Information . . . . . . . . . . . . . . . . . . 8 3.6. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.7. Additional Information . . . . . . . . . . . . . . . . . . 9
4.1. Main Requirements . . . . . . . . . . . . . . . . . . . . 9 4. Solution Details . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Desirable Non-Functional Properties . . . . . . . . . . . 10 4.1. Initial Exchanges . . . . . . . . . . . . . . . . . . . . 10
4.3. Implementation Considerations . . . . . . . . . . . . . . 10 4.2. Reauthentication . . . . . . . . . . . . . . . . . . . . . 11
4.4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Creating CHILD_SAs . . . . . . . . . . . . . . . . . . . . 12
5. Solution Discussion . . . . . . . . . . . . . . . . . . . . . 11 4.4. Relationship to Neighbor Discovery . . . . . . . . . . . . 12
5.1. Link Model . . . . . . . . . . . . . . . . . . . . . . . . 12 4.5. Relationship to Existing IKEv2 Payloads . . . . . . . . . 13
5.2. Distributing Prefix Information . . . . . . . . . . . . . 12 5. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 14
5.3. Unique Address Allocation . . . . . . . . . . . . . . . . 13 5.1. INTERNAL_IP6_LINK Configuration Attribute . . . . . . . . 14
5.4. Layer 3 Access Control . . . . . . . . . . . . . . . . . . 13 5.2. INTERNAL_IP6_PREFIX Configuration Attribute . . . . . . . 14
5.5. Other Considerations . . . . . . . . . . . . . . . . . . . 14 5.3. LINK_ID Notify Payload . . . . . . . . . . . . . . . . . . 15
6. Solution Sketch . . . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6.1. Initial Exchanges . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6.2. Reauthentication . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
6.3. Creating CHILD_SAs . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
6.5. Relationship to Neighbor Discovery . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . . 19
6.6. Relationship to Existing IKEv2 Payloads . . . . . . . . . 19 Appendix A. Design Rationale (Non-Normative) . . . . . . . . . . 22
7. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 21 A.1. Link Model . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. INTERNAL_IP6_LINK Configuration Attribute . . . . . . . . 21 A.2. Distributing Prefix Information . . . . . . . . . . . . . 23
7.2. INTERNAL_IP6_PREFIX Configuration Attribute . . . . . . . 21 A.3. Unique Address Allocation . . . . . . . . . . . . . . . . 23
7.3. LINK_ID Notify Payload . . . . . . . . . . . . . . . . . . 22 A.4. Layer 3 Access Control . . . . . . . . . . . . . . . . . . 24
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 A.5. Other Considerations . . . . . . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 A.6. Alternative Solution Sketches . . . . . . . . . . . . . . 27
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 A.6.1. Version -00 Sketch . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 A.6.2. Router Aggregation Sketch #1 . . . . . . . . . . . . . 28
11.1. Normative References . . . . . . . . . . . . . . . . . . . 26 A.6.3. Router Aggregation Sketch #2 . . . . . . . . . . . . . 29
11.2. Informative References . . . . . . . . . . . . . . . . . . 26 A.6.4. IPv4-like Sketch . . . . . . . . . . . . . . . . . . . 31
Appendix A. Alternative Solution Sketches . . . . . . . . . . . . 29 A.6.5. Sketch Based on RFC 3456 . . . . . . . . . . . . . . . 32
A.1. Version -00 Sketch . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
A.2. Router Aggregation Sketch #1 . . . . . . . . . . . . . . . 30
A.3. Router Aggregation Sketch #2 . . . . . . . . . . . . . . . 31
A.4. IPv4-like Sketch . . . . . . . . . . . . . . . . . . . . . 33
A.5. Sketch Based on RFC 3456 . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 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 5, line 38 skipping to change at page 5, line 38
2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5 -
2001:DB8:0:1:2:3:4:5), 2001:DB8:0:1:2:3:4:5),
TSr = (0, 0-65535, TSr = (0, 0-65535,
0:0:0:0:0:0:0:0: - 0:0:0:0:0:0:0:0: -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) } FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) }
Figure 2: IPv6 configuration Figure 2: IPv6 configuration
In other words, IPv6 is basically treated as IPv4 with larger In other words, IPv6 is basically treated as IPv4 with larger
addresses. As noted in [RFC4718], this does not fully follow the addresses. As noted in [RFC4718], this does not fully follow the
"normal IPv6 way of doing things". The IPsec tunnels are not full- "normal IPv6 way of doing things", and it complicates or prevents
featured "interfaces" in the IPv6 addressing architecture [IPv6Addr] using certain features of IPv6. Section 3 describes the limitations
sense. For example, they do not necessarily have link-local in detail.
addresses, and this may complicate the use of protocols that assume
them.
This document describes what exactly are the limitations of current This document specifies new configuration attributes for IKEv2 that
IKEv2 configuration payloads for IPv6, and explores possible allows the VPN gateway to assign IPv6 prefixes to clients, enabling
solutions that would allow IKEv2-based VPNs to set up full-featured all features of IPv6 to be used with the client-gateway "virtual
virtual IPv6 interfaces. link".
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS]. document are to be interpreted as described in [KEYWORDS].
When messages containing IKEv2 payloads are described, optional When messages containing IKEv2 payloads are described, optional
payloads are shown in brackets (for instance, "[FOO]"), and a plus payloads are shown in brackets (for instance, "[FOO]"), and a plus
sign indicates that a payload can be repeated one or more times (for sign indicates that a payload can be repeated one or more times (for
instance, "FOO+"). instance, "FOO+").
This document uses the term "virtual interface" when describing how This document uses the term "virtual interface" when describing how
the client uses the IPv6 address(es) assigned by the gateway. While the client uses the IPv6 address(es) assigned by the gateway. While
existing IPsec documents do not use this term, it is not a new existing IPsec documents do not use this term, it is not a new
concept. In order to use the address assigned by the VPN gateway, concept. In order to use the address assigned by the VPN gateway,
current VPN clients already create a local "virtual interface" (as current VPN clients already create a local "virtual interface", as
only addresses assigned to interfaces can be used, e.g., as source only addresses assigned to interfaces can be used, e.g., as source
addresses for TCP connections). Note that this definition of addresses for TCP connections. Note that this definition of
"interface" is not necessarily identical with what some particular "interface" is not necessarily identical with what some particular
implementation calls "interface". implementation calls "interface".
3. Current Limitations 3. Current Limitations and Goals
This section explores the limitations of the current IPv6
configuration mechanism.
The IKEv2 specification does not always fully describe the semantics This section describes the limitations of the current IPv6
associated with configuration payloads, only their on-the-wire configuration mechanism, and requirements for the new solution.
format. This section assumes the semantics implied by Figure 2. It
is possible that many of the limitations described here could be
solved by specifying additional semantics for these configuration
payloads.
3.1. Multiple Prefixes 3.1. Multiple Prefixes
In Figure 2 only a single IPv6 address (from a single prefix) is In Figure 2 only a single IPv6 address (from a single prefix) is
assigned. The specification does allow the client to include assigned. The specification does allow the client to include
multiple INTERNAL_IP6_ADDRESS attributes in its request, but the multiple INTERNAL_IP6_ADDRESS attributes in its request, but the
gateway cannot assign more addresses than the client requested. gateway cannot assign more addresses than the client requested.
Multiple prefixes are useful for site renumbering, host-based site Multiple prefixes are useful for site renumbering, host-based site
multihoming [SHIM6], and unique local IPv6 addresses [RFC4193]. In multihoming [SHIM6], and unique local IPv6 addresses [RFC4193]. In
all of these cases, the gateway has better information on how many all of these cases, the gateway has better information on how many
different addresses (from different prefixes) the client should be different addresses (from different prefixes) the client should be
assigned. assigned.
The solution should support assigning address from multiple prefixes,
without requiring the client to know beforehand how many prefixes are
needed.
3.2. Link-Local Addresses 3.2. Link-Local Addresses
The IPv6 addressing architecture [IPv6Addr] specifies that "IPv6 The IPv6 addressing architecture [IPv6Addr] specifies that "IPv6
addresses of all types are assigned to interfaces, not nodes. [..] addresses of all types are assigned to interfaces, not nodes. [..]
All interfaces are required to have at least one Link-Local unicast All interfaces are required to have at least one Link-Local unicast
address". address".
Currently, the virtual interface created by IKEv2 configuration Currently, the virtual interface created by IKEv2 configuration
payloads does not have link-local addresses. This violates payloads does not have link-local addresses. This violates the
[IPv6Addr] and prevents the use of protocols that require link-local requirements in [IPv6Addr] and prevents the use of protocols that
addresses, such as [MLDv2] and [DHCPv6] require link-local addresses, such as [MLDv2] and [DHCPv6].
3.3. Receiving Multicast Traffic
Even if MLD would work, the traffic selectors negotiated in Figure 2 The solution should assign link-local addresses to the virtual
do not allow receiving multicast traffic. interfaces, and allow them to be used for protocols between the VPN
client and gateway.
3.4. 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 Generates
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
skipping to change at page 8, line 22 skipping to change at page 8, line 18
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
Addresses [HBA] and privacy addresses [RFC4941]. Addresses [HBA] and privacy addresses [RFC4941].
Without CGAs and HBAs, VPN clients are not able to fully use IPv6 Without CGAs and HBAs, VPN clients are not able to fully use IPv6
features such as [SHIM6] or enhanced Mobile IPv6 route optimization features such as [SHIM6] or enhanced Mobile IPv6 route optimization
[RFC4866]. [RFC4866].
3.5. Sharing VPN Access The solution should allow the VPN client to easily obtain several
addresses from a given prefix, where the interface IDs are selected
by the client, and may depend on the prefix.
3.4. Sharing VPN Access
Some VPN clients may want to share the VPN connection with other Some VPN clients may want to share the VPN connection with other
devices (e.g., from a cell phone to a laptop, or vice versa) via some devices (e.g., from a cell phone to a laptop, or vice versa) via some
local area network connection (such as Wireless LAN or Bluetooth). local area network connection (such as Wireless LAN or Bluetooth), if
allowed by the security policy.
It is to be determined how common this use case would actually be;
e.g., how likely it is that security policies would allow this.
Quite obviously sharing of VPN access requires more than one address Quite obviously sharing of VPN access requires more than one address
(unless NAT is used). However, the current model where each address (unless NAT is used). However, the current model where each address
is requested separately is probably complex to integrate with a local is requested separately is probably complex to integrate with a local
area network that uses stateless address autoconfiguration. Thus, area network that uses stateless address autoconfiguration
obtaining a whole prefix for the VPN client, and advertising that to [AUTOCONF]. Thus, obtaining a whole prefix for the VPN client, and
the local link (something resembling [NDProxy]) would be preferable. advertising that to the local link (something resembling [NDProxy])
With DHCPv6 prefix delegation [RFC3633], even [NDProxy] and would be preferable. With DHCPv6 prefix delegation [RFC3633], even
associated multi-link subnet issues would be avoided. [NDProxy] and associated multi-link subnet issues would be avoided.
3.6. Additional Information
The original 3GPP standards for IPv6 assigned a single IPv6 address
to each mobile phone, resembling current IKEv2 payloads. [RFC3314]
describes the problems with this approach, and caused 3GPP to change
the specifications to assign unique /64 prefix(es) for each phone.
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.
4. Design Goals
4.1. Main Requirements
o A VPN client can obtain several addresses from a given prefix; the The solution should support sharing the VPN access over a local area
interface IDs can be selected by the client, and may depend on the network connection when the other hosts are using stateless address
prefix. autoconfiguration.
o A VPN client can be assigned multiple prefixes for use on the 3.5. General Goals
client-gateway link. The client does not have to know beforehand
how many prefixes are needed.
o The solution should avoid periodic messages over the VPN tunnel. o The solution should avoid periodic messages over the VPN tunnel.
o The solution should avoid Duplicate Address Detection (DAD) over
the VPN tunnel.
o Multicast works. That is, the client is able to send multicast
packets (tunneled to the gateway via unicast), join multicast
groups using [MLDv2], and receive multicast packets (tunneled from
the gateway to the client via unicast).
o It should be possible to share the VPN access over a local area
network connection, without requiring anything special from other
hosts in the local network (beyond minimal IPv6 node requirements
specified in [RFC4294]).
o Re-authentication works: the client can start a new IKE SA and o Re-authentication works: the client can start a new IKE SA and
continue using the same "virtual link" (with same addresses, continue using the same addresses as before.
etc.).
o Compatibility with other IPsec uses: Configuring a virtual IPv6 o Compatibility with other IPsec uses: Configuring a virtual IPv6
link should not prevent the peers from using IPsec/IKEv2 for other link (with addresses assigned in IKEv2) should not prevent the
uses. same peers from using IPsec/IKEv2 for other uses (with other
addresses). In particular, the peers may have SPD entries and PAD
Child SA Authorization Data entries that are not related to the
virtual link; when a CHILD_SA is created, it should be unambigous
which entries are used.
o Compatibility with current IPv6 configuration: Although the o Compatibility with current IPv6 configuration: Although the
current IPv6 mechanism is not widely implemented, new solutions current IPv6 mechanism is not widely implemented, new solutions
should not preclude its use (e.g., by defining incompatible should not preclude its use (e.g., by defining incompatible
semantics for the existing payloads). semantics for the existing payloads).
o Compatibility with current IPv4 configuration: it should be o The solution should have clean implementation dependencies. In
possible to use the existing IPv4 configuration mechanism within
the same IKE SA.
o (Optional/To be determined) When the client is also a router (to
some local network), it should be able to use DHCPv6 prefix
delegation [RFC3633] over the virtual link.
4.2. Desirable Non-Functional Properties
Note that the following desirable properties may be somewhat
conflicting.
o Re-use existing mechanisms, such as [AUTOCONF] and [DHCPv6] as
much as possible; as explained in [IPConfig], creating IKEv2-
specific mechanisms should be avoided.
o Avoid the Not Invented Here (NIH) syndrome: There were several
proposals how to do IP address configuration in IKEv2, and the
IPsec WG chose one of them. Any significant changes should be
motivated by real technical needs, not by dislike of the proposal
that was chosen.
4.3. Implementation Considerations
The solution should have clean implementation dependencies. In
particular, it should not require significant modifications to the particular, it should not require significant modifications to the
core IPv6 stack (typically part of the operating system), or require core IPv6 stack (typically part of the operating system), or
the IKE implementor to re-implement parts of the IPv6 stack (to, require the IKEv2 implementor to re-implement parts of the IPv6
e.g., have access or control to functionality that is currently not stack (to, e.g., have access or control to functionality that is
exposed by public interfaces of the IPv6 stack). currently not exposed by interfaces of the IPv6 stack).
4.4. Non-Goals 3.6. Non-Goals
Mobile IPv6 already defines how it interacts with IPsec/IKEv2 Mobile IPv6 already defines how it interacts with IPsec/IKEv2
[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.
5. Solution Discussion 3.7. Additional Information
Assigning a new IPv6 address to the client creates a new "virtual
IPv6 interface", and "virtual link" between the client and the
gateway. We will assume that the virtual link has the following
properties:
o The link and its interfaces are created and destroyed by the IKEv2
process.
o The IPv6 addresses and prefixes are assigned to the link and its
interfaces by IKEv2 messages, and are removed once they are no
longer used by any IKE SA. An IKEv2 implementation may delay
removal of the IPv6 addresses and prefixes for a period of time to
allow upper layer protocol communications (e.g., a TCP connection)
to survive an IKE SA re-authentication that would use the same
addresses and prefixes.
o The link is not an IPsec SA; at any time, there can be zero or
more IPsec SAs covering traffic on this link.
o The link is not a single IKE SA; to support reauthentication, it
must be possible to identify the same link in another IKE SA.
o It is TBD whether a single IKE SA needs to support multiple
virtual links. (Possibly not; if multiple virtual links are
needed, multiple IKE_SAs could be used.)
o Not all IPsec-protected traffic between the peers is necessarily
related to the virtual link (although in the simplest VPN client-
to-gateway scenario it will be).
Given these assumptions and the goals described in the previous
section, it seems that the most important design choices to be made
are the following:
o What link/subnet model is used: in other words, the relationships
between VPN clients, IPv6 subnet prefixes, and link-local traffic
(especially link-local multicast).
o How information about the IPv6 prefix(es) is distributed from the
gateway to the clients.
o How to ensure unique IPv6 addresses for each client, and keep
forwarding state up-to-date accordingly..
o How layer 3 access control is done; in other words, where the
mechanisms for preventing address spoofing by clients are placed
architecturally.
Each of these is discussed next in turn.
5.1. Link Model
There are at least three main choices how to organize the
relationships between VPN clients, IPv6 subnet prefixes, and link-
local traffic:
o Point-to-point link model: each VPN client is assigned one or more
IPv6 prefixes; these prefixes are not shared with other clients,
and there is no link-local traffic between different VPN clients
connected to the same gateway.
o Multi-access link model: multiple VPN clients share the same IPv6
prefix. Link-local multicast packets sent by one VPN client will
be received by other VPN clients (VPN gateway will forward the
packets, possibly with MLD snooping to remove unnecessary
packets).
o "Router aggregation" link model: one form of "multi-link" subnet
[Multilink] where multiple VPN clients share the same IPv6 prefix.
Link-local multicast will not be received by other VPN clients.
In the multi-access link model, VPN clients who are idle (i.e., not
currently sending or receiving application traffic) could receive
significant amounts of multicast packets from other clients
(depending on how many other clients are connected). This is
especially undesirable when the clients are battery-powered; for
example, a PDA which keeps the VPN connection to corporate intranet
active 24/7. For this reason, we will not consider the multi-access
link model in the rest of this document.
5.2. Distributing Prefix Information
Some types of addresses, such as CGAs, require knowledge about the
prefix before an address can be generated. The prefix information
could be distributed to clients in the following ways:
o IKEv2 messages (Configuration Payloads).
o Router Advertisement messages (sent over the IPsec tunnel).
o DHCPv6 messages (sent over the IPsec tunnel).
5.3. Unique Address Allocation
In the "multi-access" and "router aggregation" link models (where a
single IPv6 prefix is shared between multiple VPN clients) mechanisms
are needed to ensure that one VPN client does not use an address
already used by some other client. Also, the VPN gateway has to know
which client is using which addresses in order to correctly forward
traffic.
The main choices seem to be the following:
o Clients receive the address(es) they are allowed to use in IKEv2
messages (Configuration Payloads). In this case, keeping track of
which client is using which address is trivial.
o Clients receive the address(es) they are allowed to use in DHCPv6
messages sent over the IPsec tunnel. In case the DHCPv6 server is
not integrated with the VPN gateway, the gateway may need to work
as a relay agent to keep track of which client is using which
address (and update its forwarding state accordingly).
o Clients can use stateless address autoconfiguration to configure
addresses and perform Duplicate Address Detection (DAD). This is
easy to do in multi-access link model, and can be made to work
with router aggretation link model if the VPN gateway traps NS
messages and spoofs NA replies. The gateway keeps track of which
client is using which address (and updates its forwarding state
accordingly) by trapping these NS/NA messages.
In the point-to-point link model, the client can simply use any
address from the prefix, and the VPN gateway only needs to know which
client is using which prefix in order to forward packets correctly.
5.4. Layer 3 Access Control
It is almost always desirable to prevent one VPN client from sending
packets with a source address that is used by another VPN client. In
order to correctly forward packets destined to clients, the VPN
gateway obviously has to know which client is using which address;
the question is therefore where, architecturally, the mechanisms for
ingress filtering are placed.
o Layer 3 access control enforced by IPsec SAD/SPD: the addresses/
prefixes assigned to a VPN client are reflected in the traffic
selectors used in IPsec Security Association and Security Policy
Database entries, as negotiated in IKEv2.
o The ingress filtering capability could be placed outside IPsec;
the traffic selectors in SAD/SPD entries would cover traffic that
would be dropped later by ingress filtering.
The former approach is used by the current IPv4 solution.
5.5. Other Considerations
VPN gateway state
In some combinations of design choices, the amount of state
information required in the VPN gateway depends not only on the
number of clients, but also on the number of addresses used by one
client. With privacy addresses and potentially some uses of
Cryptographically Generated Addresses (CGAs), a single client
could have a large number of different addresses (especially if
different privacy addresses are used with different destinations).
Virtual link identifier
Reauthentication requires a way to uniquely identify the virtual
link when a second IKE SA is created. Some possible alternatives
are the IKE SPIs of the IKE SA where the virtual link was
"created" (assuming we can't have multiple virtual links within
the same IKE SA), a new identifier assigned when the link is
created, or any unique prefix or address that remains assigned to
the link for its entire lifetime. Currently, Section 6 proposes
that the gateway assigns a new IKEv2 Link ID when the link is
created. The client treats the Link ID as an opaque octet string;
the gateway uses it to identify relevant local state when
reauthentication is done.
Note that the link is not uniquely identified by the IKE peer
identities (because IDi is often a user identity that can be used
on multiple hosts at the same time), or the outer IP addresses of
the peers (due to NAT Traversal and [MOBIKE]).
Prefix lifetime
Prefixes could remain valid either for the lifetime of the IKE SA,
until explicitly cancelled, or for an explicitly specified time.
Currently, Section 6 proposes that prefixes remain valid for the
lifetime of the IKE SA (and its continuations via rekeying, but
not reauthentication). If necessary, the VPN gateway can thus add
or remove prefixes by triggering reauthentication. It is assumed
that adding or removing prefixes is a relatively rare situation,
and thus this draft does not currently specify more complex
solutions (such as explicit prefix lifetimes, or use of CFG_SET/
CFG_ACK).
Compatibility with other IPsec uses
Compatibility with other IPsec uses probably requires that when a
CHILD_SA is created, both peers can determine whether the CHILD_SA
applies to the virtual interface (at the end of the virtual link),
or the real interfaces IKEv2 messages are being sent over. This
is required to select the correct SPD to be used for traffic
selector narrowing and SA authorization in general.
One straight-forward solution would be to add an extra payload to
CREATE_CHILD_SA requests, containing the virtual link identifier.
Requests not containing this payload would refer to the real link
(over which IKEv2 messages are being sent).
Another solution is to require that the peer requesting a CHILD_SA
proposes traffic selectors that identify the link. For example,
if TSi includes the peer's "outer" IP address, it's probably
related to the real interface, not the virtual one. Or if TSi
includes any of the prefixes assigned by the gateway (or the link-
local or multicast prefix), it is probably related to the virtual
interface.
These heuristics can work in many situations, but have proved
inadequate in the context of IPv6-in-IPv4 tunnels [RFC4891] and
Provider Provisioned VPNs [VLINK] [RFC3884], and Mobile IPv6
[RFC4877]. Thus, currently Section 6 proposes including the
virtual link identifier in all CREATE_CHILD_SA requests that apply
to the virtual interface.
Example about other IPsec uses:
If a VPN gateway receives a CREATE_CHILD_SA request associated
with a physical Ethernet interface, requesting SA for (TSi=FE80::
something, dst=*), it would typically reject the request (or in
other words, narrow it to an empty set) because it doesn't have
SPD/PAD entries that would allow joe.user@example.com to request
such CHILD_SAs.
(However, it might have SPD/PAD entries that would allow
"neighboring-router.example.com" to create such SAs, for
protecting e.g. some routing protocol that uses link-local
addresses.)
However, the virtual interface created when joe.user@example.com If the VPN client is assigned IPv6 address(es) from prefix(es) that
authenticated and sent INTERNAL_IP6_LINK would have a different are shared with other VPN clients, this results in some kind of
SPD/PAD, which would allow joe.user@example.com to create this SA. multi-link subnet. [Multilink] describes issues associated with
multi-link subnets, and recommends that they should be avoided.
6. Solution Sketch 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.
This solution is basically a combination of (1) point-to-point link Due to similar concerns, the IEEE 802.16 IPv6 Convergence Sublayer
model, (2) prefix information distributed in IKEv2 messages, and (3) [RFC5121] and Proxy Mobile IPv6 [RFC5213] also assign unique
access control enforced by IPsec SAD/SPD. prefixes.
(Second preliminary version, based on discussions with Tero Kivinen.) 4. Solution Details
6.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,
INTERNAL_IP6_LINK, which requests a virtual link to be configured. INTERNAL_IP6_LINK, which requests a virtual link to be configured.
The attribute contains the client's interface ID for link-local The attribute contains the client's interface ID for the link-local
address (other addresses may use other interface IDs). Typically, address (other addresses may use other interface IDs). Typically,
the client would also ask for DHCPv6 server address; this is used the client would also ask for DHCPv6 server address; this is used
only for configuration, not address assignment. only for configuration (such as DNS server addresses), not address
assignment.
To handle backward compatibility between a client that supports the
extended address configuration mechanism hereby specified and a VPN
gateway that does not, this specification RECOMMENDS that the VPN
client includes as well the INTERNAL_IP6_ADDRESS configuration
attribute to allow graceful fallback to the existing address
configuration mechanism specified in the IKEv2 specification [IKEv2],
unless it knows for sure that the VPN gateway supports the extended
mechanism hereby specified (e.g., via configuration.)
CP(CFG_REQUEST) = CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK(Client's Link-Local Interface ID) { INTERNAL_IP6_LINK(Client's Link-Local Interface ID)
INTERNAL_IP6_ADDRESS()
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) -->
To handle backward compatibility between a VPN gateway that supports
the extended address configuration mechanism hereby specified and a
client that does not, if the client has not sent the
INTERNAL_IP6_LINK configuration attribute the VPN gateway MUST NOT
include the INTERNAL_IP6_LINK configuration attribute in its reply
and should fallback to the address configuration mechanism specified
in the IKEv2 specification [IKEv2].
If the client has sent the INTERNAL_IP6_LINK configuration attribute, If the client has sent the INTERNAL_IP6_LINK configuration attribute,
the VPN gateway SHOULD ignore any INTERNAL_IP6_ADDRESS configuration the VPN gateway SHOULD ignore any INTERNAL_IP6_ADDRESS configuration
attribute present in the request. attribute present in the request.
The VPN gateway MUST choose for itself a link-local interface The VPN gateway MUST choose for itself a link-local interface
identifier different than the client's one, i.e., accept the link- identifier different than the client's one, i.e., accept the link-
local interface identifier proposed by the client. In case the VPN local interface identifier proposed by the client. In case the VPN
gateway cannot accept the link-local interface identifier the client gateway cannot accept the link-local interface identifier the client
proposed, the VPN gateway MUST fail the IPv6 address assignment by proposed, the VPN gateway MUST fail the IPv6 address assignment by
including a NOTIFY payload with the INTERNAL_ADDRESS_FAILURE message, including a NOTIFY payload with the INTERNAL_ADDRESS_FAILURE message.
i.e., the IKE_SA can be created but no CHILD_SA will be created.
The VPN Gateway then replies with an INTERNAL_IP6_LINK configuration The VPN Gateway then replies with an INTERNAL_IP6_LINK configuration
attribute that contains the IKEv2 Link ID (which will be used for attribute that contains the IKEv2 Link ID (an identifier selected by
reauthentication and CREATE_CHILD_SA messages), the client's link the VPN gateway, treated as an opaque octet string by the client --
local interface identier, and zero or more INTERNAL_IP6_PREFIX this will be used for reauthentication and CREATE_CHILD_SA messages),
attributes. The traffic selectors proposed by the initiator are also the gateway's link local interface identier, and zero or more
narrowed to contain only the assigned prefixes, and the client link- INTERNAL_IP6_PREFIX attributes. The traffic selectors proposed by
local address formed from the well-known link-local subnet prefix and the initiator are also narrowed to contain only the assigned
the client link-local interface identifier. prefixes, and the client link-local address (FE80::<Client's
Interface ID>)identifier.
CP(CFG_REPLY) = CP(CFG_REPLY) =
{ INTERNAL_IP6_LINK(Client's Link-Local Interface ID, { INTERNAL_IP6_LINK(Gateway's Link-Local Interface ID,
IKEv2 Link ID) IKEv2 Link ID)
INTERNAL_IP6_PREFIX(Prefix1/64), INTERNAL_IP6_PREFIX(Prefix1/64),
[INTERNAL_IP6_PREFIX(Prefix2/64),...], [INTERNAL_IP6_PREFIX(Prefix2/64),...],
[INTERNAL_IP6_DHCP(Address) ] [INTERNAL_IP6_DHCP(Address) ]
TSi = ((0, 0-65535, TSi = ((0, 0-65535,
FE80::<Client's Interface ID> - FE80::<Client's Interface ID> -
FE80::<Client's Interface ID>) FE80::<Client's Interface ID>)
(0, 0-65535, (0, 0-65535,
Prefix1::0 - Prefix1::0 -
Prefix1::FFFF:FFFF:FFFF:FFFF), Prefix1::FFFF:FFFF:FFFF:FFFF),
[(0, 0-65535, [(0, 0-65535,
Prefix2::0 - Prefix2::0 -
Prefix2::FFFF:FFFF:FFFF:FFFF), ...]) Prefix2::FFFF:FFFF:FFFF:FFFF), ...])
TSr = (0, 0-65535, TSr = (0, 0-65535,
0:0:0:0:0:0:0:0 - 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
At this point, the client can configure 1) its link-local address At this point, the client can configure its link-local address
from the well-known link-local subnet prefix (FE80::/64) and the (FE80::<Client's Interface ID>), and other non-link-local unicast
assigned client's link-local interface identifier, and 2) other non- addresses from the assigned prefixes (with any proper interface
link-local unicast addresses from the assigned prefixes and any identifier [IPv6Addr]). The VPN gateway MUST NOT simultaneously
proper interface identifier [IPv6Addr]. The VPN gateway MUST NOT assign the same prefixes to any other client, and MUST NOT itself
simultaneously assign the same prefixes to any other client, and MUST configure addresses from these prefixes. Thus, the client does not
NOT itself configure addresses from these prefixes. Thus, the client have to perform Duplicate Address Detection (DAD). (This approach is
does not have to perform Duplicate Address Detection (DAD). (This based on [IPv6PPP].)
approach is based on [IPv6PPP].)
The prefixes remain valid through the lifetime of the IKE SA (and its The prefixes remain valid through the lifetime of the IKE SA (and its
continuations via rekeying). If the VPN gateway needs to remove a continuations via rekeying). If the VPN gateway needs to remove a
prefix it has previously assigned, or assign a new prefix, it can do prefix it has previously assigned, or assign a new prefix, it can do
so by triggering reauthentication. so with reauthentication (either starting reauthentication itself, or
requesting the client to reauthenticate using [RFC4478]).
2) The client also contacts the DHCPv6 server. This is the 2) The client also contacts the DHCPv6 server. This is the
RECOMMENDED way to obtain additional configuration parameters (such RECOMMENDED way to obtain additional configuration parameters (such
as the DNS server), as it allows easier extensibility and more as DNS server addresses), as it allows easier extensibility and more
options (such as the domain search list for DNS). options (such as the domain search list for DNS).
6.2. Reauthentication 4.2. Reauthentication
When the client performs reauthentication (and wants to continue When the client performs reauthentication (and wants to continue
using the same "virtual link"), it includes the IKEv2 Link ID given using the same "virtual link"), it includes the IKEv2 Link ID given
by the gateway in the INTERNAL_IP6_LINK attribute. by the gateway in the INTERNAL_IP6_LINK attribute.
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, The gateway uses the Link ID to look up relevant local state,
verifies that the authenticated peer identity associated with the verifies that the authenticated peer identity associated with the
link is correct, and continues the handshake as usual. link is correct, and continues the handshake as usual.
6.3. Creating CHILD_SAs 4.3. Creating CHILD_SAs
As described in the previous section, both peers need to be able to
determine whether a CHILD_SA applies to the virtual interfaces, or
the real interfaces IKEv2 messages are being sent over.
Currently, this document proposes using an explicit indication
instead of relying on heuristics: the peers MUST include a LINK_ID
notification, containing the IKEv2 Link ID, in all CREATE_CHILD_SA
requests, including rekeys, that are related to the virtual link.
The LINK_ID notification is not included in the CREATE_CHILD_SA
response, or when doing IKE_SA rekeying.
6.4. Multicast
(The details of multicast use are to-be-determined.)
One way would be to create an SA for receiving multicast packets:
TSi = (0, 0-65535, When a CHILD_SA is created, the peers need to determine which SPD
FF00:0:0:0:0:0:0:0 - entries and PAD Child SA Authorization Data entries are used for this
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) CHILD_SA. In the basic client-to-VPN-gateway uses, the situation is
TSr = (0, 0-65535, simple: all the matching SPD entries and Child SA Authorization Data
0:0:0:0:0:0:0:0 - entries are related to the "virtual link" between the VPN client and
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> the VPN gateway. However, if the same peers are also using IPsec/
IKEv2 for other uses (with addresses not assigned inside IKEv2), they
would also have SPD entries and PAD Child SA Authorization Data that
is not related to the virtual link.
<-- If one of the peers requests a CHILD_SA and proposes traffic
TSi = (0, 0-65535, selectors covering everything (like in Figure 2), should those be
FF00:0:0:0:0:0:0:0 - narrowed to the prefixes configured with INTERNAL_IP6_PREFIX, or to
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) the other SPD/PAD entries? While some kind of heuristics are
TSr = (0, 0-65535, possible (see Appendix A for discussion), this document specifies an
0:0:0:0:0:0:0:0 - explicit solution:
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
...and then use MLD as usual. The peers MUST include a LINK_ID notification, containing the IKEv2
Link ID, in all CREATE_CHILD_SA requests (including rekeys) that are
related to the virtual link. The LINK_ID notification is not
included in the CREATE_CHILD_SA response, or when doing IKE_SA
rekeying.
6.5. Relationship to Neighbor Discovery 4.4. Relationship to Neighbor Discovery
Neighbor Discovery [IPv6ND] specifies the following mechanisms: Neighbor Discovery [IPv6ND] specifies the following mechanisms:
Router Discovery, Prefix Discovery, Parameter Discovery,and Address Router Discovery, Prefix Discovery, Parameter Discovery,and Address
Autoconfiguration are not used, as the necessary functionality is Autoconfiguration are not used, as the necessary functionality is
implemented in IKEv2 layer. implemented in IKEv2.
Address Resolution, Next-hop Determination, and Redirect are not Address Resolution, Next-hop Determination, and Redirect are not
used, as the virtual link does not have link-local addresses, and is used, as the virtual link does not have link-layer addresses, and is
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.
6.6. 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
INTENAL_ADDRESS_EXPIRY) from [IKEv2] remain valid, including the INTENAL_ADDRESS_EXPIRY) from [IKEv2] remain valid, including the
somewhat confusingly named INTERNAL_IP6_SUBNET (see Section 6.3 of somewhat confusingly named INTERNAL_IP6_SUBNET (see Section 6.3 of
[RFC4718] for discussion). [RFC4718] for discussion).
7. Payload Formats 5. Payload Formats
7.1. INTERNAL_IP6_LINK Configuration Attribute 5.1. INTERNAL_IP6_LINK Configuration Attribute
The INTERNAL_IP6_LINK configuration attribute is formatted as The INTERNAL_IP6_LINK configuration attribute is formatted as
follows: follows:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!R| Attribute Type ! Length | !R| Attribute Type ! Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client's Link-Local | | Link-Local |
| Interface ID | | Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ IKEv2 Link ID ~ ~ IKEv2 Link ID ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Reserved (1 bit) - See [IKEv2]. o Reserved (1 bit) - See [IKEv2].
o Attribute Type (15 bits) - INTERNAL_IP6_LINK (TBD1). o Attribute Type (15 bits) - INTERNAL_IP6_LINK (TBD1).
o Length (2 octets) - Length in octets of the Value field (Client's o Length (2 octets) - Length in octets of the Value field ( Link-
Link-Local Interface ID and IKEv2 Link ID); 8 or more. Local Interface ID and IKEv2 Link ID); 8 or more.
o Link-Local Interface ID (8 octets) - The Interface ID used for o Link-Local Interface ID (8 octets) - The Interface ID used for
link-local address (by the party that sent this attribute). link-local address (by the party that sent this attribute).
o IKEv2 Link ID (variable length) - The link ID (may be empty when o IKEv2 Link ID (variable length) - The link ID (may be empty when
the client does not yet know the link ID). the client does not yet know the link ID). The link ID is
selected by the VPN gateway, and is treated as an opaque octet
string by the client.
7.2. INTERNAL_IP6_PREFIX Configuration Attribute 5.2. INTERNAL_IP6_PREFIX Configuration Attribute
The INTERNAL_IP6_PREFIX configuration attribute is formatted as The INTERNAL_IP6_PREFIX configuration attribute is formatted as
follows: follows:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!R| Attribute Type ! Length | !R| Attribute Type ! Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 22, line 33 skipping to change at page 15, line 33
case, 17. case, 17.
o Prefix (16 octets) - An IPv6 prefix assigned to the virtual link. o Prefix (16 octets) - An IPv6 prefix assigned to the virtual link.
The low order bits of the prefix field which are not part of the The low order bits of the prefix field which are not part of the
prefix MUST be set to zero by the sender and MUST be ignored by prefix MUST be set to zero by the sender and MUST be ignored by
the receiver. the receiver.
o Prefix Length (1 octets) - The length of the prefix in bits; o Prefix Length (1 octets) - The length of the prefix in bits;
usually 64. usually 64.
7.3. LINK_ID Notify Payload 5.3. LINK_ID Notify Payload
The LINK_ID notification is included in CREATE_CHILD_SA requests to The LINK_ID notification is included in CREATE_CHILD_SA requests to
indicate that the SA being created is related to the virtual link. indicate that the SA being created is related to the virtual link.
If this notification is not included, the CREATE_CHILD_SA requests is If this notification is not included, the CREATE_CHILD_SA requests is
related to the physical interface. related to the real interface.
The Notify Message Type for LINK_ID is TBD3. The Protocol ID and SPI The Notify Message Type for LINK_ID is TBD3. The Protocol ID and SPI
Size fields are set to zero. The data associated with this Size fields are set to zero. The data associated with this
notification is the IKEv2 Link ID returned in the notification is the IKEv2 Link ID returned in the INTERNAL_IP6_LINK
INTERNAL_IP6_LINK_ID configuration attribute. configuration attribute.
8. IANA Considerations 6. IANA Considerations
This document defines two new IKEv2 configuration attributes, whose This document defines two new IKEv2 configuration attributes, whose
values are to be allocated (have been allocated) from the "IKEv2 values are to be allocated (have been allocated) from the "IKEv2
Configuration Payload Attribute Types" namespace [IKEv2]: Configuration Payload Attribute Types" namespace [IKEv2]:
Multi- Multi-
Value Attribute Type Valued Length Reference Value Attribute Type Valued Length Reference
------ ---------------------- ------ ------------- --------- ------ ---------------------- ------ ------------- ---------
TBD1 INTERNAL_IP6_LINK NO 8 or more [this doc] TBD1 INTERNAL_IP6_LINK NO 8 or more [this doc]
TBD2 INTERNAL_IP6_PREFIX YES 17 octets [this doc] TBD2 INTERNAL_IP6_PREFIX YES 17 octets [this doc]
skipping to change at page 24, line 5 skipping to change at page 17, line 5
to be allocated (has been allocated) from the "IKEv2 Notify Message to be allocated (has been allocated) from the "IKEv2 Notify Message
Types - Status Types" namespace [IKEv2]: Types - Status Types" namespace [IKEv2]:
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.
9. Security Considerations 7. Security Considerations
To be written. (The security consideration should be pretty much the
same as for current configuration payloads.)
Assigning each client a unique prefix makes using randomized Assigning each client a unique prefix makes using randomized
interface identifiers [RFC4941] ineffective from privacy point of interface identifiers [RFC4941] ineffective from privacy point of
view: the client is still uniquely identified by the prefix. In some view: the client is still uniquely identified by the prefix. In some
environments, it may be preferable to assign a VPN client the same environments, it may be preferable to assign a VPN client the same
prefixes each time a VPN connection is established; other prefix each time a VPN connection is established; other environments
environments may prefer assigning a different prefix every time for may prefer assigning a different prefix every time for privacy
privacy reasons. (This is basically a similar trade-off as in Mobile reasons. (This is basically a similar trade-off as in Mobile IPv6 --
IPv6 -- using the same Home Address forever is simpler than changing using the same Home Address forever is simpler than changing it
it often, but has privacy implications.) often, but has privacy implications.)
10. Acknowledgments 8. Acknowledgments
The author would like to thank Patrick Irwin, Tero Kivinen, Julien The author would like to thank Patrick Irwin, Tero Kivinen, Julien
Laganier, Chinh Nguyen, Mohan Parthasarathy, Yaron Sheffer, Hemant Laganier, Chinh Nguyen, Mohan Parthasarathy, Yaron Sheffer, Hemant
Singh, Dave Thaler, Yinghzhe Wu, and Fan Zhao for their valuable Singh, Dave Thaler, Yinghzhe Wu, and Fan Zhao for their valuable
comments. 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
Provisioned VPNs [VLINK] [RFC3884], and Mobile IPv6 [RFC4877]. Some Provisioned VPNs [VLINK] [RFC3884], and Mobile IPv6 [RFC4877]. Some
of the limitations of assigning a single IPv6 address were identified of the limitations of assigning a single IPv6 address were identified
in [RFC3314]. in [RFC3314].
11. References 9. References
11.1. Normative References 9.1. Normative References
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[IPv6Addr] [IPv6Addr]
Hinden, R. and S. Deering, "IP Version 6 Addressing Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[KEYWORDS] [KEYWORDS]
Bradner, S., "Key words for use in RFCs to Indicate Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
11.2. Informative References 9.2. Informative References
[AUTOCONF] [AUTOCONF]
Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2006. RFC 3972, March 2006.
[DHCPv6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [DHCPv6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[HBA] Bagnulo, M., "Hash Based Addresses (HBA)", [HBA] Bagnulo, M., "Hash Based Addresses (HBA)",
draft-ietf-shim6-hba-05 (work in progress), December 2007. draft-ietf-shim6-hba-05 (work in progress), December 2007.
[IPConfig]
Aboba, B., Thaler, D., and L. Andersson, "Principles of
Internet Host Configuration", draft-iab-ip-config-04 (work
in progress), May 2008.
[IPv6ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [IPv6ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[IPv6PPP] Varada, S., Haskins, D., and E. Allen, "IP Version 6 over [IPv6PPP] Varada, S., Haskins, D., and E. Allen, "IP Version 6 over
PPP", RFC 5072, September 2007. PPP", RFC 5072, September 2007.
[MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery [MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
skipping to change at page 27, line 31 skipping to change at page 20, line 27
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec [RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec
Transport Mode for Dynamic Routing", RFC 3884, Transport Mode for Dynamic Routing", RFC 3884,
September 2004. September 2004.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC4294] Loughney, J., Ed., "IPv6 Node Requirements", RFC 4294, [RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange
April 2006. (IKEv2) Protocol", RFC 4478, April 2006.
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
Implementation Guidelines", RFC 4718, October 2006. Implementation Guidelines", RFC 4718, October 2006.
[RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
Optimization for Mobile IPv6", RFC 4866, May 2007. Optimization for Mobile IPv6", RFC 4866, May 2007.
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877, IKEv2 and the Revised IPsec Architecture", RFC 4877,
April 2007. April 2007.
[RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H. [RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H.
Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels",
RFC 4891, May 2007. RFC 4891, May 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007. IPv6", RFC 4941, September 2007.
[RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S.
Madanapalli, "Transmission of IPv6 via the IPv6
Convergence Sublayer over IEEE 802.16 Networks", RFC 5121,
February 2008.
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdury,
K., and B. Patil, "Proxy Mobile IPv6", RFC 5213,
August 2008.
[SHIM6] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming [SHIM6] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", draft-ietf-shim6-proto-10 (work Shim Protocol for IPv6", draft-ietf-shim6-proto-12 (work
in progress), February 2008. in progress), February 2009.
[VLINK] Duffy, M., "Framework for IPsec Protected Virtual Links [VLINK] Duffy, M., "Framework for IPsec Protected Virtual Links
for PPVPNs", draft-duffy-ppvpn-ipsec-vlink-00 (work in for PPVPNs", draft-duffy-ppvpn-ipsec-vlink-00 (work in
progress), October 2002. progress), October 2002.
Appendix A. Alternative Solution Sketches Appendix A. Design Rationale (Non-Normative)
A.1. Version -00 Sketch This appendix describes some of the reasons why the solution in
Section 4 was selected, and lists some alternative designs that were
considered, but ultimately rejected.
Assigning a new IPv6 address to the client creates a new "virtual
IPv6 interface", and "virtual link" between the client and the
gateway. We will assume that the virtual link has the following
properties:
o The link and its interfaces are created and destroyed by the IKEv2
process.
o The link is not an IPsec SA; at any time, there can be zero or
more IPsec SAs covering traffic on this link.
o The link is not a single IKE SA; to support reauthentication, it
must be possible to identify the same link in another IKE SA.
o Not all IPsec-protected traffic between the peers is necessarily
related to the virtual link (although in the simplest VPN client-
to-gateway scenario it will be).
Given these assumptions and the goals described in Section 3, it
seems that the most important design choices to be made are the
following:
o What link/subnet model is used: in other words, the relationships
between VPN clients, IPv6 subnet prefixes, and link-local traffic
(especially link-local multicast).
o How information about the IPv6 prefix(es) is distributed from the
gateway to the clients.
o How to ensure unique IPv6 addresses for each client, and keep
forwarding state up-to-date accordingly.
o How layer 3 access control is done; in other words, where the
mechanisms for preventing address spoofing by clients are placed
architecturally.
Each of these is discussed next in turn.
A.1. Link Model
There are at least three main choices how to organize the
relationships between VPN clients, IPv6 subnet prefixes, and link-
local traffic:
o Point-to-point link model: each VPN client is assigned one or more
IPv6 prefixes; these prefixes are not shared with other clients,
and there is no link-local traffic between different VPN clients
connected to the same gateway.
o Multi-access link model: multiple VPN clients share the same IPv6
prefix. Link-local multicast packets sent by one VPN client will
be received by other VPN clients (VPN gateway will forward the
packets, possibly with MLD snooping to remove unnecessary
packets).
o "Router aggregation" link model: one form of "multi-link" subnet
[Multilink] where multiple VPN clients share the same IPv6 prefix.
Link-local multicast will not be received by other VPN clients.
In the multi-access link model, VPN clients who are idle (i.e., not
currently sending or receiving application traffic) could receive
significant amounts of multicast packets from other clients
(depending on how many other clients are connected). This is
especially undesirable when the clients are battery-powered; for
example, a PDA which keeps the VPN connection to corporate intranet
active 24/7. For this reason, using the multi-access link model was
rejected.
The configuration attributes specified in Section 4 use the point-to-
point link model.
A.2. Distributing Prefix Information
Some types of addresses, such as CGAs, require knowledge about the
prefix before an address can be generated. The prefix information
could be distributed to clients in the following ways:
o IKEv2 messages (Configuration Payloads).
o Router Advertisement messages (sent over the IPsec tunnel).
o DHCPv6 messages (sent over the IPsec tunnel).
In Section 4, the prefix information is distributed in IKEv2
messages.
A.3. Unique Address Allocation
In the "multi-access" and "router aggregation" link models (where a
single IPv6 prefix is shared between multiple VPN clients) mechanisms
are needed to ensure that one VPN client does not use an address
already used by some other client. Also, the VPN gateway has to know
which client is using which addresses in order to correctly forward
traffic.
The main choices seem to be the following:
o Clients receive the address(es) they are allowed to use in IKEv2
messages (Configuration Payloads). In this case, keeping track of
which client is using which address is trivial.
o Clients receive the address(es) they are allowed to use in DHCPv6
messages sent over the IPsec tunnel. In case the DHCPv6 server is
not integrated with the VPN gateway, the gateway may need to work
as a relay agent to keep track of which client is using which
address (and update its forwarding state accordingly).
o Clients can use stateless address autoconfiguration to configure
addresses and perform Duplicate Address Detection (DAD). This is
easy to do in multi-access link model, and can be made to work
with router aggregation link model if the VPN gateway traps
Neighbor Solicitation (NS) messages and spoofs Neighbor
Advertisement (NA) replies. The gateway keeps track of which
client is using which address (and updates its forwarding state
accordingly) by trapping these NS/NA messages.
In the point-to-point link model, the client can simply use any
address from the prefix, and the VPN gateway only needs to know which
client is using which prefix in order to forward packets correctly.
A.4. Layer 3 Access Control
It is almost always desirable to prevent one VPN client from sending
packets with a source address that is used by another VPN client. In
order to correctly forward packets destined to clients, the VPN
gateway obviously has to know which client is using which address;
the question is therefore where, architecturally, the mechanisms for
ingress filtering are placed.
o Layer 3 access control enforced by IPsec SAD/SPD: the addresses/
prefixes assigned to a VPN client are reflected in the traffic
selectors used in IPsec Security Association and Security Policy
Database entries, as negotiated in IKEv2.
o The ingress filtering capability could be placed outside IPsec;
the traffic selectors in SAD/SPD entries would cover traffic that
would be dropped later by ingress filtering.
The former approach is used by the current IPv4 solution, and the
mechanism specified in Section 4.
A.5. Other Considerations
VPN gateway state
In some combinations of design choices, the amount of state
information required in the VPN gateway depends not only on the
number of clients, but also on the number of addresses used by one
client. With privacy addresses and potentially some uses of
Cryptographically Generated Addresses (CGAs), a single client
could have a large number of different addresses (especially if
different privacy addresses are used with different destinations).
Virtual link identifier
Reauthentication requires a way to uniquely identify the virtual
link when a second IKE SA is created. Some possible alternatives
are the IKE SPIs of the IKE SA where the virtual link was
"created" (assuming we can't have multiple virtual links within
the same IKE SA), a new identifier assigned when the link is
created, or any unique prefix or address that remains assigned to
the link for its entire lifetime. Section 4 specifies that the
gateway assigns a new IKEv2 Link ID when the link is created. The
client treats the Link ID as an opaque octet string; the gateway
uses it to identify relevant local state when reauthentication is
done.
Note that the link is not uniquely identified by the IKE peer
identities (because IDi is often a user identity that can be used
on multiple hosts at the same time), or the outer IP addresses of
the peers (due to NAT Traversal and [MOBIKE]).
Prefix lifetime
Prefixes could remain valid either for the lifetime of the IKE SA,
until explicitly cancelled, or for an explicitly specified time.
In Section 4 the prefixes remain valid for the lifetime of the IKE
SA (and its continuations via rekeying, but not reauthentication).
If necessary, the VPN gateway can thus add or remove prefixes by
triggering reauthentication. It is assumed that adding or
removing prefixes is a relatively rare situation, and thus this
document does not specify more complex solutions (such as explicit
prefix lifetimes, or use of CFG_SET/CFG_ACK).
Compatibility with other IPsec uses
Compatibility with other IPsec uses probably requires that when a
CHILD_SA is created, both peers can determine whether the CHILD_SA
applies to the virtual interface (at the end of the virtual link),
or the real interfaces IKEv2 messages are being sent over. This
is required to select the correct SPD to be used for traffic
selector narrowing and SA authorization in general.
One straight-forward solution is to add an extra payload to
CREATE_CHILD_SA requests, containing the virtual link identifier.
Requests not containing this payload would refer to the real link
(over which IKEv2 messages are being sent).
Another solution is to require that the peer requesting a CHILD_SA
proposes traffic selectors that identify the link. For example,
if TSi includes the peer's "outer" IP address, it's probably
related to the real interface, not the virtual one. Or if TSi
includes any of the prefixes assigned by the gateway (or the link-
local or multicast prefix), it is probably related to the virtual
interface.
These heuristics can work in many situations, but have proved
inadequate in the context of IPv6-in-IPv4 tunnels [RFC4891] and
Provider Provisioned VPNs [VLINK] [RFC3884], and Mobile IPv6
[RFC4877]. Thus, Section 4 includes the virtual link identifier
in all CREATE_CHILD_SA requests that apply to the virtual
interface.
Example about other IPsec uses:
If a VPN gateway receives a CREATE_CHILD_SA request associated
with a physical Ethernet interface, requesting SA for (TSi=FE80::
something, dst=*), it would typically reject the request (or in
other words, narrow it to an empty set) because it doesn't have
SPD/PAD entries that would allow joe.user@example.com to request
such CHILD_SAs.
(However, it might have SPD/PAD entries that would allow
"neighboring-router.example.com" to create such SAs, for
protecting e.g. some routing protocol that uses link-local
addresses.)
However, the virtual interface created when joe.user@example.com
authenticated and sent INTERNAL_IP6_LINK would have a different
SPD/PAD, which would allow joe.user@example.com to create this SA.
A.6. Alternative Solution Sketches
A.6.1. Version -00 Sketch
The -00 version of this draft contained the following solution The -00 version of this draft contained the following solution
sketch, which is basically a combination of (1) point-to-point link sketch, which is basically a combination of (1) point-to-point link
model, (2) prefix information distributed in Neighbor Advertisements, model, (2) prefix information distributed in Neighbor Advertisements,
and (3) access control enforced outside IPsec. and (3) access control enforced outside IPsec.
1) During IKE_AUTH, client sends a new configuration attribute, 1) During IKE_AUTH, client sends a new configuration attribute,
INTERNAL_IP6_LINK_ID, which requests a virtual link to be created. INTERNAL_IP6_LINK, which requests a virtual link to be created. The
The attribute contains the client's interface ID for link-local attribute contains the client's interface ID for link-local address
address (other addresses may use other interface IDs). (other addresses may use other interface IDs).
CP(CFG_REQUEST) = CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK_ID(Link-Local Interface ID) } { INTERNAL_IP6_LINK(Link-Local Interface ID) }
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 VPN gateway replies with its own link-local interface ID (which The VPN gateway replies with its own link-local interface ID (which
MUST be different from the client's) and an IKEv2 Link ID (which will has to be different from the client's) and an IKEv2 Link ID (which
be used for reauthentication). will be used for reauthentication).
CP(CFG_REPLY) = CP(CFG_REPLY) =
{ INTERNAL_IP6_LINK_ID(Link-Local Interface ID, IKEv2 Link ID) } { INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID) }
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)
At this point, both peers configure the virtual interface with the At this point, both peers configure the virtual interface with the
link-local addresses. link-local addresses.
2) The next step is IPv6 stateless address autoconfiguration; that 2) The next step is IPv6 stateless address autoconfiguration; that
is, Router Solicitation and Router Advertisement messages sent over is, Router Solicitation and Router Advertisement messages sent over
the IPsec SA. the IPsec SA.
ESP(Router Solicitation: ESP(Router Solicitation:
src=: src=::,
dst=FF02:0:0:0:0:0:0:2) --> dst=FF02:0:0:0:0:0:0:2) -->
<-- ESP(Router Advertisement: <-- ESP(Router Advertisement:
src=FE80::<Gateway's Interface ID> src=FE80::<Gateway's Interface ID>
dst=FF02:0:0:0:0:0:0:1, dst=FF02:0:0:0:0:0:0:1,
Prefix1, [Prefix2...]) Prefix1, [Prefix2...])
After receiving the Router Advertisement, the client can configure After receiving the Router Advertisement, the client can configure
unicast addresses from the advertised prefixes, using any interface unicast addresses from the advertised prefixes, using any proper
ID. The VPN gateway MUST NOT simultaneously assign the same prefixes interface ID. The VPN gateway does not simultaneously assign the
to any other client, and MUST NOT itself configure addresses from same prefixes to any other client, and does not itself configure
these prefixes. Thus, the client does not have to perform Duplicate addresses from these prefixes. Thus, the client does not have to
Address Detection (DAD). perform Duplicate Address Detection (DAD).
3) Reauthentication works basically the same way as in Section 6.2; 3) Reauthentication works basically the same way as in Section 4; the
the client includes the IKEv2 Link ID in the INTERNAL_IP6_LINK_ID client includes the IKEv2 Link ID in the INTERNAL_IP6_LINK attribute.
attribute.
4) Creating and rekeying IPsec SAs works basically the same way as in 4) Creating and rekeying IPsec SAs works basically the same way as in
Section 6.3; the client includes the IKEv2 Link ID in those CHILD_SA Section 4.3; the client includes the IKEv2 Link ID in those CHILD_SA
requests that are related to the virtual link. requests that are related to the virtual link.
Comments: This was changed in -01 draft based on feedback from VPN Comments: This was changed in -01 draft based on feedback from VPN
vendors: while the solution looks nice on paper, it is claimed to be vendors: while the solution looks nice on paper, it is claimed to be
unneccessarily complex to implement when the IKE implementation and unneccessarily complex to implement when the IKE implementation and
IPv6 stack are from different companies. Furthermore, enforcing IPv6 stack are from different companies. Furthermore, enforcing
access control outside IPsec is a significant architectural change access control outside IPsec is a significant architectural change
compared to current IPv4 solutions. compared to current IPv4 solutions.
A.2. Router Aggregation Sketch #1 A.6.2. Router Aggregation Sketch #1
The following solution was sketched during the IETF 70 meeting in The following solution was sketched during the IETF 70 meeting in
Vancouver together with Hemant Singh. It combines the (1) router Vancouver together with Hemant Singh. It combines the (1) router
aggregation link model, (2) prefix information distributed in IKEv2 aggregation link model, (2) prefix information distributed in IKEv2
messages, (3) unique address allocation with stateless address messages, (3) unique address allocation with stateless address
autoconfiguration (with VPN gateway trapping NS messages and spoofing autoconfiguration (with VPN gateway trapping NS messages and spoofing
NA replies), and (4) access control enforced (partly) outside IPsec. NA replies), and (4) access control enforced (partly) outside IPsec.
1) During IKE_AUTH, the client sends a new configuration attribute, 1) During IKE_AUTH, the client sends a new configuration attribute,
INTERNAL_IP6_LINK_ID, which requests a virtual link to be created. INTERNAL_IP6_LINK, which requests a virtual link to be created. The
The attribute contains the client's interface ID for link-local attribute contains the client's interface ID for link-local address
address (other addresses may use other interface IDs). (other addresses may use other interface IDs).
CP(CFG_REQUEST) = CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK_ID(Link-Local Interface ID) } { INTERNAL_IP6_LINK(Link-Local Interface ID) }
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 VPN gateway replies with its own link-local interface ID (which The VPN gateway replies with its own link-local interface ID (which
MUST be different from the client's), an IKEv2 Link ID (which will be has to be different from the client's), an IKEv2 Link ID (which will
used for reauthentication and CREATE_CHILD_SA messages), and zero or be used for reauthentication and CREATE_CHILD_SA messages), and zero
more INTERNAL_IP6_PREFIX attributes. The traffic selectors proposed or more INTERNAL_IP6_PREFIX attributes. The traffic selectors
by the initiator are also narrowed to contain only the assigned proposed by the initiator are also narrowed to contain only the
prefixes (and the link-local prefix). assigned prefixes (and the link-local prefix).
CP(CFG_REPLY) = CP(CFG_REPLY) =
{ INTERNAL_IP6_LINK_ID(Link-Local Interface ID, IKEv2 Link ID), { INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID),
INTERNAL_IP6_PREFIX(Prefix1/64), INTERNAL_IP6_PREFIX(Prefix1/64),
[INTERNAL_IP6_PREFIX(Prefix2/64),...], [INTERNAL_IP6_PREFIX(Prefix2/64),...],
INTERNAL_IP6_DHCP(Address) ] INTERNAL_IP6_DHCP(Address) ]
TSi = ((0, 0-65535, TSi = ((0, 0-65535,
FE80::<Client's Interface ID> - FE80::<Client's Interface ID> -
FE80::<Client's Interface ID>) FE80::<Client's Interface ID>)
(0, 0-65535, (0, 0-65535,
Prefix1::0 - Prefix1::0 -
Prefix1::FFFF:FFFF:FFFF:FFFF), Prefix1::FFFF:FFFF:FFFF:FFFF),
[(0, 0-65535, [(0, 0-65535,
skipping to change at page 31, line 39 skipping to change at page 29, line 38
if the target address is already in use by some other VPN client, the if the target address is already in use by some other VPN client, the
gateway replies with a Neighbor Advertisement. If the target address gateway replies with a Neighbor Advertisement. If the target address
is not already in use, the VPN gateway notes that it is now being is not already in use, the VPN gateway notes that it is now being
used by this client, and updates its forwarding state accordingly. used by this client, and updates its forwarding state accordingly.
Comments: The main disadvantages of this solution are non-standard Comments: The main disadvantages of this solution are non-standard
processing of NS messages (which are used to update the gateway's processing of NS messages (which are used to update the gateway's
forwarding state), and performing access control partly outside forwarding state), and performing access control partly outside
IPsec. IPsec.
A.3. Router Aggregation Sketch #2 A.6.3. Router Aggregation Sketch #2
This is basically similar to the version -00 sketch described with This is basically similar to the version -00 sketch described with
above, but uses router aggregation link model. In other words, it above, but uses router aggregation link model. In other words, it
combines (1) router aggregation link model, (2) prefix information combines (1) router aggregation link model, (2) prefix information
distributed in Neighbor Advertisements, (3) unique address allocation distributed in Neighbor Advertisements, (3) unique address allocation
with stateless address autoconfiguration (with VPN gateway trapping with stateless address autoconfiguration (with VPN gateway trapping
NS messages and spoofing NA replies), and (4) access control enforced NS messages and spoofing NA replies), and (4) access control enforced
outside IPsec. outside IPsec.
1) During IKE_AUTH, client sends a new configuration attribute, 1) During IKE_AUTH, client sends a new configuration attribute,
INTERNAL_IP6_LINK_ID, which requests a virtual link to be created. INTERNAL_IP6_LINK, which requests a virtual link to be created. The
The attribute contains the client's interface ID for link-local attribute contains the client's interface ID for link-local address
address (other addresses may use other interface IDs). (other addresses may use other interface IDs).
CP(CFG_REQUEST) = CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK_ID(Link-Local Interface ID) } { INTERNAL_IP6_LINK(Link-Local Interface ID) }
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 VPN gateway replies with its own link-local interface ID (which The VPN gateway replies with its own link-local interface ID (which
MUST be different from the client's) and an IKEv2 Link ID (which will has to be different from the client's) and an IKEv2 Link ID (which
be used for reauthentication). will be used for reauthentication).
CP(CFG_REPLY) = CP(CFG_REPLY) =
{ INTERNAL_IP6_LINK_ID(Link-Local Interface ID, IKEv2 Link ID) } { INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID) }
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)
At this point, both peers configure the virtual interface with the At this point, both peers configure the virtual interface with the
link-local addresses. link-local addresses.
2) The next step is IPv6 stateless address autoconfiguration; that 2) The next step is IPv6 stateless address autoconfiguration; that
is, Router Solicitation and Router Advertisement messages sent over is, Router Solicitation and Router Advertisement messages sent over
the IPsec SA. the IPsec SA.
ESP(Router Solicitation: ESP(Router Solicitation:
src=: src=::,
dst=FF02:0:0:0:0:0:0:2) --> dst=FF02:0:0:0:0:0:0:2) -->
<-- ESP(Router Advertisement: <-- ESP(Router Advertisement:
src=FE80::<Gateway's Interface ID> src=FE80::<Gateway's Interface ID>
dst=FF02:0:0:0:0:0:0:1, dst=FF02:0:0:0:0:0:0:1,
Prefix1, [Prefix2...]) Prefix1, [Prefix2...])
3) The client now configures tentative unicast addresses from the 3) The client now configures tentative unicast addresses from the
prefixes given by the gateway, and performs Duplicate Address prefixes given by the gateway, and performs Duplicate Address
Detection (DAD) for them. Detection (DAD) for them.
skipping to change at page 33, line 6 skipping to change at page 31, line 5
The Neighbor Solicitation messages are processed by the VPN gateway: The Neighbor Solicitation messages are processed by the VPN gateway:
if the target address is already in use by some other VPN client, the if the target address is already in use by some other VPN client, the
gateway replies with a Neighbor Advertisement. If the target address gateway replies with a Neighbor Advertisement. If the target address
is not already in use, the VPN gateway notes that it is now being is not already in use, the VPN gateway notes that it is now being
used by this client, and updates its forwarding state accordingly. used by this client, and updates its forwarding state accordingly.
Comments: The main disadvantages of this solution are non-standard Comments: The main disadvantages of this solution are non-standard
processing of NS messages (which are used to update the gateway's processing of NS messages (which are used to update the gateway's
forwarding state), and performing access control outside IPsec. forwarding state), and performing access control outside IPsec.
A.4. IPv4-like Sketch A.6.4. IPv4-like Sketch
This sketch resembles the current IPv4 configuration payloads, and it This sketch resembles the current IPv4 configuration payloads, and it
combines (1) router aggregation link model, (2) prefix information combines (1) router aggregation link model, (2) prefix information
distributed in IKEv2 messages, (3) unique address allocation with distributed in IKEv2 messages, (3) unique address allocation with
IKEv2 messages, and (4) access control enforced by IPsec SAD/SPD. IKEv2 messages, and (4) access control enforced by IPsec SAD/SPD.
1) During IKE_AUTH, the client sends a new configuration attribute, 1) During IKE_AUTH, the client sends a new configuration attribute,
INTERNAL_IP6_LINK_ID, which requests a virtual link to be created. INTERNAL_IP6_LINK, which requests a virtual link to be created. The
The attribute contains the client's interface ID for link-local attribute contains the client's interface ID for link-local address
address (other addresses may use other interface IDs). (other addresses may use other interface IDs).
CP(CFG_REQUEST) = CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK_ID(Link-Local Interface ID) } { INTERNAL_IP6_LINK(Link-Local Interface ID) }
TSi = (0, 0-65535, TSi = (0, 0-65535,
0:0:0:0:0:0:0:0 - 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, TSr = (0, 0-65535,
0:0:0:0:0:0:0:0 - 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 VPN gateway replies with its own link-local interface ID (which The VPN gateway replies with its own link-local interface ID (which
MUST be different from the client's), an IKEv2 Link ID (which will be has to be different from the client's), an IKEv2 Link ID (which will
used for reauthentication and CREATE_CHILD_SA messages), and zero or be used for reauthentication and CREATE_CHILD_SA messages), and zero
more INTERNAL_IP6_ADDRESS2 attributes. Each attribute contains one or more INTERNAL_IP6_ADDRESS2 attributes. Each attribute contains
address from a particular prefix. one address from a particular prefix.
CP(CFG_REPLY) = CP(CFG_REPLY) =
{ INTERNAL_IP6_LINK_ID(Link-Local Interface ID, IKEv2 Link ID), { INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID),
INTERNAL_IP6_ADDRESS2(Prefix1+Client's Interface ID1), INTERNAL_IP6_ADDRESS2(Prefix1+Client's Interface ID1),
[INTERNAL_IP6_ADDRESS2(Prefix2+Client's Interface ID2),...], [INTERNAL_IP6_ADDRESS2(Prefix2+Client's Interface ID2),...],
TSi = ((0, 0-65535, TSi = ((0, 0-65535,
FE80::<Client's Link-Local Interface ID> - FE80::<Client's Link-Local Interface ID> -
FE80::<Client's Link-Local Interface ID>) FE80::<Client's Link-Local Interface ID>)
(0, 0-65535, (0, 0-65535,
Prefix1::<Client's Interface ID1> - Prefix1::<Client's Interface ID1> -
Prefix1::<Client's Interface ID1>), Prefix1::<Client's Interface ID1>),
[(0, 0-65535, [(0, 0-65535,
Prefix2::<Client's Interface ID2> - Prefix2::<Client's Interface ID2> -
skipping to change at page 34, line 40 skipping to change at page 32, line 38
Comments: The main advantage of this solution is that it's quite Comments: The main advantage of this solution is that it's quite
close to the current IPv4 way of doing things. By adding explicit close to the current IPv4 way of doing things. By adding explicit
link creation (with Link ID for reauthentication/SPD selection, and link creation (with Link ID for reauthentication/SPD selection, and
link-local addresses), and slightly changing the semantics (and also link-local addresses), and slightly changing the semantics (and also
name) of INTERNAL_IP6_ADDRESS attribute (can return more attributes name) of INTERNAL_IP6_ADDRESS attribute (can return more attributes
than was asked), we get much of the needed functionality. than was asked), we get much of the needed functionality.
The biggest disadvantages are probably potentially complex The biggest disadvantages are probably potentially complex
implementation dependency for interface ID selection (see implementation dependency for interface ID selection (see
Section 3.4), and the multi-link subnet model. Section 3.3), and the multi-link subnet model.
A.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.
Authors' Addresses Authors' Addresses
Pasi Eronen Pasi Eronen
Nokia Research Center Nokia Research Center
skipping to change at page 36, line 4 skipping to change at line 1279
Phone: +49 89 56824 231 Phone: +49 89 56824 231
Email: julien.laganier.IETF@googlemail.com Email: julien.laganier.IETF@googlemail.com
Cheryl Madson Cheryl Madson
Cisco Systems, Inc. Cisco Systems, Inc.
510 MacCarthy Drive 510 MacCarthy Drive
Milpitas, CA Milpitas, CA
USA USA
Email: cmadson@cisco.com Email: cmadson@cisco.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 103 change blocks. 
568 lines changed or deleted 497 lines changed or added

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