[Search] [txt|xml|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
Network Working Group                                     Amjad. Inamdar
Internet-Draft                                                  R. Singh
Intended status: Standards Track                                   Cisco
Expires: September 13, 2014                               March 12, 2014


           IKEv2 based lightweight secure data communication
           draft-amjads-ipsecme-ikev2-data-channel-01 (D-IKE)

Abstract

   The Internet Key Exchange (IKEv2) protocol provides authentication,
   confidentiality, integrity, data-origin authentication and anti-
   replay.  Currently, IKEv2 is mainly used as a control channel to
   negotiate IPsec SA(s).  IPsec is not well suited to provide transport
   layer security for applications as it resides at the network layer
   and most of the IPsec implementations require integration into
   operating systems making it difficult to deploy.  IPsec uses
   different sessions for control and data traffic which is not NAT and
   load balancer friendly.  TLS/DTLS, the other popular security
   mechanism to provide the above security services does not mandate
   mutual peer authentication and Diffie Hellman exchange.

   This document describes an IKEv2 based lightweight secure data
   communication protocol and a way to provide transport layer security
   for UDP client/server applications.  The protocol provides integrity
   protected encryption and integrity-only protection based on
   application needs.  As most of the IoT applications are UDP based,
   IKEv2 can be used for key management as well secure data
   communication in IoT due to its simplicity, scalability,
   lightweightedness and ease of deployment.

Status of This Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on September 13, 2014.



Inamdar & Singh        Expires September 13, 2014               [Page 1]


Internet-Draft             IKEv2 data channel                 March 2014


Copyright Notice

   Copyright (c) 2014 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 Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  D-IKE comparision with IPsec  . . . . . . . . . . . . . . . .   3
   4.  D-IKE comparision with DTLS . . . . . . . . . . . . . . . . .   4
   5.  D-IKE Description . . . . . . . . . . . . . . . . . . . . . .   4
   6.  Securing UDP applications with D-IKE  . . . . . . . . . . . .   4
   7.  Benefits  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   8.  Protocol Outline  . . . . . . . . . . . . . . . . . . . . . .   7
   9.  D-IKE capabilities  . . . . . . . . . . . . . . . . . . . . .   7
     9.1.  Encryption and Integrity protection . . . . . . . . . . .   7
     9.2.  Integrity only protection . . . . . . . . . . . . . . . .   8
   10. D-IKE negotiation . . . . . . . . . . . . . . . . . . . . . .   8
   11. D-IKE packet and payload formats  . . . . . . . . . . . . . .   9
     11.1.  D-IKE_SUPPORTED Notify payload . . . . . . . . . . . . .   9
     11.2.  D-IKE Control and Data packets . . . . . . . . . . . . .  10
     11.3.  D-IKE payload  . . . . . . . . . . . . . . . . . . . . .  11
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  11
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   14. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   15. Change Log  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     15.1.  Draft -01  . . . . . . . . . . . . . . . . . . . . . . .  12
   16. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     16.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     16.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Appendix A.  Design decisions . . . . . . . . . . . . . . . . . .  13
     A.1.  Use of the existing IKEv2 control channel . . . . . . . .  13
     A.2.  IKEv2 header modification . . . . . . . . . . . . . . . .  14
     A.3.  Use of separate UDP port for data channel . . . . . . . .  14
   Appendix B.  Possible extensions  . . . . . . . . . . . . . . . .  14
     B.1.  Securing TCP client/server applications using D-IKE . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15



Inamdar & Singh        Expires September 13, 2014               [Page 2]


Internet-Draft             IKEv2 data channel                 March 2014


1.  Introduction

   The Internet Key Exchange Protocol version 2 (IKEv2), specified in
   RFC5996 [1], is a UDP based protocol that provides a secure
   communication channel similar to ESP defined in RFC4303 [2].  IKEv2
   defines mechanisms for mutual authentication of peers, key
   management, SA management and exchange of configuration information.
   IKEv2 is mainly used as a secure control channel to negotiate child
   IPsec SAs.  As IKEv2 provides encryption, integrity protection, data
   origin authenication and replay protection similar to ESP, IKEv2 can
   be leveraged for secure data communication.  This document defines an
   IKEv2 based secure data communication mechanism (henceforth referred
   to as D-IKE) and describes a way to secure UDP applications with
   D-IKE.  While the IKE control channel is always encryption and
   integrity protected, the IKE data channel can provide encryption and
   integrity protection as well as integrity-only protection depending
   on the needs of the application.


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 RFC 2119 [7].


3.  D-IKE comparision with IPsec

   o  D-IKE being UDP based is easier to deploy as it resides in the
      operating system application space and does not require
      integration with the operating system kernel unlike most of the
      IPsec implementations

   o  D-IKE is lighter with fewer keys and protocol exchanges as it uses
      the same channel for control messages and data

   o  D-IKE is simpler as it does not involve programming the Security
      Policy Database (SPD)

   o  D-IKE being at transport layer is better suited to provide
      granular and end-to-end security to applications than IPsec which
      provides network layer security suitable for site to site

   o  D-IKE control and data channels run over a single UDP port and
      hence D-IKE is load balancer friendly






Inamdar & Singh        Expires September 13, 2014               [Page 3]


Internet-Draft             IKEv2 data channel                 March 2014


4.  D-IKE comparision with DTLS

   o  D-IKE provides better enforcement of security through mandatory
      mutual peer authentication and Diffie Hellman key exchange

   o  D-IKE supports comprehensive authentication methods and has built-
      in support for mobility, DOS attack mitigation and load balancing


5.  D-IKE Description

   Each UDP application using D-IKE for security will use different UDP
   port numbers.  So with D-IKE, IKEv2 packets are no longer identified
   by UDP ports 500 and 4500.  D-IKE will use a different UDP port
   number for each UDP application to carry the D-IKE control messages
   for IKEv2 negotiation as well as application data.  The first octet
   in the UDP payload will identify D-IKE control and data packets.
   D-IKE control packets will carry the IKEv2 header and payloads as
   defined in RFC5996 [1] and will be used to negotiate a childless
   IKEv2 session between UDP client and server.  D-IKE data packets will
   carry encrypted and authenticated UDP application data.

   The following diagram depicts the format of UDP encapsulated D-IKE
   control and Data packets.

       +------------+------+----------+---------------------------+
       | UDP Header | Type | RESERVED | D-IKE Control/Data Packet |
       +------------+------+----------+---------------------------+
                    |<---------------- UDP Payload -------------->|

                      Encapsulation of D-IKE packets

   D-IKE can provide integrity-only protection in addition to integrity
   protected encryption.  D-IKE does not negotiate child IPsec SAs in
   the IKEv2 initial exchange and subsequently as depicted in D-IKE
   Negotiation section, similar to Childless IKEv2 defined in RFC6023
   [3].

   Please refer the appendix section of this document for details on the
   alternative mechanisms that were considered for data communication
   over IKEv2 and their drawbacks.


6.  Securing UDP applications with D-IKE

   This document introduces the concept of D-IKE sockets to secure
   communication between UDP client/server applications.  D-IKE socket
   is an IKEv2 session between a UDP client and server uniquely



Inamdar & Singh        Expires September 13, 2014               [Page 4]


Internet-Draft             IKEv2 data channel                 March 2014


   identified by the 4 tuple of client and server IP addresses and UDP
   ports.


               +--------------+              +--------------+
               |  UDP Client  |              | UDP Service  |
               +--------------+              +--------------+
               | D-IKE socket |              | D-IKE socket |
               +--------------+              +--------------+
               |     UDP      |              |      UDP     |
               +--------------+              +--------------+
               |      IP      |<------------>|      IP      |
               +--------------+              +--------------+

                               D-IKE Sockets


   o  A UDP service will register with D-IKE socket specifying the UDP
      port it wants to listen to.  D-IKE will listen on the UDP port
      number on behalf of the application

   o  A UDP client will open a D-IKE socket specifying the server IP
      address and the UDP port number.  D-IKE will open a UDP socket to
      the server on behalf of the client

   o  D-IKE will initiate an IKEv2 session without any child SA from UDP
      client to the server

   o  After successful negotiation of IKEv2 session, the client and
      server can securely exchange data over D-IKE socket


               UDP Client                           UDP Server
               ----------                           ----------
                   |                                    |
                   |<-------- IKE negotiation --------->|
                   |                                    |
                   |<----- Secure Data Transfer ------->|
                   |                                    |

                    Secure UDP communication over D-IKE


   For a node running multiple UDP applications(Clients and/or
   Services), each UDP application will have a unique D-IKE socket






Inamdar & Singh        Expires September 13, 2014               [Page 5]


Internet-Draft             IKEv2 data channel                 March 2014


           +----------------+----------------+----------------+
           |    UDP App 1   |    UDP App 2   |   UDP App N    |
           +----------------+----------------+----------------+
           | D-IKE socket 1 | D-IKE socket 2 | D-IKE socket N |
           +----------------+----------------+----------------+
           |                        UDP                       |
           +--------------------------------------------------+
           |                        IP                        |
           +--------------------------------------------------+

                     D-IKE socket per UDP Application


   A well known UDP service can simultaneously open a UDP socket as well
   as D-IKE socket.

        +--------------+    +---------------------------+    +------------+
        |  UDP Client  |    |        UDP Service        |    | UDP Client |
        +--------------+    +---------------------------+    +------------+
        | D-IKE socket |    | D-IKE socket | UDP Socket |<-->| UDP Socket |
        +--------------+    +--------------+------------+    +------------+
        |      UDP     |<-->|     UDP      |      |<-- Unsecured -->|
        +--------------+    +--------------+         Communication
                |<----- Secure ----->|
                        Communication

                   Securing UDP Applications using D-IKE


   The following diagram shows the format of D-IKE packet.

                   |<------------- D-IKE packet -------------->|
       +----+------+--------+-------------+---------+----------+
       | IP | UDP  | D-IKE  |   UDP App   | D-IKE   |  D-IKE   |
       |    |      | Header |   Data      | Trailer | Checksum |
       +----+------+--------+-------------+-- ------+----------+
                   |        |<----- Encrypted ----->|
                   |<----- Integrity Protected ---->|

                            D-IKE packet format

   D-IKE packet consists of D-IKE header, UDP application data, an
   optional D-IKE trailer and D-IKE integrity checksum value.








Inamdar & Singh        Expires September 13, 2014               [Page 6]


Internet-Draft             IKEv2 data channel                 March 2014


7.  Benefits

   o  Lightweight, scalable and simpler with fewer keys and protocol
      exchanges

   o  Support for integrity-only protection, in addition to integrity
      protected encryption

   o  Works seamlessly with load balancers and PAT devices as D-IKE uses
      the same UDP port as the IKEv2 control channel


8.  Protocol Outline

   This document proposes following extensions to IKEv2 protocol for
   data communication:

   o  IKEv2 Notify type 'D-IKE_SUPPORTED' to negotiate the use of IKEv2
      for data communication
   o  D-IKE packet formats


9.  D-IKE capabilities

   D-IKE will support the following data protection modes:

   o  Encryption and Integrity protection
   o  Integrity only protection


9.1.  Encryption and Integrity protection

   This protection mode provides encryption and integrity protection of
   D-IKE packets similar to the IKEv2 Encrypted payload as defined in
   RFC5996 [1]

   The UDP app data and D-IKE trailer are encrypted and the D-IKE
   header, UDP app data and D-IKE trailer are integrity protected.

       +----+------+--------+-------------+---------+----------+
       | IP | UDP  | D-IKE  |   UDP App   | D-IKE   |  D-IKE   |
       |    |      | Header |   Data      | Trailer | Checksum |
       +----+------+--------+-------------+-- ------+----------+
                   |        |<----- Encrypted ----->|
                   |<----- Integrity Protected ---->|

                    Encryption and Integrity protection




Inamdar & Singh        Expires September 13, 2014               [Page 7]


Internet-Draft             IKEv2 data channel                 March 2014


9.2.  Integrity only protection

   This protection mode provides integrity protection of IKEv2 data
   packets and no encryption similar to ESP null encryption as described
   in RFC4303 [2].  This is suitable for applications that just need
   data integrity and not confidentiality such as routing protocol
   exchanges.  It may be noted that integrity only protection applies
   only to D-IKE packets and that D-IKE control packets will always use
   integrity protected encryption.

   The UDP app data and D-IKE trailer are encrypted and the D-IKE
   header, UDP app data and D-IKE trailer are integrity protected.

           +----+------+--------+-------------+----------+
           | IP | UDP  | D-IKE  |   UDP App   |  D-IKE   |
           |    |      | Header |   Data      | Checksum |
           +----+------+--------+-------------+----------+
                       |<---- Integrity ----->|
                               Protected

                         Integrity only protection

10.  D-IKE negotiation

   IKEv2 nodes can negotiate to use D-IKE and its capabilities by
   exchanging D-IKE_SUPPORTED Notify type in IKE_SA_INIT exchange.

   o  IKEv2 initiator can communicate its intent to use D-IKE by
      including a notify payload of type D-IKE_SUPPORTED along with the
      proposed capabilities in IKE_SA_INIT request

   o  IKEv2 responder can indicate its willingness to use D-IKE with the
      proposed capabilities by including a notify payload of type
      D-IKE_SUPPORTED along with the same capabilities in IKE_SA_INIT
      response

   o  If the capabilities proposed by IKEv2 Initiator are not acceptable
      to IKEv2 responder, it MUST NOT include D-IKE_SUPPORTED Notify
      type in IKE_SA_INIT response

   o  The absence of Notify payload of type D-IKE_SUPPORTED in
      IKE_SA_INIT response indicates the incapability or unwillingness
      of the IKEv2 responder to use D-IKE

   o  If IKEv2 responder does not include the same capabilities as
      proposed by IKEv2 initiator, IKEv2 initiator MUST treat this as
      unsuccessful negotiation of D-IKE




Inamdar & Singh        Expires September 13, 2014               [Page 8]


Internet-Draft             IKEv2 data channel                 March 2014


   o  On unsuccessful negotiation of D-IKE, IKEv2 initiator and
      responder MUST NOT use D-IKE for data transfer.  However rest of
      the IKEv2 negotiation can proceed as normal

   o  On successful negotiation of D-IKE, IKEv2 Initiator and Responder
      MUST exclude any payloads related to Child SA negotiation in
      IKE_AUTH exchange and can use D-IKE for data transfer


       Initiator                                 Responder
       ------------------------------------------------------
       HDR, SAi1, KEi, Ni
       [N(D-IKE_SUPPORTED)] -->

                               <-- HDR, SAr1, KEr, Nr, [CERTREQ]
                                       N(D-IKE_SUPPORTED)

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

                               <-- HDR, SK {IDr, [CERT,] AUTH,
                                       [CP(CFG_REPLY)]

                      IKEv2 data channel negotiation


11.  D-IKE packet and payload formats

11.1.  D-IKE_SUPPORTED Notify payload

                       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  !   SPI Size    !      Notify Message Type      !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !     Flags     !                   RESERVED                    !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      D-IKE_SUPPORTED Notify payload

   o  Protocol ID (1 octet): MUST be 1, as this message is related to an
      IKEv2 SA

   o  SPI Size (1 octet): MUST be zero, in conformance with section 3.10
      of [RFC5996]



Inamdar & Singh        Expires September 13, 2014               [Page 9]


Internet-Draft             IKEv2 data channel                 March 2014


   o  Notify Message Type (2 octets): MUST be xxxxx, the value assigned
      for D-IKE_SUPPORTED by IANA

   o  Flags (8 bits): Specify the IKEv2 Data channel properties

      *  bit 0:

            0 - Encryption and Integrity protection
            1 - Integrity-only protection


      *  bit 1-7:

            Reserved, sender MUST set these bits to zero and receiver
            MUST ignore it


11.2.  D-IKE Control and Data packets

   The first octet in the UDP payload will identify D-IKE control and
   data packets.  D-IKE control packets will carry the IKEv2 header and
   payloads as defined in RFC 5996 and will be used to negotiate a
   childless IKEv2 session between UDP client and server.  D-IKE data
   packets will carry encrypted and authenticated UDP application data.

                       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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |                   RESERVED                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                   IKEv2 Header and payloads                   ~
   |                              or                               |
   |                      D-IKE data payload                       |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      D-IKE Control and Data packets

   o  Type (1 octet, unsigned integer): Identifies D-IKE control and
      data packet

      *  0 - D-IKE control packet
      *  1 - D-IKE data packet
      *  2 - 7 - RESERVED






Inamdar & Singh        Expires September 13, 2014              [Page 10]


Internet-Draft             IKEv2 data channel                 March 2014


11.3.  D-IKE payload

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             |           RESERVED            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             SPI                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Sequence Number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Initialization Vector                     |
   |         (length is block size for encryption algorithm)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                    Encrypted/Cleartext Data                   ~
   +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |             Padding (0-255 octets)            |
   +-+-+-+-+-+-+-+-+                               +-+-+-+-+-+-+-+-+
   |                                               |  Pad Length   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                    Integrity Checksum Data                    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                               D-IKE payload

   o  Length (2 octets, unsigned integer): Length in octets of the
      entire IKEv2 Data packet

   o  Reserved (2 octets): Sender MUST set these bits to zero and
      receiver MUST ignore these bits

   o  SPI (8 octets): A value used by receiver to lookup the session
      associated with the packet in order to verify integrity and
      decrypt the data packet.  This value is usually the data packet
      receiver's IKE SPI

   o  Sequence Number (4 octets): This field identifies the D-IKE packet
      sequence numbers, used for anti-replay checks


12.  Security Considerations

   This protocol variation inherits all the security properties of
   regular IKEv2 as described in [RFC5996].  The new notification
   carried in the initial exchange advertises the capability, and cannot
   be forged or added by an adversary without being detected, because
   the response to the initial exchange is authenticated with the AUTH



Inamdar & Singh        Expires September 13, 2014              [Page 11]


Internet-Draft             IKEv2 data channel                 March 2014


   payload of the IKE_AUTH exchange.  IKEv2 data payload inherits all
   security properties of ESP protocol defined in [RFC4303].


13.  IANA Considerations

   This document introduces one new IKEv2 Notification Message types as
   described in Section 11.1.  The new Notify Message Types must be
   assigned values between 16429 and 40959.

   o  D-IKE_SUPPORTED

   For UDP applications that need a well known port number to secure the
   application using D-IKE (for example, CoAP over D-IKE), the port
   number MUST be reserved from IANA.


14.  Acknowledgements

   We would like to thank following people (in alphabetical order) for
   their review comments and valuable suggestions for idea and initial
   version of the document: Amit Phadnis, Arif Shouqi, Balaji B L, Brian
   Weis, Cheryl Madson, Frederic Detienne, J P Vasseur, Kalyani
   Garigipati, Mike Sullenberger, Naresh Sunkara, Nick Doyle, Paul
   Hoffman, Rajiv Shankar Daulath, Ramesh Nethi, Sandeep Rao, Scott
   Fluhrer, and Thamil Kandasamy.


15.  Change Log

   This section lists all the changes in this document.

   NOTE TO RFC EDITOR: Please remove this section in before final RFC
   publication.


15.1.  Draft -01

   Reworked the draft with more focus on UDP application security.
   Updated the problem statement.  Added comparision with IPsec and TLS/
   DTLS.  Updated D-IKE Notify and Data payloads.  Added possible
   extensions.

16.  References







Inamdar & Singh        Expires September 13, 2014              [Page 12]


Internet-Draft             IKEv2 data channel                 March 2014


16.1.  Normative References

   [1]        Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
              "Internet Key Exchange Protocol Version 2: IKEv2", RFC
              5996, September 2010.

   [2]        Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
              4303, December 2005.

   [3]        Nir, Y., Tschofenig, H., Deng, H., and R. Singh, "A
              Childless Initiation of IKEv2 SA", RFC 6023, October 2010.

   [4]        Smyslov, V., "IKEv2 Fragmentation", draft-ietf-ipsecme-
              ikev2-fragmentation-02 (work in progress), September 2013.

   [5]        Rowles, S., Yeung, A., Tran, P., and Y. Nir, "Group Key
              Management using IKEv2", draft-yeung-g-ikev2-06 (work in
              progress), April 2013.

   [6]        Kivinen, T., "Minimal IKEv2", draft-ietf-lwig-
              ikev2-minimal-00.txt (work in progress), April 2013.

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

16.2.  Informative References

   [8]        Devarapalli, V. and K. Weniger, "Redirect Mechanism for
              IKEv2", RFC 5685, November 2009.

Appendix A.  Design decisions

   This section describes the alternative mechanisms for data
   communication over IKEv2 that were considered and their drawbacks.

A.1.  Use of the existing IKEv2 control channel

   The existing IKEv2 control channel can be used for data transfer
   using a new IKEv2 exchange type DATA exchange similar to
   INFORMATIONAL exchange, and a new payload type to encapsulate
   cleartext data that will be protected by Encrypted payload.

   A drawback with this approach is that the data packets will incur the
   overhead of IKEv2 header (28 octets) and a minimum of two generic
   payload headers (4 octets each) with a total protocol overhead of 36
   octets per data packet.  Also, it is difficult to support
   unacknowledged data transfer and integrity-only protection for data
   packets.



Inamdar & Singh        Expires September 13, 2014              [Page 13]


Internet-Draft             IKEv2 data channel                 March 2014


A.2.  IKEv2 header modification

   IKEv2 header can be modified to allow differentiation between control
   and data packets using the first four bytes of the header and the
   rest of the header can be different for control and data packets.  A
   possible way to accomplish this is to move the Exchange type field to
   the beginning of IKEv2 header.

   The obvious drawback with this approach is that it is not backward
   compatible with existing IKEv2 protocol.  Also, it makes it difficult
   to support unacknowledged data transfer and integrity-only protection
   for data packets.


A.3.  Use of separate UDP port for data channel

   A separate UDP port e.g 501 can be used for IKEv2 data channel that
   allows to leverage the IKEv2 protocol's security and reliability
   mechanisms and security parameters for data communication while
   avoiding the overhead of IKEv2 header and generic payload headers for
   data packets.  Use of a fixed UDP port for data channel instead of
   dynamically negotiated UDP ports has the advantage of not requiring
   the firewalls to snoop the IKEv2 control channel to be able to
   determine and allow the traffic on data channel UDP port.

   A drawback with this approach is that the use of different ports for
   IKEv2 control and data channels makes it difficult for load balancers
   to associate an IKEv2 control channel with its data channel when
   there are multiple IKEv2 initiators behind a PAT device.  Also when
   IKEv2 initiator is behind a PAT device, the data packets from
   responder will be dropped by the PAT device as port 501 will not be
   open unless there is data traffic from initiator.


Appendix B.  Possible extensions

   This section describes the possible extensions to D-IKE protocol.

B.1.  Securing TCP client/server applications using D-IKE

   D-IKE can be used to secure TCP applications using one of the
   following methods.

   o  While IKE control channel can run over UDP, the IKE data channel
      can negotiate and run over a TCP session carring D-IKE protected
      application data.  A drawback with this approach is that using
      differnet sessions for control and data may not be friendly with
      load balancers



Inamdar & Singh        Expires September 13, 2014              [Page 14]


Internet-Draft             IKEv2 data channel                 March 2014


   o  If IKEv2 were to run over TCP, IKEv2 over TCP can be used to
      secure TCP applications

   o  D-IKE tunnel mode can be defined that can encapsulate TCP or any
      other protocol over D-IKE tunnel


Authors' Addresses

   Amjad S. Inamdar
   Cisco Systems India Pvt. Ltd.
   SEZ Unit, Cessna Business Park
   Sarjapur Marathahalli Outer Ring Road
   Bangalore, Karnataka  560087
   India

   Phone: +91 80 4426 4834
   Email: amjads@cisco.com


   Rajeshwar Singh Janwar
   Cisco Systems India Pvt. Ltd.
   SEZ Unit, Cessna Business Park
   Sarjapur Marathahalli Outer Ring Road
   Bangalore, Karnataka  560087
   India

   Phone: +91 80 4426 2731
   Email: rsj@cisco.com






















Inamdar & Singh        Expires September 13, 2014              [Page 15]