[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 draft-ietf-v6ops-ipsec-tunnels

IPv6 Operations WG                                           R. Graveman
Internet-Draft                                         RFG Security, LLC
Expires: April 24, 2005                                 M. Parthasarathy
                                                                   Nokia
                                                               P. Savola
                                                               CSC/FUNET
                                                           H. Tschofenig
                                                                 Siemens
                                                        October 24, 2004


              Using IPsec to Secure IPv6-over-IPv4 Tunnels
              draft-tschofenig-v6ops-secure-tunnels-02.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any 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 become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 24, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This document gives guidance on securing IPv6-in-IPv4 tunnels using
   IPsec.  No additional protocol extensions are described beyond those



Graveman, et al.         Expires April 24, 2005                 [Page 1]


Internet-Draft    Using IPsec to Secure v6-over-v4 Tunnels  October 2004


   available with the revised IPsec framework.  IKEv2 is extensively
   used as an authentication and key exchange protocol to cover address
   configuration procedures, and the usage of the Extensible
   Authentication Procotol and NAT traversal capabilities is also
   described.

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 . . . . . . . . . . . . . . . . . . .  4
   3.  Scenarios and Overview . . . . . . . . . . . . . . . . . . . .  5
     3.1   Router-to-Router Tunnels . . . . . . . . . . . . . . . . .  5
     3.2   Site-to-Router/Router-to-Site Tunnels  . . . . . . . . . .  5
     3.3   Host-to-Host Tunnels . . . . . . . . . . . . . . . . . . .  7
   4.  Assumptions  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  IPsec Configuration Details  . . . . . . . . . . . . . . . . .  9
     5.1   IPsec Transport mode . . . . . . . . . . . . . . . . . . .  9
     5.2   IPsec Tunnel mode  . . . . . . . . . . . . . . . . . . . .  9
       5.2.1   SPD for Host-to-Host Scenario  . . . . . . . . . . . .  9
       5.2.2   SPD for Host-to-Router scenario  . . . . . . . . . . . 10
   6.  Dynamic Address Configuration  . . . . . . . . . . . . . . . . 12
   7.  Extensible Authentication Support  . . . . . . . . . . . . . . 13
   8.  NAT Traversal  . . . . . . . . . . . . . . . . . . . . . . . . 15
   9.  Tunnel Endpoint Discovery  . . . . . . . . . . . . . . . . . . 16
   10.   Example  . . . . . . . . . . . . . . . . . . . . . . . . . . 17
   11.   Security Considerations  . . . . . . . . . . . . . . . . . . 17
   12.   Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . 18
   13.   Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
   14.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 20
   15.   References . . . . . . . . . . . . . . . . . . . . . . . . . 20
   15.1  Normative References . . . . . . . . . . . . . . . . . . . . 20
   15.2  Informative References . . . . . . . . . . . . . . . . . . . 21
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
       Intellectual Property and Copyright Statements . . . . . . . . 24















Graveman, et al.         Expires April 24, 2005                 [Page 2]


Internet-Draft    Using IPsec to Secure v6-over-v4 Tunnels  October 2004


1.  Introduction

   The IPv6 operations (v6ops) working group has selected IPv6-in-IPv4
   tunneling [I-D.ietf-v6ops-mech-v2] as one of the IPv6 transition
   mechanisms for IPv6 deployment.  A number of threats have been
   identified with possible solutions to mitigate them
   [I-D.ietf-v6ops-mech-v2].  One of the solutions is the use of IPsec
   protected tunnels, but there is little detail on how IPsec would
   actually be used in an interoperable manner.  This memo describes the
   use of IPsec in detail.

   First this document analyses the threats that can be addressed by
   IPsec.  Next, this document discusses some of the assumptions made by
   this document for successful IPsec SA establishment.  Then, it gives
   the details of IKE/IPsec exchange with packet formats and SPD
   entries.  Finally, it discusses the usage of IPsec NAT-traversal
   mechanism that can be used with configured tunnels in some scenarios.

2.  Threats and the Use of IPsec

   Following threats have been identified in [I-D.ietf-v6ops-mech-v2]:

   1.  IPv4 address of the encapsulating ("outer") packet can be
       spoofed.

   2.  IPv6 address of the encapsualted ("inner") packet can be spoofed.

   The reason for threat (1) is due to the lack of widespread deployment
   of IPv4 ingress filtering in the network.  The reason for threat (2)
   is that the IPv6 packet is encapsulated in IPv4 and hence escapes
   IPv6 ingress filtering.  [I-D.ietf-v6ops-mech-v2] specifies following
   strict address checks as mitigating measures.

   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., checks whether the packet is received on a
   legitimate interface.

   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.  IPsec can be used in two ways, in
   transport and tunnel mode.





Graveman, et al.         Expires April 24, 2005                 [Page 3]


Internet-Draft    Using IPsec to Secure v6-over-v4 Tunnels  October 2004


2.1  IPsec in Transport Mode

   In transport mode, the IPsec 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 (ESP) and then matches the packet against 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 IPv4
   endpoint as the SA is bound to the IPv4 source address.

   This prevents threat (1) but not the 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 that are using IPsec
   transport mode to secure the tunnel can spoof the inner payload.  The
   packet will be decapsulated successfully and accepted.

   The shortcoming can be 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 end-point, similar to a Strict
   Reverse Path Forwarding (RPF) check [RFC3704].

   For performing ingress filtering, it is assumed that the tunnel is
   modelled as an interface and the traffic of the tunnel is protected
   using IPsec transport mode SA.

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 (ESP)
   and then matches the packet against 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 IPv6 endpoint as the SA is bound to the
   IPv6 source address.

   The IPv4 addresses may be spoofed and IPsec cannot detect it in this
   mode, that is, two nodes that are using IPsec tunnel mode to secure
   the tunnel with a common tunnel endpoint can spoof each other's IPv4
   address.  But, the packet will not be accepted by IPsec as the IPv6
   address bound to the SA will not match the address in the spoofed
   packet.  Thus, the outer address spoofing is irrelevant as long as
   the inner IPv6 packet can be verified to come from the right IPv6
   endpoint.

   It may not be possible to always verify the IPv6 address -- for
   example with link-local addresses.  The additional issues with



Graveman, et al.         Expires April 24, 2005                 [Page 4]


Internet-Draft    Using IPsec to Secure v6-over-v4 Tunnels  October 2004


   address verification are discussed in each of the scenarios section
   appropriately.

3.  Scenarios and Overview

   There are roughly three kinds of scenarios: (generic)
   router-to-router tunnels, site-to-router/router-to-site tunnels (a
   generalization of host-to-router/router-to-host scenarios,
   respectively), and host-to-host tunnels.

3.1  Router-to-Router Tunnels

   IPv6/IPv4 hosts and routers can tunnel IPv6 datagrams over regions of
   IPv4 routing 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
   .--------.                           .-------.
   |  End   |                           |  End   |
   |  Host  |                           |  Host  |
   '--------'                           '--------'

                  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.  It is not
   scalable to establish IPsec tunnel mode SAs for all such packets.
   Hence, IPsec transport mode SA is recommended for this scenario.
   IPv6 ingress filtering should 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 site-to-router and router-to-site



Graveman, et al.         Expires April 24, 2005                 [Page 5]


Internet-Draft    Using IPsec to Secure v6-over-v4 Tunnels  October 2004


   tunneling, because the issues when connecting a whole site (using a
   router), and connecting a single host are roughly equal.

      _----_        .---------. 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 host.  This tunnel spans only the last segment of the
   end-to-end path.

   This is the same as the Site-to-Router case.

                                   +---------------------+
                                   |      IPv6 Network   |
                                   |                     |
   .--------.        _----_        |     .--------.      |
   | V6/V4  |      _( IPv4 )_      |     |v6-in-v4|      |
   | Site B |<====( Internet )==========>| Router |      |
   '--------'      (_      _)      |     |   A    |      |
                     '----'        |     '--------'      |
           IPsec tunnel between    |         ^           |
           V6 Site and Router A    |         |           |
                                   |         V           |
                                   |     .-------.       |
                                   |     |  V6    |      |
                                   |     |  Host  |      |
                                   |     '--------'      |
                                   +---------------------+

                   Figure 3: Site-to-Router Scenario

   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.




Graveman, et al.         Expires April 24, 2005                 [Page 6]


Internet-Draft    Using IPsec to Secure v6-over-v4 Tunnels  October 2004


   In this case, the host(s) originate the packet with source address
   coming from a well known prefix whereas the destination address could
   be any node on the internet.  In this case, the IPsec tunnel mode SA
   can be bound to the prefix that was allocated to the router at Site B
   and router A can 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, the ISP allocating a /48 to a
   customer.  The CPE (where the tunnel is terminated) "trusts" (in a
   weak sense) the ISP's router and the ISP's router can verify that the
   Site B is the only one that can originate packets within the /48.
   IPsec tunnel mode SA is recommended for this case, though similar
   amount of protection can be obtained with transport mode SA with
   strict ingress filtering as well.

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 that are interconnected by an IPv4 infrastructure can
   tunnel IPv6 packets between themselves.  In this case, the tunnel
   spans the entire end-to-end path that the packet takes.

   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
   address verification prevents IPv6 address spoofing completely.

4.  Assumptions

   Throughout this document we make a few assumptions which are briefly
   listed here.  The following documents are used as a basis:

   o  Revised 'Security Architecture for the Internet Protocol' as
      described in [I-D.ietf-ipsec-rfc2401bis].

   o  IKEv2 as described in [I-D.ietf-ipsec-ikev2] and the accompanying
      documents for cipher suites and cryptgraphic algorithms (see
      [I-D.ietf-ipsec-ikev2-algorithms], [I-D.ietf-ipsec-ikev2-iana] and
      [I-D.ietf-ipsec-ui-suites]).




Graveman, et al.         Expires April 24, 2005                 [Page 7]


Internet-Draft    Using IPsec to Secure v6-over-v4 Tunnels  October 2004


   o  'IP Encapsulating Security Payload (ESP)' as described in
      [I-D.ietf-ipsec-esp-v3]

   o  'UDP Encapsulation of IPsec Packets' as described in
      [I-D.ietf-ipsec-udp-encaps] for the purpose of NAT traversal.

   Please note that we do not consider the usage of the IP
   Authentication Header (AH) [I-D.ietf-ipsec-rfc2402bis] since Section
   3.2 of [I-D.ietf-ipsec-rfc2401bis] specifies that IPsec
   implementations MUST implement ESP and MAY implement AH with the
   reasoning that ESP provides security services (such as integrity
   protection without confidentiality protection using 'NULL'
   encryption) which are comparable with AH.

   Furthermore, we focus on IKEv2 since [I-D.ietf-ipsec-rfc2401bis]
   assumes use of IKEv2 as a key and security association management
   system and not IKEv1 with its extensions.

   The decision to focus on IKEv2 and newer IPsec documents is based on
   the premise that doing so allows using "mixed-mode" transforms as
   described below.  This is useful for Transport mode SAs.  Some
   implementations might, however, support these SAs already, at least
   using manual configuration.

   The support of IPv4/IPv6 transition capabilities with IPsec is
   possible with [RFC2401] and with [I-D.ietf-ipsec-rfc2401bis] (see
   Section 5.1.2 of [I-D.ietf-ipsec-rfc2401bis]).  IPsec allows the IP
   version of the encapsulating header to be different from that of the
   inner header.

   The IPsec framework does not allow IKEv1/IKEv2 to be used to create
   tunnels which do not experience cryptographic protection although
   this functionality might be useful in some environments.  IKEv2 would
   then migrate into a secure signaling protocol for tunnel
   establishment (without implementing data traffic protection) in a
   fashion similar to the 'IPv6 Tunnel Broker with the Tunnel Setup
   Protocol (TSP)' [I-D.blanchet-v6ops-tunnelbroker-tsp] protocol
   proposal.  Section 4.2 of [I-D.ietf-ipsec-rfc2401bis], however,
   prohibits this functionality by stating:

   "
   A compliant implementation MUST NOT allow instantiation of an ESP SA
   that employs both NULL encryption and no integrity algorithm.
   "

   Regarding the usage of the Explicit Congestion Notification (ECN), it
   appears that the ECN bits in the IPv4 and IPv6 headers have exactly
   the same semantics, so the bits just need to be copied from the outer



Graveman, et al.         Expires April 24, 2005                 [Page 8]


Internet-Draft    Using IPsec to Secure v6-over-v4 Tunnels  October 2004


   IPv4 header to the inner IPv6 header on tunnel exit.

5.  IPsec Configuration Details

   This section describes details about the IPsec tunnel establishment
   for protection of IPv4/IPv6 data traffic.

5.1  IPsec Transport mode

   This is typically used in Router-to-Router scenario.

   The following SPD entries assume that there are two routers Router1
   and Router2, whose tunnel endpoint's IPv4 address is denoted by
   IPV4-TEP1 and IPV4-TEP2 respectively.


   Router1's SPD OUT :

   IF SRC = IPV4-TEP1 && DST = IPV4-TEP2 && protocol = 41
       THEN USE ESP TRANSPORT MODE SA

   Router1's SPD IN:

   IF SRC = IPV4-TEP2 && DST = IPV4-TEP1 && protocol = 41
       THEN USE ESP TRANSPORT MODE SA

   Router2's SPD OUT:

   IF SRC = IPV4-TEP2 && DST = IPV4-TEP1 && protocol = 41
       THEN USE ESP TRANSPORT MODE SA

   Router2's SPD IN:

   IF SRC = IPV4-TEP1 && DST = IPV4-TEP2 && protocol = 41
       THEN USE ESP TRANSPORT MODE SA

   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  IPsec Tunnel mode

5.2.1  SPD for Host-to-Host Scenario

   The following SPD entries assume that there are two hosts Host1 and
   Host2, whose IPv6 addresses are denoted by IPV6-EP1 and IPV6-EP2 and
   IPV4 addresses of the tunnel endpoints are denoted by IPV4-TEP1 and
   IPV4-TEP2 respectively.



Graveman, et al.         Expires April 24, 2005                 [Page 9]


Internet-Draft    Using IPsec to Secure v6-over-v4 Tunnels  October 2004


   Host1's SPD OUT :

   IF SRC = IPV6-EP1 && DST = IPV6-EP2
       THEN USE ESP TUNNEL MODE SA:
           outer source = IPv4-TEP1
           outer dest   = IPV4-TEP2

   Host1's SPD IN:

   IF SRC = IPV6-EP2 && DST = IPV6-EP1
       THEN USE ESP TUNNEL MODE SA
           outer source = IPV4-TEP2
           outer dest = IPV4-TEP1

   Host2's SPD OUT:

   IF SRC = IPV6-EP2 && DST = IPV6-EP1
       THEN USE ESP TUNNEL MODE SA
           outer source = IPV4-TEP2
           outer dest = IPV4-TEP1

   Host2's SPD IN:

   IF SRC = IPV6-EP1 && DST = IPV6-EP2
       THEN USE ESP TUNNEL MODE SA:
           outer source = IPv4-TEP1
            outer dest = IPV4-TEP2

   The IDci and IDcr payloads of IKEv1 carry the IPV6-EP1 and IPV6-TEP2
   as phase 2 identities.  With IKEv2, the traffic selectors are used to
   carry the same information.

5.2.2  SPD for Host-to-Router scenario

   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-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, the corresponding SPD entries can be derived by
   substituting IPV6-EP1 by IPV6-PREF/48.











Graveman, et al.         Expires April 24, 2005                [Page 10]


Internet-Draft    Using IPsec to Secure v6-over-v4 Tunnels  October 2004


   Host's SPD OUT:

   IF SRC = IPV6-EP1 && DST = any
       THEN use ESP TUNNEL MODE SA
           outer source = IPV4-TEP1
           outer dest = IPV4-TEP2

   Host's SPD IN:

   IF SRC = any && DST = IPV6-EP1
       THEN use ESP TUNNEL MODE SA
           outer source = IPV4-TEP1
           outer dest = IPV4-TEP2

   Router's SPD OUT:

   IF SRC = any && DST = IPV6-EP1
       THEN use ESP TUNNEL MODE SA
           outer source = IPV4-TEP1
           outer dest = IPV4-TEP2

   Router's SPD IN:

   IF SRC = IPV6-EP1 && DST = any
       THEN use ESP TUNNEL MODE SA
           outer source = IPV4-TEP1
           outer dest = IPV4-TEP2

   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.
   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
   and the end address is all zeroes for ID_IPV6_ADDR_SUBNET.  With
   IKEv2, the traffic selectors are used to carry the same information.

   To describe the packet format the following acronyms are used
   throughout this document:

   o  IPV4-TEP1 and IPV4-TEP2 denote the IPv4 address of the tunnel
      endpoints.

   o  IPV6-EP1 and IPV6-EP2 denote the IPv6 address of the two IPv6
      endpoints of the communication.

   The packet format is the same for both transport mode and tunnel mode
   as shown in Figure 9.





Graveman, et al.         Expires April 24, 2005                [Page 11]


Internet-Draft    Using IPsec to Secure v6-over-v4 Tunnels  October 2004


            IPv4 header      (source = IPV4-TEP1,
                              destination = IPV4-TEP2)
            ESP  header
            IPv6 header      (source = IPV6-EP1,
                              destination = IPV6-EP2)

         Figure 9: Packet Format for transport and tunnel mode

   This type of layering may not be valid with [RFC2401] since, with a
   strict definition, IP does not meet the definition of a "higher layer
   protocol" being the next protocol after an IP header.

   With [I-D.ietf-ipsec-rfc2401bis] the definition about the "next layer
   protocol" was explicitly expanded and hence this type of layering is
   valid.

6.  Dynamic Address Configuration

   With the exchange of protected configuration payloads, IKEv2 is able
   to provide the IKEv2 peer with DHCP-like information payloads.  These
   configuration payloads are exchanged between the IKEv2 initiator and
   the responder with the help of the CFG_REQUEST/CFG_REPLY and
   CFG_SET/CFG_ACK payloads.  The former is used to request information
   and the latter allows pushing configuration data.  Configuration
   information (e.g., a temporary address) can be carried in any request
   to create a CHILD_SA by including a CP payload.

   These configuration payloads are primiarly used for bootstrapping the
   IKEv2 peer.  Although these payloads are extensible they are not used
   as a generic purpose management.

   The following example exchange illustrates the usage of configuration
   payloads:


















Graveman, et al.         Expires April 24, 2005                [Page 12]


Internet-Draft    Using IPsec to Secure v6-over-v4 Tunnels  October 2004


          Initiator                         Responder
          -------------                     --------------
          HDR, SAi1, KEi, Ni         -->

                                     <-- HDR(A,0), N(COOKIE)

          HDR(A,0), N(COOKIE), SAi1, KEi, Ni   -->

                                     <--    HDR, SAr1, KEr, Nr,[CERTREQ]

          HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
           AUTH, CP(CFG_REQUEST), SAi2, TSi, TSr}     -->

                                     <--    HDR, SK {IDr, [CERT,] AUTH,
                                     CP(CFG_REPLY), SAr2, TSi, TSr}

        Figure 10: IKEv2 Configuration payload payload exchange

   The example message exchange shown in Figure 10 shows IKEv2 with a
   denial of service protection enabled exchange and a CFG_REQUEST in
   message 5 and the corresponding response in message 6.  The content
   of these payloads, for example, contains (as given in Section 2.19 of
   [I-D.ietf-ipsec-ikev2]):


        CP(CFG_REQUEST)=
           INTERNAL_ADDRESS(0.0.0.0)
           INTERNAL_NETMASK(0.0.0.0)
           INTERNAL_DNS(0.0.0.0)
         TSi = (0, 0-65536,0.0.0.0-255.255.255.255)
         TSr = (0, 0-65536,0.0.0.0-255.255.255.255)

         CP(CFG_REPLY)=
           INTERNAL_ADDRESS(10.168.219.202)
           INTERNAL_NETMASK(255.255.255.0)
           INTERNAL_SUBNET(10.168.219.0/255.255.255.0)
         TSi = (0, 0-65536,10.168.219.202-10.168.219.202)
         TSr = (0, 0-65536,10.168.219.0-10.168.219.255)


