draft-ietf-v6ops-ipsec-tunnels-02.txt   draft-ietf-v6ops-ipsec-tunnels-03.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: September 7, 2006 Nokia Expires: April 12, 2007 Nokia
P. Savola P. Savola
CSC/FUNET CSC/FUNET
H. Tschofenig H. Tschofenig
Siemens Siemens
March 6, 2006 October 9, 2006
Using IPsec to Secure IPv6-in-IPv4 Tunnels Using IPsec to Secure IPv6-in-IPv4 Tunnels
draft-ietf-v6ops-ipsec-tunnels-02.txt draft-ietf-v6ops-ipsec-tunnels-03.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 September 7, 2006. This Internet-Draft will expire on April 12, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (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.
skipping to change at page 2, line 17 skipping to change at page 2, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Threats and the Use of IPsec . . . . . . . . . . . . . . . . . 3 2. Threats and the Use of IPsec . . . . . . . . . . . . . . . . . 3
2.1. IPsec in Transport Mode . . . . . . . . . . . . . . . . . 4 2.1. IPsec in Transport Mode . . . . . . . . . . . . . . . . . 4
2.2. IPsec in Tunnel Mode . . . . . . . . . . . . . . . . . . . 5 2.2. IPsec in Tunnel Mode . . . . . . . . . . . . . . . . . . . 5
3. Scenarios and Overview . . . . . . . . . . . . . . . . . . . . 5 3. Scenarios and Overview . . . . . . . . . . . . . . . . . . . . 5
3.1. Router-to-Router Tunnels . . . . . . . . . . . . . . . . . 5 3.1. Router-to-Router Tunnels . . . . . . . . . . . . . . . . . 5
3.2. Site-to-Router/Router-to-Site Tunnels . . . . . . . . . . 6 3.2. Site-to-Router/Router-to-Site Tunnels . . . . . . . . . . 6
3.3. Host-to-Host Tunnels . . . . . . . . . . . . . . . . . . . 8 3.3. Host-to-Host Tunnels . . . . . . . . . . . . . . . . . . . 8
4. IKE and IPsec Versions . . . . . . . . . . . . . . . . . . . . 8 4. IKE and IPsec Versions . . . . . . . . . . . . . . . . . . . . 8
5. IPsec Configuration Details . . . . . . . . . . . . . . . . . 9 5. IPsec Configuration Details . . . . . . . . . . . . . . . . . 9
5.1. Transport vs Tunnel Mode . . . . . . . . . . . . . . . . . 10 5.1. IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 10
5.2. IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 11 5.2. IPsec Tunnel Mode . . . . . . . . . . . . . . . . . . . . 10
5.3. IPsec Tunnel Mode . . . . . . . . . . . . . . . . . . . . 11 5.3. Peer Authorization Database . . . . . . . . . . . . . . . 12
5.3.1. Generic SPDs for Tunnel Mode . . . . . . . . . . . . . 12 6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 12
6. Dynamic Address Configuration . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. NAT Traversal and Mobility . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Tunnel Endpoint Discovery . . . . . . . . . . . . . . . . . . 14 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . . 14
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Using Tunnel Mode . . . . . . . . . . . . . . . . . . 15
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 A.1. Tunnel Mode Implementation Methods . . . . . . . . . . . . 15
14.1. Normative References . . . . . . . . . . . . . . . . . . . 16 A.2. Specific SPD for Host-to-Host Scenario . . . . . . . . . . 16
14.2. Informative References . . . . . . . . . . . . . . . . . . 16 A.3. Specific SPD for Host-to-Router scenario . . . . . . . . . 17
Appendix A. Specific SPDs for Tunnel Mode . . . . . . . . . . . . 17 Appendix B. Optional Features . . . . . . . . . . . . . . . . . . 18
A.1. Specific SPD for Host-to-Host Scenario . . . . . . . . . . 17 B.1. Dynamic Address Configuration . . . . . . . . . . . . . . 18
A.2. Specific SPD for Host-to-Router scenario . . . . . . . . . 18 B.2. NAT Traversal and Mobility . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 B.3. Tunnel Endpoint Discovery . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 22
1. Introduction 1. Introduction
The IPv6 operations (v6ops) working group has selected (manually The IPv6 operations (v6ops) working group has selected (manually
configured) IPv6-in-IPv4 tunneling [RFC4213] as one of the IPv6 configured) IPv6-in-IPv4 tunneling [RFC4213] as one of the IPv6
transition mechanisms for IPv6 deployment. transition mechanisms for IPv6 deployment.
[RFC4213] identified a number of threats which had not been [RFC4213] identified a number of threats that had not been adequately
adequately analyzed or addressed in its predecessor, [RFC2893]. The analyzed or addressed in its predecessor [RFC2893]. The most
most complete solution is to use IPsec to protect IPv6-in-IPv4 complete solution is to use IPsec to protect IPv6-in-IPv4 tunneling.
tunneling. The document was intentionally not expanded to include The document was intentionally not expanded to include the details on
the details on how to set up an IPsec-protected tunnel in an how to set up an IPsec-protected tunnel in an interoperable manner,
interoperable manner, but instead the details were deferred to this but instead the details were deferred to this memo.
memo.
First this document analyses the threats and scenarios that can be First four sections of this document analyse the threats and
addressed by IPsec. Next, this document discusses some of the scenarios that can be addressed by IPsec and assumptions made by this
assumptions made by this document for successful IPsec Security document for successful IPsec Security Association (SA)
Association (SA) establishment. Then, it gives the details of establishment. Section 5 gives the details of Internet Key Exchange
Internet Key Exchange (IKE) and IP security (IPsec) exchange with (IKE) and IP security (IPsec) exchange with packet formats and
packet formats and Security Policy Database (SPD) entries. Finally, Security Policy Database (SPD) entries. Section 6 gives
it discusses the usage of IPsec NAT-traversal mechanism that can be recommendations. Appendices further discuss Tunnel mode usage and
used with configured tunnels in some scenarios. optional extensions.
This document does not address the use of IPsec for tunnels which 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 (ECN) bits [RFC4213]) from the encapsulated packets to
the tunnel path is out of scope. the 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:
skipping to change at page 4, line 19 skipping to change at page 4, line 18
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. IPsec can be used in two ways, in transport and confidentiality.
tunnel mode; further comparison is done in Section 5.1.
IPsec can be used in two ways, in transport and tunnel mode; detailed
discussion about applicability in this context is described in
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 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
skipping to change at page 5, line 22 skipping to change at page 5, line 22
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 it in
this mode; the packets will be demultiplexed based on the SPI and this mode; the packets will be demultiplexed based on the SPI and
possibly the IPv6 address bound to the SA. Thus, the outer address possibly the IPv6 address bound to the SA. Thus, the outer address
spoofing is irrelevant as long as the decryption succeeds and the spoofing is irrelevant as long as the decryption succeeds and the
inner IPv6 packet can be verified to come from the right tunnel inner IPv6 packet can be verified to come from the right tunnel
endpoint. endpoint.
A Tunnel mode SA can be used in two ways depending on whether it is As described in Section 5.2, using tunnel mode is more difficult than
modelled as an interface or not. These are described in section applying transport mode to a tunnel interface, and as a result this
Section 5.3. document recommends transport mode.
3. Scenarios and Overview 3. Scenarios and Overview
There are roughly three kinds of scenarios: There are roughly three kinds of 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/router-to-site tunnels. This refers to a tunnel
between a site's IPv6 (border) device to an IPv6 upstream between a site's IPv6 (border) device to 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.
skipping to change at page 7, line 34 skipping to change at page 7, line 34
Respectively, IPv6/IPv4 hosts can tunnel IPv6 packets to an Respectively, 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 source addresses
coming from a well known prefix whereas the destination address could coming from a well known prefix whereas the destination address could
be any node on the Internet. be any node on the Internet.
In this case, the IPsec tunnel mode SA can be bound to the prefix In this case, the IPsec tunnel mode SA could be bound to the prefix
that was allocated to the router at Site B and router A can 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, the 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 the 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
skipping to change at page 8, line 22 skipping to change at page 8, line 22
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 that are interconnected by an IPv4 infrastructure can
tunnel IPv6 packets between themselves. In this case, the tunnel tunnel IPv6 packets between themselves. In this case, the tunnel
spans the entire end-to-end path that the packet takes. spans the entire end-to-end path that the packet takes.
In this case, the source and the destination IPv6 address are known a In this case, the source and the destination IPv6 address are known a
priori. A tunnel mode SA can be bound to the specific address. The priori. A tunnel mode SA could be bound to the specific address.
address verification prevents IPv6 address spoofing completely. The address verification prevents IPv6 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 of 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 originally defined in [RFC2401]
skipping to change at page 8, line 45 skipping to change at page 8, line 45
[RFC2409] (which is referred to as IKEv1 in this document) and is now [RFC2409] (which is referred to as IKEv1 in this document) and is now
superseded by [RFC4306] (referred to as IKEv2). There are several superseded by [RFC4306] (referred to as IKEv2). There are several
differences between them. The differences relevant to this document differences between them. The differences relevant to this document
are discussed below. 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. [RFC2401] does not support transport mode SAs between hosts and 2. [RFC4301] assumes IKEv2, as some of the new features cannot be
security gateways. [RFC4301] supports transport mode SA between
hosts and security gateway to provide link security e.g., IP-IP
tunnel protected with IPsec.
3. [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 the two versions of
the security architecture. the security architecture.
IKEv2 supports features that are useful for configuring and securing IKEv2 supports features that are useful for configuring and securing
tunnels which are not present with IKEv1. tunnels that are 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 the hosts/sites
to the ISP using EAP methods that support username and password. to the 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 to
configure the IPv6 address of the host. 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.
skipping to change at page 9, line 38 skipping to change at page 9, line 33
interchangeably. The main difference is that AH is able to provide interchangeably. The main difference is that AH is able to provide
integrity-protection for certain fields in the outer IP header and IP integrity-protection for certain fields in the outer IP header and IP
options. However, as the outer IP header will be discarded in any options. However, as the outer IP 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 the establishment of an IPsec
tunnel for the protection of IPv4/IPv6 data traffic. However, first tunnel for the protection of IPv4/IPv6 data traffic. However, first
we will take a look at the packet format on the wire, and the salient we will take a look at the packet format on the wire.
differences between transport and tunnel modes.
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
5.1. Transport vs Tunnel Mode 5.1. IPsec Transport Mode
Transport mode is typically used by setting up a regular IPv6-in-IPv4
(or GRE, L2TP, ...) tunnel, and then applying a transport mode SA to
protect the packets before they are sent out over an interface.
Tunnel mode can be deployed in two very different ways depending on
the implementation:
1. "Generic SPDs": some implementations model the tunnel mode SA as
an IP interface. In this case, an IPsec tunnel interface is
created and used with "any" address ("::/0 <-> ::/0" ) as IPsec
traffic selectors while setting up the SA. Though this allows
all traffic between the two nodes to be protected by IPsec, the
routing table would decide what traffic gets sent over the
tunnel. Ingress filtering must be separately applied on the
tunnel interface as the IPsec policy checks do not check the IPv6
addresses at all. Routing protocols, multicast, etc. will work
through this tunnel. This mode is very similar to the transport
mode.
2. "Specific SPDs": some implementations don't model the tunnel mode
SA as an IP interface. Traffic selection is done based on
specific SPD entries, e.g., "2001:db8:1::/48 <-> 2001:db8:
2::/48". As the IPsec session between two endpoints does not
have an interface (though an implementation may have a common
pseudo-interface for all IPsec traffic), there is no DAD, MLD, or
link-local traffic to protect; multicast is not possible over
such a tunnel. Ingress filtering is performed automatically by
the IPsec traffic selectors.
Ingress filtering is guaranteed by IPsec processing when option (2)
is chosen whereas the operator has to enable them explicitly when
transport mode or option (1) of tunnel mode SA is chosen.
We describe the specific SPD case in Appendix A due to its length and
relative complexity compared to transport mode or generic SPD tunnel
mode.
5.2. IPsec Transport Mode
The transport mode has typically been applied to L2TP, GRE, and other The transport mode has typically been applied to L2TP, GRE, and other
kind of tunneling methods, especially when the user wants to tunnel kind of tunneling methods, especially when the user wants to tunnel
non-IP traffic. [RFC3884] provides an example of applicability. non-IP traffic. [RFC3884], [RFC3193], and [RFC4023] provide examples
of applying transport mode to protect tunnel traffic that spans only
a 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 which 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 are denoted by IPV4- and Router2, with tunnel endpoint IPv4 addresses denoted by IPV4-TEP1
TEP1 and IPV4-TEP2 respectively. (In other scenarios, the SPDs are and IPV4-TEP2 respectively. (In other scenarios, the SPDs are set up
set up in a similar fashion.) Implementations that are strictly in a similar fashion.)
conformant to [RFC2401] may not be able to setup the IPsec transport
mode SA.
Router1's SPD OUT :
IF SRC = IPV4-TEP1 && DST = IPV4-TEP2 && protocol = 41
THEN USE ESP TRANSPORT MODE SA
Router1's SPD IN:
IF SRC = IPV4-TEP2 && DST = IPV4-TEP1 && protocol = 41
THEN USE ESP TRANSPORT MODE SA
Router2's SPD OUT:
IF SRC = IPV4-TEP2 && DST = IPV4-TEP1 && protocol = 41 Router1's SPD:
THEN USE ESP TRANSPORT MODE SA Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- --------
1 IPV4-TEP1 IPV4-TEP2 ESP BYPASS
2 IPV4-TEP1 IPV4-TEP2 IKE BYPASS
3 IPv4-TEP1 IPV4-TEP2 41 PROTECT(ESP,transport)
Router2's SPD IN: Router2's SPD:
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- --------
1 IPV4-TEP2 IPV4-TEP1 ESP BYPASS
2 IPV4-TEP2 IPV4-TEP1 IKE BYPASS
3 IPv4-TEP2 IPV4-TEP1 41 PROTECT(ESP,transport)
IF SRC = IPV4-TEP1 && DST = IPV4-TEP2 && protocol = 41 In both SPD entries, "IKE" refers to UDP destination port 500
THEN USE ESP TRANSPORT MODE SA 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.3. IPsec Tunnel Mode 5.2. IPsec Tunnel Mode
As we described above, tunnel mode can be used either with "generic"
or "specific" SPDs. We describe the generic approach below, and
specific SPDs in Appendix A.
Implementations may or may not model a tunnel mode SA as a separate
interface between each IPsec peer. A separate interface for each is
simple as long as generic SPDs are used. However, with specific
SPDs, having an interface becomes highly problematic. That is,
interfaces must always have link-local addresses, run Duplicate
Address Detection, etc. -- which results in packets which must be
secured. These would require a set-up of a number of complex SPDs
because link-local addresses are not unique. Therefore, this memo
restricts to describing only the scenario where SPD tunnel mode is
not modelled as separate interfaces.
Routing protocols, multicast, etc. work fine over generic SPD tunnel
mode, but are not feasible with specific SPDs.
5.3.1. Generic SPDs for Tunnel Mode
In the generic SPD case, for any scenario, SPDs are not really used
for traffic selectors. All the SPD entries match all the traffic,
i.e., "src = ::/0 & destination = ::/0" (we do not write these out as
the SPD entries are trivial). We assume that the tunnel is modelled
as an interface, one for each IPsec session. Instead of SPDs, the
routing table is used to perform outbound traffic selection, and all
the traffic that is passed to the interface, gets IPsec-protected.
Similarly, the inbound SPD matches everything, so demultiplexing is
done based on the SPI. This is secure; while an attacker could spoof
packets with the correct SPI (and even tunnel source/destination
addresses), the attacker would not know the keying material and such
packets would fail IPsec processing.
This mode obviously does not prevent an attacker from spoofing IPv6
addresses, as any traffic sent by the IPsec peer is accepted.
Therefore, ingress filtering must be applied on the tunnel interface.
As all (IP) traffic will pass on this kind of tunnel, routing
protocols, multicast, etc. will work without problems.
6. Dynamic Address Configuration
With the exchange of protected configuration payloads, IKEv2 is able
to provide the IKEv2 peer with DHCP-like information payloads. These
configuration payloads are exchanged between the IKEv2 initiator and
the responder.
This can 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
up the IPsec tunnel mode SA. The details of these procedures are out
of scope of this memo.
7. NAT Traversal and Mobility
Network address (and port) translation devices are commonly found in A tunnel mode SA is essentially an SA applied to an IP tunnel, with
today's networks. A detailed description of the problem of IPsec the access controls applied to the headers of the traffic inside the
protected data traffic traversing a NAT including requirements are tunnel [RFC4301].
discussed in [RFC3715].
IKEv2 can detect the presence of a NAT automatically by sending an Several requirements arise when IPsec is used to protect the IPv6
Informational exchange with NAT_DETECTION_SOURCE_IP and traffic (inner header) for the scenarios mentioned in Section 3.
NAT_DETECTION_DESTINATION_IP payloads before establishing an IPsec
SA. These payloads are processed in the same way as in the initial
IKE_SA_INIT exchange. Once a NAT is detected and both end points
support IPsec NAT traversal extensions UDP encapsulation can be
enabled.
More details about UDP encapsulation of IPsec protected IP packets 1. All of IPv6 traffic should be protected including link-local
can be found in [RFC3948]. (e.g., Neighbor Discovery) and multicast traffic.
For IPv6-in-IPv4 tunneling, NAT traversal is interesting for two 2. In Router-to-Router tunnels, the source and destination addresses
reasons: of the traffic could come from a wide range of prefixes that are
normally learnt through routing. As routing can always learn a
new prefix, there is no way to know all the prefixes a priori
[RFC3884].
1. One of the tunnel endpoints is often behind a NAT, and configured 3. Source address selection depends on the notion of routes and
tunneling, using protocol 41, is not guaranteed to traverse the interfaces. This affects scenarios (2) and (3).
NAT. Hence, using IPsec tunnels would enable one to both set-up
a secure tunnel, and set-up a tunnel where it might not always be
possible without other tunneling mechanisms.
2. Using NAT traversal allows the outer address to change without The implementations may or may not model the IPsec tunnel mode SA as
having to renegotiate the SAs. This could be very beneficial for an interface as described in Appendix A.1.
a crude form of mobility, and in scenarios where the NAT changes
the IP addresses frequently. However, as the outer address may
change, this might introduce new security issues, and using
tunnel mode would be most appropriate.
When NAT is not applied, the second benefit would still be desirable. If IPsec tunnel mode SA is not modeled as an interface (e.g., as of
In particular, using manually configured tunneling is an operational this writing, popular in many open source implementations), the SPD
challenge with dynamic IP addresses as both ends need to be entries for protecting all the traffic between the two endpoints must
reconfigured if an address changes. Therefore an easy and efficient be described. Evaluating against the requirements above, link-local
way to re-establish the IPsec tunnel if the IP address changes would traffic cannot be sent because there is no interface and multicast
be desirable. The IETF MOBIKE working group is looking into traffic would need to be identified, possibly resulting in a long
providing a solution for IKEv2 but the work is still in progress list of SPD entries. The second requirement is difficult to satisfy
[I-D.ietf-mobike-protocol]. because the traffic that needs to be protected is not necessarily
(e.g., router-to-router tunnel) known a priori [RFC3884]. The third
requirement is equally hard because almost all implementations assume
addresses are assigned on interfaces (rather than configured in SPDs)
for proper source address selection.
8. Tunnel Endpoint Discovery If IPsec tunnel mode SA is modeled as interface, the traffic that
needs protection can be modeled as routes pointing to the interface.
The second requirement is difficult to satisfy because the traffic
that needs to be protected is not necessarily known a priori. The
third requirement is easily solved because IPsec is modeled as an
interface.
The IKEv2 initiator needs to know the address of the IKEv2 responder In practice (2) has been solved by protecting all the traffic (::/0),
to start IKEv2 signaling. A number of ways can be used to provide but there are no inter-operable implementations supporting this
the initiator with this information, for example: feature. For a detailed list of issues pertaining to this, see
[I-D.duffy-ppvpn-ipsec-vlink].
o Using out-of-band mechanisms, e.g., from the ISP's web page. Because applying transport mode to protect a tunnel is a much more
simpler solution and also easily protects link-local and multicast
traffic, we do not recommend using tunnel mode in this context.
Tunnel mode is still discussed in Appendix A.
o Using DNS to look up a service name by appending it to the DNS 5.3. Peer Authorization Database
search path provided by DHCPv4 (e.g. "tunnel-
service.example.com").
o Using a DHCP option. The Peer Authorization Database (PAD) provides the link between SPD
and the key management daemon [RFC4306]. This is defined in
[RFC4301] and hence relevant only when used with IKEv2.
o Using a pre-configured or pre-determined IPv4 anycast address. As there is no way to currently discover the PAD related parameters
dynamically, it is assumed that these are manually configured:
o Using other, unspecified or proprietary methods. o The Identity of the peer which will be asserted in the IKEv2
exchange. There are many different types of identities that can
be used. At least, IPv4 address of the peer should be supported.
For the purpose of this document it is assumed that this address can o The IKEv2 can authenticate the peer using several methods. Pre-
be obtained somehow. Once the address has been learned, it is shared key and X.509 certificate based authentication is required
configured as the tunnel end-point for the configured IPv6-in-IPv4 by [RFC4301]. At least, pre-shared key should be supported as it
tunnel. interoperates with a larger number of implementations.
This problem is also discussed at more length in o The child SA authorization data should contain the IPv4 address of
[I-D.palet-v6ops-tun-auto-disc]. the peer.
9. Recommendations 6. Recommendations
In Section 5 we examined the differences of setting up an IPsec IPv6- In Section 5 we examined the differences of setting up an IPsec IPv6-
in-IPv4 using either tunnel or transport mode. We observe that the in-IPv4 using either transport or tunnel mode. We observe that
transport mode and tunnel mode with generic SPDs are very similar; applying transport mode to a tunnel interface is the simplest and
multicast and routing protocols work over both, and ingress filtering therefore recommended solution.
must be applied on the tunnel interface manually.
Tunnel mode with specific SPDs is slightly more complicated. The
approach does not seem feasible if modelled as an interface, so we do
not recommend it. Without an interface, the main benefit is that it
automatically applies ingress filtering within the IPsec processing.
However, multicast, routing protocols, etc. are not feasible with
this approach, so its applicability is limited to host-to-host or
edge tunnel cases.
Tunnel mode may be more attractive when the IPv4 tunnel endpoint In Appendix A, we also explore what it would take to use so-called
addresses change, as MOBIKE only supports tunnel mode. Specific SPD (SSPD) tunnel mode. Such usage is more complicated
because IPv6 prefixes need to be known a priori and multicast and
link-local traffic do not work over such a tunnel. Fragment handling
in tunnel mode is also more difficult. However, because MOBIKE
[RFC4555] supports only tunnel mode, when the IPv4 endpoints of a
tunnel are dynamic and the other constraints are not applicable,
using tunnel mode may be an acceptable solution.
Therefore our primary recommendation is to use either tunnel mode Therefore our primary recommendation is to use transport mode applied
with generic SPDs or transport mode, and apply ingress filtering on to a tunnel interface. Spoofing can be prevented by enabling ingress
the tunnel. filtering on the tunnel interface.
10. 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. ]]
11. Security Considerations 8. Security Considerations
When you run IPv6-in-IPv4 tunnels (unsecured) over the Internet, it When you run 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 signalled
somehow (e.g., some messages where you authenticate to the server, so somehow (e.g., some messages where you authenticate to the server, so
that you would get a static v6 prefix), someone might be able to that you would get a static v6 prefix), someone might be able to
spoof the signalling (control plane security). spoof the signalling (control 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 the Encapsulating Security Payload (ESP), offers
integrity and data origin authentication, confidentiality, with integrity and data origin authentication, confidentiality, with
optional (at the discretion of the receiver) anti-replay features. optional (at the discretion of the receiver) anti-replay features.
The usage of confidentity-only is discouraged. ESP furthermore The usage of confidentity-only is discouraged. ESP furthermore
provides limited traffic flow confidentality. provides limited traffic flow 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 usage of policies dictated by the Security
Policy Database (SPD). 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 the usage of IPsec for the scenarios described in
Figure 3, Figure 2 and Figure 1 does not aim to protect the end-to- Figure 3, Figure 2 and Figure 1 does not aim to protect the end-to-
end communication. It protects just the tunnel part. It is still end 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 that is not attached to the IPsec
tunnel to spoof packets. tunnel to spoof packets.
12. 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 the
topic. topic.
13. 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, and Alfred
Hines for their substantive feedback. Hoenes for their substantive feedback.
We would like to thank Pasi Eronen for his text contributions. We would like to thank Pasi Eronen for his text contributions and
suggestions for improvement.
14. References 11. References
14.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.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. (IKE)", RFC 2409, November 1998.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
skipping to change at page 16, line 45 skipping to change at page 14, line 38
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
14.2. Informative References 11.2. Informative References
[I-D.ietf-mobike-protocol] [I-D.duffy-ppvpn-ipsec-vlink]
Eronen, P., "IKEv2 Mobility and Multihoming Protocol Duffy, M., "Framework for IPsec Protected Virtual Links
(MOBIKE)", draft-ietf-mobike-protocol-08 (work in for PPVPNs", draft-duffy-ppvpn-ipsec-vlink-00 (work in
progress), February 2006. progress), October 2002.
[I-D.palet-v6ops-tun-auto-disc] [I-D.palet-v6ops-tun-auto-disc]
Palet, J. and M. Diaz, "Analysis of IPv6 Tunnel End-point Palet, J. and M. Diaz, "Analysis of IPv6 Tunnel End-point
Discovery Mechanisms", draft-palet-v6ops-tun-auto-disc-03 Discovery Mechanisms", draft-palet-v6ops-tun-auto-disc-03
(work in progress), January 2005. (work in progress), January 2005.
[RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for [RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 2893, August 2000. IPv6 Hosts and Routers", RFC 2893, August 2000.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001. via IPv4 Clouds", RFC 3056, February 2001.
[RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth,
"Securing L2TP using IPsec", RFC 3193, November 2001.
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation
(NAT) Compatibility Requirements", RFC 3715, March 2004. (NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec [RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec
Transport Mode for Dynamic Routing", RFC 3884, Transport Mode for Dynamic Routing", RFC 3884,
September 2004. September 2004.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating
MPLS in IP or Generic Routing Encapsulation (GRE)",
RFC 4023, March 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
Appendix A. Specific SPDs for Tunnel Mode [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006.
We describe the specific SPD case in an appendix due to its length Appendix A. Using Tunnel Mode
and relative complexity compared to transport mode or generic SPD
tunnel mode.
We assume that this kind of IPsec association is not modelled as an First, we describe the different tunnel mode implementation methods.
interface, because then the link-local traffic would require very We note that in this context, only so-called Specific SPD (SSPD)
complex SPDs as well. model (without a tunnel interface) can be made to work, but has
reduced applicability and the use of a transport mode tunnel is
recommended instead. However, we will describe how the SSPD Tunnel
Mode might look like if one would like to use it in any case.
A.1. Specific SPD for Host-to-Host Scenario A.1. Tunnel Mode Implementation Methods
The following SPD entries assume that there are two hosts Host1 and Tunnel mode could (in theory) be deployed in two very different ways
Host2, whose IPv6 addresses are denoted by IPV6-EP1 and IPV6-EP2 depending on the implementation:
(global addresses) and IPV4 addresses of the tunnel endpoints are
denoted by IPV4-TEP1 and IPV4-TEP2 respectively.
The outbound SPD will encrypt the traffic to the specified global 1. "Generic SPDs": some implementations model the tunnel mode SA as
IPv6 address. an IP interface. In this case, an IPsec tunnel interface is
created and used with "any" address ("::/0 <-> ::/0" ) as IPsec
traffic selectors while setting up the SA. Though this allows
all traffic between the two nodes to be protected by IPsec, the
routing table would decide what traffic gets sent over the
tunnel. Ingress filtering must be separately applied on the
tunnel interface as the IPsec policy checks do not check the IPv6
addresses at all. Routing protocols, multicast, etc. will work
through this tunnel. This mode is very similar to the transport
mode. The SPDs must be interface-specific. However, because IKE
uses IPv4 but the tunnel is IPv6, there is no standard solution
to map the IPv4 interface to IPv6 interface
[I-D.duffy-ppvpn-ipsec-vlink] and this approach is not feasible.
Host1's SPD OUT : 2. "Specific SPDs": some implementations don't model the tunnel mode
SA as an IP interface. Traffic selection is done based on
specific SPD entries, e.g., "2001:db8:1::/48 <-> 2001:db8:
2::/48". As the IPsec session between two endpoints does not
have an interface (though an implementation may have a common
pseudo-interface for all IPsec traffic), there is no DAD, MLD, or
link-local traffic to protect; multicast is not possible over
such a tunnel. Ingress filtering is performed automatically by
the IPsec traffic selectors.
IF SRC = IPV6-EP1 & DST = IPV6-EP2 Ingress filtering is guaranteed by IPsec processing when option (2)
THEN USE ESP TUNNEL MODE SA: is chosen whereas the operator has to enable them explicitly when
outer source = IPv4-TEP1 transport mode or option (1) of tunnel mode SA is chosen.
outer dest = IPV4-TEP2
Host1's SPD IN: In summary, there does not appear to be a standard solution in this
context for the first implementation approach.
IF SRC = IPV6-EP2 && DST = IPV6-EP1 The second approach can be made to work, but is only applicable in
THEN USE ESP TUNNEL MODE SA host-to-host or site-to-router/router-to-site scenarios (i.e., when
outer source = IPV4-TEP2 the IPv6 prefixes can be known a priori), and offers only a limited
outer dest = IPV4-TEP1 set of features (e.g., no multicast) compared to a transport mode
tunnel.
Host2's SPD OUT: When tunnel mode is used, fragment handling [RFC4301] may also be
more difficult compared to transport mode and, depending on
implementation, may need to be reflected in SPDs.
IF SRC = IPV6-EP2 & DST = IPV6-EP1 A.2. Specific SPD for Host-to-Host Scenario
THEN USE ESP TUNNEL MODE SA:
outer source = IPv4-TEP2
outer dest = IPV4-TEP1
Host2's SPD IN: The following SPD entries assume that there are two hosts Host1 and
Host2, whose IPv6 addresses are denoted by IPV6-EP1 and IPV6-EP2
(global addresses) and IPV4 addresses of the tunnel endpoints are
denoted by IPV4-TEP1 and IPV4-TEP2 respectively.
IF SRC = IPV6-EP1 && DST = IPV6-EP2 Host1's SPD:
THEN USE ESP TUNNEL MODE SA: Next Layer
outer source = IPv4-TEP1 Rule Local Remote Protocol Action
outer dest = IPV4-TEP2 ---- ----- ------ ---------- --------
1 IPV6-EP1 IPV6-EP2 ESP BYPASS
2 IPV6-EP1 IPV6-EP2 IKE BYPASS
3 IPv6-EP1 IPV6-EP2 41 PROTECT(ESP,
tunnel{IPV4-TEP1,IPV4-TEP2})
Host2's SPD:
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- --------
1 IPV6-EP2 IPV6-EP1 ESP BYPASS
2 IPV6-EP2 IPV6-EP1 IKE BYPASS
3 IPv6-EP2 IPV6-EP1 41 PROTECT(ESP,
tunnel{IPV4-TEP2,IPV4-TEP1})
"IKE" refers to UDP destination port 500 and possibly also
port 4500 if NAT traversal is used.
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.2. 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 substituting IPV6-EP1
by IPV6-PREF/48. by IPV6-PREF/48.
Please note the bypass entry for host's outbound SPD, absent in Please note the bypass entry for host's SPD, absent in router's SPD.
router's inbound SPD. While this might be an implementation matter While this might be an implementation matter for host-to-router
for host-to-router tunneling, having a similar entry, "SRC=IPV6- tunneling, having a similar entry, "Local=IPV6-PREF/48 & Remote=IPV6-
PREF/48 & DST=IPV6-PREF/48" is critical for site-to-router tunneling. PREF/48" is critical for site-to-router tunneling.
Host's SPD OUT: Host's SPD:
Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- --------
1 IPV6-EP1 IPV6-EP2 ESP BYPASS
2 IPV6-EP1 IPV6-EP2 IKE BYPASS
3 IPV6-EP1 IPV6-EP1 ANY BYPASS
4 IPV6-EP1 ANY ANY PROTECT(ESP,
tunnel{IPV4-TEP1,IPV4-TEP2})
IF SRC=IPV6-EP1 & DST = IPV6-EP1 Router's SPD:
THEN BYPASS Next Layer
Rule Local Remote Protocol Action
---- ----- ------ ---------- --------
1 IPV6-EP2 IPV6-EP1 ESP BYPASS
2 IPV6-EP2 IPV6-EP1 IKE BYPASS
3 ANY IPV6-EP1 ANY PROTECT(ESP,
tunnel{IPV4-TEP1,IPV4-TEP2})
IF SRC = IPV6-EP1 & DST = any The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and
THEN USE ESP TUNNEL MODE SA: ID_IPV6_ADDR_RANGE or ID_IPV6_ADDR_SUBNET as its phase 2 identity.
outer source = IPv4-TEP1 The starting address is zero IP address and the end address is all
outer dest = IPV4-TEP2 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
IKEv2, the traffic selectors are used to carry the same information.
Host's SPD IN: Appendix B. Optional Features
IF SRC = any && DST = IPV6-EP1 B.1. Dynamic Address Configuration
THEN use ESP TUNNEL MODE SA
outer source = IPV4-TEP2
outer dest = IPV4-TEP1
Router's SPD OUT: With the exchange of protected configuration payloads, IKEv2 is able
to provide the IKEv2 peer with DHCP-like information payloads. These
configuration payloads are exchanged between the IKEv2 initiator and
the responder.
IF SRC = any & DST = IPV6-EP1 This could be used (for example) by the host in the host-to-router
THEN USE ESP TUNNEL MODE SA: scenario to obtain the IPv6 address from the ISP as part of setting
outer source = IPv4-TEP2 up the IPsec tunnel mode SA. The details of these procedures are out
outer dest = IPV4-TEP1 of scope of this memo.
Router's SPD IN: B.2. NAT Traversal and Mobility
IF SRC = IPV6-EP1 && DST = any Network address (and port) translation devices are commonly found in
THEN use ESP TUNNEL MODE SA today's networks. A detailed description of the problem of IPsec
outer source = IPV4-TEP1 protected data traffic traversing a NAT including requirements are
outer dest = IPV4-TEP2 discussed in [RFC3715].
The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and IKEv2 can detect the presence of a NAT automatically by sending
ID_IPV6_ADDR_RANGE or ID_IPV6_ADDR_SUBNET as its phase 2 identity. NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads in
The starting address is zero IP address and the end address is all the initial IKE_SA_INIT exchange. Once a NAT is detected and both
ones for ID_IPV6_ADDR_RANGE. The starting address is zero IP address end points support IPsec NAT traversal extensions UDP encapsulation
and the end address is all zeroes for ID_IPV6_ADDR_SUBNET. With can be enabled.
IKEv2, the traffic selectors are used to carry the same information.
More details about UDP encapsulation of IPsec protected IP packets
can be found in [RFC3948].
For IPv6-in-IPv4 tunneling, NAT traversal is interesting for two
reasons:
1. One of the tunnel endpoints is often behind a NAT, and configured
tunneling, using protocol 41, is not guaranteed to traverse the
NAT. Hence, using IPsec tunnels would enable one to both set-up
a secure tunnel, and set-up a tunnel where it might not always be
possible without other tunneling mechanisms.
2. Using NAT traversal allows the outer address to change without
having to renegotiate the SAs. This could be very beneficial for
a crude form of mobility, and in scenarios where the NAT changes
the IP addresses frequently. However, as the outer address may
change, this might introduce new security issues, and using
tunnel mode would be most appropriate.
When NAT is not applied, the second benefit would still be desirable.
In particular, using manually configured tunneling is an operational
challenge with dynamic IP addresses as both ends need to be
reconfigured if an address changes. Therefore an easy and efficient
way to re-establish the IPsec tunnel if the IP address changes would
be desirable. MOBIKE [RFC4555] provides a solution when IKEv2 is
used but only supports tunnel mode.
B.3. Tunnel Endpoint Discovery
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
the initiator with this information, for example:
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
search path provided by DHCPv4 (e.g. "tunnel-
service.example.com").
o Using a DHCP option.
o Using a pre-configured or pre-determined IPv4 anycast address.
o Using other, unspecified or proprietary methods.
For the purpose of this document it is assumed that this address can
be obtained somehow. Once the address has been learned, it is
configured as the tunnel end-point for the configured IPv6-in-IPv4
tunnel.
This problem is also discussed at more length in
[I-D.palet-v6ops-tun-auto-disc].
However, simply discovering the tunnel endpoint is not sufficient for
establishing an IKE session with the peer. The PAD information (see
Section 5.3) also needs to be learnt dynamically. Hence, currently
automatic endpoint discovery provides benefit only if PAD information
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
Email: rfg@acm.org Email: rfg@acm.org
skipping to change at page 20, line 26 skipping to change at page 20, line 44
Nokia Nokia
313 Fairchild Drive 313 Fairchild Drive
Mountain View CA-94043 Mountain View CA-94043
USA USA
Email: mohanp@sbcglobal.net Email: mohanp@sbcglobal.net
Pekka Savola Pekka Savola
CSC/FUNET CSC/FUNET
Espoo Espoo
Finnland Finland
Email: psavola@funet.fi Email: psavola@funet.fi
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
 End of changes. 84 change blocks. 
330 lines changed or deleted 355 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/