draft-ietf-v6ops-ipsec-tunnels-03.txt   draft-ietf-v6ops-ipsec-tunnels-04.txt 
IPv6 Operations WG R. Graveman IPv6 Operations WG R. Graveman
Internet-Draft RFG Security, LLC Internet-Draft RFG Security, LLC
Intended status: Informational M. Parthasarathy Intended status: Informational M. Parthasarathy
Expires: April 12, 2007 Nokia Expires: May 25, 2007 Nokia
P. Savola P. Savola
CSC/FUNET CSC/FUNET
H. Tschofenig H. Tschofenig
Siemens Siemens
October 9, 2006 November 21, 2006
Using IPsec to Secure IPv6-in-IPv4 Tunnels Using IPsec to Secure IPv6-in-IPv4 Tunnels
draft-ietf-v6ops-ipsec-tunnels-03.txt draft-ietf-v6ops-ipsec-tunnels-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. 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
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 April 12, 2007. This Internet-Draft will expire on May 25, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2006).
Abstract Abstract
This document gives guidance on securing manually configured IPv6-in- This document gives guidance on securing manually configured IPv6-in-
IPv4 tunnels using IPsec. No additional protocol extensions are IPv4 tunnels using IPsec. No additional protocol extensions are
described beyond those available with the IPsec framework. described beyond those available with the IPsec framework.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 3, line 24 skipping to change at page 3, line 24
The document was intentionally not expanded to include the details on The document was intentionally not expanded to include the details on
how to set up an IPsec-protected tunnel in an interoperable manner, how to set up an IPsec-protected tunnel in an interoperable manner,
but instead the details were deferred to this memo. but instead the details were deferred to this memo.
First four sections of this document analyse the threats and First four sections of this document analyse the threats and
scenarios that can be addressed by IPsec and assumptions made by this scenarios that can be addressed by IPsec and assumptions made by this
document for successful IPsec Security Association (SA) document for successful IPsec Security Association (SA)
establishment. Section 5 gives the details of Internet Key Exchange establishment. Section 5 gives the details of Internet Key Exchange
(IKE) and IP security (IPsec) exchange with packet formats and (IKE) and IP security (IPsec) exchange with packet formats and
Security Policy Database (SPD) entries. Section 6 gives Security Policy Database (SPD) entries. Section 6 gives
recommendations. Appendices further discuss Tunnel mode usage and recommendations. Appendices further discuss tunnel mode usage and
optional extensions. optional extensions.
This document does not address the use of IPsec for tunnels that are This document does not address the use of IPsec for tunnels that are
not manually configured (e.g., 6to4 tunnels [RFC3056]). Presumably, not manually configured (e.g., 6to4 tunnels [RFC3056]). Presumably,
some form of opportunistic encryption or "better-than-nothing some form of opportunistic encryption or "better-than-nothing
security" might or might not be applicable. Similarly, propagating security" might or might not be applicable. Similarly, propagating
quality of service attributes (apart from Explicit Congestion quality of service attributes (apart from Explicit Congestion
Notification (ECN) bits [RFC4213]) from the encapsulated packets to Notification bits [RFC4213]) from the encapsulated packets to the
the tunnel path is out of scope. tunnel path is out of scope.
2. Threats and the Use of IPsec 2. Threats and the Use of IPsec
[RFC4213] is mostly concerned about address spoofing threats: [RFC4213] is mostly concerned about address spoofing threats:
1. IPv4 address of the encapsulating ("outer") packet can be 1. The IPv4 source address of the encapsulating ("outer") packet can
spoofed. be spoofed.
2. IPv6 address of the encapsulated ("inner") packet can be spoofed. 2. The IPv6 source address of the encapsulated ("inner") packet can
be spoofed.
IPsec can obviously also provide payload integrity and IPsec can obviously also provide payload integrity, replay detection,
confidentiality as well for the part of the end-to-end path that is and confidentiality as well for the part of the end-to-end path that
tunneled. is tunneled.
The reason for threat (1) is the lack of widespread deployment of The reason threat (1) exists is the lack of widespread deployment of
IPv4 ingress filtering [RFC3704]. The reason for threat (2) is that IPv4 ingress filtering [RFC3704]. The reason threat (2) exists is
the IPv6 packet is encapsulated in IPv4 and hence may escape IPv6 that the IPv6 packet is encapsulated in IPv4 and hence may escape
ingress filtering. [RFC4213] specifies the following strict address IPv6 ingress filtering. [RFC4213] specifies the following strict
checks as mitigating measures: address checks as mitigating measures:
o To mitigate threat (1), the decapsulator verifies that the IPv4 o To mitigate threat (1), the decapsulator verifies that the IPv4
source address of the packet is the same as the address of the source address of the packet is the same as the address of the
configured tunnel endpoint. The decapsulator may also implement configured tunnel endpoint. The decapsulator may also implement
IPv4 ingress filtering, i.e., check whether the packet is received IPv4 ingress filtering, i.e., check whether the packet is received
on a legitimate interface. on a legitimate interface.
o To mitigate threat (2), the decapsulator verifies whether the o To mitigate threat (2), the decapsulator verifies whether the
inner IPv6 address is a valid IPv6 address and also applies IPv6 inner IPv6 address is a valid IPv6 address and also applies IPv6
ingress filtering before accepting the IPv6 packet. ingress filtering before accepting the IPv6 packet.
This memo proposes using IPsec for providing stronger security in This memo proposes using IPsec for providing stronger security in
preventing these threats and additionally providing integrity and preventing these threats and additionally providing integrity and
confidentiality. confidentiality.
IPsec can be used in two ways, in transport and tunnel mode; detailed IPsec can be used in two ways, in transport and tunnel mode; detailed
discussion about applicability in this context is described in discussion about applicability in this context is provided in
Section 5. Section 5.
2.1. IPsec in Transport Mode 2.1. IPsec in Transport Mode
In transport mode, the IPsec security association (SA) is established In transport mode, the IPsec Encapsulating Security Payload (ESP) or
Authentication Header (AH) security association (SA) is established
to protect the traffic defined by (IPv4-source, IPv4-dest, protocol = to protect the traffic defined by (IPv4-source, IPv4-dest, protocol =
41). On receiving such an IPsec packet, the receiver first applies 41). On receiving such an IPsec packet, the receiver first applies
the IPsec transform (e.g., ESP) and then matches the packet against the IPsec transform (e.g., ESP) and then matches the packet against
the Security Parameter Index (SPI) and the inbound selectors the Security Parameter Index (SPI) and the inbound selectors
associated with the SA to verify that the packet is appropriate for associated with the SA to verify that the packet is appropriate for
the SA via which it was received. A successful verification implies the SA via which it was received. A successful verification implies
that the packet came from the right IPv4 endpoint as the SA is bound that the packet came from the right IPv4 endpoint, because the SA is
to the IPv4 source address. bound to the IPv4 source address.
This prevents threat (1) but not the threat (2). IPsec in transport This prevents threat (1) but not the threat (2). IPsec in transport
mode does not verify the contents of the payload itself where the mode does not verify the contents of the payload itself where the
IPv6 addresses are carried, that is, two nodes that are using IPsec IPv6 addresses are carried. That is, two nodes using IPsec transport
transport mode to secure the tunnel can spoof the inner payload. The mode to secure the tunnel can spoof the inner payload. The packet
packet will be decapsulated successfully and accepted. will be decapsulated successfully and accepted.
The shortcoming can be mitigated by IPv6 ingress filtering i.e., This shortcoming can be partially mitigated by IPv6 ingress filtering
check that the packet is arriving from the interface in the direction i.e., check that the packet is arriving from the interface in the
of the route towards the tunnel end-point, similar to a Strict direction of the route towards the tunnel end-point, similar to a
Reverse Path Forwarding (RPF) check [RFC3704]. Strict Reverse Path Forwarding (RPF) check [RFC3704].
In most implementations, a transport mode SA is applied to a normal In most implementations, a transport mode SA is applied to a normal
IPv6-in-IPv4 tunnel. Therefore, ingress filtering can be applied in IPv6-in-IPv4 tunnel. Therefore, ingress filtering can be applied in
the tunnel interface. (Transport mode is often also used in other the tunnel interface. (Transport mode is often also used in other
kind of tunnels such as GRE and L2TP.) kind of tunnels such as GRE [RFC4023] and L2TP [RFC3193].)
2.2. IPsec in Tunnel Mode 2.2. IPsec in Tunnel Mode
In tunnel mode, the IPsec SA is established to protect the traffic In tunnel mode, the IPsec SA is established to protect the traffic
defined by (IPv6-source, IPv6-destination). On receiving such an defined by (IPv6-source, IPv6-destination). On receiving such an
IPsec packet, the receiver first applies the IPsec transform (e.g., IPsec packet, the receiver first applies the IPsec transform (e.g.,
ESP) and then matches the packet against the SPI and the inbound ESP) and then matches the packet against the SPI and the inbound
selectors associated with the SA to verify that the packet is selectors associated with the SA to verify that the packet is
appropriate for the SA via which it was received. The successful appropriate for the SA via which it was received. The successful
verification implies that the packet came from the right endpoint. verification implies that the packet came from the right endpoint.
The outer IPv4 addresses may be spoofed and IPsec cannot detect it in The outer IPv4 addresses may be spoofed and IPsec cannot detect this
this mode; the packets will be demultiplexed based on the SPI and in tunnel mode; the packets will be demultiplexed based on the SPI
possibly the IPv6 address bound to the SA. Thus, the outer address and possibly the IPv6 address bound to the SA. Thus, the outer
spoofing is irrelevant as long as the decryption succeeds and the address spoofing is irrelevant as long as the decryption succeeds and
inner IPv6 packet can be verified to come from the right tunnel the inner IPv6 packet can be verified to come from the right tunnel
endpoint. endpoint.
As described in Section 5.2, using tunnel mode is more difficult than As described in Section 5.2, using tunnel mode is more difficult than
applying transport mode to a tunnel interface, and as a result this applying transport mode to a tunnel interface, and as a result this
document recommends transport mode. document recommends transport mode. Note that even though transport
rather than tunnel mode is recommended, an IPv6-in-IPv4 tunnel
specified by Protocol 41 still exists.
3. Scenarios and Overview 3. Scenarios and Overview
There are roughly three kinds of scenarios: There are roughly three scenarios:
1. (generic) router-to-router tunnels. 1. (generic) router-to-router tunnels.
2. site-to-router/router-to-site tunnels. This refers to a tunnel 2. site-to-router or router-to-site tunnels. These refer to tunnels
between a site's IPv6 (border) device to an IPv6 upstream between a site's IPv6 (border) device and an IPv6 upstream
provider's router. A degenerate case of a site is a single host. provider's router. A degenerate case of a site is a single host.
3. Host-to-host tunnels. 3. Host-to-host tunnels.
3.1. Router-to-Router Tunnels 3.1. Router-to-Router Tunnels
IPv6/IPv4 hosts and routers can tunnel IPv6 datagrams over regions of IPv6/IPv4 hosts and routers can tunnel IPv6 datagrams over regions of
IPv4 routing topology by encapsulating them within IPv4 packets. IPv4 forwarding topology by encapsulating them within IPv4 packets.
Tunneling can be used in a variety of ways. Tunneling can be used in a variety of ways.
.--------. _----_ .--------. .--------. _----_ .--------.
|v6-in-v4| _( IPv4 )_ |v6-in-v4| |v6-in-v4| _( IPv4 )_ |v6-in-v4|
| Router | <======( Internet )=====> | Router | | Router | <======( Internet )=====> | Router |
| A | (_ _) | B | | A | (_ _) | B |
'--------' '----' '--------' '--------' '----' '--------'
^ IPsec tunnel between ^ ^ IPsec tunnel between ^
| Router A and Router B | | Router A and Router B |
V V V V
Figure 1: Router-to-Router Scenario Figure 1: Router-to-Router Scenario.
IPv6/IPv4 routers interconnected by an IPv4 infrastructure can tunnel IPv6/IPv4 routers interconnected by an IPv4 infrastructure can tunnel
IPv6 packets between themselves. In this case, the tunnel spans one IPv6 packets between themselves. In this case, the tunnel spans one
segment of the end-to-end path that the IPv6 packet takes. segment of the end-to-end path that the IPv6 packet takes.
The source and destination addresses of the IPv6 packets traversing The source and destination addresses of the IPv6 packets traversing
the tunnel could come from a wide range of IPv6 prefixes, so binding the tunnel could come from a wide range of IPv6 prefixes, so binding
IPv6 addresses to be used to the SA is not feasible. IPv6 ingress IPv6 addresses to be used to the SA is not generally feasible. IPv6
filtering must be performed to mitigate the IPv6 address spoofing ingress filtering must be performed to mitigate the IPv6 address
threat. spoofing threat.
A specific case of router-to-router tunnels, when one router resides A specific case of router-to-router tunnels, when one router resides
at an end site, is described in the next section. at an end site, is described in the next section.
3.2. Site-to-Router/Router-to-Site Tunnels 3.2. Site-to-Router/Router-to-Site Tunnels
This is a generalization of host-to-router and router-to-host This is a generalization of host-to-router and router-to-host
tunneling, because the issues when connecting a whole site (using a tunneling, because the issues when connecting a whole site (using a
router), and connecting a single host are roughly equal. router), and connecting a single host are roughly equal.
skipping to change at page 6, line 49 skipping to change at page 6, line 49
'----' '---------' '----' '----' '---------' '----'
^ ^
| |
V V
.--------. .--------.
| Native | | Native |
| IPv6 | | IPv6 |
| node | | node |
'--------' '--------'
Figure 2: Router-to-Site Scenario Figure 2: Router-to-Site Scenario.
IPv6/IPv4 routers can tunnel IPv6 packets to their final destination IPv6/IPv4 routers can tunnel IPv6 packets to their final destination
IPv6/IPv4 site. This tunnel spans only the last segment of the end- IPv6/IPv4 site. This tunnel spans only the last segment of the end-
to-end path. to-end path.
+---------------------+ +---------------------+
| IPv6 Network | | IPv6 Network |
| | | |
.--------. _----_ | .--------. | .--------. _----_ | .--------. |
| V6/V4 | _( IPv4 )_ | |v6-in-v4| | | V6/V4 | _( IPv4 )_ | |v6-in-v4| |
skipping to change at page 7, line 23 skipping to change at page 7, line 23
'----' | '--------' | '----' | '--------' |
IPsec tunnel between | ^ | IPsec tunnel between | ^ |
IPv6 Site and Router A | | | IPv6 Site and Router A | | |
| V | | V |
| .-------. | | .-------. |
| | V6 | | | | V6 | |
| | Hosts | | | | Hosts | |
| '--------' | | '--------' |
+---------------------+ +---------------------+
Figure 3: Site-to-Router Scenario Figure 3: Site-to-Router Scenario.
Respectively, IPv6/IPv4 hosts can tunnel IPv6 packets to an In the other direction, IPv6/IPv4 hosts can tunnel IPv6 packets to an
intermediary IPv6/IPv4 router that is reachable via an IPv4 intermediary IPv6/IPv4 router that is reachable via an IPv4
infrastructure. This type of tunnel spans the first segment of the infrastructure. This type of tunnel spans the first segment of the
packet's end-to-end path. packet's end-to-end path.
The hosts in the site originate the packets with source addresses The hosts in the site originate the packets with IPv6 source
coming from a well known prefix whereas the destination address could addresses coming from a well known prefix, whereas the destination
be any node on the Internet. addresses could be any nodes on the Internet.
In this case, the IPsec tunnel mode SA could be bound to the prefix In this case, an IPsec tunnel mode SA could be bound to the prefix
that was allocated to the router at Site B and router A could verify that was allocated to the router at Site B, and router A could verify
that the source address of the packet matches the prefix. Site B that the source address of the packet matches the prefix. Site B
will not be able to do a similar verification for the packets it will not be able to do a similar verification for the packets it
receives. This may be quite reasonable for most of the deployment receives. This may be quite reasonable for most of the deployment
cases, for example, the Internet Service Provider (ISP) allocating a cases, for example, an Internet Service Provider (ISP) allocating a
/48 to a customer. The Customer Premises Equipment (CPE) where the /48 to a customer. The Customer Premises Equipment (CPE) where the
tunnel is terminated "trusts" (in a weak sense) the ISP's router and tunnel is terminated "trusts" (in a weak sense) the ISP's router, and
the ISP's router can verify that the Site B is the only one that can the ISP's router can verify that Site B is the only one that can
originate packets within the /48. originate packets within the /48.
IPv6 spoofing must be prevented, and setting up ingress filtering may IPv6 spoofing must be prevented, and setting up ingress filtering may
require some amount of manual configuration; see more of these require some amount of manual configuration; see more of these
options in Section 5. options in Section 5.
3.3. Host-to-Host Tunnels 3.3. Host-to-Host Tunnels
.--------. _----_ .--------. .--------. _----_ .--------.
| V6/V4 | _( IPv4 )_ | V6/V4 | | V6/V4 | _( IPv4 )_ | V6/V4 |
| Host | <======( Internet )=====> | Host | | Host | <======( Internet )=====> | Host |
| A | (_ _) | B | | A | (_ _) | B |
'--------' '----' '--------' '--------' '----' '--------'
IPsec tunnel between IPsec tunnel between
Host A and Host B Host A and Host B
Figure 4: Host-to-Host Scenario Figure 4: Host-to-Host Scenario.
IPv6/IPv4 hosts that are interconnected by an IPv4 infrastructure can IPv6/IPv4 hosts interconnected by an IPv4 infrastructure can tunnel
tunnel IPv6 packets between themselves. In this case, the tunnel IPv6 packets between themselves. In this case, the tunnel spans the
spans the entire end-to-end path that the packet takes. entire end-to-end path.
In this case, the source and the destination IPv6 address are known a In this case, the source and the destination IPv6 addresses are known
priori. A tunnel mode SA could be bound to the specific address. a priori. A tunnel mode SA could be bound to these specific
The address verification prevents IPv6 address spoofing completely. addresses. Address verification prevents IPv6 source address
spoofing completely.
As noted in the Introduction, automatic host-to-host tunneling As noted in the Introduction, automatic host-to-host tunneling
methods (e.g., 6to4) are out of scope of this memo. methods (e.g., 6to4) are out of scope for this memo.
4. IKE and IPsec Versions 4. IKE and IPsec Versions
This section discusses the different versions of the IKE and IPsec This section discusses the different versions of the IKE and IPsec
security architecture and their applicability to this document. security architecture and their applicability to this document.
The IPsec security architecture was originally defined in [RFC2401] The IPsec security architecture was previously defined in [RFC2401]
and now superseded by [RFC4301]. IKE was originally defined in and is now superseded by [RFC4301]. IKE was originally defined in
[RFC2409] (which is referred to as IKEv1 in this document) and is now [RFC2409] (which is called as IKEv1 in this document) and is now
superseded by [RFC4306] (referred to as IKEv2). There are several superseded by [RFC4306] (called IKEv2; see also [RFC4718]). There
differences between them. The differences relevant to this document are several differences between them. The differences relevant to
are discussed below. this document are discussed below.
1. [RFC2401] does not allow IP as the next layer protocol in traffic 1. [RFC2401] does not allow IP as the next layer protocol in traffic
selectors when an IPsec SA is negotiated. [RFC4301] also allows selectors when an IPsec SA is negotiated. [RFC4301] also allows
IP as the next layer protocol like TCP or UDP in traffic IP as the next layer protocol (like TCP or UDP) in traffic
selectors. selectors.
2. [RFC4301] assumes IKEv2, as some of the new features cannot be 2. [RFC4301] assumes IKEv2, as some of the new features cannot be
negotiated using IKEv1. It is valid to negotiate multiple negotiated using IKEv1. It is valid to negotiate multiple
traffic selectors for a given IPsec SA in [RFC4301]. This is traffic selectors for a given IPsec SA in [RFC4301]. This is
possible only with [RFC4306]. If [RFC2409] is used, then possible only with [RFC4306]. If [RFC2409] is used, then
multiple SAs need to be set up for each traffic selector. multiple SAs need to be set up for each traffic selector.
Note that the existing implementations based on [RFC2409] may already Note that the existing implementations based on [RFC2409] may already
be able to support the [RFC4301] features described in (1) and (2). be able to support the [RFC4301] features described in (1) and (2).
If appropriate, the deployment may choose to use the two versions of If appropriate, the deployment may choose to use either version of
the security architecture. the security architecture.
IKEv2 supports features that are useful for configuring and securing IKEv2 supports features useful for configuring and securing tunnels
tunnels that are not present with IKEv1. not present with IKEv1.
1. IKEv2 supports legacy authentication methods by carrying them in 1. IKEv2 supports legacy authentication methods by carrying them in
EAP payloads. This can be used to authenticate the hosts/sites EAP payloads. This can be used to authenticate hosts or sites to
to the ISP using EAP methods that support username and password. an ISP using EAP methods that support username and password.
2. IKEv2 supports dynamic address configuration which may be used to 2. IKEv2 supports dynamic address configuration, which may be used
configure the IPv6 address of the host. to configure the IPv6 address of the host.
NAT traversal works with both the old and revised IPsec NAT traversal works with both the old and revised IPsec
architectures, but the negotiation is integrated with IKEv2. architectures, but the negotiation is integrated with IKEv2.
For the purposes of this document, where the confidentiality of ESP For the purposes of this document, where the confidentiality of ESP
is not required, Authentication Header (AH) [RFC4302] can be used [RFC4303] is not required, AH [RFC4302] can be used as an alternative
interchangeably. The main difference is that AH is able to provide to ESP. The main difference is that AH is able to provide integrity
integrity-protection for certain fields in the outer IP header and IP protection for certain fields in the outer IPv4 header and IPv4
options. However, as the outer IP header will be discarded in any options. However, as the outer IPv4 header will be discarded in any
case and those particular fields are not believed to be relevant in case, and those particular fields are not believed to be relevant in
this particular application, there is no particular reason to use AH. this particular application, there is no particular reason to use AH.
5. IPsec Configuration Details 5. IPsec Configuration Details
This section describes details about the establishment of an IPsec This section describes details about establishing an IPsec tunnel for
tunnel for the protection of IPv4/IPv6 data traffic. However, first the protection of IPv4/IPv6 data traffic.
we will take a look at the packet format on the wire.
The packet format is the same for both transport mode and tunnel mode The packet format is the same for both transport mode and tunnel mode
as shown in Table 1. as shown in Table 1.
+----------------------------+------------------------------------+ +----------------------------+------------------------------------+
| Components (first to last) | Contains | | Components (first to last) | Contains |
+----------------------------+------------------------------------+ +----------------------------+------------------------------------+
| IPv4 header | (src = IPV4-TEP1, dst = IPV4-TEP2) | | IPv4 header | (src = IPV4-TEP1, dst = IPV4-TEP2) |
| ESP header | | | ESP header | |
| IPv6 header | (src = IPV6-EP1, dst = IPV6-EP2) | | IPv6 header | (src = IPV6-EP1, dst = IPV6-EP2) |
| (payload) | | | (payload) | |
+----------------------------+------------------------------------+ +----------------------------+------------------------------------+
Table 1 Table 1: Packet Format for IPv6/IPv4 Tunnels.
5.1. IPsec Transport Mode 5.1. IPsec Transport Mode
The transport mode has typically been applied to L2TP, GRE, and other Transport mode has typically been applied to L2TP, GRE, and other
kind of tunneling methods, especially when the user wants to tunnel tunneling methods, especially when the user wants to tunnel non-IP
non-IP traffic. [RFC3884], [RFC3193], and [RFC4023] provide examples traffic. [RFC3884], [RFC3193], and [RFC4023] provide examples of
of applying transport mode to protect tunnel traffic that spans only applying transport mode to protect tunnel traffic that spans only a
a part of an end-to-end path. part of an end-to-end path.
IPv6 ingress filtering must be applied on the tunnel interface on all IPv6 ingress filtering must be applied on the tunnel interface on all
the packets that pass the inbound IPsec processing. the packets that pass the inbound IPsec processing.
The following SPD entries assume that there are two routers Router1 The following SPD entries assume that there are two routers, Router1
and Router2, with tunnel endpoint IPv4 addresses denoted by IPV4-TEP1 and Router2, with tunnel endpoint IPv4 addresses denoted IPV4-TEP1
and IPV4-TEP2 respectively. (In other scenarios, the SPDs are set up and IPV4-TEP2, respectively. (In other scenarios, the SPDs are set
in a similar fashion.) up similarly.)
Router1's SPD: Router1's SPD:
Next Layer Next Layer
Rule Local Remote Protocol Action Rule Local Remote Protocol Action
---- ----- ------ ---------- -------- ---- ----- ------ ---------- --------
1 IPV4-TEP1 IPV4-TEP2 ESP BYPASS 1 IPV4-TEP1 IPV4-TEP2 ESP BYPASS
2 IPV4-TEP1 IPV4-TEP2 IKE BYPASS 2 IPV4-TEP1 IPV4-TEP2 IKE BYPASS
3 IPv4-TEP1 IPV4-TEP2 41 PROTECT(ESP,transport) 3 IPv4-TEP1 IPV4-TEP2 41 PROTECT(ESP,transport)
Router2's SPD: Router2's SPD:
Next Layer Next Layer
Rule Local Remote Protocol Action Rule Local Remote Protocol Action
---- ----- ------ ---------- -------- ---- ----- ------ ---------- --------
1 IPV4-TEP2 IPV4-TEP1 ESP BYPASS 1 IPV4-TEP2 IPV4-TEP1 ESP BYPASS
2 IPV4-TEP2 IPV4-TEP1 IKE BYPASS 2 IPV4-TEP2 IPV4-TEP1 IKE BYPASS
3 IPv4-TEP2 IPV4-TEP1 41 PROTECT(ESP,transport) 3 IPv4-TEP2 IPV4-TEP1 41 PROTECT(ESP,transport)
In both SPD entries, "IKE" refers to UDP destination port 500 In both SPD entries, "IKE" refers to UDP destination port 500
and possibly also port 4500 if NAT traversal is used. and possibly also port 4500 if NAT traversal is used.
The IDci and IDcr payloads of IKEv1 carry the IPv4-TEP1, IPV4-TEP2 The IDci and IDcr payloads of IKEv1 carry the IPv4-TEP1, IPV4-TEP2,
and protocol value 41 as phase 2 identities. With IKEv2, the traffic and protocol value 41 as phase 2 identities. With IKEv2, the traffic
selectors are used to carry the same information. selectors are used to carry the same information.
5.2. IPsec Tunnel Mode 5.2. IPsec Tunnel Mode
A tunnel mode SA is essentially an SA applied to an IP tunnel, with A tunnel mode SA is essentially an SA applied to an IP tunnel, with
the access controls applied to the headers of the traffic inside the the access controls applied to the headers of the traffic inside the
tunnel [RFC4301]. tunnel [RFC4301].
Several requirements arise when IPsec is used to protect the IPv6 Several requirements arise when IPsec is used to protect the IPv6
traffic (inner header) for the scenarios mentioned in Section 3. traffic (inner header) for the scenarios listed in Section 3.
1. All of IPv6 traffic should be protected including link-local 1. All of IPv6 traffic should be protected, including link-local
(e.g., Neighbor Discovery) and multicast traffic. (e.g., Neighbor Discovery) and multicast traffic.
2. In Router-to-Router tunnels, the source and destination addresses 2. In router-to-router tunnels, the source and destination addresses
of the traffic could come from a wide range of prefixes that are of the traffic could come from a wide range of prefixes that are
normally learnt through routing. As routing can always learn a normally learned through routing. As routing can always learn a
new prefix, there is no way to know all the prefixes a priori new prefix, there is no way to know all the prefixes a priori
[RFC3884]. [RFC3884].
3. Source address selection depends on the notion of routes and 3. Source address selection depends on the notions of routes and
interfaces. This affects scenarios (2) and (3). interfaces. This affects scenarios (2) and (3).
The implementations may or may not model the IPsec tunnel mode SA as Implementations may or may not model the IPsec tunnel mode SA as an
an interface as described in Appendix A.1. interface as described in Appendix A.1.
If IPsec tunnel mode SA is not modeled as an interface (e.g., as of If IPsec tunnel mode SA is not modeled as an interface (e.g., as of
this writing, popular in many open source implementations), the SPD this writing, popular in many open source implementations), the SPD
entries for protecting all the traffic between the two endpoints must entries for protecting all traffic between the two endpoints must be
be described. Evaluating against the requirements above, link-local described. Evaluating against the requirements above, link-local
traffic cannot be sent because there is no interface and multicast traffic cannot be sent, because there is no interface and multicast
traffic would need to be identified, possibly resulting in a long traffic would need to be identified, possibly resulting in a long
list of SPD entries. The second requirement is difficult to satisfy list of SPD entries. The second requirement is difficult to satisfy,
because the traffic that needs to be protected is not necessarily because the traffic needing protection is not necessarily (e.g.,
(e.g., router-to-router tunnel) known a priori [RFC3884]. The third router-to-router tunnel) known a priori [RFC3884]. The third
requirement is equally hard because almost all implementations assume requirement is also problematical, because almost all implementations
addresses are assigned on interfaces (rather than configured in SPDs) assume addresses are assigned on interfaces (rather than configured
for proper source address selection. in SPDs) for proper source address selection.
If IPsec tunnel mode SA is modeled as interface, the traffic that If the IPsec tunnel mode SA is modeled as interface, the traffic that
needs protection can be modeled as routes pointing to the interface. needs protection can be modeled as routes pointing to the interface.
The second requirement is difficult to satisfy because the traffic The second requirement is difficult to satisfy, because the traffic
that needs to be protected is not necessarily known a priori. The needing protection is not necessarily known a priori. The third
third requirement is easily solved because IPsec is modeled as an requirement is easily solved, because IPsec is modeled as an
interface. interface.
In practice (2) has been solved by protecting all the traffic (::/0), In practice, (2) has been solved by protecting all the traffic
but there are no inter-operable implementations supporting this (::/0), bu no inter-operable implementations support this feature.
feature. For a detailed list of issues pertaining to this, see For a detailed list of issues pertaining to this, see
[I-D.duffy-ppvpn-ipsec-vlink]. [I-D.duffy-ppvpn-ipsec-vlink].
Because applying transport mode to protect a tunnel is a much more Because applying transport mode to protect a tunnel is a much simpler
simpler solution and also easily protects link-local and multicast solution and also easily protects link-local and multicast traffic,
traffic, we do not recommend using tunnel mode in this context. we do not recommend using tunnel mode in this context. Tunnel mode
Tunnel mode is still discussed in Appendix A. is, however, discussed further in Appendix A.
5.3. Peer Authorization Database 5.3. Peer Authorization Database
The Peer Authorization Database (PAD) provides the link between SPD The Peer Authorization Database (PAD) provides the link between SPD
and the key management daemon [RFC4306]. This is defined in and the key management daemon [RFC4306]. This is defined in
[RFC4301] and hence relevant only when used with IKEv2. [RFC4301] and hence relevant only when used with IKEv2.
As there is no way to currently discover the PAD related parameters As there is no currently defined way to discover the PAD-related
dynamically, it is assumed that these are manually configured: parameters dynamically, it is assumed that these are manually
configured:
o The Identity of the peer which will be asserted in the IKEv2 o The Identity of the peer asserted in the IKEv2 exchange: Many
exchange. There are many different types of identities that can different types of identities can be used. At least, the IPv4
be used. At least, IPv4 address of the peer should be supported. address of the peer should be supported.
o The IKEv2 can authenticate the peer using several methods. Pre- o IKEv2 can authenticate the peer by several methods. Pre-shared
shared key and X.509 certificate based authentication is required key and X.509 certificate-based authentication is required by
by [RFC4301]. At least, pre-shared key should be supported as it [RFC4301]. At least, pre-shared key should be supported, because
interoperates with a larger number of implementations. it interoperates with a larger number of implementations.
o The child SA authorization data should contain the IPv4 address of o The child SA authorization data should contain the IPv4 address of
the peer. the peer.
6. Recommendations 6. Recommendations
In Section 5 we examined the differences of setting up an IPsec IPv6- In Section 5, we examined the differences between setting up an IPsec
in-IPv4 using either transport or tunnel mode. We observe that IPv6-in-IPv4 tunnel using either transport or tunnel mode. We
applying transport mode to a tunnel interface is the simplest and observe that applying transport mode to a tunnel interface is the
therefore recommended solution. simplest and therefore recommended solution.
In Appendix A, we also explore what it would take to use so-called In Appendix A, we also explore what it would take to use so-called
Specific SPD (SSPD) tunnel mode. Such usage is more complicated Specific SPD (SSPD) tunnel mode. Such usage is more complicated
because IPv6 prefixes need to be known a priori and multicast and because IPv6 prefixes need to be known a priori and multicast and
link-local traffic do not work over such a tunnel. Fragment handling link-local traffic do not work over such a tunnel. Fragment handling
in tunnel mode is also more difficult. However, because MOBIKE in tunnel mode is also more difficult. However, because MOBIKE
[RFC4555] supports only tunnel mode, when the IPv4 endpoints of a [RFC4555] supports only tunnel mode, when the IPv4 endpoints of a
tunnel are dynamic and the other constraints are not applicable, tunnel are dynamic and the other constraints are not applicable,
using tunnel mode may be an acceptable solution. using tunnel mode may be an acceptable solution.
Therefore our primary recommendation is to use transport mode applied Therefore our primary recommendation is to use transport mode applied
to a tunnel interface. Spoofing can be prevented by enabling ingress to a tunnel interface. Source address spoofing can be limited by
filtering on the tunnel interface. enabling ingress filtering on the tunnel interface.
7. IANA Considerations 7. IANA Considerations
This memo makes no request to IANA. [[ RFC-editor: please remove this This memo makes no request to IANA. [[ RFC-editor: please remove this
section prior to publication. ]] section prior to publication. ]]
8. Security Considerations 8. Security Considerations
When you run IPv6-in-IPv4 tunnels (unsecured) over the Internet, it When running IPv6-in-IPv4 tunnels (unsecured) over the Internet, it
is possible to "inject" packets into the tunnel by spoofing the is possible to "inject" packets into the tunnel by spoofing the
source address (data plane security), or if the tunnel is signalled source address (data plane security), or if the tunnel is signaled
somehow (e.g., some messages where you authenticate to the server, so somehow (e.g., using authentication protocol and obtaining a static
that you would get a static v6 prefix), someone might be able to v6 prefix), someone might be able to spoof the signaling (control
spoof the signalling (control plane security). plane security).
The IPsec framework plays an important role in adding security to The IPsec framework plays an important role in adding security to
both the protocol for tunnel setup and data traffic. both the protocol for tunnel setup and data traffic.
Either IKEv1 or IKEv2 provides a secure signaling protocol for Either IKEv1 or IKEv2 provides a secure signaling protocol for
establishing, maintaining and deleting an IPsec tunnel. establishing, maintaining, and deleting an IPsec tunnel.
IPsec, with the Encapsulating Security Payload (ESP), offers IPsec, with ESP, offers integrity and data origin authentication,
integrity and data origin authentication, confidentiality, with confidentiality, and optional (at the discretion of the receiver)
optional (at the discretion of the receiver) anti-replay features. anti-replay features. Using confidentiality without integrity is
The usage of confidentity-only is discouraged. ESP furthermore discouraged. ESP furthermore provides limited traffic flow
provides limited traffic flow confidentiality. confidentiality.
IPsec provides access control mechanisms through the distribution of IPsec provides access control mechanisms through the distribution of
keys and also through the usage of policies dictated by the Security keys and also through the application of policies dictated by the
Policy Database (SPD). Security Policy Database (SPD).
The NAT traversal mechanism provided by IKEv2 introduces some The NAT traversal mechanism provided by IKEv2 introduces some
weaknesses into IKE and IPsec. These issues are discussed in more weaknesses into IKE and IPsec. These issues are discussed in more
detail in [RFC4306]. detail in [RFC4306].
Please note that the usage of IPsec for the scenarios described in Please note that using IPsec for the scenarios described in Figure 3,
Figure 3, Figure 2 and Figure 1 does not aim to protect the end-to- Figure 2 and Figure 1 does not aim to protect the end-to-end
end communication. It protects just the tunnel part. It is still communication. It protects just the tunnel part. It is still
possible for an IPv6 endpoint that is not attached to the IPsec possible for an IPv6 endpoint not attached to the IPsec tunnel to
tunnel to spoof packets. spoof packets.
9. Contributors 9. Contributors
The authors are listed in alphabetical order. The authors are listed in alphabetical order.
Suresh Satapati also participated in the initial discussions on the Suresh Satapati also participated in the initial discussions on this
topic. topic.
10. Acknowledgments 10. Acknowledgments
The authors would like to thank Stephen Kent, Michael Richardson, The authors would like to thank Stephen Kent, Michael Richardson,
Florian Weimer, Elwyn Davies, Eric Vyncke, Merike Kaeo, and Alfred Florian Weimer, Elwyn Davies, Eric Vyncke, Merike Kaeo, Alfred
Hoenes for their substantive feedback. Hoenes, and Francis Dupont for their substantive feedback.
We would like to thank Pasi Eronen for his text contributions and We would like to thank Pasi Eronen for his text contributions and
suggestions for improvement. suggestions for improvement.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
skipping to change at page 15, line 29 skipping to change at page 15, line 29
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating
MPLS in IP or Generic Routing Encapsulation (GRE)", MPLS in IP or Generic Routing Encapsulation (GRE)",
RFC 4023, March 2005. RFC 4023, March 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006. (MOBIKE)", RFC 4555, June 2006.
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
Implementation Guidelines", RFC 4718, October 2006.
Appendix A. Using Tunnel Mode Appendix A. Using Tunnel Mode
First, we describe the different tunnel mode implementation methods. First, we describe the different tunnel mode implementation methods.
We note that in this context, only so-called Specific SPD (SSPD) We note that, in this context, only the so-called Specific SPD (SSPD)
model (without a tunnel interface) can be made to work, but has model (without a tunnel interface) can be made to work, but it has
reduced applicability and the use of a transport mode tunnel is reduced applicability, and the use of a transport mode tunnel is
recommended instead. However, we will describe how the SSPD Tunnel recommended instead. However, we will describe how the SSPD Tunnel
Mode might look like if one would like to use it in any case. Mode might look if one would like to use it in any case.
A.1. Tunnel Mode Implementation Methods A.1. Tunnel Mode Implementation Methods
Tunnel mode could (in theory) be deployed in two very different ways Tunnel mode could (in theory) be deployed in two very different ways
depending on the implementation: depending on the implementation:
1. "Generic SPDs": some implementations model the tunnel mode SA as 1. "Generic SPDs": some implementations model the tunnel mode SA as
an IP interface. In this case, an IPsec tunnel interface is an IP interface. In this case, an IPsec tunnel interface is
created and used with "any" address ("::/0 <-> ::/0" ) as IPsec created and used with "any" addresses ("::/0 <-> ::/0" ) as IPsec
traffic selectors while setting up the SA. Though this allows traffic selectors while setting up the SA. Though this allows
all traffic between the two nodes to be protected by IPsec, the all traffic between the two nodes to be protected by IPsec, the
routing table would decide what traffic gets sent over the routing table would decide what traffic gets sent over the
tunnel. Ingress filtering must be separately applied on the tunnel. Ingress filtering must be separately applied on the
tunnel interface as the IPsec policy checks do not check the IPv6 tunnel interface as the IPsec policy checks do not check the IPv6
addresses at all. Routing protocols, multicast, etc. will work addresses at all. Routing protocols, multicast, etc. will work
through this tunnel. This mode is very similar to the transport through this tunnel. This mode is similar to transport mode.
mode. The SPDs must be interface-specific. However, because IKE The SPDs must be interface-specific. However, because IKE uses
uses IPv4 but the tunnel is IPv6, there is no standard solution IPv4 but the tunnel is IPv6, there is no standard solution to map
to map the IPv4 interface to IPv6 interface the IPv4 interface to IPv6 interface
[I-D.duffy-ppvpn-ipsec-vlink] and this approach is not feasible. [I-D.duffy-ppvpn-ipsec-vlink] and this approach is not feasible.
2. "Specific SPDs": some implementations don't model the tunnel mode 2. "Specific SPDs": some implementations do not model the tunnel
SA as an IP interface. Traffic selection is done based on mode SA as an IP interface. Traffic selection is based on
specific SPD entries, e.g., "2001:db8:1::/48 <-> 2001:db8: specific SPD entries, e.g., "2001:db8:1::/48 <-> 2001:db8:
2::/48". As the IPsec session between two endpoints does not 2::/48". As the IPsec session between two endpoints does not
have an interface (though an implementation may have a common have an interface (though an implementation may have a common
pseudo-interface for all IPsec traffic), there is no DAD, MLD, or pseudo-interface for all IPsec traffic), there is no DAD, MLD, or
link-local traffic to protect; multicast is not possible over link-local traffic to protect; multicast is not possible over
such a tunnel. Ingress filtering is performed automatically by such a tunnel. Ingress filtering is performed automatically by
the IPsec traffic selectors. the IPsec traffic selectors.
Ingress filtering is guaranteed by IPsec processing when option (2) Ingress filtering is guaranteed by IPsec processing when option (2)
is chosen whereas the operator has to enable them explicitly when is chosen, whereas the operator has to enable it explicitly when
transport mode or option (1) of tunnel mode SA is chosen. transport mode or option (1) is chosen.
In summary, there does not appear to be a standard solution in this In summary, there does not appear to be a standard solution in this
context for the first implementation approach. context for the first implementation approach.
The second approach can be made to work, but is only applicable in The second approach can be made to work, but is only applicable in
host-to-host or site-to-router/router-to-site scenarios (i.e., when host-to-host or site-to-router/router-to-site scenarios (i.e., when
the IPv6 prefixes can be known a priori), and offers only a limited the IPv6 prefixes can be known a priori), and it offers only a
set of features (e.g., no multicast) compared to a transport mode limited set of features (e.g., no multicast) compared with a
tunnel. transport mode tunnel.
When tunnel mode is used, fragment handling [RFC4301] may also be When tunnel mode is used, fragment handling [RFC4301] may also be
more difficult compared to transport mode and, depending on more difficult compared with transport mode and, depending on
implementation, may need to be reflected in SPDs. implementation, may need to be reflected in SPDs.
A.2. Specific SPD for Host-to-Host Scenario A.2. Specific SPD for Host-to-Host Scenario
The following SPD entries assume that there are two hosts Host1 and The following SPD entries assume that there are two hosts, Host1 and
Host2, whose IPv6 addresses are denoted by IPV6-EP1 and IPV6-EP2 Host2, whose IPv6 addresses are denoted IPV6-EP1 and IPV6-EP2 (global
(global addresses) and IPV4 addresses of the tunnel endpoints are addresses), and the IPV4 addresses of the tunnel endpoints are
denoted by IPV4-TEP1 and IPV4-TEP2 respectively. denoted IPV4-TEP1 and IPV4-TEP2, respectively.
Host1's SPD: Host1's SPD:
Next Layer Next Layer
Rule Local Remote Protocol Action Rule Local Remote Protocol Action
---- ----- ------ ---------- -------- ---- ----- ------ ---------- --------
1 IPV6-EP1 IPV6-EP2 ESP BYPASS 1 IPV6-EP1 IPV6-EP2 ESP BYPASS
2 IPV6-EP1 IPV6-EP2 IKE BYPASS 2 IPV6-EP1 IPV6-EP2 IKE BYPASS
3 IPv6-EP1 IPV6-EP2 41 PROTECT(ESP, 3 IPv6-EP1 IPV6-EP2 41 PROTECT(ESP,
tunnel{IPV4-TEP1,IPV4-TEP2}) tunnel{IPV4-TEP1,IPV4-TEP2})
skipping to change at page 17, line 36 skipping to change at page 17, line 36
The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and IPV6-TEP2 The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and IPV6-TEP2
as phase 2 identities. With IKEv2, the traffic selectors are used to as phase 2 identities. With IKEv2, the traffic selectors are used to
carry the same information. carry the same information.
A.3. Specific SPD for Host-to-Router scenario A.3. Specific SPD for Host-to-Router scenario
The following SPD entries assume that the host has the IPv6 address The following SPD entries assume that the host has the IPv6 address
IPV6-EP1 and the tunnel end points of the host and router are IPV4- IPV6-EP1 and the tunnel end points of the host and router are IPV4-
TEP1 and IPV4-TEP2 respectively. If the tunnel is between a router TEP1 and IPV4-TEP2 respectively. If the tunnel is between a router
and a host where the router has allocated a IPV6-PREF/48 to the host, and a host where the router has allocated a IPV6-PREF/48 to the host,
the corresponding SPD entries can be derived by substituting IPV6-EP1 the corresponding SPD entries can be derived by replacing IPV6-EP1
by IPV6-PREF/48. with IPV6-PREF/48.
Please note the bypass entry for host's SPD, absent in router's SPD. Please note the bypass entry for host's SPD, absent in router's SPD.
While this might be an implementation matter for host-to-router While this might be an implementation matter for host-to-router
tunneling, having a similar entry, "Local=IPV6-PREF/48 & Remote=IPV6- tunneling, having a similar entry, "Local=IPV6-PREF/48 & Remote=IPV6-
PREF/48" is critical for site-to-router tunneling. PREF/48" is critical for site-to-router tunneling.
Host's SPD: Host's SPD:
Next Layer Next Layer
Rule Local Remote Protocol Action Rule Local Remote Protocol Action
---- ----- ------ ---------- -------- ---- ----- ------ ---------- --------
skipping to change at page 18, line 25 skipping to change at page 18, line 25
Router's SPD: Router's SPD:
Next Layer Next Layer
Rule Local Remote Protocol Action Rule Local Remote Protocol Action
---- ----- ------ ---------- -------- ---- ----- ------ ---------- --------
1 IPV6-EP2 IPV6-EP1 ESP BYPASS 1 IPV6-EP2 IPV6-EP1 ESP BYPASS
2 IPV6-EP2 IPV6-EP1 IKE BYPASS 2 IPV6-EP2 IPV6-EP1 IKE BYPASS
3 ANY IPV6-EP1 ANY PROTECT(ESP, 3 ANY IPV6-EP1 ANY PROTECT(ESP,
tunnel{IPV4-TEP1,IPV4-TEP2}) tunnel{IPV4-TEP1,IPV4-TEP2})
The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and
ID_IPV6_ADDR_RANGE or ID_IPV6_ADDR_SUBNET as its phase 2 identity. ID_IPV6_ADDR_RANGE or ID_IPV6_ADDR_SUBNET as their phase 2
The starting address is zero IP address and the end address is all identities. The starting address is zero and the end address is all
ones for ID_IPV6_ADDR_RANGE. The starting address is zero IP address ones for ID_IPV6_ADDR_RANGE. The starting address is zero IP address
and the end address is all zeroes for ID_IPV6_ADDR_SUBNET. With and the end address is all zeroes for ID_IPV6_ADDR_SUBNET. With
IKEv2, the traffic selectors are used to carry the same information. IKEv2, the traffic selectors are used to carry the same information.
Appendix B. Optional Features Appendix B. Optional Features
B.1. Dynamic Address Configuration B.1. Dynamic Address Configuration
With the exchange of protected configuration payloads, IKEv2 is able With the exchange of protected configuration payloads, IKEv2 is able
to provide the IKEv2 peer with DHCP-like information payloads. These to provide the IKEv2 peer with DHCP-like information payloads. These
configuration payloads are exchanged between the IKEv2 initiator and configuration payloads are exchanged between the IKEv2 initiator and
the responder. responder.
This could be used (for example) by the host in the host-to-router This could be used (for example) by the host in the host-to-router
scenario to obtain the IPv6 address from the ISP as part of setting scenario to obtain an IPv6 address from the ISP as part of setting up
up the IPsec tunnel mode SA. The details of these procedures are out the IPsec tunnel mode SA. The details of these procedures are out of
of scope of this memo. scope for this memo.
B.2. NAT Traversal and Mobility B.2. NAT Traversal and Mobility
Network address (and port) translation devices are commonly found in Network address (and port) translation devices are commonly found in
today's networks. A detailed description of the problem of IPsec today's networks. A detailed description of the problem of IPsec-
protected data traffic traversing a NAT including requirements are protected data traffic traversing a NAT including requirements are
discussed in [RFC3715]. discussed in [RFC3715].
IKEv2 can detect the presence of a NAT automatically by sending IKEv2 can detect the presence of a NAT automatically by sending
NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads in NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads in
the initial IKE_SA_INIT exchange. Once a NAT is detected and both the initial IKE_SA_INIT exchange. Once a NAT is detected and both
end points support IPsec NAT traversal extensions UDP encapsulation end points support IPsec NAT traversal extensions, UDP encapsulation
can be enabled. can be enabled.
More details about UDP encapsulation of IPsec protected IP packets More details about UDP encapsulation of IPsec-protected IP packets
can be found in [RFC3948]. can be found in [RFC3948].
For IPv6-in-IPv4 tunneling, NAT traversal is interesting for two For IPv6-in-IPv4 tunneling, NAT traversal is interesting for two
reasons: reasons:
1. One of the tunnel endpoints is often behind a NAT, and configured 1. One of the tunnel endpoints is often behind a NAT, and configured
tunneling, using protocol 41, is not guaranteed to traverse the tunneling, using protocol 41, is not guaranteed to traverse the
NAT. Hence, using IPsec tunnels would enable one to both set-up NAT. Hence, using IPsec tunnels would enable one to set up both
a secure tunnel, and set-up a tunnel where it might not always be a secure tunnel and a tunnel that might not always be possible
possible without other tunneling mechanisms. without other tunneling mechanisms.
2. Using NAT traversal allows the outer address to change without 2. Using NAT traversal allows the outer address to change without
having to renegotiate the SAs. This could be very beneficial for having to renegotiate the SAs. This could be beneficial for a
a crude form of mobility, and in scenarios where the NAT changes crude form of mobility and in scenarios where the NAT changes the
the IP addresses frequently. However, as the outer address may IP addresses frequently. However, as the outer address may
change, this might introduce new security issues, and using change, this might introduce new security issues, and using
tunnel mode would be most appropriate. tunnel mode would be most appropriate.
When NAT is not applied, the second benefit would still be desirable. When NAT is not applied, the second benefit would still be desirable.
In particular, using manually configured tunneling is an operational In particular, using manually configured tunneling is an operational
challenge with dynamic IP addresses as both ends need to be challenge with dynamic IP addresses, because both ends need to be
reconfigured if an address changes. Therefore an easy and efficient reconfigured if an address changes. Therefore, an easy and efficient
way to re-establish the IPsec tunnel if the IP address changes would way to re-establish the IPsec tunnel if the IP address changes would
be desirable. MOBIKE [RFC4555] provides a solution when IKEv2 is be desirable. MOBIKE [RFC4555] provides a solution when IKEv2 is
used but only supports tunnel mode. used, but it only supports tunnel mode.
B.3. Tunnel Endpoint Discovery B.3. Tunnel Endpoint Discovery
The IKEv2 initiator needs to know the address of the IKEv2 responder The IKEv2 initiator needs to know the address of the IKEv2 responder
to start IKEv2 signaling. A number of ways can be used to provide to start IKEv2 signaling. A number of ways can be used to provide
the initiator with this information, for example: the initiator with this information, for example:
o Using out-of-band mechanisms, e.g., from the ISP's web page. o Using out-of-band mechanisms, e.g., from the ISP's web page.
o Using DNS to look up a service name by appending it to the DNS o Using DNS to look up a service name by appending it to the DNS
skipping to change at page 20, line 19 skipping to change at page 20, line 19
For the purpose of this document it is assumed that this address can For the purpose of this document it is assumed that this address can
be obtained somehow. Once the address has been learned, it is be obtained somehow. Once the address has been learned, it is
configured as the tunnel end-point for the configured IPv6-in-IPv4 configured as the tunnel end-point for the configured IPv6-in-IPv4
tunnel. tunnel.
This problem is also discussed at more length in This problem is also discussed at more length in
[I-D.palet-v6ops-tun-auto-disc]. [I-D.palet-v6ops-tun-auto-disc].
However, simply discovering the tunnel endpoint is not sufficient for However, simply discovering the tunnel endpoint is not sufficient for
establishing an IKE session with the peer. The PAD information (see establishing an IKE session with the peer. The PAD information (see
Section 5.3) also needs to be learnt dynamically. Hence, currently Section 5.3) also needs to be learned dynamically. Hence, currently,
automatic endpoint discovery provides benefit only if PAD information automatic endpoint discovery provides benefit only if PAD information
is chosen in such a manner that it is not IP-address specific. is chosen in such a manner that it is not IP-address specific.
Authors' Addresses Authors' Addresses
Richard Graveman Richard Graveman
RFG Security, LLC RFG Security, LLC
15 Park Avenue 15 Park Avenue
Morristown, New Jersey 07960 Morristown, New Jersey 07960
USA USA
skipping to change at page 22, line 7 skipping to change at page 22, line 7
Hannes Tschofenig Hannes Tschofenig
Siemens Siemens
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bayern 81739 Munich, Bayern 81739
Germany Germany
Email: Hannes.Tschofenig@siemens.com Email: Hannes.Tschofenig@siemens.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 96 change blocks. 
207 lines changed or deleted 215 lines changed or added

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