7.  Extensible Authentication Support

   In addition to the authentication mechanisms provided in IKEv2 the
   Extensible Authentication Protocol (EAP) [I-D.ietf-eap-rfc2284bis] is
   included which provides some flexibility for authentication
   mechanisms.  Figure 12 shows an example IKEv2 exchange with EAP
   support.  The usage of EAP offers two interesting features:




Graveman, et al.         Expires April 24, 2005                [Page 13]


Internet-Draft    Using IPsec to Secure v6-over-v4 Tunnels  October 2004


   o  User authentication is terminated at a different entity other than
      the IKEv2 responder.  This allows users' security credentials to
      be kept in a central place (e.g., AAA server) and to terminate the
      EAP method at this entity instead at the IKEv2 responder.
      Authorization can also be executed at the same entity.

   o  A number of authentication and key exchange protocols are
      supported via EAP method (such as EAP-AKA, EAP-SIM, SRP, etc.).
      Each EAP methods provides its own properties and usage
      environment.  This provides a certain degree of flexibility.

   Note that IKEv2 with EAP authentication still requires public key
   based authentication of the IKEv2 responder outside the EAP
   authentication.  In most deployments this requires a server-side
   public-key based authentication to protect the EAP exchange with a
   uni-lateral authenticated tunnel.  With the extensions proposed in
   [I-D.eronen-ipsec-ikev2-eap-auth] only EAP authentication is used by
   omitting the IKEv2 responder authentication.

   Please note that Section 3.16 of [I-D.ietf-ipsec-ikev2] indicates
   that the EAP Identity-Request/Identity-Response payload SHOULD NOT be
   used.  The IDr payload (message 3 in Figure 12) carries this identity
   instead.  As a consequence active user identity confidentiality for
   the IKEv2 initiator is not provided.  Special purpose EAP methods
   must be used instead if this features is desired.

   Figure 12 shows an example IKEv2 message exchange with EAP-AKA as an
   EAP method.  Note that the interaction between the IKEv2 responder
   and the AAA infrastructure is not shown.






















