GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4891

Network Working Group R. Graveman Request for Comments: 4891 RFG Security, LLC Category: Informational M. Parthasarathy

                                                                 Nokia
                                                             P. Savola
                                                             CSC/FUNET
                                                         H. Tschofenig
                                                Nokia Siemens Networks
                                                              May 2007
             Using IPsec to Secure IPv6-in-IPv4 Tunnels

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The IETF Trust (2007).

Abstract

 This document gives guidance on securing manually configured IPv6-in-
 IPv4 tunnels using IPsec in transport mode.  No additional protocol
 extensions are described beyond those available with the IPsec
 framework.

Graveman, et al. Informational [Page 1] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
 2.  Threats and the Use of IPsec . . . . . . . . . . . . . . . . .  3
   2.1.  IPsec in Transport Mode  . . . . . . . . . . . . . . . . .  4
   2.2.  IPsec in Tunnel Mode . . . . . . . . . . . . . . . . . . .  5
 3.  Scenarios and Overview . . . . . . . . . . . . . . . . . . . .  5
   3.1.  Router-to-Router Tunnels . . . . . . . . . . . . . . . . .  6
   3.2.  Site-to-Router/Router-to-Site Tunnels  . . . . . . . . . .  6
   3.3.  Host-to-Host Tunnels . . . . . . . . . . . . . . . . . . .  8
 4.  IKE and IPsec Versions . . . . . . . . . . . . . . . . . . . .  9
 5.  IPsec Configuration Details  . . . . . . . . . . . . . . . . . 10
   5.1.  IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 11
   5.2.  Peer Authorization Database and Identities . . . . . . . . 12
 6.  Recommendations  . . . . . . . . . . . . . . . . . . . . . . . 13
 7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
 8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
 9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
   10.2. Informative References . . . . . . . . . . . . . . . . . . 15
 Appendix A.  Using Tunnel Mode . . . . . . . . . . . . . . . . . . 17
   A.1.  Tunnel Mode Implementation Methods . . . . . . . . . . . . 17
   A.2.  Specific SPD for Host-to-Host Scenario . . . . . . . . . . 18
   A.3.  Specific SPD for Host-to-Router Scenario . . . . . . . . . 19
 Appendix B.  Optional Features . . . . . . . . . . . . . . . . . . 20
   B.1.  Dynamic Address Configuration  . . . . . . . . . . . . . . 20
   B.2.  NAT Traversal and Mobility . . . . . . . . . . . . . . . . 20
   B.3.  Tunnel Endpoint Discovery  . . . . . . . . . . . . . . . . 21

Graveman, et al. Informational [Page 2] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007

1. Introduction

 The IPv6 Operations (v6ops) working group has selected (manually
 configured) IPv6-in-IPv4 tunneling [RFC4213] as one of the IPv6
 transition mechanisms for IPv6 deployment.
 [RFC4213] identified a number of threats that had not been adequately
 analyzed or addressed in its predecessor [RFC2893].  The most
 complete solution is to use IPsec to protect IPv6-in-IPv4 tunneling.
 The document was intentionally not expanded to include the details on
 how to set up an IPsec-protected tunnel in an interoperable manner,
 but instead the details were deferred to this memo.
 The first four sections of this document analyze the threats and
 scenarios that can be addressed by IPsec and assumptions made by this
 document for successful IPsec Security Association (SA)
 establishment.  Section 5 gives the details of Internet Key Exchange
 (IKE) and IP security (IPsec) exchange with packet formats and
 Security Policy Database (SPD) entries.  Section 6 gives
 recommendations.  Appendices further discuss tunnel mode usage and
 optional extensions.
 This document does not address the use of IPsec for tunnels that are
 not manually configured (e.g., 6to4 tunnels [RFC3056]).  Presumably,
 some form of opportunistic encryption or "better-than-nothing
 security" might or might not be applicable.  Similarly, propagating
 quality-of-service attributes (apart from Explicit Congestion
 Notification bits [RFC4213]) from the encapsulated packets to the
 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

 [RFC4213] is mostly concerned about address spoofing threats:
 1.  The IPv4 source address of the encapsulating ("outer") packet can
     be spoofed.
 2.  The IPv6 source address of the encapsulated ("inner") packet can
     be spoofed.

