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
Inamdar & Singh Expires March 19, 2014 [Page 1]
Internet-Draft IKEv2 data channel September 2013
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5
5. Protocol Outline . . . . . . . . . . . . . . . . . . . . . . 6
6. IKEv2 data channel capabilities . . . . . . . . . . . . . . . 6
6.1. Acknowledged data transfer . . . . . . . . . . . . . . . 6
6.2. Unacknowledged data transfer . . . . . . . . . . . . . . 7
6.3. Encryption and Integrity protection . . . . . . . . . . . 7
6.4. Integrity only protection . . . . . . . . . . . . . . . . 7
6.5. In-band keys . . . . . . . . . . . . . . . . . . . . . . 8
6.6. Out-of-band keys . . . . . . . . . . . . . . . . . . . . 8
6.7. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 8
7. IKEv2 data channel negotiation . . . . . . . . . . . . . . . 8
8. IKEv2 data channel payload formats . . . . . . . . . . . . . 10
8.1. IKEV2_DATA_CHANNEL_SUPPORTED Notify payload . . . . . . . 10
8.2. IKEv2 data payload . . . . . . . . . . . . . . . . . . . 11
8.3. IKEv2 data ack payload . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 14
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
13.1. Normative References . . . . . . . . . . . . . . . . . . 14
13.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Design decisions . . . . . . . . . . . . . . . . . . 14
A.1. Use of the existing IKEv2 control channel . . . . . . . . 14
A.2. IKEv2 header modification . . . . . . . . . . . . . . . . 15
A.3. Use of separate UDP port for data channel . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
The Internet Key Exchange Protocol version 2 (IKEv2), specified in
RFC5996 [1], is a UDP based reliable protocol that provides encrypted
and integrity protected secure communication channel similar to ESP
defined in RFC4303 [2]. 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.
Inamdar & Singh Expires March 19, 2014 [Page 2]
Internet-Draft IKEv2 data channel September 2013
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 [3], 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.
Inamdar & Singh Expires March 19, 2014 [Page 3]
Internet-Draft IKEv2 data channel September 2013
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 [5].
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. 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 [6].
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.
Inamdar & Singh Expires March 19, 2014 [Page 4]
Internet-Draft IKEv2 data channel September 2013
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.
Inamdar & Singh Expires March 19, 2014 [Page 5]
Internet-Draft IKEv2 data channel September 2013
5. Protocol Outline
This document proposes following extensions to IKEv2 protocol for
data communication:
o IKEv2 Notify type 'IKEV2_DATA_CHANNEL_SUPPORTED' for IKEv2 data
channel negotiation.
o IKEv2 packet formats for IKEv2 Data and Data-Ack packets.
6. IKEv2 data channel capabilities
IKEv2 data channel will support the following data transfer modes:
o Acknowledged data transfer
o Unacknowledged data transfer
IKEv2 data channel will support the following data protection modes:
o Encryption and Integrity protection
o Integrity only protection
IKEv2 data channel will support in-band and out-of-band keys:
o IKEv2 data channel using the same keys as IKEv2 control channel
(in-band)
o IKEv2 data channel using the different keys from IKEv2 control
channel (out-of-band)
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.
Inamdar & Singh Expires March 19, 2014 [Page 6]
Internet-Draft IKEv2 data channel September 2013
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.
Inamdar & Singh Expires March 19, 2014 [Page 7]
Internet-Draft IKEv2 data channel September 2013
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 [5].
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.
o IKEv2 initiator can communicate its intent to use IKEv2 data
channel by including a notify payload of type
IKEV2_DATA_CHANNEL_SUPPORTED along with the proposed capabilities
in IKE_SA_INIT request.
o IKEv2 responder can indicate its willingness to use IKEv2 data
channel with the proposed capabilities by including a notify
payload of type IKEV2_DATA_CHANNEL_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
IKEV2_DATA_CHANNEL_SUPPORTED Notify type in IKE_SA_INIT response.
Inamdar & Singh Expires March 19, 2014 [Page 8]
Internet-Draft IKEv2 data channel September 2013
o The absence of Notify payload of type IKEV2_DATA_CHANNEL_SUPPORTED
in IKE_SA_INIT response indicates the incapability or
unwillingness of the IKEv2 responder to use IKEv2 data channel.
o If IKEv2 responder does not include the same capabilities as
proposed by IKEv2 initiator, IKEv2 initiator MUST treat this as
unsuccessful negotiation of IKEv2 data channel.
o On unsuccessful negotiation of IKEv2 data channel, IKEv2 initiator
and responder MUST NOT use IKEv2 data channel for data transfer.
However rest of the IKEv2 negotiation can proceed as normal.
o On successful negotiation of IKEv2 Data Channel, IKEv2 Initiator
and Responder MUST exclude any payloads related to Child SA
negotiation in IKE_AUTH exchange and can use IKEv2 data channel
for data transfer.
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
Inamdar & Singh Expires March 19, 2014 [Page 9]
Internet-Draft IKEv2 data channel September 2013
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
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].
o Notify Message Type (2 octets): MUST be xxxxx, the value assigned
for IKEV2_DATA_CHANNEL_SUPPORTED by IANA.
o Flags (8 bits): Specify the IKEv2 Data channel properties
* bit 0:
0 - Acknowledged transfer
1 - Unacknowledged transfer
* bit 1:
0 - Encryption and Integrity protection
1 - Integrity-only protection
* bit 2:
0 - Use same keys for IKEv2 Control and Data channel
protection (In-band keys)
1 - Use different keys for IKEv2 Control and Data channel
protection (Out-of-band keys)
* bit 3-7:
Reserved, sender MUST set these bits to zero and receiver
MUST ignore it
Inamdar & Singh Expires March 19, 2014 [Page 10]
Internet-Draft IKEv2 data channel September 2013
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
o Flags (1 octet):
* bit-0 (Ack bit): The Ack bit MUST be used only when
unacknowledged data transfer is negotiated.
0 - Payload is a data packet
1 - Payload is a data ack packet
* bit-1 (Fragment bit): Specifies if the payload is a fragment.
0 - Payload is not a fragment
1 - Payload is a fragment
* bit-2-7: Reserved, sender MUST set these bits to zero and
receiver MUST ignore it
o Payload Type (1 octets): Identifies the payload type in tunnelling
mode, allowing a session to carry multiple traffic types such as
IPv4, IPv6, non-IP and other traffic types.
Inamdar & Singh Expires March 19, 2014 [Page 11]
Internet-Draft IKEv2 data channel September 2013
0 - Not used
1 - IPv4
2 - IPv6
3-255 - Reserved
o Length (2 octets, unsigned integer): Length in octets of the
entire IKEv2 Data packet.
o Frag Num (1 octet): Specifies fragment number if Fragment bit is
set. If Fragment bit is not set, sender MUST set this field to
zeros and receiver MUST ignore it.
o Total Frags (1 octet): Specifies the total number of fragments
number, if Fragment bit is set. If Fragment bit is not set,
sender MUST set this field to zeros and receiver MUST ignore it.
o SPI (8 octets): A value used be 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 IKEv2 Data
packet sequence numbers. For acknowledged data transfer, this
field is used for re-transmission, windowing and anti-replay
checks. For unacknowledged data transfer, this field is used for
anti-replay checks.
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
Inamdar & Singh Expires March 19, 2014 [Page 12]
Internet-Draft IKEv2 data channel September 2013
o Flags (1 octet):
bit 0 (Ack bit): Set to 1 to indicate it is a Data Ack packet.
bits (1-7): Reserved, sender MUST set these bits to zero and
receiver MUST ignore them.
o Length (2 octets, unsigned integer): Length in octets of the
entire IKEv2 Data Ack packet.
o SPI (8 octets): A value used be receiver to lookup the session
associated with the packet in order to verify integrity of the
data ack packet.
o Sequence Number (4 octets): This field identifies the sequence
number of the IKEv2 Data packet being acknowledged.
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.
o IKEV2_DATA_CHANNEL_SUPPORTED
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.
Inamdar & Singh Expires March 19, 2014 [Page 13]
Internet-Draft IKEv2 data channel September 2013
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", 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.
13.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
Inamdar & Singh Expires March 19, 2014 [Page 14]
Internet-Draft IKEv2 data channel September 2013
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
Inamdar & Singh Expires March 19, 2014 [Page 15]
Internet-Draft IKEv2 data channel September 2013
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 March 19, 2014 [Page 16]