Graveman, et al.         Expires April 24, 2005                [Page 14]


Internet-Draft    Using IPsec to Secure v6-over-v4 Tunnels  October 2004


     Initiator                         Responder
     -------------                     --------------
     HDR, SAi1, KEi, Ni         -->

                                <--    HDR, SAr1, KEr, Nr, [CERTREQ]

     HDR, SK {IDi, [CERTREQ,] [IDr,]
              SAi2, TSi, TSr}   -->

                                <--    HDR, SK {IDr, [CERT,] AUTH,
              EAP-Request/AKA-Challenge (AT_RAND, AT_AUTN, AT_MAC) }

     HDR, SK {EAP-Response/AKA-Challenge(AT_RES, AT_MAC)}     -->

                                <--    HDR, SK {EAP-Success, AUTH}

     HDR, SK { AUTH }           -->

                                <--   HDR, SK { SAr2, TSi, TSr }

               Figure 12: EAP usage in IKEv2 with EAP-AKA

   EAP will typically be used with a backend AAA server which raises
   some security concerns.  See [I-D.ietf-eap-keying] for a more
   complete discussion of these security issues.

   When a backend server is used, there are actually two authentication
   exchanges: the EAP method between the client and the AAA server, and
   another authentication between the AAA server and IKEv2 gateway.  The
   AAA server authenticates the client using the selected EAP method,
   and they establish a session key.  The AAA server then sends this key
   to the IKEv2 gateway over a connection authenticated using e.g.
   IPsec or TLS.  The protocol used between the IKEv2 responder and the
   AAA server could be, for instance, Diameter or RADIUS [RFC3579].
   RADIUS and Diameter are able to carry EAP payloads as described in
   [RFC3579] and in [I-D.ietf-aaa-eap], respectively.