Graveman, et al. Informational [Page 3] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007

 The reason threat (1) exists is the lack of universal deployment of
 IPv4 ingress filtering [RFC3704].  The reason threat (2) exists is
 that the IPv6 packet is encapsulated in IPv4 and hence may escape
 IPv6 ingress filtering.  [RFC4213] specifies the following strict
 address checks as mitigating measures:
 o  To mitigate threat (1), the decapsulator verifies that the IPv4
    source address of the packet is the same as the address of the
    configured tunnel endpoint.  The decapsulator may also implement
    IPv4 ingress filtering, i.e., check whether the packet is received
    on a legitimate interface.
 o  To mitigate threat (2), the decapsulator verifies whether the
    inner IPv6 address is a valid IPv6 address and also applies IPv6
    ingress filtering before accepting the IPv6 packet.
 This memo proposes using IPsec for providing stronger security in
 preventing these threats and additionally providing integrity,
 confidentiality, replay protection, and origin protection between
 tunnel endpoints.
 IPsec can be used in two ways, in transport and tunnel mode; detailed
 discussion about applicability in this context is provided in
 Section 5.

2.1. IPsec in Transport Mode

 In transport mode, the IPsec Encapsulating Security Payload (ESP) or
 Authentication Header (AH) security association (SA) is established
 to protect the traffic defined by (IPv4-source, IPv4-dest, protocol =
 41).  On receiving such an IPsec packet, the receiver first applies
 the IPsec transform (e.g., ESP) and then matches the packet against
 the Security Parameter Index (SPI) and the inbound selectors
 associated with the SA to verify that the packet is appropriate for
 the SA via which it was received.  A successful verification implies
 that the packet came from the right IPv4 endpoint, because the SA is
 bound to the IPv4 source address.
 This prevents threat (1) but not threat (2).  IPsec in transport mode
 does not verify the contents of the payload itself where the IPv6
 addresses are carried.  That is, two nodes using IPsec transport mode
 to secure the tunnel can spoof the inner payload.  The packet will be
 decapsulated successfully and accepted.
 This shortcoming can be partially mitigated by IPv6 ingress
 filtering, i.e., check that the packet is arriving from the interface
 in the direction of the route towards the tunnel endpoint, similar to
 a Strict Reverse Path Forwarding (RPF) check [RFC3704].

Graveman, et al. Informational [Page 4] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007

 In most implementations, a transport mode SA is applied to a normal
 IPv6-in-IPv4 tunnel.  Therefore, ingress filtering can be applied in
 the tunnel interface.  (Transport mode is often also used in other
 kinds of tunnels such as Generic Routing Encapsulation (GRE)
 [RFC4023] and Layer 2 Tunneling Protocol (L2TP) [RFC3193].)

2.2. IPsec in Tunnel Mode

 In tunnel mode, the IPsec SA is established to protect the traffic
 defined by (IPv6-source, IPv6-destination).  On receiving such an
 IPsec packet, the receiver first applies the IPsec transform (e.g.,
 ESP) and then matches the packet against the SPI and the inbound
 selectors associated with the SA to verify that the packet is
 appropriate for the SA via which it was received.  The successful
 verification implies that the packet came from the right endpoint.
 The outer IPv4 addresses may be spoofed, and IPsec cannot detect this
 in tunnel mode; the packets will be demultiplexed based on the SPI
 and possibly the IPv6 address bound to the SA.  Thus, the outer
 address spoofing is irrelevant as long as the decryption succeeds and
 the inner IPv6 packet can be verified to have come from the right
 tunnel endpoint.
 As described in Section 5, using tunnel mode is more difficult than
 applying transport mode to a tunnel interface, and as a result this
 document recommends transport mode.  Note that even though transport
 rather than tunnel mode is recommended, an IPv6-in-IPv4 tunnel
 specified by protocol 41 still exists [RFC4213].

