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

Versions: 00

IPSECME WG                                               Jitender Arora
Internet Draft                                           Prashant Kumar
Intended status: Informational                              Acme Packet
Expires: October 22, 2011                                April 22, 2010

                   Alternate Tunnel Addresses for IKEv2
        draft-arora-ipsecme-ikev2-alt-tunnel-addresses-00

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and BCP 79.

   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 October 22, 2011.

Copyright and License Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document.  Code Components extracted from this
   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the BSD License.






Arora & Kumar          Expires October 18, 2010               [Page 1]


Internet-Draft                                              April 2010


Abstract

  IKEv2 is a protocol for setting up Virtual Private Network (VPN)
  tunnels from a remote location to a gateway so that the VPN client
  can access services in the network behind the gateway. Currently the
  IKE SAs and tunnel mode Ipsec SA's are created implicitly between the
  IP addresses that are used when the IKE_SA is established. These IP
  addresses are then used as the outer (tunnel header) addresses
  for tunnel mode IPSEC packets (transport mode IPsec SAs are beyond
  the scope of this document). This document defines an IKEv2 extension
  that allows the outer tunnel header addresses for the tunnel mode
  IPSEC packets to be different than the IKE peer IP addresses.

Table of Contents

   1.    Introduction................................................2
   2.    Terminology.................................................3
   3.    IKEv2 IKE_AUTH exchange with different Tunnel Address.......3
   4.    IKEv2 CREATE_CHILD_SA exchange with different Tunnel Address4
   5.    Usage Scenarios.............................................5
      5.1.   IKEv2 signaling and the IPSEC tunnel mode traffic on
      different addresses............................................5
   6.    NAT Scenarios and Routing issues............................5
   7.    Alternate Tunnel address messages...........................6
      7.1.   DIFFERENT_TUNNEL_ADDRESS_SUPPORTED.....................6
      7.2.   TUNNEL_ADDRESS.........................................6
   8.    IANA Considerations.........................................7
   9.    Security Considerations.....................................8
      9.1.   Different Tunnel Addresses and Hijacking...............8
   10.   Acknowledgements............................................9
   11.   Informative References......................................9
      11.1.  Normative References...................................9
      11.2.  Informative References.................................9
   Author's Address.................................................10


1. Introduction

  IKEv2 [2] is used for setting up IPsec [8] based VPNs.  Currently the
  IKE SAs and tunnel mode Ipsec SA's are created implicitly between the
  IP addresses that are used when the IKE_SA is established. These IP
  addresses are then used as the outer (tunnel header) addresses
  for tunnel mode IPSEC packets. This imposes a limitation that all the
  Ikev2 signaling and the IPSEC traffic needs to go to the same address
  on the gateway. This document defines an IKEv2 extension that allows
  the outer tunnel header addresses for the tunnel mode IPSEC packets
Arora & Kumar                   Page 2                       4/22/2010

                        Expires - October 2011                [Page 2]


Internet-Draft                                              April 2010


  to be different than the IKE peer IP addresses.

  This document proposes an alternate Tunnel address mechanism for
  IKEv2 that enables a VPN gateway or the VPN client use the different
  tunnel address for the IPSEC packets than the one which is being
  used for the IKE negotiation. The tunnel address can be specified
  during the IKE_AUTH exchange and also during the CREATE_CHILD_SA
  exchange.

2. Terminology

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in [1].