8.  NAT Traversal

   Network address (and port) translation devices are commonly found in
   today's networks.  A detailed description of the problem of IPsec
   protected data traffic traversing a NAT including requirements are
   discussed in [RFC3715].

   IKEv2 can detect the presence of a NAT automatically by sending an
   Informational exchange with NAT_DETECTION_SOURCE_IP and
   NAT_DETECTION_DESTINATION_IP payloads before establishing an IPsec
   SA.  These payloads are processed the same way as in the initial



Graveman, et al.         Expires April 24, 2005                [Page 15]


Internet-Draft    Using IPsec to Secure v6-over-v4 Tunnels  October 2004


   IKE_SA_INIT exchange.  Once a NAT is detected and both end points
   support IPsec NAT traversal extensions UDP encapsulation can be
   enabled.

   More details about UDP encapsulation of IPsec protected IP packets
   can be found in [I-D.ietf-ipsec-udp-encaps].

   For IPv6-over-IPv4 tunneling, NAT traversal is interesting for two
   reasons:

   1.  One of the tunnel endpoints is often behind a NAT, and configured
       tunneling, using protocol 41, is not guaranteed to traverse the
       NAT.  Hence, using IPsec tunnels would enable one to both set-up
       a secure tunnel, and set-up a tunnel where it might not always be
       possible without other tunneling mechanisms.

   2.  Using NAT traversal allows the outer address to change without
       having to renegotiate the SAs.  This could be very beneficial for
       a crude form of mobility, and in scenarios 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.


