draft-ietf-v6ops-ipsec-tunnels-01.txt   draft-ietf-v6ops-ipsec-tunnels-02.txt 
IPv6 Operations WG R. Graveman IPv6 Operations WG R. Graveman
Internet-Draft RFG Security, LLC Internet-Draft RFG Security, LLC
Expires: February 26, 2006 M. Parthasarathy Intended status: Informational M. Parthasarathy
Nokia Expires: September 7, 2006 Nokia
P. Savola P. Savola
CSC/FUNET CSC/FUNET
H. Tschofenig H. Tschofenig
Siemens Siemens
August 25, 2005 March 6, 2006
Using IPsec to Secure IPv6-in-IPv4 Tunnels Using IPsec to Secure IPv6-in-IPv4 Tunnels
draft-ietf-v6ops-ipsec-tunnels-01.txt draft-ietf-v6ops-ipsec-tunnels-02.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 February 26, 2006. This Internet-Draft will expire on September 7, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). 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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 2, line 31 skipping to change at page 2, line 31
6. Dynamic Address Configuration . . . . . . . . . . . . . . . . 12 6. Dynamic Address Configuration . . . . . . . . . . . . . . . . 12
7. NAT Traversal and Mobility . . . . . . . . . . . . . . . . . . 13 7. NAT Traversal and Mobility . . . . . . . . . . . . . . . . . . 13
8. Tunnel Endpoint Discovery . . . . . . . . . . . . . . . . . . 14 8. Tunnel Endpoint Discovery . . . . . . . . . . . . . . . . . . 14
9. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 14 9. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 14
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
14.1. Normative References . . . . . . . . . . . . . . . . . . . 16 14.1. Normative References . . . . . . . . . . . . . . . . . . . 16
14.2. Informative References . . . . . . . . . . . . . . . . . . 17 14.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Specific SPDs for Tunnel Mode . . . . . . . . . . . . 17 Appendix A. Specific SPDs for Tunnel Mode . . . . . . . . . . . . 17
A.1. Specific SPD for Host-to-Host Scenario . . . . . . . . . . 18 A.1. Specific SPD for Host-to-Host Scenario . . . . . . . . . . 17
A.2. Specific SPD for Host-to-Router scenario . . . . . . . . . 18 A.2. Specific SPD for Host-to-Router scenario . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 21
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 [I-D.ietf-v6ops-mech-v2] as one of configured) IPv6-in-IPv4 tunneling [RFC4213] as one of the IPv6
the IPv6 transition mechanisms for IPv6 deployment. transition mechanisms for IPv6 deployment.
[I-D.ietf-v6ops-mech-v2] identified a number of threats which had not [RFC4213] identified a number of threats which had not been
been adequately analyzed or addressed in its predecessor, [RFC2893]. adequately analyzed or addressed in its predecessor, [RFC2893]. The
The most complete solution is to use IPsec to protect IPv6-in-IPv4 most complete solution is to use IPsec to protect IPv6-in-IPv4
tunneling. The document was intentionally not expanded to include tunneling. The document was intentionally not expanded to include
the details on how to set up an IPsec-protected tunnel in an the details on how to set up an IPsec-protected tunnel in an
interoperable manner, but instead the details were deferred to this interoperable manner, but instead the details were deferred to this
memo. memo.
First this document analyses the threats and scenarios that can be First this document analyses the threats and scenarios that can be
addressed by IPsec. Next, this document discusses some of the addressed by IPsec. Next, this document discusses some of the
assumptions made by this document for successful IPsec Security assumptions made by this document for successful IPsec Security
Association (SA) establishment. Then, it gives the details of Association (SA) establishment. Then, it gives the details of
Internet Key Exchange (IKE) and IP security (IPsec) exchange with Internet Key Exchange (IKE) and IP security (IPsec) exchange with
packet formats and Security Policy Database (SPD) entries. Finally, packet formats and Security Policy Database (SPD) entries. Finally,
it discusses the usage of IPsec NAT-traversal mechanism that can be it discusses the usage of IPsec NAT-traversal mechanism that can be
used with configured tunnels in some scenarios. used with configured tunnels in some scenarios.
This document does not address the use of IPsec for tunnels which are This document does not address the use of IPsec for tunnels which 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 [I-D.ietf-v6ops-mech-v2]) from the Notification (ECN) bits [RFC4213]) from the encapsulated packets to
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
[I-D.ietf-v6ops-mech-v2] is mostly concerned about address spoofing [RFC4213] is mostly concerned about address spoofing threats:
threats:
1. IPv4 address of the encapsulating ("outer") packet can be 1. IPv4 address of the encapsulating ("outer") packet can be
spoofed. spoofed.
2. IPv6 address of the encapsulated ("inner") packet can be spoofed. 2. IPv6 address of the encapsulated ("inner") packet can be spoofed.
IPsec can obviously also provide payload integrity and IPsec can obviously also provide payload integrity and
confidentiality as well for the part of the end-to-end path that is confidentiality as well for the part of the end-to-end path that is
tunneled. tunneled.
The reason for threat (1) is the lack of widespread deployment of The reason for threat (1) is the lack of widespread deployment of
IPv4 ingress filtering [RFC3704]. The reason for threat (2) is that IPv4 ingress filtering [RFC3704]. The reason for threat (2) is that
the IPv6 packet is encapsulated in IPv4 and hence may escape IPv6 the IPv6 packet is encapsulated in IPv4 and hence may escape IPv6
ingress filtering. [I-D.ietf-v6ops-mech-v2] specifies the following ingress filtering. [RFC4213] specifies the following strict address
strict address checks as mitigating measures: 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., checks whether the packet is IPv4 ingress filtering, i.e., check whether the packet is received
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. IPsec can be used in two ways, in transport and
tunnel mode; further comparison is done in Section 5.1. tunnel mode; further comparison is done in Section 5.1.
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 (ESP) and then matches the packet against the the IPsec transform (e.g., ESP) and then matches the packet against
Security Parameter Index (SPI) and the inbound selectors associated the Security Parameter Index (SPI) and the inbound selectors
with the SA to verify that the packet is appropriate for the SA via associated with the SA to verify that the packet is appropriate for
which it was received. A successful verification implies that the the SA via which it was received. A successful verification implies
packet came from the right IPv4 endpoint as the SA is bound to the that the packet came from the right IPv4 endpoint as the SA is bound
IPv4 source address. to the IPv4 source address.
This prevents threat (1) but not the threat (2). IPsec in transport This prevents threat (1) but not the threat (2). IPsec in transport
mode does not verify the contents of the payload itself where the mode does not verify the contents of the payload itself where the
IPv6 addresses are carried, that is, two nodes that are using IPsec IPv6 addresses are carried, that is, two nodes that are using IPsec
transport mode to secure the tunnel can spoof the inner payload. The transport mode to secure the tunnel can spoof the inner payload. The
packet will be decapsulated successfully and accepted. packet will be decapsulated successfully and accepted.
The shortcoming can be mitigated by IPv6 ingress filtering i.e., The shortcoming can be mitigated by IPv6 ingress filtering i.e.,
check that the packet is arriving from the interface in the direction check that the packet is arriving from the interface in the direction
of the route towards the tunnel end-point, similar to a Strict of the route towards the tunnel end-point, similar to a Strict
skipping to change at page 5, line 9 skipping to change at page 5, line 9
In most implementations, a transport mode SA is applied to a normal In most implementations, a transport mode SA is applied to a normal
IPv6-in-IPv4 tunnel. Therefore, ingress filtering can be applied in IPv6-in-IPv4 tunnel. Therefore, ingress filtering can be applied in
the tunnel interface. (Transport mode is often also used in other the tunnel interface. (Transport mode is often also used in other
kind of tunnels such as GRE and L2TP.) kind of tunnels such as GRE and L2TP.)
2.2. IPsec in Tunnel Mode 2.2. IPsec in Tunnel Mode
In tunnel mode, the IPsec SA is established to protect the traffic In tunnel mode, the IPsec SA is established to protect the traffic
defined by (IPv6-source, IPv6-destination). On receiving such an defined by (IPv6-source, IPv6-destination). On receiving such an
IPsec packet, the receiver first applies the IPsec transform (ESP) IPsec packet, the receiver first applies the IPsec transform (e.g.,
and then matches the packet against the SPI and the inbound selectors ESP) and then matches the packet against the SPI and the inbound
associated with the SA to verify that the packet is appropriate for selectors associated with the SA to verify that the packet is
the SA via which it was received. The successful verification appropriate for the SA via which it was received. The successful
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.
Tunnel mode SA can be used in two ways depending on whether it is A Tunnel mode SA can be used in two ways depending on whether it is
modelled as an interface or not. These are described in section modelled as an interface or not. These are described in section
Section 5.3. Section 5.3.
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-route/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.
3. Host-to-host tunnels. 3. Host-to-host tunnels.
3.1. Router-to-Router Tunnels 3.1. Router-to-Router Tunnels
IPv6/IPv4 hosts and routers can tunnel IPv6 datagrams over regions of IPv6/IPv4 hosts and routers can tunnel IPv6 datagrams over regions of
IPv4 routing topology by encapsulating them within IPv4 packets. IPv4 routing topology by encapsulating them within IPv4 packets.
Tunneling can be used in a variety of ways. Tunneling can be used in a variety of ways.
skipping to change at page 8, line 25 skipping to change at page 8, line 25
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 can be bound to the specific address. The
address verification prevents IPv6 address spoofing completely. address verification prevents IPv6 address spoofing completely.
As noted in Introduction, automatic host-to-host tunneling methods As noted in the Introduction, automatic host-to-host tunneling
(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]
and now superseded by [I-D.ietf-ipsec-rfc2401bis]. IKE was and now superseded by [RFC4301]. IKE was originally defined in
originally defined in [RFC2409] (which is referred to as IKEv1 in [RFC2409] (which is referred to as IKEv1 in this document) and is now
this document) and is now superseded by [I-D.ietf-ipsec-ikev2] superseded by [RFC4306] (referred to as IKEv2). There are several
(referred to as IKEv2). There are several differences between them. differences between them. The differences relevant to this document
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 IPsec SA is negotiated. [I-D.ietf-ipsec- selectors when an IPsec SA is negotiated. [RFC4301] also allows
rfc2401bis] also allows IP as the next layer protocol like TCP or IP as the next layer protocol like TCP or UDP in traffic
UDP in traffic selectors. selectors.
2. [RFC2401] does not support transport mode SAs between hosts and 2. [RFC2401] does not support transport mode SAs between hosts and
security gateways. [I-D.ietf-ipsec-rfc2401bis] supports security gateways. [RFC4301] supports transport mode SA between
transport mode SA between hosts and security gateway to provide hosts and security gateway to provide link security e.g., IP-IP
link security e.g., IP-IP tunnel protected with IPsec. tunnel protected with IPsec.
3. [I-D.ietf-ipsec-rfc2401bis] assumes IKEv2, as some of the new 3. [RFC4301] assumes IKEv2, as some of the new features cannot be
features cannot be negotiated using IKEv1. It is valid to negotiated using IKEv1. It is valid to negotiate multiple
negotiate multiple traffic selectors for a given IPsec SA in traffic selectors for a given IPsec SA in [RFC4301]. This is
[I-D.ietf-ipsec-rfc2401bis]. This is possible only with possible only with [RFC4306]. If [RFC2409] is used, then
[I-D.ietf-ipsec-ikev2]. If [RFC2409] is used, then multiple SAs multiple SAs need to be set up for each traffic selector.
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 [I-D.ietf-ipsec-rfc2401bis] features described be able to support the [RFC4301] features described in (1) and (2).
in (1) and (2). If appropriate, the deployment may choose to use the If appropriate, the deployment may choose to use the two versions of
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 which 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.
We do not consider the usage of the IP Authentication Header (AH) For the purposes of this document, where the confidentiality of ESP
[I-D.ietf-ipsec-rfc2402bis] as ESP [I-D.ietf-ipsec-esp-v3] provides is not required, Authentication Header (AH) [RFC4302] can be used
security services (such as integrity protection without interchangeably. The main difference is that AH is able to provide
confidentiality protection using 'NULL' encryption) which are integrity-protection for certain fields in the outer IP header and IP
comparable with AH. This is explicitly stated in [I-D.ietf-ipsec- options. However, as the outer IP header will be discarded in any
rfc2401bis]. case and those particular fields are not believed to be relevant in
this particular application, there is no particular reason to use AH.
5. IPsec Configuration Details 5. IPsec Configuration Details
This section describes details about establishment of an IPsec tunnel This section describes details about the establishment of an IPsec
for the protection of IPv4/IPv6 data traffic. However, first we will tunnel for the protection of IPv4/IPv6 data traffic. However, first
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, and the salient
differences between transport and tunnel modes. 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 | |
skipping to change at page 14, line 28 skipping to change at page 14, line 28
o Using a pre-configured or pre-determined IPv4 anycast address. o Using a pre-configured or pre-determined IPv4 anycast address.
o Using other, unspecified or proprietary methods. o Using other, unspecified or proprietary methods.
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 [I-D.palet-v6ops- This problem is also discussed at more length in
tun-auto-disc]. [I-D.palet-v6ops-tun-auto-disc].
9. Recommendations 9. 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 tunnel or transport mode. We observe that the
transport mode and tunnel mode with generic SPDs are very similar; transport mode and tunnel mode with generic SPDs are very similar;
multicast and routing protocols work over both, and ingress filtering multicast and routing protocols work over both, and ingress filtering
must be applied on the tunnel interface manually. must be applied on the tunnel interface manually.
Tunnel mode with specific SPDs is slightly more complicated. The Tunnel mode with specific SPDs is slightly more complicated. The
skipping to change at page 15, line 38 skipping to change at page 15, line 38
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 confidentality.
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 [I-D.ietf-ipsec-ikev2]. 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 12. 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 13. 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, and Eric Vyncke for their substantive Florian Weimer, Elwyn Davies, Eric Vyncke, Merike Kaeo, and Alfred
feedback. Hines 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.
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-ipsec-esp-v3]
Kent, S., "IP Encapsulating Security Payload (ESP)",
draft-ietf-ipsec-esp-v3-10 (work in progress), March 2005.
[I-D.ietf-ipsec-ikev2]
Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-17 (work in progress),
October 2004.
[I-D.ietf-ipsec-rfc2401bis]
Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work
in progress), April 2005.
[I-D.ietf-v6ops-mech-v2]
Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-07
(work in progress), March 2005.
[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.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710,
October 1999.
[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.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005. RFC 3948, January 2005.
14.2. Informative References [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[I-D.ietf-ipsec-rfc2402bis] [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Kent, S., "IP Authentication Header", Internet Protocol", RFC 4301, December 2005.
draft-ietf-ipsec-rfc2402bis-11 (work in progress),
March 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
14.2. Informative References
[I-D.ietf-mobike-protocol] [I-D.ietf-mobike-protocol]
Eronen, P., "IKEv2 Mobility and Multihoming Protocol Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", draft-ietf-mobike-protocol-01 (work in (MOBIKE)", draft-ietf-mobike-protocol-08 (work in
progress), July 2005. progress), February 2006.
[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.
[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.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
Appendix A. Specific SPDs for Tunnel Mode Appendix A. Specific SPDs for Tunnel Mode
We describe the specific SPD case in an appendix due to its length We describe the specific SPD case in an appendix due to its length
and relative complexity compared to transport mode or generic SPD and relative complexity compared to transport mode or generic SPD
tunnel mode. tunnel mode.
We assume that this kind of IPsec association is not modelled an We assume that this kind of IPsec association is not modelled as an
interface, because then the link-local traffic would require very interface, because then the link-local traffic would require very
complex SPDs as well. complex SPDs as well.
A.1. Specific SPD for Host-to-Host Scenario A.1. Specific SPD for Host-to-Host Scenario
The following SPD entries assume that there are two hosts Host1 and The following SPD entries assume that there are two hosts Host1 and
Host2, whose IPv6 addresses are denoted by IPV6-EP1 and IPV6-EP2 Host2, whose IPv6 addresses are denoted by IPV6-EP1 and IPV6-EP2
(global addresses) and IPV4 addresses of the tunnel endpoints are (global addresses) and IPV4 addresses of the tunnel endpoints are
denoted by IPV4-TEP1 and IPV4-TEP2 respectively. denoted by IPV4-TEP1 and IPV4-TEP2 respectively.
skipping to change at page 19, line 10 skipping to change at page 18, line 46
A.2. Specific SPD for Host-to-Router scenario A.2. 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, and the Please note the bypass entry for host's outbound SPD, absent in
corresponding router's inbound SPD. While this might be an router's inbound SPD. While this might be an implementation matter
implementation matter for host-to-router tunneling, having a similar for host-to-router tunneling, having a similar entry, "SRC=IPV6-
entry, "SRC=IPV6-PREF/48 & destination=IPV6-PREF/48" would be PREF/48 & DST=IPV6-PREF/48" is critical for site-to-router tunneling.
critical for site-to-router tunneling.
Host's SPD OUT: Host's SPD OUT:
IF SRC=IPV6-EP1 & DST = IPV6-EP1 IF SRC=IPV6-EP1 & DST = IPV6-EP1
THEN BYPASS THEN BYPASS
IF SRC = IPV6-EP1 & DST = any IF SRC = IPV6-EP1 & DST = any
THEN USE ESP TUNNEL MODE SA: THEN USE ESP TUNNEL MODE SA:
outer source = IPv4-TEP1 outer source = IPv4-TEP1
outer dest = IPV4-TEP2 outer dest = IPV4-TEP2
skipping to change at page 19, line 42 skipping to change at page 19, line 31
Router's SPD OUT: Router's SPD OUT:
IF SRC = any & DST = IPV6-EP1 IF SRC = any & DST = IPV6-EP1
THEN USE ESP TUNNEL MODE SA: THEN USE ESP TUNNEL MODE SA:
outer source = IPv4-TEP2 outer source = IPv4-TEP2
outer dest = IPV4-TEP1 outer dest = IPV4-TEP1
Router's SPD IN: Router's SPD IN:
IF SRC=IPV6-EP1 & DST = IPV6-EP1
THEN BYPASS
IF SRC = IPV6-EP1 && DST = any IF SRC = IPV6-EP1 && DST = any
THEN use ESP TUNNEL MODE SA THEN use ESP TUNNEL MODE SA
outer source = IPV4-TEP1 outer source = IPV4-TEP1
outer dest = IPV4-TEP2 outer dest = IPV4-TEP2
The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and
ID_IPV6_ADDR_RANGE or ID_IPV6_ADDR_SUBNET as its phase 2 identity. ID_IPV6_ADDR_RANGE or ID_IPV6_ADDR_SUBNET as its phase 2 identity.
The starting address is zero IP address and the end address is all The starting address is zero IP address and the end address is all
ones for ID_IPV6_ADDR_RANGE. The starting address is zero IP address ones for ID_IPV6_ADDR_RANGE. The starting address is zero IP address
and the end address is all zeroes for ID_IPV6_ADDR_SUBNET. With and the end address is all zeroes for ID_IPV6_ADDR_SUBNET. With
skipping to change at page 22, line 5 skipping to change at page 21, line 5
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
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 22, line 29 skipping to change at page 21, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 41 change blocks. 
132 lines changed or deleted 110 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/