3. IKEv2 IKE_AUTH exchange with different Tunnel Address

  This section describes the use of different Tunnel Address mechanism
  during the IKE_AUTH exchange. The use of different tunnel address
  during CREATE_CHILD_SA exchange are explained in subsequent
  sections.

  The VPN client indicates support for the IKEv2 different tunnel
  address mechanism and the willingness to send or receive the traffic
  on tunnel addresses different than the IKE peer addresses by
  including a DIFFERENT_TUNNEL_ADDRESS_SUPPORTED notification message
  in the initial IKE_SA_INIT request. If the VPN gateway supports this
  it will also send the DIFFERENT_TUNNEL_ADDRESS_SUPPORTED message
  back to the client in the IKE_SA_INIT response.

       Initiator                    Responder (VPN GW)
       ---------                    -------------------------

    (IKE_IP_I:500 -> IKE_IP_R:500)
    HDR(A,0), SAi1, KEi, Ni,   -->
    N(DIFFERENT_TUNNEL_ADDRESS_SUPPORTED)

                              (IKE_IP_R:500 -> IKE_IP_I:500)
                          <-- HDR(A,0),
                              N(DIFFERENT_TUNNEL_ADDRESS_SUPPORTED)


  Once the Gateway gets the notification that the different tunnel
  address is supported by the endpoint, it can choose to assign the
Arora & Kumar                   Page 3                       4/22/2010

                        Expires - October 2011                [Page 3]


Internet-Draft                                              April 2010


  tunnel address which is different than the address which is used for
  the IKEv2 signaling. Similarly the endpoint on getting the
  notification that the gateway supports the different tunnel address
  can chose to assign the different tunnel address. The following
  IKE_AUTH exchange describes this:


       Initiator                   Responder (VPN GW)
       ---------                   ---------------------------
    (IKE_IP_I:500 -> IKE_IP_R:500)
    HDR(A,B), SK {IDi, [CERT,] [CERTREQ,]
    [IDr,]AUTH, SAi2, TSi, TSr, [N(TUNNEL_ADDRESS)]} -->

                              (IKE_IP_R:500 -> IKE_IP_I:500)
                          <-- HDR(A,B), SK {IDr, [CERT,] AUTH,
                               SAr2, TSi, TSr, [N(TUNNEL_ADDRESS)]}

  The client will tell the TUNNEL-SRC-ADDRESS (client side) and the
  Gateway will tell the TUNNEL-DST-ADDRESS (gateway side). If only one
  side tells the different tunnel address, the IKE-address will be
  used as the other side's TUNNEL address.

4. IKEv2 CREATE_CHILD_SA exchange with different Tunnel Address

  This section describes the use of different Tunnel Address mechanism
  during the CREATE_CHILD_SA exchange.

  Please refer to section 3 for the DIFFERENT_TUNNEL_ADDRESS_SUPPORTED
  notification message during the IKE_SA_INIT exchange.

  Once the Gateway gets the notification that the different tunnel
  address is supported by the endpoint, it can choose to assign the
  tunnel address which is different than the address which is used for
  the IKEv2 signaling during the CREATE_CHILD_SA request. Similarly
  the endpoint on getting the notification that the gateway supports
  the different tunnel address can chose to assign the different
  tunnel address. The following CREATE_CHILD_SA exchange describes
  this:







Arora & Kumar                   Page 4                       4/22/2010

                        Expires - October 2011                [Page 4]