9.  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 off-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 such as TED (see
      [I-D.fluhrer-ted]).

   For the purpose of this document it is assumed that this address can
   be obtained somehow.  Once the address has been learned, it is
   configured as the tunnel end-point for the configured IPv6-over-IPv4
   tunnel.




Graveman, et al.         Expires April 24, 2005                [Page 16]


Internet-Draft    Using IPsec to Secure v6-over-v4 Tunnels  October 2004


10.  Example

   TBD: Full-fledged example

11.  Security Considerations

   When you run IPv6-in-IPv4 tunnels (unsecured) over the Internet, it
   is possible to "inject" packets in the tunnel by spoofing the source
   address (data plane security), or if the tunnel is signalled somehow
   (e.g., some messages where you authenticate to the server, so that
   you would get a static v6 prefix), someone might be able to spoof the
   signalling (control plane security).

   To add security to both, the protocol for tunnel setup and to the
   data traffic, the IPsec framework plays an important role.

   IKEv2 is a signaling protocol with optional Denial of Service
   protection which authenticates both end points (with different
   identifities) and establishes two types of security associations
   (CHILD-SAs and IKE-SA).  The authentication mechanisms are very
   flexible due to the built-in support for symmetric and asymmetric
   cryptography (or even a combination of both) and the Extensible
   Authentication Protocol support (as desribed in Figure 12).  The
   IKE-SA is used to secure most of the IKEv2 message exchange.  In
   particular the CHILD-SA exchange, Informational exchanges (such as
   the dead-peer detection mechanisms used for liveness checks) and the
   exchange of configuration messages are secured.  The CHILD-SA
   exchange leads to the establishment of a IPsec tunnel and the
   creation of SAD and SPD entries.

   As a summary, IKEv2 provides a secure signaling protocol for
   establishing, maintaining and deleting an IPsec tunnel.

   IPsec, with the Encapsulating Security Payload (ESP), offers
   integrity and data origin authentication, confidentiality, with
   optional (at the discretion of the receiver) anti-replay features.
   The usage of confidentity-only is discouraged.  ESP furthermore
   provides limited traffic flow confidentality.

   IPsec provides access control mechanisms through the distribution of
   keys and also through the usage of policies dictated by the Security
   Policy Database (SPD).  Furthermore, through the usage of EAP and the
   backend AAA infrastructure it is possible to enforce additional
   authorization mechanisms (at the user level) at entities other than
   the tunnel end points.

   The NAT traversal mechanism provided by IKEv2 introduces some
   weaknesses into IKEv2 and IPsec.  These issues are discussed in more



