Network Working Group Amjad. Inamdar
Internet-Draft R. Singh
Intended status: Standards Track Cisco
Expires: March 19, 2014 September 15, 2013

IKEv2 based lightweight secure data communication
draft-amjads-ipsecme-ikev2-data-channel-00

Abstract

This document describes an IKEv2 based lightweight secure data communication mechanism over UDP port 4500, that supports reliable and unreliable data transfers, integrity protected encryption and integrity-only protection, in-band and out-of-band keys, fragmentation and payload identification. With this mechanism, IKEv2 provides a complete secure connectivity solution that addresses key management and secure data communication needs of applications.

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 March 19, 2014.

Copyright Notice

Copyright (c) 2013 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

The Internet Key Exchange Protocol version 2 (IKEv2), specified in RFC5996 [RFC5996], is a UDP based reliable protocol that provides encrypted and integrity protected secure communication channel similar to ESP defined in RFC4303 [RFC4303]. IKEv2 defines mechanisms for mutual authentication of peers, session key establishment, SA management and exchange of configuration information. As IKEv2 provides encryption, integrity protection, replay protection along with reliable communication, mobility, windowing, load-balancing and fragmentation, IKEv2 has all the properties required for scalable secure data communication.

This document defines an IKEv2 based secure data communication mechanism over UDP port 4500, henceforth referred to as IKEv2 data channel in this document. To be able to use IKEv2 data channel the IKEv2 negotiation MUST start on port 4500. For application multiplexing, either ephemeral source UDP port numbers or IKEv2 identity MAY be used. A packet received on UDP port 4500 can either be an IKE packet or an ESP packet. The first 4 octets of the UDP payload are used to differentiate between IKE and ESP packets. For ESP packets the first octets form the ESP SPI, a non-zero value with values 1 through 255 reserved. This draft proposes to use one of the reserved ESP SPI values as IKEV2-DATA-MARKER to identify IKEv2 data packets. Differentiating IKEv2 data packets from control packets 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. It also enables the support for unacknowledged data transfer, integrity-only protection, out-of-band keys, fragmentation, payload identification and secure group communication. Similar to Childless IKEv2 defined in RFC6023 [RFC6023], IKEv2 data channel does not negotiate/require child IPsec SA in the IKEv2 initial exchange and subsequently.

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.

Secure connectivity in Internet of Things (IoT) and Machine to Machine (M2M) domains offers unique challenges. The challenges of secure connectivity solution for IoT and M2M are: being lightweight, scalability, reliability and easier deployment. The solution must be lightweight for the resource constrained IoT devices, scalable for IoT gateways to aggregate a multitude of IoT devices, reliable for the lossy sensor networks and easily deployable on a variety of IoT device and gateway vendor platforms and operating systems.

IKEv2 data channel is lightweight and scalable as it is UDP based and hence resides in the application layer. It resides in the operating system user space and does not require integration within operating system kernel. It uses only parent IKEv2 SA negotiation. It uses a minimal overhead secure encapsulation by avoiding the overhead of IKEv2 header and generic payload headers for data packets. IKEv2 data channel provides reliability using the IKEv2 protocol's retransmission mechanism. IKEv2 data channel does not require operating system integration and resides in application space, hence it is easily deployable on different operating system platforms. So IKEv2 data channel addresses the above challenges of secure connectivity solution for IoT and M2M.

Further, IKEv2 data channel also provides unreliable data transfer, an option for integrity-only protection for applications that do not require confidentiality such as routing protocols. IKEv2 data channel can also provide secure group communication by integrating with group keying mechanism such as Group Key Management using IKEv2 defined in G-IKEv2 [G-IKEv2].

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 [RFC2119].

3. Benefits