Internet-Draft                                              April 2010


       Initiator                   Responder (VPN GW)
       ---------                   ---------------------------
    (IKE_IP_I:500 -> IKE_IP_R:500)
    HDR(A,B), SK {{[N], SA, Ni, [KEi],
     TSi, TSr, [N(TUNNEL_ADDRESS)]} -->

                              (IKE_IP_R:500 -> IKE_IP_I:500)
                          <-- HDR(A,B), SK {SA, Nr, [KEr],
                               TSi, TSr, [N(TUNNEL_ADDRESS)]}

   The client will tell the TUNNEL-SRC-ADDRESS (client side) and the
   Gateway will tell the TUNNEL-DST-ADDRESS (gateway side). If only one
   side tells the different tunnel address, the IKE-address will be
   used as the other side's TUNNEL address.


5. Usage Scenarios

5.1. IKEv2 signaling and the IPSEC tunnel mode traffic on different
    addresses

   Currently it is not possible to separate the IKEv2 signaling and the
   IPSEC traffic on different IP addresses. There are applications
   where we would like to have different addresses for signaling and
   the IPSEC traffic coming to the gateway. One of these applications
   can be load balancing of IPSEC tunnels. In this model, all the IKEv2
   signaling from the clients will go through the IKEv2 load Balancer
   to the selected gateway on a particular IP address, where as the
   IPSEC traffic from clients will go directly to the gateway
   (bypassing the load balancer) on different address. So in this case
   the signaling and the traffic will reach the selected Gateway at
   different addresses.

6. NAT Scenarios and Routing issues

   In some scenarios, the network may contain NATs or stateful packet
   filters (for brevity, the rest of this document simply describes
   NATs).  The NAT Traversal feature specified in [IKEv2] allows IKEv2
   to work through NATs in many cases, and this draft will leverage
   this functionality.

   If the Gateway or the client determines that there is a NAT in front
   of them, they will not change the tunnel address and will keep the
   tunnel address same as the IKE address. If we try to solve this
   issue, it will add a lot of complexity to the [IKEv2] protocol.


Arora & Kumar                   Page 5                       4/22/2010

                        Expires - October 2011                [Page 5]


Internet-Draft                                              April 2010


   The issues related to the routing of the IPSEC traffic between the
   negotiated Tunnel Addresses is beyond the scope of this document.
   The network operators need to take care of the routing between the
   VPN clients and the Gateway.

7. Alternate Tunnel address messages

7.1. DIFFERENT_TUNNEL_ADDRESS_SUPPORTED

  The DIFFERENT_TUNNEL_ADDRESS_SUPPORTED payload is included in the
  initial IKE_SA_INIT request by the initiator or the
  IKE_SA_INIT_RESPONSE by responder to indicate support for the IKEv2
  different tunnel address mechanism described in this document.

                         1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Next Payload  |C|  RESERVED   |         Payload Length        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Protocol ID(=0)| SPI Size (=0) |      Notify Message Type      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size' and
  the 'Notify Message Type' fields are the same as described in
  Section 3.10 of [2].  The 'SPI Size' field MUST be set to 0 to
  indicate that the SPI is not present in this message.  The 'Protocol
  ID' MUST be set to 0, since the notification is not specific to a
  particular security association.

  The 'Payload Length' field is set to the length in octets of the
  entire payload, including the generic payload header.  The 'Notify
  Message Type' field is set to indicate the
  DIFFERENT_TUNNEL_ADDRESS_SUPPORTED Payload <value to be assigned by
  IANA>.

7.2. TUNNEL_ADDRESS

  The TUNNEL_ADDRESS payload is included in an IKE_AUTH request or
  response and also in the CREATE_CHILD_SA request or response if the
  initiator or the responder wants to use the different address for
  the tunnel address (different than the address used for the IKEv2
  signaling.

  The message includes the IP address to be used for the tunnel src
Arora & Kumar                   Page 6                       4/22/2010

                        Expires - October 2011                [Page 6]


Internet-Draft                                              April 2010


  (client) or the tunnel destination (gateway).

                         1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Next Payload  |C|  RESERVED   |         Payload Length        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Protocol ID(=0)| SPI Size (=0) |      Notify Message Type      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | IP Type |                     |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                   IPv4 or the IPv6 address                   ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The 'Next Payload', 'Payload Length', 'Protocol ID', 'SPI Size' and
  the 'Notify Message Type' fields are the same as described in
  Section 3.10 of [2].  The 'SPI Size' field MUST be set to 0 to
  indicate that the SPI is not present in this message.  The 'Protocol
  ID' MUST be set to (2) to indicate AH or (3) to indicate ESP, since
  the notification is specific to an IPSEC Security Associations.
  The 'Payload Length' field is set to the length in octets of the
  entire payload, including the generic payload header.  'Notify
  Message Type' field is set to indicate the TUNNEL_ADDRESS payload
  <value to be assigned by IANA>.  The IP Type' field indicates the IP
  address type. The following values are valid in the TUNNEL ADDRESS
  payload.

      1 - IPv4 address
      2 - IPv6 address

  The IPv4 address, the IPv6 address MUST be encoded as described in
  section 3.5 of [2].

8.   IANA Considerations

  This document defines two new IKEv2 Notification Message types as
  described in Section 7. The two Notify Message Types must be
  assigned values between 16396 and 40959.

   o  DIFFERENT_TUNNEL_ADDRESS_SUPPORTED
   o  TUNNEL_ADDRESS

Arora & Kumar                   Page 7                       4/22/2010

                        Expires - October 2011                [Page 7]


Internet-Draft                                              April 2010


  This document creates a new namespace called the "IP Type".  This is
  used to indicate the type of IP address being used.

      1 - IPv4 Tunnel address
      2 - IPv6 Tunnel address

  Values '0', and 4-240 are reserved.  New values can be allocated by
  Expert Review [9].  Values 241-255 are set aside for private use.  A
  specification that extends this registry MUST also mention which of
  the new values are valid in which Notification payload.

9. Security Considerations

  The main goals of this specification are to maintain the security
  offered by usual IKEv2 procedures and to counter any threats
  introduced by this draft in an appropriate manner.  This section
  describes new security considerations introduced by this draft.  See
  [IKEv2] for security considerations for IKEv2 in general.

9.1. Different Tunnel Addresses and Hijacking

   The payloads relating to different tunnel addresses are encrypted,
   integrity protected, and replay protected using the IKE_SA.  This
   assures that no one except the participants can, for instance, give
   a control message to use the different tunnel address.

   However, as with normal IKEv2, the actual IP addresses in the IP
   header are not covered by the integrity protection.  This means that
   a NAT between the parties (or an attacker acting as a NAT) can
   modify the addresses and cause incorrect tunnel header (outer) IP
   addresses to be used for IPsec SAs.  The scope of this attack is
   limited mainly to denial of service because all traffic is protected
   using IPsec.

   This attack can only be launched by on-path attackers that are
   capable of modifying IKEv2 messages carrying NAT detection
   indications (such as Dead Peer Detection messages).  By modifying
   the IP header of these packets, the attackers can lead the peers to
   believe a new NAT or a changed NAT binding exists between them.  The
   attack can continue as long as the attacker is on the path,
   modifying the IKEv2 messages.



Arora & Kumar                   Page 8                       4/22/2010

                        Expires - October 2011                [Page 8]


Internet-Draft                                              April 2010



10.  Acknowledgements

    Thanks to Bob Penfield and others for their input.

11.  Informative References

11.1.     Normative References

  [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.

  [2]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
       4306, December 2005.

11.2.     Informative References

  [3]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
       IPv6", RFC 3775, June 2004.

  [4]  Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
       Bootstrapping in Split Scenario", RFC 5026, October 2007.

  [5]  Haley, B., Devarapalli, V., Deng, H., and J. Kempf, "Mobility
       Header Home Agent Switch Message", RFC 5142, January 2008.

  [6]  Eronen, P. and J. Korhonen, "Multiple Authentication Exchanges
       in the Internet Key Exchange (IKEv2) Protocol", RFC 4739,
       November 2006.

  [7]  Weniger, K. and F. Dupont, "IKEv2-based Home Agent Assignment
       In Mobile IPv6/NEMO Bootstrapping", draft-dupont-ikev2-
       haassign-02 (work in progress), January 2007.

  [8]  Kent, S. and K. Seo, "Security Architecture for the Internet
       Protocol", RFC 4301, December 2005.

  [9]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
       Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

  [10] V. Devarapalli and K. Weniger, "Redirect Mechanism for the
       Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5685,
       November 2009



Arora & Kumar                   Page 9                       4/22/2010

                        Expires - October 2011                [Page 9]


Internet-Draft                                              April 2010





Author's Address

   Jitender Arora
   Acme Packet
   71 Third Ave.
   Burlington, MA 01803, USA
   Email: jarora@acmepacket.com

   Prashant Kumar
   Acme Packet
   71 Third Ave.
   Burlington, MA 01803, USA
   Email: pkumar@acmepacket.com

































Arora & Kumar                  Page 10                      4/22/2010

                        Expires - October 2011               [Page 10]


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