3. Scenarios and Overview

 There are roughly three scenarios:
 1.  (Generic) router-to-router tunnels.
 2.  Site-to-router or router-to-site tunnels.  These refer to tunnels
     between a site's IPv6 (border) device and an IPv6 upstream
     provider's router.  A degenerate case of a site is a single host.
 3.  Host-to-host tunnels.

Graveman, et al. Informational [Page 5] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007

3.1. Router-to-Router Tunnels

 IPv6/IPv4 hosts and routers can tunnel IPv6 datagrams over regions of
 IPv4 forwarding topology by encapsulating them within IPv4 packets.
 Tunneling can be used in a variety of ways.
 .--------.           _----_          .--------.
 |v6-in-v4|         _( IPv4 )_        |v6-in-v4|
 | Router | <======( Internet )=====> | Router |
 |   A    |         (_      _)        |   B    |
 '--------'           '----'          '--------'
     ^        IPsec tunnel between        ^
     |        Router A and Router B       |
     V                                    V
                 Figure 1: Router-to-Router Scenario.
 IPv6/IPv4 routers interconnected by an IPv4 infrastructure can tunnel
 IPv6 packets between themselves.  In this case, the tunnel spans one
 segment of the end-to-end path that the IPv6 packet takes.
 The source and destination addresses of the IPv6 packets traversing
 the tunnel could come from a wide range of IPv6 prefixes, so binding
 IPv6 addresses to be used to the SA is not generally feasible.  IPv6
 ingress filtering must be performed to mitigate the IPv6 address
 spoofing threat.
 A specific case of router-to-router tunnels, when one router resides
 at an end site, is described in the next section.

3.2. Site-to-Router/Router-to-Site Tunnels

 This is a generalization of host-to-router and router-to-host
 tunneling, because the issues when connecting a whole site (using a
 router) and connecting a single host are roughly equal.

Graveman, et al. Informational [Page 6] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007

    _----_        .---------. IPsec     _----_    IPsec  .-------.
  _( IPv6 )_      |v6-in-v4 | Tunnel  _( IPv4 )_  Tunnel | V4/V6  |
 ( Internet )<--->| Router  |<=======( Internet )=======>| Site B |
  (_      _)      |   A     |         (_      _)         '--------'
    '----'        '---------'           '----'
      ^
      |
      V
  .--------.
  | Native |
  | IPv6   |
  | node   |
  '--------'
                  Figure 2: Router-to-Site Scenario.
 IPv6/IPv4 routers can tunnel IPv6 packets to their final destination
 IPv6/IPv4 site.  This tunnel spans only the last segment of the end-
 to-end path.
                                 +---------------------+
                                 |      IPv6 Network   |
                                 |                     |
 .--------.        _----_        |     .--------.      |
 | V6/V4  |      _( IPv4 )_      |     |v6-in-v4|      |
 | Site B |<====( Internet )==========>| Router |      |
 '--------'      (_      _)      |     |   A    |      |
                   '----'        |     '--------'      |
         IPsec tunnel between    |         ^           |
         IPv6 Site and Router A  |         |           |
                                 |         V           |
                                 |     .-------.       |
                                 |     |  V6    |      |
                                 |     |  Hosts |      |
                                 |     '--------'      |
                                 +---------------------+
                  Figure 3: Site-to-Router Scenario.
 In the other direction, IPv6/IPv4 hosts can tunnel IPv6 packets to an
 intermediary IPv6/IPv4 router that is reachable via an IPv4
 infrastructure.  This type of tunnel spans the first segment of the
 packet's end-to-end path.
 The hosts in the site originate the packets with IPv6 source
 addresses coming from a well-known prefix, whereas the destination
 addresses could be any nodes on the Internet.