Graveman, et al.         Expires April 24, 2005                [Page 17]


Internet-Draft    Using IPsec to Secure v6-over-v4 Tunnels  October 2004


   detail in [I-D.ietf-ipsec-ikev2].

   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-end communication.  It protects just the tunnel part.  It is
   still possible for an IPv6 endpoint that is not attached to the IPsec
   tunnel to spoof packets.

12.  Open Issues

   This section lists some open issues that will be resolved in future
   versions of this document.

   o  Some text on the usage of IKEv1 might be useful.

   o  Discussion of 'Use of IPsec Transport Mode for Dynamic Routing'
      [I-D.touch-ipsec-vpn] would be appropriate.

   o  A more detailed description of the address configuration mechanism
      would be helpful.  The configuration example with
      CFG_REQUEST/CFG_REPLY payloads should contain IPv6 addresses.

   o  The full-fledged example of Section 10 is still missing.  A
      possible example is described below.

   o  Some notes on the implications of mobility interworking are still
      missing.

   o  Discuss the use of link-local etc.  messages with Tunnel mode SAs
      -- i.e., how many SAs will be needed (and how they are negotiated)
      if link-local messages will be present as well?

   o  The "Site-to-Router" scenarios separation is a bit weak -- any
      better ideas how to categorize these would be appreciated.

   o  Better discussion of when transport/tunnel mode SAs make sense and
      would probably be useful.

   The following paragraph describes a possible scenario for Section 10.