Following are some of the benefits of IKEv2 data channel:

  1. Lightweight and scalable data communication mechanism.
  2. Support for acknowledged and unacknowledged data transfer.
  3. Support for integrity-only protection, in addition to integrity protected encryption.
  4. Support for multicast communication using G-IKEv2 as control channel.
  5. Easier integration and adoption across multiple platforms and operating systems as the IKEv2 protocol resides in OS application layer (user space).
  6. Reliable secure communication over UDP suitable for lossy networks.
  7. Better NAT and firewall traversal, IKEv2 protocol being UDP based.
  8. Leverages the built in support for mobility, fragmentation and load balancing mechanisms in IKEv2.
  9. Support for IKEv2 based certificate as well pre-shared key and EAP authentication methods.
  10. As IKEv2 is an identity centric protocol rather than IP centric, IKEv2 data channel provides easier integration with policy servers in dynamic deployment scenarios.
  11. IKEv2 data channel can leverage any protocol improvements to IKEv2 control channel e.g. Minimal IKEv2 [Minimal-IKEv2].
  12. Since IKEv2 data channel uses the same UDP port as control channel, it works seamlessly with load balancers and PAT devices.
  13. Support for payload type identification in tunnelling mode, allowing a session to carry multiple traffic types such as IPv4, IPv6, non-IP and other traffic types
  14. Support for application multiplexing using either ephemeral source UDP port numbers or IKEv2 identity.

4. Usage Scenarios

One of the main use cases envisaged for IKEv2 data channel is secure communication for IoT and M2M for endpoint to endpoint and endpoint to gateway that would aggregate and relay the connections to back-end applications.

1. Endpoint to Endpoint: IKEv2 data channel in endpoint to endpoint scenario offers the advantages of being lightweight and easily deployable being data-plane and hardware independent.

 
               ----------                        ----------
              |          |  IKEv2 data channel  |          |
              | Endpoint |<-------------------->| Endpoint |
              |          |                      |          |
               ----------                        ---------- 
			

Endpoint to Endpoint

2. Endpoint to Security Gateway: IKEv2 data channel in endpoint to security gateway scenario offers the advantages being scalable to be able to aggregate large number of sessions and relay the connections to back-end applications in the datacenter.

 
               ----------                       ---------
              |          |  IKEv2 data channel |         |    Back-end 
              | Endpoint |<------------------->| Gateway |<-> Applications 
              |          |                     |         |
               ----------                       ---------
			

Endpoint to Gateway

Use-cases of IKEv2 data channel for IoT and M2M scenarios:

  1. UDP based IKEv2 data channel provides a lightweight and scalable secure connectivity solution for IoT and M2M domains.
  2. The IKEv2 data channel's reliable data transfer is suitable for lossy sensor networks.
  3. The IKEv2 data channel's unreliable data transfer is suitable for delay sensitive applications.
  4. The IKEv2 data channel's integrity-only protection is suitable for routing protocol security.
  5. With IKEv2 data channel, IKEv2 provides a single and complete solution for key management and secure communication needs of the applications such as IoT and M2M.



5. Protocol Outline

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

6. IKEv2 data channel capabilities

IKEv2 data channel will support the following data transfer modes:

IKEv2 data channel will support the following data protection modes:

IKEv2 data channel will support in-band and out-of-band keys:

IKEv2 data channel will support data fragmentation built within IKEv2 data payload.

The IKEv2 data channel capabilities are negotiated using the IKEV2_DATA_CHANNEL_SUPPORTED Notify in IKE_SA_INIT exchange. Any combination of data transfer modes, protection modes and in-band or out-of-band keys can be negotiated.

6.1. Acknowledged data transfer

This data transfer mode provides a lightweight reliable data transfer over UDP suitable for lossy transports such as sensor networks. This mode will use IKEv2 protocol's existing reliability and windowing mechanisms as described in [RFC5996]. This mode uses IKEv2 data and data-ack packets. The Message IDs are used for reliability and replay protection.




 			
   Initiator             Responder
   -------------------------------
 a)  IKEv2-Data     -->
                    <--  IKEv2-Data-Ack

 b)  IKEv2-Data     -->
                    <--  IKEv2-Data-Ack

 c)                 <--  IKEv2-Data
     IKEv2-Data-Ack -->
			

Acknowledged data transfer

6.2. Unacknowledged data transfer

This mode provides unreliable data transfer over UDP suitable for delay sensitive traffic such as voice. This mode uses unidirectional packet sequence numbers for replay protection similar to ESP anti-replay mechanism as described in [RFC4303]. This mode uses IKEv2 data packets with no data-ack packets.

   Initiator             Responder
   -------------------------------