Graveman, et al. Informational [Page 7] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007

 In this case, an IPsec tunnel mode SA could be bound to the prefix
 that was allocated to the router at Site B, and Router A could verify
 that the source address of the packet matches the prefix.  Site B
 will not be able to do a similar verification for the packets it
 receives.  This may be quite reasonable for most of the deployment
 cases, for example, an Internet Service Provider (ISP) allocating a
 /48 to a customer.  The Customer Premises Equipment (CPE) where the
 tunnel is terminated "trusts" (in a weak sense) the ISP's router, and
 the ISP's router can verify that Site B is the only one that can
 originate packets within the /48.
 IPv6 spoofing must be prevented, and setting up ingress filtering may
 require some amount of manual configuration; see more of these
 options in Section 5.

3.3. Host-to-Host Tunnels

   .--------.           _----_          .--------.
   | V6/V4  |         _( IPv4 )_        | V6/V4  |
   | Host   | <======( Internet )=====> | Host   |
   |   A    |         (_      _)        |   B    |
   '--------'           '----'          '--------'
                IPsec tunnel between
                Host A and Host B
                   Figure 4: Host-to-Host Scenario.
 IPv6/IPv4 hosts interconnected by an IPv4 infrastructure can tunnel
 IPv6 packets between themselves.  In this case, the tunnel spans the
 entire end-to-end path.
 In this case, the source and the destination IPv6 addresses are known
 a priori.  A tunnel mode SA could be bound to these specific
 addresses.  Address verification prevents IPv6 source address
 spoofing completely.
 As noted in the Introduction, automatic host-to-host tunneling
 methods (e.g., 6to4) are out of scope for this memo.

Graveman, et al. Informational [Page 8] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007

4. IKE and IPsec Versions

 This section discusses the different versions of the IKE and IPsec
 security architecture and their applicability to this document.
 The IPsec security architecture was previously defined in [RFC2401]
 and is now superseded by [RFC4301].  IKE was originally defined in
 [RFC2409] (which is called IKEv1 in this document) and is now
 superseded by [RFC4306] (called IKEv2; see also [RFC4718]).  There
 are several differences between them.  The differences relevant to
 this document are discussed below.
 1.  [RFC2401] does not require allowing IP as the next layer protocol
     in traffic selectors when an IPsec SA is negotiated.  In
     contrast, [RFC4301] requires supporting IP as the next layer
     protocol (like TCP or UDP) in traffic selectors.
 2.  [RFC4301] assumes IKEv2, as some of the new features cannot be
     negotiated using IKEv1.  It is valid to negotiate multiple
     traffic selectors for a given IPsec SA in [RFC4301].  This is
     possible only with IKEv2.  If IKEv1 is used, then multiple SAs
     need to be set up, one for each traffic selector.
 Note that the existing implementations based on IKEv1 may already be
 able to support the [RFC4301] features described in (1) and (2).  If
 appropriate, the deployment may choose to use either version of the
 security architecture.
 IKEv2 supports features useful for configuring and securing tunnels
 not present with IKEv1.
 1.  IKEv2 supports legacy authentication methods by carrying them in
     Extensible Authentication Protocol (EAP) payloads.  This can be
     used to authenticate hosts or sites to an ISP using EAP methods
     that support username and password.
 2.  IKEv2 supports dynamic address configuration, which may be used
     to configure the IPv6 address of the host.
 Network Address Translation (NAT) traversal works with both the old
 and revised IPsec architectures, but the negotiation is integrated
 with IKEv2.
 For the purposes of this document, where the confidentiality of ESP
 [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
 protection for certain fields in the outer IPv4 header and IPv4
 options.  However, as the outer IPv4 header will be discarded in any

Graveman, et al. Informational [Page 9] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007

 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

 This section describes the SPD entries for setting up the IPsec
 transport mode SA to protect the IPv6 traffic.
 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.  Without this,
     an attacker can pollute the IPv6 neighbor cache causing
     disruption in communication between the two routers.
 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

Graveman, et al. Informational [Page 10] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007

 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 interoperable implementations support this feature.
 For a detailed list of issues pertaining to this, see [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 set up to discard spoofed
 packets.

5.1. IPsec Transport Mode

 Transport mode has typically been applied to L2TP, GRE, and other
 tunneling methods, especially when the user wants to tunnel 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
 the packets that pass the inbound IPsec processing.
 The following SPD entries assume that there are two routers, Router1
 and Router2, with tunnel endpoint IPv4 addresses denoted IPV4-TEP1
 and IPV4-TEP2, respectively.  (In other scenarios, the SPDs are set
 up similarly.)
   Router1's SPD:
                                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)

Graveman, et al. Informational [Page 11] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007

   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)
   In both SPD entries, "IKE" refers to UDP destination port 500
   and possibly also port 4500 if NAT traversal is used.
 The packet format is as shown in Table 1.
  +----------------------------+------------------------------------+
  | Components (first to last) |              Contains              |
  +----------------------------+------------------------------------+
  |         IPv4 header        | (src = IPV4-TEP1, dst = IPV4-TEP2) |
  |         ESP header         |                                    |
  |         IPv6 header        |  (src = IPV6-EP1, dst = IPV6-EP2)  |
  |          (payload)         |                                    |
  +----------------------------+------------------------------------+
             Table 1: Packet Format for IPv6/IPv4 Tunnels.
 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
 selectors are used to carry the same information.