Graveman, et al.         Expires April 24, 2005                [Page 18]


Internet-Draft    Using IPsec to Secure v6-over-v4 Tunnels  October 2004


                                                    +------------------+
                             Transition             |   IPv6 Network   |
                             Device                 |                  |
   .--------.     _----_    .--------.    _----_    |  .--------.      |
   | V6/V4  |   _( IPv4 )_  | V4/V6  |  _( IPv6 )_  |  | V6     |      |
   | Host A |<-( Network )--| Router |-( Network )---> | Router |      |
   '--------'   (_      _)  '--------'  (_      _)  |  |   X    |      |
       ^          '----'                  '----'    |/>'--------'      |
       |                                           //      ^           |
       |                                          / |      |           |
       |                                         /  |      V           |
       |                                       //   |  .-------.       |
       |                                      /     |  |  V6    |      |
       +-------------------------------------/      |  | Host B |      |
                IPsec tunnel between                |  '--------'      |
                V6 Host and Router B                +------------------+

   As noted in the figure above there is an IPv4/IPv6 transition
   mechanism (which is not further specified) between the IPv4/IPv6
   network.  The following IPsec packet is sent from Host A towards Host
   B (via router X).

   Host A (outgoing)

   IPsec ESP, Tunnel mode
   Outer Header:
      Src IP: IPv4 A
      Dst IP: IPv4 Router X
   Inner Header:
      Src IP: IPv6 A
      Dst IP: IPv6 Host B

   The transition device then changes the source and destination IP
   address is replaced (from IPv4 to an IPv6 address):

   Router (incoming):

   IPsec ESP, Tunnel mode
   Outer Header:
      Src IP: IPv6 NAT-PT box
      Dst IP: IPv6 Router X (automatic encapsulation of IPv4 in IPv6)
   Inner Header:
      Src IP: IPv6 A
      Dst IP: IPv6 Host B







Graveman, et al.         Expires April 24, 2005                [Page 19]


Internet-Draft    Using IPsec to Secure v6-over-v4 Tunnels  October 2004


   Router X (outgoing towards Host B, packet decapsulated):

   Header:
      Src IP: IPv6 A
      Dst IP: IPv6 Host B

   The packet then travels the same path backwards experiencing the same
   procressing.

13.  Contributors

   Please note that the authors are listed in alphabetical order.

   Suresh Satapati also participated in the discussions.

14.  Acknowledgments

   The authors would like to thank Stephen Kent and Michael Richardson
   for their comments.

   We would like to thank Pasi Eronen for his text contributions.

15.  References

15.1  Normative References

   [I-D.ietf-eap-rfc2284bis]
              Blunk, L., "Extensible Authentication Protocol (EAP)",
              draft-ietf-eap-rfc2284bis-09 (work in progress), February
              2004.

   [I-D.ietf-ipsec-esp-v3]
              Kent, S., "IP Encapsulating Security Payload (ESP)",
              draft-ietf-ipsec-esp-v3-09 (work in progress), October
              2004.

   [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-ikev2-algorithms]
              Schiller, J., "Cryptographic Algorithms for use in the
              Internet Key Exchange Version 2",
              draft-ietf-ipsec-ikev2-algorithms-05 (work in progress),
              April 2004.

   [I-D.ietf-ipsec-rfc2401bis]



Graveman, et al.         Expires April 24, 2005                [Page 20]


Internet-Draft    Using IPsec to Secure v6-over-v4 Tunnels  October 2004


              Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", draft-ietf-ipsec-rfc2401bis-03 (work
              in progress), September 2004.

   [I-D.ietf-ipsec-udp-encaps]
              Huttunen, A., "UDP Encapsulation of IPsec Packets",
              draft-ietf-ipsec-udp-encaps-09 (work in progress), May
              2004.

   [I-D.ietf-ipsec-ui-suites]
              Hoffman, P., "Cryptographic Suites for IPsec",
              draft-ietf-ipsec-ui-suites-06 (work in progress), April
              2004.

   [I-D.ietf-v6ops-mech-v2]
              Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
              for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-06
              (work in progress), September 2004.

15.2  Informative References

   [I-D.bellovin-useipsec]
              Bellovin, S., "Guidelines for Mandating the Use of IPsec",
              draft-bellovin-useipsec-03 (work in progress), March 2004.

   [I-D.blanchet-v6ops-tunnelbroker-tsp]
              Parent, F. and M. Blanchet, "IPv6 Tunnel Broker with the
              Tunnel Setup Protocol(TSP)",
              draft-blanchet-v6ops-tunnelbroker-tsp-01 (work in
              progress), June 2004.

   [I-D.eronen-ipsec-ikev2-eap-auth]
              Eronen, P., "Extension for EAP Authentication in IKEv2",
              draft-eronen-ipsec-ikev2-eap-auth-02 (work in progress),
              October 2004.

   [I-D.fluhrer-ted]
              Fluhrer, S., "Tunnel Endpoint Discovery",
              draft-fluhrer-ted-00 (work in progress), November 2001.

   [I-D.ietf-aaa-eap]
              Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
              Authentication Protocol (EAP) Application",
              draft-ietf-aaa-eap-09 (work in progress), August 2004.

   [I-D.ietf-eap-keying]
              Aboba, B., "Extensible Authentication Protocol (EAP) Key
              Management Framework", draft-ietf-eap-keying-03 (work in



Graveman, et al.         Expires April 24, 2005                [Page 21]


Internet-Draft    Using IPsec to Secure v6-over-v4 Tunnels  October 2004


              progress), July 2004.

   [I-D.ietf-ipsec-ikev2-iana]
              Richardson, M., "Initial IANA registry contents",
              draft-ietf-ipsec-ikev2-iana-02 (work in progress), April
              2004.

   [I-D.ietf-ipsec-rfc2402bis]
              Kent, S., "IP Authentication Header",
              draft-ietf-ipsec-rfc2402bis-08 (work in progress), October
              2004.

   [I-D.ietf-pana-ipsec]
              Parthasarathy, M., "PANA enabling IPsec based Access
              Control", draft-ietf-pana-ipsec-04 (work in progress),
              September 2004.

   [I-D.kivinen-mobike-design]
              Kivinen, T., "Design of the MOBIKE protocol",
              draft-kivinen-mobike-design-00 (work in progress), March
              2004.

   [I-D.touch-ipsec-vpn]
              Touch, J., Eggert, L. and Y. Wang, "Use of IPsec Transport
              Mode for Dynamic Routing", draft-touch-ipsec-vpn-07 (work
              in progress), March 2004.

   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998.

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations", RFC
              2663, August 1999.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A. and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)", RFC
              2865, June 2000.

   [RFC3579]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
              Dial In User Service) Support For Extensible
              Authentication Protocol (EAP)", RFC 3579, September 2003.

   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
              Networks", BCP 84, RFC 3704, March 2004.

   [RFC3715]  Aboba, B. and W. Dixon, "IPsec-Network Address Translation
              (NAT) Compatibility Requirements", RFC 3715, March 2004.




Graveman, et al.         Expires April 24, 2005                [Page 22]


Internet-Draft    Using IPsec to Secure v6-over-v4 Tunnels  October 2004


Authors' Addresses

   Richard Graveman
   RFG Security, LLC
   15 Park Avenue
   Morristown, New Jersey  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
   Finnland

   EMail: psavola@funet.fi


   Hannes Tschofenig
   Siemens
   Otto-Hahn-Ring 6
   Munich, Bayern  81739
   Germany

   EMail: Hannes.Tschofenig@siemens.com
















Graveman, et al.         Expires April 24, 2005                [Page 23]


Internet-Draft    Using IPsec to Secure v6-over-v4 Tunnels  October 2004


Intellectual Property Statement

   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.


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 (2004).  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

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




Graveman, et al.         Expires April 24, 2005                [Page 24]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/