a)  IKEv2-Data   -->

b)  IKEv2-Data   -->

c)               <--  IKEv2-Data

d)               <--  IKEv2-Data
			

Unacknowledged data transfer

6.3. Encryption and Integrity protection

This protection mode provides encryption and integrity protection of IKEv2 data packets similar to the IKEv2 Encrypted payload as defined in [RFC5996].

6.4. 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]. This is suitable for applications that just need data integrity and not confidentiality such as routing protocol exchanges.



6.5. In-band keys

IKEv2 data channel will use the same keys as IKEv2 control channel to provide encryption and integrity protection. With in-band keys, for additional security, the IKEv2 nodes MAY force a rekey immediately after the initial exchange to protect the credentials exchanged in the initial exchange, even if the keys were to be compromised after the initial exchange.

6.6. Out-of-band keys

IKEv2 data channel will use different keys from IKEv2 control channel to provide encryption and integrity protection. The negotiation of out-of-band keys is outside the scope of IKEv2 data channel. An example of out-of-band keys is the group keys negotiated using G-IKEv2 [G-IKEv2].

6.7. Fragmentation

IKEv2 data channel provides fragmentation of the cleartext data payload based on a pre-configured MTU value, in order to avoid fragmentation after encryption. The fragmentation is done on cleartext packet before encryption and integrity protection. The Fragment bit, Frag Num field, and Total Fragment fields in IKEv2 data packet specify if the packet contains a fragment, the fragment number and the total number of fragments respectively. The receiver SHOULD decrypt and reassemble the cleartext fragments after receiving and validating all the encrypted fragments.

7. IKEv2 data channel negotiation

IKEv2 nodes can negotiate to use IKEv2 data channel and its capabilities by exchanging IKEV2_DATA_CHANNEL_SUPPORTED Notify type in IKE_SA_INIT exchange.

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

                         <-- HDR, SAr1, KEr, Nr, [CERTREQ]
                                 N(IKEV2_DATA_CHANNEL_SUPPORTED)    
  
  HDR, SK {IDi, [CERT,]
       [CERTREQ,] [IDr,]
	   AUTH, [CP(CFG_REQUEST)]   -->
	   
							<-- HDR, SK {IDr, [CERT,] AUTH, 
												[CP(CFG_REPLY)]							 
			

IKEv2 data channel negotiation















8. IKEv2 data channel payload formats

8.1. IKEV2_DATA_CHANNEL_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                    !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
				

IKEV2_DATA_CHANNEL_SUPPORTED Notify payload












8.2. IKEv2 data 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Flags     |  Payload Type |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Frag Num   |  Total Frags  |           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                    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			

IKEv2 data payload

8.3. IKEv2 data ack payload

The IKEv2 Data Ack packet is integrity protected and is not encrypted as it does not carry any data. The Data Ack packet contains the SPI to identify the session and Sequence number to identify the packet being acknowledged.

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Flags     |    RESERVED   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             SPI                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Sequence Number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                    Integrity Checksum Data                    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			

IKEv2 data ack payload

9. 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 payload of the IKE_AUTH exchange. IKEv2 data payload inherits all security properties of ESP protocol defined in [RFC4303].

10. IANA Considerations

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

This document proposes to use one of the reserved ESP SPI values (1 through 255, preferably 1) as IKEV2-DATA-MARKER to identify IKEv2 data packets received over UDP port 4500.

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

12. Change Log

This section lists all the changes in this document.

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

13. References

13.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", Internet-Draft draft-ietf-ipsecme-ikev2-fragmentation-02, September 2013.
[5] Rowles, S. R., Yeung, A.Y., Tran, P. T. and Y. Nir, "Group Key Management using IKEv2", Internet-Draft draft-yeung-g-ikev2-06, April 2013.
[6] Kivinen, T., "Minimal IKEv2", Internet-Draft draft-ietf-lwig-ikev2-minimal-00.txt, April 2013.
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

13.2. Informative References

[1] 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.

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.

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