5.2. Peer Authorization Database and Identities

 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.
 As there is currently no defined way to discover the PAD-related
 parameters dynamically, it is assumed that these are manually
 configured:
 o  The Identity of the peer asserted in the IKEv2 exchange: Many
    different types of identities can be used.  At least, the IPv4
    address of the peer should be supported.
 o  IKEv2 can authenticate the peer by several methods.  Pre-shared
    key and X.509 certificate-based authentication is required by
    [RFC4301].  At least, pre-shared key should be supported, because
    it interoperates with a larger number of implementations.

Graveman, et al. Informational [Page 12] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007

 o  The child SA authorization data should contain the IPv4 address of
    the peer.
 IPv4 address should be supported as Identity during the key exchange.
 As this does not provide Identity protection, main mode or aggressive
 mode can be used with IKEv1.

6. Recommendations

 In Section 5, we examined the differences between setting up an IPsec
 IPv6-in-IPv4 tunnel using either transport or tunnel mode.  We
 observe that applying transport mode to a tunnel interface is the
 simplest and therefore recommended solution.
 In Appendix A, we also explore what it would take to use so-called
 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 the Mobility
 and Multihoming Protocol (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 transport mode
 applied to a tunnel interface.  Source address spoofing can be
 limited by 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. Security Considerations

 When running IPv6-in-IPv4 tunnels (unsecured) over the Internet, it
 is possible to "inject" packets into the tunnel by spoofing the
 source address (data plane security), or if the tunnel is signaled
 somehow (e.g., using authentication protocol and obtaining a static
 v6 prefix), someone might be able to spoof the signaling (control
 plane security).
 The IPsec framework plays an important role in adding security to
 both the protocol for tunnel setup and data traffic.
 Either IKEv1 or IKEv2 provides a secure signaling protocol for
 establishing, maintaining, and deleting an IPsec tunnel.

Graveman, et al. Informational [Page 13] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007

 IPsec, with ESP, offers integrity and data origin authentication,
 confidentiality, and optional (at the discretion of the receiver)
 anti-replay features.  Using confidentiality without integrity is
 discouraged.  ESP furthermore provides limited traffic flow
 confidentiality.
 IPsec provides access control mechanisms through the distribution of
 keys and also through the application of policies dictated by the
 Security Policy Database (SPD).
 The NAT traversal mechanism provided by IKEv2 introduces some
 weaknesses into IKE and IPsec.  These issues are discussed in more
 detail in [RFC4306].
 Please note that using IPsec for the scenarios described in Figures
 1, 2, and 3 does not aim to protect the end-to-end communication.  It
 protects just the tunnel part.  It is still possible for an IPv6
 endpoint not attached to the IPsec tunnel to spoof packets.

8. Contributors

 The authors are listed in alphabetical order.
 Suresh Satapati also participated in the initial discussions on this
 topic.

9. Acknowledgments

 The authors would like to thank Stephen Kent, Michael Richardson,
 Florian Weimer, Elwyn Davies, Eric Vyncke, Merike Kaeo, Alfred
 Hoenes, Francis Dupont, and David Black for their substantive
 feedback.
 We would like to thank Pasi Eronen for his text contributions and
 suggestions for improvement.

Graveman, et al. Informational [Page 14] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007

10. References

10.1. Normative References

 [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
            Internet Protocol", RFC 2401, November 1998.
 [RFC2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
            (IKE)", RFC 2409, November 1998.
 [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
            Networks", BCP 84, RFC 3704, March 2004.
 [RFC3948]  Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
            Stenberg, "UDP Encapsulation of IPsec ESP Packets",
            RFC 3948, January 2005.
 [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
            for IPv6 Hosts and Routers", RFC 4213, October 2005.
 [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
            Internet Protocol", RFC 4301, December 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.

10.2. Informative References

 [RFC2893]  Gilligan, R. and E. Nordmark, "Transition Mechanisms for
            IPv6 Hosts and Routers", RFC 2893, August 2000.
 [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
            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
            (NAT) Compatibility Requirements", RFC 3715, March 2004.
 [RFC3884]  Touch, J., Eggert, L., and Y. Wang, "Use of IPsec
            Transport Mode for Dynamic Routing", RFC 3884,
            September 2004.

Graveman, et al. Informational [Page 15] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007

 [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,
            December 2005.
 [RFC4555]  Eronen, P., "IKEv2 Mobility and Multihoming Protocol
            (MOBIKE)", RFC 4555, June 2006.
 [RFC4718]  Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
            Implementation Guidelines", RFC 4718, October 2006.
 [TUNN-AD]  Palet, J. and M. Diaz, "Analysis of IPv6 Tunnel End-point
            Discovery Mechanisms", Work in Progress, January 2005.
 [VLINK]    Duffy, M., "Framework for IPsec Protected Virtual Links
            for PPVPNs", Work in Progress, October 2002.

Graveman, et al. Informational [Page 16] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007

Appendix A. Using Tunnel Mode

 First, we describe the different tunnel mode implementation methods.
 We note that, in this context, only the so-called Specific SPD (SSPD)
 model (without a tunnel interface) can be made to work, but it 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 if one would like to use it in any case.

A.1. Tunnel Mode Implementation Methods

 Tunnel mode could (in theory) 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" addresses ("::/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 similar to 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 [VLINK] and this approach is
     not feasible.
 2.  "Specific SPDs": some implementations do not model the tunnel
     mode SA as an IP interface.  Traffic selection is 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 Duplicate
     Address Detection (DAD), Multicast Listener Discovery (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 it explicitly when
 transport mode or option (1) is chosen.
 In summary, there does not appear to be a standard solution in this
 context for the first implementation approach.

Graveman, et al. Informational [Page 17] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007

 The second approach can be made to work, but is only applicable in
 host-to-host or site-to-router/router-to-site scenarios (i.e., when
 the IPv6 prefixes can be known a priori), and it offers only a
 limited set of features (e.g., no multicast) compared with a
 transport mode tunnel.
 When tunnel mode is used, fragment handling [RFC4301] may also be
 more difficult compared with transport mode and, depending on
 implementation, may need to be reflected in SPDs.

A.2. Specific SPD for Host-to-Host Scenario

 The following SPD entries assume that there are two hosts, Host1 and
 Host2, whose IPv6 addresses are denoted IPV6-EP1 and IPV6-EP2 (global
 addresses), and the IPV4 addresses of the tunnel endpoints are
 denoted IPV4-TEP1 and IPV4-TEP2, respectively.
 Host1'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-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
 as phase 2 identities.  With IKEv2, the traffic selectors are used to
 carry the same information.

Graveman, et al. Informational [Page 18] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007

A.3. Specific SPD for Host-to-Router Scenario

 The following SPD entries assume that the host has the IPv6 address
 IPV6-EP1 and the tunnel endpoints of the host and router are IPV4-
 TEP1 and IPV4-TEP2, respectively.  If the tunnel is between a router
 and a host where the router has allocated an IPV6-PREF/48 to the
 host, the corresponding SPD entries can be derived by replacing IPV6-
 EP1 with IPV6-PREF/48.
 Please note the bypass entry for host's SPD, absent in router's SPD.
 While this might be an implementation matter for host-to-router
 tunneling, having a similar entry, "Local=IPV6-PREF/48 & Remote=IPV6-
 PREF/48", is critical for site-to-router tunneling.
 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})
 Router's SPD:
                              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})
 The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and
 ID_IPV6_ADDR_RANGE or ID_IPV6_ADDR_SUBNET as their phase 2
 identities.  The starting address is zero and the end address is all
 ones for ID_IPV6_ADDR_RANGE.  The starting address is zero IP address
 and the end address is all zeroes for ID_IPV6_ADDR_SUBNET.  With
 IKEv2, the traffic selectors are used to carry the same information.

Graveman, et al. Informational [Page 19] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007

Appendix B. Optional Features

B.1. Dynamic Address Configuration

 With the exchange of protected configuration payloads, IKEv2 is able
 to provide the IKEv2 peer with Dynamic Host Configuration Protocol
 (DHCP)-like information payloads.  These configuration payloads are
 exchanged between the IKEv2 initiator and responder.
 This could be used (for example) by the host in the host-to-router
 scenario to obtain an IPv6 address from the ISP as part of setting up
 the IPsec tunnel mode SA.  The details of these procedures are out of
 scope for this memo.

B.2. NAT Traversal and Mobility

 Network address (and port) translation devices are commonly found in
 today's networks.  A detailed description of the problem and
 requirements of IPsec-protected data traffic traversing a NAT is
 provided in [RFC3715].
 IKEv2 can detect the presence of a NAT automatically by sending
 NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads in
 the initial IKE_SA_INIT exchange.  Once a NAT is detected and both
 endpoints support IPsec NAT traversal extensions, UDP encapsulation
 can be enabled.
 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 set up both
     a secure tunnel and a tunnel that 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 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.

Graveman, et al. Informational [Page 20] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007

 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, because 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 it 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 endpoint for the configured IPv6-in-IPv4
 tunnel.
 This problem is also discussed at more length in [TUNN-AD].
 However, simply discovering the tunnel endpoint is not sufficient for
 establishing an IKE session with the peer.  The PAD information (see
 Section 5.2) also needs to be learned 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.

Graveman, et al. Informational [Page 21] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007

Authors' Addresses

 Richard Graveman
 RFG Security, LLC
 15 Park Avenue
 Morristown, NJ  07960
 USA
 EMail: rfg@acm.org
 Mohan Parthasarathy
 Nokia
 313 Fairchild Drive
 Mountain View, CA  94043
 USA
 EMail: mohanp@sbcglobal.net
 Pekka Savola
 CSC/FUNET
 Espoo
 Finland
 EMail: psavola@funet.fi
 Hannes Tschofenig
 Nokia Siemens Networks
 Otto-Hahn-Ring 6
 Munich, Bayern  81739
 Germany
 EMail: Hannes.Tschofenig@nsn.com

Graveman, et al. Informational [Page 22] RFC 4891 IPsec with IPv6-in-IPv4 Tunnels May 2007

Full Copyright Statement

 Copyright (C) The IETF Trust (2007).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Graveman, et al. Informational [Page 23]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4891.txt · Last modified: 2007/05/09 16:31 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki