Network Working Group P. Eronen
Internet-Draft Nokia
Expires: May 11, 2008 November 8, 2007
IPv6 Configuration in IKEv2
draft-eronen-ipsec-ikev2-ipv6-config-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
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
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 11, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Eronen Expires May 11, 2008 [Page 1]
Internet-Draft IPv6 Configuration in IKEv2 November 2007
Abstract
When IKEv2 is used for remote VPN access (client to VPN gateway), the
gateway assigns the client an IP address from the internal network
using IKEv2 configuration payloads. The configuration payloads
specified in RFC 4306 work well for IPv4, but make it difficult to
use certain features of IPv6. This document describes the
limitations of current IKEv2 configuration payloads for IPv6, and
explores possible solutions that would allow IKEv2 to set up full-
featured virtual IPv6 interfaces.
Eronen Expires May 11, 2008 [Page 2]
Internet-Draft IPv6 Configuration in IKEv2 November 2007
Table of Contents
1. Introduction and Problem Statement . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Current Limitations . . . . . . . . . . . . . . . . . . . . . 7
3.1. Multiple Prefixes . . . . . . . . . . . . . . . . . . . . 7
3.2. Link-Local Addresses . . . . . . . . . . . . . . . . . . . 7
3.3. Receiving Multicast Traffic . . . . . . . . . . . . . . . 7
3.4. Interface Identifier Selection . . . . . . . . . . . . . . 7
3.5. Sharing VPN Access . . . . . . . . . . . . . . . . . . . . 8
3.6. Additional Information . . . . . . . . . . . . . . . . . . 8
4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Main Requirements . . . . . . . . . . . . . . . . . . . . 9
4.2. Desirable Non-Functional Properties . . . . . . . . . . . 9
4.3. Implementation Considerations . . . . . . . . . . . . . . 10
4.4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Solution Discussion . . . . . . . . . . . . . . . . . . . 10
4.6. Example About Other IPsec Uses . . . . . . . . . . . . . . 12
5. Solution Sketch . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Initial Exchanges . . . . . . . . . . . . . . . . . . . . 13
5.2. Reauthentication . . . . . . . . . . . . . . . . . . . . . 14
5.3. Creating CHILD_SAs . . . . . . . . . . . . . . . . . . . . 14
5.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 14
5.5. Relationship to Neighbor Discovery . . . . . . . . . . . . 15
5.6. Relationship to Existing IKEv2 Payloads . . . . . . . . . 15
6. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. INTERNAL_IP6_LINK Configuration Attribute . . . . . . . . 17
6.2. INTERNAL_IP6_PREFIX Configuration Attribute . . . . . . . 17
6.3. LINK_ID Notify Payload . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. First sketch . . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 27
Eronen Expires May 11, 2008 [Page 3]
Internet-Draft IPv6 Configuration in IKEv2 November 2007
1. Introduction and Problem Statement
In typical remote access VPN use (client to VPN gateway), the client
needs an IP address in the network protected by the security gateway.
IKEv2 includes a feature called "configuration payloads" that allows
the gateway to dynamically assign a temporary address to the client
[IKEv2].
For IPv4, the message exchange would look as follows:
Client Gateway
-------- ---------
HDR(IKE_SA_INIT), SAi1, KEi, Ni -->
<-- HDR(IKE_SA_INIT), SAr1, KEr, Nr, [CERTREQ]
HDR(IKE_AUTH),
SK { IDi, CERT, [CERTREQ], AUTH, [IDr],
CP(CFG_REQUEST) =
{ INTERNAL_IP4_ADDRESS(),
INTERNAL_IP4_DNS() }, SAi2,
TSi = (0, 0-65535, 0.0.0.0-255.255.255.255),
TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) } -->
<-- HDR(IKE_AUTH),
SK { IDr, CERT, AUTH,
CP(CFG_REPLY) =
{ INTERNAL_IP4_ADDRESS(192.0.2.234),
INTERNAL_IP4_DNS(10.11.22.33) },
SAr2,
TSi = (0, 0-65535, 192.0.2.234-192.0.2.234),
TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) }
Figure 1: IPv4 configuration
The IPv4 case has been implemented by various vendors, and in general
works well. IKEv2 also defines almost identical configuration
payloads for IPv6:
Eronen Expires May 11, 2008 [Page 4]
Internet-Draft IPv6 Configuration in IKEv2 November 2007
Client Gateway
-------- ---------
HDR(IKE_AUTH),
SK { IDi, CERT, [CERTREQ], AUTH, [IDr],
CP(CFG_REQUEST) =
{ INTERNAL_IP6_ADDRESS(),
INTERNAL_IP6_DNS() }, SAi2,
TSi = (0, 0-65535,
0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF),
TSr = (0,
0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) } -->
<-- HDR(IKE_AUTH),
SK { IDr, CERT, AUTH,
CP(CFG_REPLY) =
{ INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64),
INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44) },
SAr2,
TSi = (0, 0-65535,
2001:DB8:0:1:2:3:4:5 -
2001:DB8:0:1:2:3:4:5),
TSr = (0, 0-65535,
0:0:0:0:0:0:0:0: -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) }
Figure 2: IPv6 configuration
In other words, IPv6 is basically treated as IPv4 with larger
addresses. As noted in [RFC4718], this does not fully follow the
"normal IPv6 way of doing things". The IPsec tunnels are not full-
featured "interfaces" in the IPv6 addressing architecture [IPv6Addr]
sense. For example, they do not necessarily have link-local
addresses, and this may complicate the use of protocols that assume
them.
This document describes what exactly are the limitations of current
IKEv2 configuration payloads for IPv6, and explores possible
solutions that would allow IKEv2-based VPNs to set up full-featured
virtual IPv6 interfaces.
Note that while existing IPsec documents do not use the term "virtual
interface", it is not a new concept. In order to use the address
assigned by the VPN gateway, current VPN clients already create a
local "virtual interface" (as only addresses assigned to interfaces
can be used, e.g., as source addresses for TCP connections).
Eronen Expires May 11, 2008 [Page 5]
Internet-Draft IPv6 Configuration in IKEv2 November 2007
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS].
When messages containing IKEv2 payloads are described, optional
payloads are shown in brackets (for instance, "[FOO]"), and a plus
sign indicates that a payload can be repeated one or more times (for
instance, "FOO+").
Eronen Expires May 11, 2008 [Page 6]
Internet-Draft IPv6 Configuration in IKEv2 November 2007
3. Current Limitations
This section explores the limitations of the current IPv6
configuration mechanism.
The IKEv2 specification does not always fully describe the semantics
associated with configuration payloads, only their on-the-wire
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
In Figure 2 only a single IPv6 address (from a single prefix) is
assigned. The specification does allow the client to include
multiple INTERNAL_IP6_ADDRESS attributes in its request, but the
gateway cannot assign more addresses than the client requested.
Multiple prefixes are useful for site renumbering, host-based site
multihoming [SHIM6], and unique local IPv6 addresses [RFC4193]. In
all of these cases, the gateway has better information on how many
different addresses (from different prefixes) the client should be
assigned.
3.2. Link-Local Addresses
The IPv6 addressing architecture [IPv6Addr] specifies that "IPv6
addresses of all types are assigned to interfaces, not nodes. [..]
All interfaces are required to have at least one Link-Local unicast
address".
Currently, the virtual interface created by IKEv2 configuration
payloads does not have link-local addresses. This violates
[IPv6Addr] and prevents the use of protocols that require link-local
addresses, such as [MLDv2].
3.3. Receiving Multicast Traffic
Even if MLD would work, the traffic selectors negotiated in Figure 2
do not allow receiving multicast traffic.
3.4. Interface Identifier Selection
In the message exchange shown in Figure 2, the gateway chooses the
interface ID used by the client. It is also possible for the client
to request a specific interface ID; the gateway then chooses the
prefix part.
Eronen Expires May 11, 2008 [Page 7]
Internet-Draft IPv6 Configuration in IKEv2 November 2007
This approach complicates the use of Cryptographically Generates
Addresses [CGA]. With CGAs, the interface ID cannot be calculated
before the prefix is known. The client could first obtain a non-CGA
address to determine the prefix, and then send a separate CFG_REQUEST
to obtain a CGA address with the same prefix. However, this approach
requires that the IKEv2 software component provides an interface the
component managing CGAs; an ugly implementation dependency that would
be best avoided.
Similar concerns apply to other cases where the client has some
interest in what interface ID is being used, such as Hash-Based
Addresses [HBA] and privacy addresses [RFC4941].
Without CGAs and HBAs, VPN clients are not able to fully use IPv6
features such as [SHIM6] or enhanced Mobile IPv6 route optimization
[RFC4866].
3.5. Sharing VPN Access
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
local area network connection (such as Wireless LAN or Bluetooth).
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
(unless NAT is used). However, the current model where each address
is requested separately is probably complex to integrate with a local
area network that uses stateless address autoconfiguration. Thus,
obtaining a whole prefix for the VPN client, and advertising that to
the local link (something resembling [NDProxy]) would be preferable.
With DHCPv6 prefix delegation [RFC3633], even [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.
Eronen Expires May 11, 2008 [Page 8]
Internet-Draft IPv6 Configuration in IKEv2 November 2007
4. Design Goals
4.1. Main Requirements
o A VPN client can obtain a whole prefix, and use arbitrary
interface IDs without requiring IKEv2 signaling for each interface
ID.
o A VPN client can be assigned multiple prefixes for use on the
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 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 Re-authentication works: the client can start a new IKE SA and
continue using the same "virtual link" (with same addresses,
etc.).
o Compatibility with other IPsec uses: Configuring a virtual IPv6
link should not prevent the peers from using IPsec/IKEv2 for other
uses.
o Compatibility with current IPv6 configuration: Although the
current IPv6 mechanism is not widely implemented, new solutions
should not preclude its use (e.g., by defining incompatible
semantics for the existing payloads).
o Compatibility with current IPv4 configuration: it should be
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.
Eronen Expires May 11, 2008 [Page 9]
Internet-Draft IPv6 Configuration in IKEv2 November 2007
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
core IPv6 stack (typically part of the operating system), or require
the IKE implementor to re-implement parts of the IPv6 stack (to,
e.g., have access or control to functionality that is currently not
exposed by public interfaces of the IPv6 stack).
4.4. Non-Goals
Mobile IPv6 already defines how it interacts with IPsec/IKEv2
[RFC4877], and the intent of this document is not to change that
interaction in any way.
4.5. Solution Discussion
Virtual link properties
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:
* The link and its interfaces are created by IKEv2 messages, and
are destroyed once they are no longer used by any IKE SA.
* The link is not an IPsec SA; at any time, there can be zero or
more IPsec SAs covering traffic on this link.
* The link is not a single IKE SA; to support reauthentication,
it must be possible to identify the same link in another IKE
SA.
* 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.)
Eronen Expires May 11, 2008 [Page 10]
Internet-Draft IPv6 Configuration in IKEv2 November 2007
* 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).
Link model and Duplicate Address Detection
The ability to use arbitrary interface IDs without IKEv2
signalling or Duplicate Address Detection implies a point-to-point
link model [Multilink]. In other words, the connection between
the client and the VPN gateway is treated as a virtual point-to-
point link, and prefixes assigned to this link are not shared with
any other link (other VPN clients connected to the same gateway).
It is also required that the VPN gateway does not configure any
addresses from the assigned prefixes for itself (as is done in
[IPv6PPP]).
Prefix assignment
Prefixes could be assigned either using IKEv2 messages, by Router
Advertisements sent inside the tunnel, or by DHCPv6 messages sent
inside the tunnel (cf. [RFC3456]). Any of these approaches would
work; all have some advantages. Currently, Section 5 proposes
using IKEv2 messages.
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 5 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
introduce add or remove prefixes by triggering reauthentication.
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 that remains assigned to the link
for its entire lifetime. Currently, Section 5 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
Eronen Expires May 11, 2008 [Page 11]
Internet-Draft IPv6 Configuration in IKEv2 November 2007
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]).
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 5 proposes including the
virtual link identifier in all CREATE_CHILD_SA requests that apply
to the virtual interface.
4.6. 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 create 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.
Eronen Expires May 11, 2008 [Page 12]
Internet-Draft IPv6 Configuration in IKEv2 November 2007
5. Solution Sketch
(Second preliminary version, based on discussions with Tero Kivinen.)
5.1. Initial Exchanges
1) During IKE_AUTH, the client sends a new configuration attribute,
INTERNAL_IP6_LINK, which requests a virtual link to be created. The
attribute contains the client's interface ID for link-local address
(other addresses may use other interface IDs). Typically, the client
would also ask for DHCPv6 server address; this is used only for
configuration, not address assignment.
CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID)
INTERNAL_IP6_DHCP() }
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) -->
The 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
used for reauthentication and CREATE_CHILD_SA messages), and zero or
more INTERNAL_IP6_PREFIX attributes. The traffic selectors proposed
by the initiator are also narrowed to contain only the assigned
prefixes (and the link-local prefix).
CP(CFG_REPLY) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID),
INTERNAL_IP6_PREFIX(Prefix1/64),
[INTERNAL_IP6_PREFIX(Prefix2/64),...],
INTERNAL_IP6_DHCP(Address) ]
TSi = ((0, 0-65535,
FE80::<Client's Interface ID> -
FE80::<Client's Interface ID>)
(0, 0-65535,
Prefix1::0 -
Prefix1::FFFF:FFFF:FFFF:FFFF),
[(0, 0-65535,
Prefix2::0 -
Prefix2::FFFF:FFFF:FFFF:FFFF), ...])
TSr = (0, 0-65535,
0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
(To be determined: is it necessary to include the gateway's link-
local interface ID? Probably the client does not need it.)
Eronen Expires May 11, 2008 [Page 13]
Internet-Draft IPv6 Configuration in IKEv2 November 2007
At this point, the client can configure unicast addresses from the
assigned prefixes, using any interface ID. The VPN gateway MUST NOT
simultaneously assign the same prefixes to any other client, and MUST
NOT itself configure addresses from these prefixes. Thus, the client
does not have to perform Duplicate Address Detection (DAD).
The prefixes remain valid through the lifetime of the IKE SA (and its
continuations via rekeying).
2) The client also contacts the DHCPv6 server. This is the
RECOMMENDED way to obtain additional configuration parameters (such
as the DNS server), as it allows easier extensibility and more
options (such as the domain search list for DNS).
5.2. Reauthentication
When the client performs reauthentication (and wants to continue
using the same "virtual link"), it includes the IKEv2 Link ID given
by the gateway in the INTERNAL_IP6_LINK attribute.
CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK(Link-Local Interface ID, IKEv2 Link ID)
INTERNAL_IP6_DHCP() }
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) -->
The gateway uses the Link ID to look up relevant local state,
verifies that the authenticated peer identity associated with the
link is correct, and continues the handshake as usual.
5.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 that are related to the virtual link.
5.4. Multicast
(The details of multicast use are to-be-determined.)O
One way would be to create an SA for receiving multicast packets:
Eronen Expires May 11, 2008 [Page 14]
Internet-Draft IPv6 Configuration in IKEv2 November 2007
TSi = (0, 0-65535,
FF00:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535,
0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) -->
<--
TSi = (0, 0-65535,
FF00:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535,
0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
...and then use MLD as usual.
5.5. Relationship to Neighbor Discovery
Neighbor Discovery [IPv6ND] specifies the following mechanisms:
Router Discovery, Prefix Discovery, Parameter Discovery,and Address
Autoconfiguration are not used, as the necessary functionality is
implemented in IKEv2 layer.
Address Resolution, Next-hop Determination, and Redirect are not
used, as the virtual link does not have link-local addresses, and is
a point-to-point link.
Neighbor Unreachability Detection could be used, but is a bit
redundant given IKEv2 Dead Peer Detection.
Duplicate Address Detection is not needed, because this is a point-
to-point link, where the VPN gateway does not assign any addresses
from the global unicast prefixes, and link-local interface ID is
negotiated separately.
5.6. Relationship to Existing IKEv2 Payloads
The mechanism described in this document is not intended to be used
at the same time as the existing INTERNAL_IP6_ADDRESS attribute. For
compatibility with gateways implementing only INTERNAL_IP6_ADDRESS,
the VPN client MAY include attributes for both mechanisms in
CFG_REQUEST. The capabilities and preferences of the VPN gateway
will then determine which is used.
All other attributes except INTERNAL_IP6_ADDRESS (and
INTENAL_ADDRESS_EXPIRY) from [IKEv2] remain valid, including the
Eronen Expires May 11, 2008 [Page 15]
Internet-Draft IPv6 Configuration in IKEv2 November 2007
somewhat confusingly named INTERNAL_IP6_SUBNET (see Section 6.3 of
[RFC4718] for discussion).
Eronen Expires May 11, 2008 [Page 16]
Internet-Draft IPv6 Configuration in IKEv2 November 2007
6. Payload Formats
6.1. INTERNAL_IP6_LINK Configuration Attribute
The INTERNAL_IP6_LINK configuration attribute is formatted as
follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!R| Attribute Type ! Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link-Local |
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ IKEv2 Link ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Reserved (1 bit) - See [IKEv2].
o Attribute Type (15 bits) - INTERNAL_IP6_LINK (TBD1).
o Length (2 octets) - Length in octets of the Value field (Link-
Local Interface ID and IKEv2 Link ID); 8 or more.
o Link-Local Interface ID (8 octets) - The Interface ID used for
link-local address (by the party that sent this attribute).
o IKEv2 Link ID (variable length) - The link ID (may be empty when
the client does not yet know the link ID).
6.2. INTERNAL_IP6_PREFIX Configuration Attribute
The INTERNAL_IP6_PREFIX configuration attribute is formatted as
follows:
Eronen Expires May 11, 2008 [Page 17]
Internet-Draft IPv6 Configuration in IKEv2 November 2007
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!R| Attribute Type ! Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Prefix |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length |
+-+-+-+-+-+-+-+-+
o Reserved (1 bit) - See [IKEv2].
o Attribute Type (15 bits) - INTERNAL_IP6_PREFIX (TBD2).
o Length (2 octets) - Length in octets of the Value field; in this
case, 17.
o Prefix (16 octets) - An IPv6 prefix assigned to the virtual link.
o Prefix Length (1 octets) - The length of the prefix in bits;
(almost) always 64.
6.3. LINK_ID Notify Payload
The LINK_ID notification is included in CREATE_CHILD_SA requests to
indicate that the SA being created is related to the virtual link.
If this notification is not included, the CREATE_CHILD_SA requests is
related to the physical interface.
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
notification is the IKEv2 Link ID returned in the INTERNAL_IP6_LINK
configuration attribute.
Eronen Expires May 11, 2008 [Page 18]
Internet-Draft IPv6 Configuration in IKEv2 November 2007
7. IANA Considerations
This document defines two new IKEv2 configuration attributes, whose
values are to be allocated (have been allocated) from the "IKEv2
Configuration Payload Attribute Types" namespace [IKEv2]:
Multi-
Value Attribute Type Valued Length Reference
------ ---------------------- ------ -------------- ---------
TBD1 INTERNAL_IP6_LINK NO 8 or more [this doc]
TBD2 INTERNAL_IP6_PREFIX YES 17 octets [this doc]
This document also defines one new IKEv2 notification, whose value is
to be allocated (has been allocated) from the "IKEv2 Notify Message
Types" namespace [IKEv2]:
Value Notify Messages - Status Types Reference
------ ------------------------------- ---------
TBD3 LINK_ID [this doc]
This document does not create any new namespaces to be maintained by
IANA.
Eronen Expires May 11, 2008 [Page 19]
Internet-Draft IPv6 Configuration in IKEv2 November 2007
8. 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
interface identifiers [RFC4941] ineffective from privacy point of
view: the client is still uniquely identified by the prefix. In some
environments, it may be preferable to assign a VPN client the same
prefixes each time a VPN connection is established; other
environments may prefer assigning a different prefix every for
privacy reasons. (This is basically a similar trade-off as in Mobile
IPv6 -- using the same Home Address forever is simpler than changing
it often, but has privacy implications.)
Eronen Expires May 11, 2008 [Page 20]
Internet-Draft IPv6 Configuration in IKEv2 November 2007
9. Acknowledgments
The author would like to thank Patrick Irwin, Tero Kivinen, Chinh
Nguyen, Mohan Parthasarathy, and Yaron Sheffer for their valuable
comments.
Many of the challenges associated with IPsec-protected "virtual
interfaces" have been identified before: for example, in the context
of protecting IPv6-in-IPv4 tunnels with IPsec [RFC4891], Provider
Provisioned VPNs [VLINK] [RFC3884], and Mobile IPv6 [RFC4877]. Some
of the limitations of assigning a single IPv6 address were identified
in [RFC3314].
Eronen Expires May 11, 2008 [Page 21]
Internet-Draft IPv6 Configuration in IKEv2 November 2007
10. References
10.1. Normative References
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[IPv6Addr]
Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[KEYWORDS]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
10.2. Informative References
[AUTOCONF]
Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[CGA] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2006.
[DHCPv6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[HBA] Bagnulo, M., "Hash Based Addresses (HBA)",
draft-ietf-shim6-hba-03 (work in progress), June 2007.
[IPConfig]
Aboba, B., Thaler, D., and L. Andersson, "Principles of
Internet Host Configuration", draft-iab-ip-config-00 (work
in progress), October 2007.
[IPv6ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[IPv6PPP] Varada, S., Haskins, D., and E. Allen, "IP Version 6 over
PPP", RFC 5072, September 2007.
[MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[MOBIKE] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006.
Eronen Expires May 11, 2008 [Page 22]
Internet-Draft IPv6 Configuration in IKEv2 November 2007
[Multilink]
Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
June 2007.
[NDProxy] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
Generation Partnership Project 3GPP) Standards", RFC 3314,
September 2002.
[RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic
Host Configuration Protocol (DHCPv4) Configuration of
IPsec Tunnel Mode", RFC 3456, January 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec
Transport Mode for Dynamic Routing", RFC 3884,
September 2004.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
Implementation Guidelines", RFC 4718, October 2006.
[RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
Optimization for Mobile IPv6", RFC 4193, May 2007.
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877,
April 2007.
[RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H.
Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels",
RFC 4891, May 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
[SHIM6] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", draft-ietf-shim6-proto-09 (work
in progress), October 2007.
Eronen Expires May 11, 2008 [Page 23]
Internet-Draft IPv6 Configuration in IKEv2 November 2007
[VLINK] Duffy, M., "Framework for IPsec Protected Virtual Links
for PPVPNs", draft-duffy-ppvpn-ipsec-vlink-00 (work in
progress), October 2002.
Eronen Expires May 11, 2008 [Page 24]
Internet-Draft IPv6 Configuration in IKEv2 November 2007
Appendix A. First sketch
The -00 version of this draft contained the following solution
sketch, where address assignment is done with Neighbor Discovery,
instead of IKEv2 payloads.
This was changed based on feedback from VPN vendors: while the
solution looks nice on paper, it is claimed to be unneccessarily
complex to implement when the IKE implementation and IPv6 stack are
from different companies.
1) During IKE_AUTH, client sends a new Configuration Payload,
INTERNAL_IP6_LINK that contains the Interface ID it will use
for the link-local address (other addresses may use other
Interface IDs).
CP(CFG_REQUEST) =
{ INTERNAL_IP6_LINK(client_link_local_interface_id) }
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) -->
The gateway replies with its own Interface ID for link-local address,
and a new identifier for the virtual link.
CP(CFG_REPLY) =
{ INTERNAL_IP6_LINK(link_id, gateway_link_local_interface_id) }
TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 -
FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
At this point, both peers configure the virtual interface with the
link-local addresses. (This step is pretty much based on [IPv6PPP])
2) The next step is unicast prefix configuration; this is
simply RS/RA sent over the IPsec SA (possibly followed by DHCPv6
if RA had the M flag set).
3) Creating and rekeying IPsec SAs: exchange initiator includes
N(LINK_ID) notification in the CREATE_CHILD_SA request.
The notification data contains the link_id.
4) Reauthentication: when creating a new IKE_SA, client includes
the link_id in INTERNAL_IP6_LINK CFG_REQUEST.
Eronen Expires May 11, 2008 [Page 25]
Internet-Draft IPv6 Configuration in IKEv2 November 2007
Author's Address
Pasi Eronen
Nokia Research Center
P.O. Box 407
FIN-00045 Nokia Group
Finland
Email: pasi.eronen@nokia.com
Eronen Expires May 11, 2008 [Page 26]
Internet-Draft IPv6 Configuration in IKEv2 November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Eronen Expires May 11, 2008 [Page 27]