< draft-ietf-v6ops-ipsec-tunnels-04.txt   draft-ietf-v6ops-ipsec-tunnels-05.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: May 25, 2007 Nokia Expires: July 19, 2007 Nokia
P. Savola P. Savola
CSC/FUNET CSC/FUNET
H. Tschofenig H. Tschofenig
Siemens Siemens
November 21, 2006 January 15, 2007
Using IPsec to Secure IPv6-in-IPv4 Tunnels Using IPsec to Secure IPv6-in-IPv4 Tunnels
draft-ietf-v6ops-ipsec-tunnels-04.txt draft-ietf-v6ops-ipsec-tunnels-05.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 May 25, 2007. This Internet-Draft will expire on July 19, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2006). Copyright (C) The IETF Trust (2007).
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 in Transport Mode. No additional protocol
described beyond those available with the IPsec framework. extensions are described beyond those available with the IPsec
framework.
Table of Contents Table of Contents
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. IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 10 5.1. IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 10
5.2. IPsec Tunnel Mode . . . . . . . . . . . . . . . . . . . . 10 5.2. Peer Authorization Database and Identities . . . . . . . . 12
5.3. Peer Authorization Database . . . . . . . . . . . . . . . 12
6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 12 6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Using Tunnel Mode . . . . . . . . . . . . . . . . . . 15 Appendix A. Using Tunnel Mode . . . . . . . . . . . . . . . . . . 15
A.1. Tunnel Mode Implementation Methods . . . . . . . . . . . . 15 A.1. Tunnel Mode Implementation Methods . . . . . . . . . . . . 16
A.2. Specific SPD for Host-to-Host Scenario . . . . . . . . . . 16 A.2. Specific SPD for Host-to-Host Scenario . . . . . . . . . . 17
A.3. Specific SPD for Host-to-Router scenario . . . . . . . . . 17 A.3. Specific SPD for Host-to-Router scenario . . . . . . . . . 17
Appendix B. Optional Features . . . . . . . . . . . . . . . . . . 18 Appendix B. Optional Features . . . . . . . . . . . . . . . . . . 18
B.1. Dynamic Address Configuration . . . . . . . . . . . . . . 18 B.1. Dynamic Address Configuration . . . . . . . . . . . . . . 18
B.2. NAT Traversal and Mobility . . . . . . . . . . . . . . . . 18 B.2. NAT Traversal and Mobility . . . . . . . . . . . . . . . . 18
B.3. Tunnel Endpoint Discovery . . . . . . . . . . . . . . . . 19 B.3. Tunnel Endpoint Discovery . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 22
1. Introduction 1. Introduction
skipping to change at page 3, line 18 skipping to change at page 3, line 18
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 that had not been adequately [RFC4213] identified a number of threats that had not been adequately
analyzed or addressed in its predecessor [RFC2893]. The most analyzed or addressed in its predecessor [RFC2893]. The most
complete solution is to use IPsec to protect IPv6-in-IPv4 tunneling. complete solution is to use IPsec to protect IPv6-in-IPv4 tunneling.
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 analyze 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 bits [RFC4213]) from the encapsulated packets to the Notification bits [RFC4213]) from the encapsulated packets to the
tunnel path is out of scope. tunnel path is out of scope.
The use of the word "interface" or the phrase "IP interface" refers
to the IPv6 interface that must be present on any IPv6 node to send
or receive IPv6 packets. The use of the phrase "tunnel interface"
refers to the interface that receives the IPv6-in-IPv4 tunneled
packets over IPv4.
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. The IPv4 source address of the encapsulating ("outer") packet can 1. The IPv4 source address of the encapsulating ("outer") packet can
be spoofed. be spoofed.
2. The IPv6 source address of the encapsulated ("inner") packet can 2. The IPv6 source address of the encapsulated ("inner") packet can
be spoofed. be spoofed.
IPsec can obviously also provide payload integrity, replay detection, The reason threat (1) exists is the lack of universal deployment of
and confidentiality as well for the part of the end-to-end path that
is tunneled.
The reason threat (1) exists is the lack of widespread deployment of
IPv4 ingress filtering [RFC3704]. The reason threat (2) exists is IPv4 ingress filtering [RFC3704]. The reason threat (2) exists is
that the IPv6 packet is encapsulated in IPv4 and hence may escape that the IPv6 packet is encapsulated in IPv4 and hence may escape
IPv6 ingress filtering. [RFC4213] specifies the following strict IPv6 ingress filtering. [RFC4213] specifies the following strict
address 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,
confidentiality. confidentiality, replay protection, and origin protection between
tunnel endpoints.
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 provided 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 Encapsulating Security Payload (ESP) or In transport mode, the IPsec Encapsulating Security Payload (ESP) or
Authentication Header (AH) security association (SA) is established 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 =
skipping to change at page 5, line 23 skipping to change at page 5, line 27
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 this The outer IPv4 addresses may be spoofed and IPsec cannot detect this
in tunnel mode; the packets will be demultiplexed based on the SPI in tunnel mode; the packets will be demultiplexed based on the SPI
and possibly the IPv6 address bound to the SA. Thus, the outer and possibly the IPv6 address bound to the SA. Thus, the outer
address spoofing is irrelevant as long as the decryption succeeds and address spoofing is irrelevant as long as the decryption succeeds and
the 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, 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. Note that even though transport document recommends transport mode. Note that even though transport
rather than tunnel mode is recommended, an IPv6-in-IPv4 tunnel rather than tunnel mode is recommended, an IPv6-in-IPv4 tunnel
specified by Protocol 41 still exists. specified by Protocol 41 still exists.
3. Scenarios and Overview 3. Scenarios and Overview
There are roughly three scenarios: There are roughly three scenarios:
1. (generic) router-to-router tunnels. 1. (generic) router-to-router tunnels.
skipping to change at page 8, line 36 skipping to change at page 8, line 36
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 for 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 previously defined in [RFC2401] The IPsec security architecture was previously defined in [RFC2401]
and is now superseded by [RFC4301]. IKE was originally defined in and is now superseded by [RFC4301]. IKE was originally defined in
[RFC2409] (which is called as IKEv1 in this document) and is now [RFC2409] (which is called IKEv1 in this document) and is now
superseded by [RFC4306] (called IKEv2; see also [RFC4718]). There superseded by [RFC4306] (called IKEv2; see also [RFC4718]). There
are several differences between them. The differences relevant to are several differences between them. The differences relevant to
this document 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 require allowing IP as the next layer protocol
selectors when an IPsec SA is negotiated. [RFC4301] also allows in traffic selectors when an IPsec SA is negotiated. In
IP as the next layer protocol (like TCP or UDP) in traffic contrast, [RFC4301] requires supporting IP as the next layer
selectors. protocol (like TCP or UDP) in traffic 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 IKEv2. If IKEv1 is used, then multiple SAs
multiple SAs need to be set up for each traffic selector. need to be set up, one for each traffic selector.
Note that the existing implementations based on [RFC2409] may already Note that the existing implementations based on IKEv1 may already be
be able to support the [RFC4301] features described in (1) and (2). able to support the [RFC4301] features described in (1) and (2). If
If appropriate, the deployment may choose to use either version of appropriate, the deployment may choose to use either version of the
the security architecture. security architecture.
IKEv2 supports features useful for configuring and securing tunnels IKEv2 supports features useful for configuring and securing tunnels
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 hosts or sites to EAP payloads. This can be used to authenticate hosts or sites to
an 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 2. IKEv2 supports dynamic address configuration, which may be used
to configure the IPv6 address of the host. to configure the IPv6 address of the host.
skipping to change at page 9, line 33 skipping to change at page 9, line 33
For the purposes of this document, where the confidentiality of ESP For the purposes of this document, where the confidentiality of ESP
[RFC4303] is not required, AH [RFC4302] can be used as an alternative [RFC4303] is not required, AH [RFC4302] can be used as an alternative
to ESP. The main difference is that AH is able to provide integrity to ESP. The main difference is that AH is able to provide integrity
protection for certain fields in the outer IPv4 header and IPv4 protection for certain fields in the outer IPv4 header and IPv4
options. However, as the outer IPv4 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 establishing an IPsec tunnel for The following section describes the SPD entries for setting up the
the protection of IPv4/IPv6 data traffic. IPsec transport mode SA to protect the IPv6 traffic.
The packet format is the same for both transport mode and tunnel mode Several requirements arise when IPsec is used to protect the IPv6
as shown in Table 1. traffic (inner header) for the scenarios listed in Section 3.
+----------------------------+------------------------------------+ 1. All of IPv6 traffic should be protected, including link-local
| Components (first to last) | Contains | (e.g., Neighbor Discovery) and multicast traffic. Without this,
+----------------------------+------------------------------------+ an attacker can pollute the IPv6 neighbor cache causing
| IPv4 header | (src = IPV4-TEP1, dst = IPV4-TEP2) | disruption in communication between the two routers.
| ESP header | |
| IPv6 header | (src = IPV6-EP1, dst = IPV6-EP2) |
| (payload) | |
+----------------------------+------------------------------------+
Table 1: Packet Format for IPv6/IPv4 Tunnels. 2. In router-to-router tunnels, the source and destination addresses
of the traffic could come from a wide range of prefixes that are
normally learned through routing. As routing can always learn a
new prefix, one cannot assume that all the prefixes are known a
priori [RFC3884]. This mainly affects scenario (1).
3. Source address selection depends on the notions of routes and
interfaces. This implies that the reachability to the various
IPv6 destinations appear as routes in the routing table. This
affects scenarios (2) and (3).
The IPv6 traffic can be protected using transport or tunnel mode.
There are many problems when using tunnel mode as implementations may
or may not model the IPsec tunnel mode SA as an interface as
described in Appendix A.1.
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
entries for protecting all traffic between the two endpoints must be
described. Evaluating against the requirements above, all link-local
traffic multicast traffic would need to be identified, possibly
resulting in a long list of SPD entries. The second requirement is
difficult to satisfy, because the traffic needing protection is not
necessarily (e.g., router-to-router tunnel) known a priori [RFC3884].
The third requirement is also problematic, because almost all
implementations assume addresses are assigned on interfaces (rather
than configured in SPDs) for proper source address selection.
If the IPsec tunnel mode SA is modeled as interface, the traffic that
needs protection can be modeled as routes pointing to the interface.
But the second requirement is difficult to satisfy, because the
traffic needing protection is not necessarily known a priori. The
third requirement is easily solved, because IPsec is modeled as an
interface.
In practice, (2) has been solved by protecting all the traffic
(::/0), but no inter-operable implementations support this feature.
For a detailed list of issues pertaining to this, see
[I-D.duffy-ppvpn-ipsec-vlink].
Because applying transport mode to protect a tunnel is a much simpler
solution and also easily protects link-local and multicast traffic,
we do not recommend using tunnel mode in this context. Tunnel mode
is, however, discussed further in Appendix A.
This document assumes that tunnels are manually configured on both
sides and the ingress filtering is manually setup to discard spoofed
packets.
5.1. IPsec Transport Mode 5.1. IPsec Transport Mode
Transport mode has typically been applied to L2TP, GRE, and other Transport mode has typically been applied to L2TP, GRE, and other
tunneling methods, especially when the user wants to tunnel non-IP tunneling methods, especially when the user wants to tunnel non-IP
traffic. [RFC3884], [RFC3193], and [RFC4023] provide examples of traffic. [RFC3884], [RFC3193], and [RFC4023] provide examples of
applying transport mode to protect tunnel traffic that spans only a applying transport mode to protect tunnel traffic that spans only 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
skipping to change at page 10, line 40 skipping to change at page 11, line 32
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 packet format is as shown in Table 1.
and protocol value 41 as phase 2 identities. With IKEv2, the traffic
selectors are used to carry the same information.
5.2. IPsec Tunnel Mode
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
tunnel [RFC4301].
Several requirements arise when IPsec is used to protect the IPv6
traffic (inner header) for the scenarios listed in Section 3.
1. All of IPv6 traffic should be protected, including link-local
(e.g., Neighbor Discovery) and multicast traffic.
2. In router-to-router tunnels, the source and destination addresses
of the traffic could come from a wide range of prefixes that are
normally learned through routing. As routing can always learn a
new prefix, there is no way to know all the prefixes a priori
[RFC3884].
3. Source address selection depends on the notions of routes and
interfaces. This affects scenarios (2) and (3).
Implementations may or may not model the IPsec tunnel mode SA as an
interface as described in Appendix A.1.
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
entries for protecting all traffic between the two endpoints must be
described. Evaluating against the requirements above, link-local
traffic cannot be sent, because there is no interface and multicast
traffic would need to be identified, possibly resulting in a long
list of SPD entries. The second requirement is difficult to satisfy,
because the traffic needing protection is not necessarily (e.g.,
router-to-router tunnel) known a priori [RFC3884]. The third
requirement is also problematical, because almost all implementations
assume addresses are assigned on interfaces (rather than configured
in SPDs) for proper source address selection.
If the IPsec tunnel mode SA is modeled as interface, the traffic that +----------------------------+------------------------------------+
needs protection can be modeled as routes pointing to the interface. | Components (first to last) | Contains |
The second requirement is difficult to satisfy, because the traffic +----------------------------+------------------------------------+
needing protection is not necessarily known a priori. The third | IPv4 header | (src = IPV4-TEP1, dst = IPV4-TEP2) |
requirement is easily solved, because IPsec is modeled as an | ESP header | |
interface. | IPv6 header | (src = IPV6-EP1, dst = IPV6-EP2) |
| (payload) | |
+----------------------------+------------------------------------+
In practice, (2) has been solved by protecting all the traffic Table 1: Packet Format for IPv6/IPv4 Tunnels.
(::/0), bu no inter-operable implementations support this feature.
For a detailed list of issues pertaining to this, see
[I-D.duffy-ppvpn-ipsec-vlink].
Because applying transport mode to protect a tunnel is a much simpler The IDci and IDcr payloads of IKEv1 carry the IPv4-TEP1, IPV4-TEP2,
solution and also easily protects link-local and multicast traffic, and protocol value 41 as phase 2 identities. With IKEv2, the traffic
we do not recommend using tunnel mode in this context. Tunnel mode selectors are used to carry the same information.
is, however, discussed further in Appendix A.
5.3. Peer Authorization Database 5.2. Peer Authorization Database and Identities
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 currently defined way to discover the PAD-related As there is no currently defined way to discover the PAD-related
parameters dynamically, it is assumed that these are manually parameters dynamically, it is assumed that these are manually
configured: configured:
o The Identity of the peer asserted in the IKEv2 exchange: Many o The Identity of the peer asserted in the IKEv2 exchange: Many
skipping to change at page 12, line 27 skipping to change at page 12, line 27
address of the peer should be supported. address of the peer should be supported.
o IKEv2 can authenticate the peer by several methods. Pre-shared o IKEv2 can authenticate the peer by several methods. Pre-shared
key and X.509 certificate-based authentication is required by key and X.509 certificate-based authentication is required by
[RFC4301]. At least, pre-shared key should be supported, because [RFC4301]. At least, pre-shared key should be supported, because
it 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.
IPv4 address should be supported as Identity during the key exchange.
As this not provide Identity protection, main mode or aggressive mode
can be used with IKEv1.
6. Recommendations 6. Recommendations
In Section 5, we examined the differences between setting up an IPsec In Section 5, we examined the differences between setting up an IPsec
IPv6-in-IPv4 tunnel using either transport or tunnel mode. We IPv6-in-IPv4 tunnel using either transport or tunnel mode. We
observe that applying transport mode to a tunnel interface is the observe that applying transport mode to a tunnel interface is the
simplest and 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. Source address spoofing can be limited by to a tunnel interface. Source address spoofing can be limited by
enabling ingress filtering on the tunnel interface. enabling ingress filtering on the tunnel interface.
Manual keying must not be used as large amounts of IPv6 traffic may
be carried over the tunnels and doing so would make it easier for an
attacker to recover the keys. IKEv1 or IKEv2 must be used for
establishing the IPsec SAs. IKEv2 should be used where supported and
available; if not, IKEv1 may be used instead.
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 running 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 signaled source address (data plane security), or if the tunnel is signaled
skipping to change at page 14, line 4 skipping to change at page 14, line 16
The authors are listed in alphabetical order. The authors are listed in alphabetical order.
Suresh Satapati also participated in the initial discussions on this 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, Alfred Florian Weimer, Elwyn Davies, Eric Vyncke, Merike Kaeo, Alfred
Hoenes, and Francis Dupont for their substantive feedback. Hoenes, Francis Dupont, and David Black 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 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 learned dynamically. Hence, currently, Section 5.2) 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 IETF Trust (2006). Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 34 change blocks. 
106 lines changed or deleted 122 lines changed or added

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