idnits 2.17.1 draft-amjads-ipsecme-ikev2-data-channel-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2014) is 3670 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'CERTREQ' on line 378 -- Looks like a reference, but probably isn't: 'RFC5996' on line 499 -- Looks like a reference, but probably isn't: 'RFC4303' on line 504 == Unused Reference: '4' is defined on line 555, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 558, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 562, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 570, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5996 (ref. '1') (Obsoleted by RFC 7296) ** Downref: Normative reference to an Experimental RFC: RFC 6023 (ref. '3') == Outdated reference: A later version (-10) exists of draft-ietf-ipsecme-ikev2-fragmentation-02 == Outdated reference: A later version (-16) exists of draft-yeung-g-ikev2-06 == Outdated reference: A later version (-05) exists of draft-ietf-lwig-ikev2-minimal-00 ** Downref: Normative reference to an Informational draft: draft-ietf-lwig-ikev2-minimal (ref. '6') Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Amjad. Inamdar 3 Internet-Draft R. Singh 4 Intended status: Standards Track Cisco 5 Expires: September 13, 2014 March 12, 2014 7 IKEv2 based lightweight secure data communication 8 draft-amjads-ipsecme-ikev2-data-channel-01 (D-IKE) 10 Abstract 12 The Internet Key Exchange (IKEv2) protocol provides authentication, 13 confidentiality, integrity, data-origin authentication and anti- 14 replay. Currently, IKEv2 is mainly used as a control channel to 15 negotiate IPsec SA(s). IPsec is not well suited to provide transport 16 layer security for applications as it resides at the network layer 17 and most of the IPsec implementations require integration into 18 operating systems making it difficult to deploy. IPsec uses 19 different sessions for control and data traffic which is not NAT and 20 load balancer friendly. TLS/DTLS, the other popular security 21 mechanism to provide the above security services does not mandate 22 mutual peer authentication and Diffie Hellman exchange. 24 This document describes an IKEv2 based lightweight secure data 25 communication protocol and a way to provide transport layer security 26 for UDP client/server applications. The protocol provides integrity 27 protected encryption and integrity-only protection based on 28 application needs. As most of the IoT applications are UDP based, 29 IKEv2 can be used for key management as well secure data 30 communication in IoT due to its simplicity, scalability, 31 lightweightedness and ease of deployment. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 13, 2014. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. D-IKE comparision with IPsec . . . . . . . . . . . . . . . . 3 70 4. D-IKE comparision with DTLS . . . . . . . . . . . . . . . . . 4 71 5. D-IKE Description . . . . . . . . . . . . . . . . . . . . . . 4 72 6. Securing UDP applications with D-IKE . . . . . . . . . . . . 4 73 7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 8. Protocol Outline . . . . . . . . . . . . . . . . . . . . . . 7 75 9. D-IKE capabilities . . . . . . . . . . . . . . . . . . . . . 7 76 9.1. Encryption and Integrity protection . . . . . . . . . . . 7 77 9.2. Integrity only protection . . . . . . . . . . . . . . . . 8 78 10. D-IKE negotiation . . . . . . . . . . . . . . . . . . . . . . 8 79 11. D-IKE packet and payload formats . . . . . . . . . . . . . . 9 80 11.1. D-IKE_SUPPORTED Notify payload . . . . . . . . . . . . . 9 81 11.2. D-IKE Control and Data packets . . . . . . . . . . . . . 10 82 11.3. D-IKE payload . . . . . . . . . . . . . . . . . . . . . 11 83 12. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 85 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 86 15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 15.1. Draft -01 . . . . . . . . . . . . . . . . . . . . . . . 12 88 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 89 16.1. Normative References . . . . . . . . . . . . . . . . . . 13 90 16.2. Informative References . . . . . . . . . . . . . . . . . 13 91 Appendix A. Design decisions . . . . . . . . . . . . . . . . . . 13 92 A.1. Use of the existing IKEv2 control channel . . . . . . . . 13 93 A.2. IKEv2 header modification . . . . . . . . . . . . . . . . 14 94 A.3. Use of separate UDP port for data channel . . . . . . . . 14 95 Appendix B. Possible extensions . . . . . . . . . . . . . . . . 14 96 B.1. Securing TCP client/server applications using D-IKE . . . 14 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 99 1. Introduction 101 The Internet Key Exchange Protocol version 2 (IKEv2), specified in 102 RFC5996 [1], is a UDP based protocol that provides a secure 103 communication channel similar to ESP defined in RFC4303 [2]. IKEv2 104 defines mechanisms for mutual authentication of peers, key 105 management, SA management and exchange of configuration information. 106 IKEv2 is mainly used as a secure control channel to negotiate child 107 IPsec SAs. As IKEv2 provides encryption, integrity protection, data 108 origin authenication and replay protection similar to ESP, IKEv2 can 109 be leveraged for secure data communication. This document defines an 110 IKEv2 based secure data communication mechanism (henceforth referred 111 to as D-IKE) and describes a way to secure UDP applications with 112 D-IKE. While the IKE control channel is always encryption and 113 integrity protected, the IKE data channel can provide encryption and 114 integrity protection as well as integrity-only protection depending 115 on the needs of the application. 117 2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [7]. 123 3. D-IKE comparision with IPsec 125 o D-IKE being UDP based is easier to deploy as it resides in the 126 operating system application space and does not require 127 integration with the operating system kernel unlike most of the 128 IPsec implementations 130 o D-IKE is lighter with fewer keys and protocol exchanges as it uses 131 the same channel for control messages and data 133 o D-IKE is simpler as it does not involve programming the Security 134 Policy Database (SPD) 136 o D-IKE being at transport layer is better suited to provide 137 granular and end-to-end security to applications than IPsec which 138 provides network layer security suitable for site to site 140 o D-IKE control and data channels run over a single UDP port and 141 hence D-IKE is load balancer friendly 143 4. D-IKE comparision with DTLS 145 o D-IKE provides better enforcement of security through mandatory 146 mutual peer authentication and Diffie Hellman key exchange 148 o D-IKE supports comprehensive authentication methods and has built- 149 in support for mobility, DOS attack mitigation and load balancing 151 5. D-IKE Description 153 Each UDP application using D-IKE for security will use different UDP 154 port numbers. So with D-IKE, IKEv2 packets are no longer identified 155 by UDP ports 500 and 4500. D-IKE will use a different UDP port 156 number for each UDP application to carry the D-IKE control messages 157 for IKEv2 negotiation as well as application data. The first octet 158 in the UDP payload will identify D-IKE control and data packets. 159 D-IKE control packets will carry the IKEv2 header and payloads as 160 defined in RFC5996 [1] and will be used to negotiate a childless 161 IKEv2 session between UDP client and server. D-IKE data packets will 162 carry encrypted and authenticated UDP application data. 164 The following diagram depicts the format of UDP encapsulated D-IKE 165 control and Data packets. 167 +------------+------+----------+---------------------------+ 168 | UDP Header | Type | RESERVED | D-IKE Control/Data Packet | 169 +------------+------+----------+---------------------------+ 170 |<---------------- UDP Payload -------------->| 172 Encapsulation of D-IKE packets 174 D-IKE can provide integrity-only protection in addition to integrity 175 protected encryption. D-IKE does not negotiate child IPsec SAs in 176 the IKEv2 initial exchange and subsequently as depicted in D-IKE 177 Negotiation section, similar to Childless IKEv2 defined in RFC6023 178 [3]. 180 Please refer the appendix section of this document for details on the 181 alternative mechanisms that were considered for data communication 182 over IKEv2 and their drawbacks. 184 6. Securing UDP applications with D-IKE 186 This document introduces the concept of D-IKE sockets to secure 187 communication between UDP client/server applications. D-IKE socket 188 is an IKEv2 session between a UDP client and server uniquely 189 identified by the 4 tuple of client and server IP addresses and UDP 190 ports. 192 +--------------+ +--------------+ 193 | UDP Client | | UDP Service | 194 +--------------+ +--------------+ 195 | D-IKE socket | | D-IKE socket | 196 +--------------+ +--------------+ 197 | UDP | | UDP | 198 +--------------+ +--------------+ 199 | IP |<------------>| IP | 200 +--------------+ +--------------+ 202 D-IKE Sockets 204 o A UDP service will register with D-IKE socket specifying the UDP 205 port it wants to listen to. D-IKE will listen on the UDP port 206 number on behalf of the application 208 o A UDP client will open a D-IKE socket specifying the server IP 209 address and the UDP port number. D-IKE will open a UDP socket to 210 the server on behalf of the client 212 o D-IKE will initiate an IKEv2 session without any child SA from UDP 213 client to the server 215 o After successful negotiation of IKEv2 session, the client and 216 server can securely exchange data over D-IKE socket 218 UDP Client UDP Server 219 ---------- ---------- 220 | | 221 |<-------- IKE negotiation --------->| 222 | | 223 |<----- Secure Data Transfer ------->| 224 | | 226 Secure UDP communication over D-IKE 228 For a node running multiple UDP applications(Clients and/or 229 Services), each UDP application will have a unique D-IKE socket 230 +----------------+----------------+----------------+ 231 | UDP App 1 | UDP App 2 | UDP App N | 232 +----------------+----------------+----------------+ 233 | D-IKE socket 1 | D-IKE socket 2 | D-IKE socket N | 234 +----------------+----------------+----------------+ 235 | UDP | 236 +--------------------------------------------------+ 237 | IP | 238 +--------------------------------------------------+ 240 D-IKE socket per UDP Application 242 A well known UDP service can simultaneously open a UDP socket as well 243 as D-IKE socket. 245 +--------------+ +---------------------------+ +------------+ 246 | UDP Client | | UDP Service | | UDP Client | 247 +--------------+ +---------------------------+ +------------+ 248 | D-IKE socket | | D-IKE socket | UDP Socket |<-->| UDP Socket | 249 +--------------+ +--------------+------------+ +------------+ 250 | UDP |<-->| UDP | |<-- Unsecured -->| 251 +--------------+ +--------------+ Communication 252 |<----- Secure ----->| 253 Communication 255 Securing UDP Applications using D-IKE 257 The following diagram shows the format of D-IKE packet. 259 |<------------- D-IKE packet -------------->| 260 +----+------+--------+-------------+---------+----------+ 261 | IP | UDP | D-IKE | UDP App | D-IKE | D-IKE | 262 | | | Header | Data | Trailer | Checksum | 263 +----+------+--------+-------------+-- ------+----------+ 264 | |<----- Encrypted ----->| 265 |<----- Integrity Protected ---->| 267 D-IKE packet format 269 D-IKE packet consists of D-IKE header, UDP application data, an 270 optional D-IKE trailer and D-IKE integrity checksum value. 272 7. Benefits 274 o Lightweight, scalable and simpler with fewer keys and protocol 275 exchanges 277 o Support for integrity-only protection, in addition to integrity 278 protected encryption 280 o Works seamlessly with load balancers and PAT devices as D-IKE uses 281 the same UDP port as the IKEv2 control channel 283 8. Protocol Outline 285 This document proposes following extensions to IKEv2 protocol for 286 data communication: 288 o IKEv2 Notify type 'D-IKE_SUPPORTED' to negotiate the use of IKEv2 289 for data communication 290 o D-IKE packet formats 292 9. D-IKE capabilities 294 D-IKE will support the following data protection modes: 296 o Encryption and Integrity protection 297 o Integrity only protection 299 9.1. Encryption and Integrity protection 301 This protection mode provides encryption and integrity protection of 302 D-IKE packets similar to the IKEv2 Encrypted payload as defined in 303 RFC5996 [1] 305 The UDP app data and D-IKE trailer are encrypted and the D-IKE 306 header, UDP app data and D-IKE trailer are integrity protected. 308 +----+------+--------+-------------+---------+----------+ 309 | IP | UDP | D-IKE | UDP App | D-IKE | D-IKE | 310 | | | Header | Data | Trailer | Checksum | 311 +----+------+--------+-------------+-- ------+----------+ 312 | |<----- Encrypted ----->| 313 |<----- Integrity Protected ---->| 315 Encryption and Integrity protection 317 9.2. Integrity only protection 319 This protection mode provides integrity protection of IKEv2 data 320 packets and no encryption similar to ESP null encryption as described 321 in RFC4303 [2]. This is suitable for applications that just need 322 data integrity and not confidentiality such as routing protocol 323 exchanges. It may be noted that integrity only protection applies 324 only to D-IKE packets and that D-IKE control packets will always use 325 integrity protected encryption. 327 The UDP app data and D-IKE trailer are encrypted and the D-IKE 328 header, UDP app data and D-IKE trailer are integrity protected. 330 +----+------+--------+-------------+----------+ 331 | IP | UDP | D-IKE | UDP App | D-IKE | 332 | | | Header | Data | Checksum | 333 +----+------+--------+-------------+----------+ 334 |<---- Integrity ----->| 335 Protected 337 Integrity only protection 339 10. D-IKE negotiation 341 IKEv2 nodes can negotiate to use D-IKE and its capabilities by 342 exchanging D-IKE_SUPPORTED Notify type in IKE_SA_INIT exchange. 344 o IKEv2 initiator can communicate its intent to use D-IKE by 345 including a notify payload of type D-IKE_SUPPORTED along with the 346 proposed capabilities in IKE_SA_INIT request 348 o IKEv2 responder can indicate its willingness to use D-IKE with the 349 proposed capabilities by including a notify payload of type 350 D-IKE_SUPPORTED along with the same capabilities in IKE_SA_INIT 351 response 353 o If the capabilities proposed by IKEv2 Initiator are not acceptable 354 to IKEv2 responder, it MUST NOT include D-IKE_SUPPORTED Notify 355 type in IKE_SA_INIT response 357 o The absence of Notify payload of type D-IKE_SUPPORTED in 358 IKE_SA_INIT response indicates the incapability or unwillingness 359 of the IKEv2 responder to use D-IKE 361 o If IKEv2 responder does not include the same capabilities as 362 proposed by IKEv2 initiator, IKEv2 initiator MUST treat this as 363 unsuccessful negotiation of D-IKE 365 o On unsuccessful negotiation of D-IKE, IKEv2 initiator and 366 responder MUST NOT use D-IKE for data transfer. However rest of 367 the IKEv2 negotiation can proceed as normal 369 o On successful negotiation of D-IKE, IKEv2 Initiator and Responder 370 MUST exclude any payloads related to Child SA negotiation in 371 IKE_AUTH exchange and can use D-IKE for data transfer 373 Initiator Responder 374 ------------------------------------------------------ 375 HDR, SAi1, KEi, Ni 376 [N(D-IKE_SUPPORTED)] --> 378 <-- HDR, SAr1, KEr, Nr, [CERTREQ] 379 N(D-IKE_SUPPORTED) 381 HDR, SK {IDi, [CERT,] 382 [CERTREQ,] [IDr,] 383 AUTH, [CP(CFG_REQUEST)] --> 385 <-- HDR, SK {IDr, [CERT,] AUTH, 386 [CP(CFG_REPLY)] 388 IKEv2 data channel negotiation 390 11. D-IKE packet and payload formats 392 11.1. D-IKE_SUPPORTED Notify payload 394 1 2 3 395 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 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 ! Next Payload !C! RESERVED ! Payload Length ! 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 ! Protocol ID ! SPI Size ! Notify Message Type ! 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 ! Flags ! RESERVED ! 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 D-IKE_SUPPORTED Notify payload 406 o Protocol ID (1 octet): MUST be 1, as this message is related to an 407 IKEv2 SA 409 o SPI Size (1 octet): MUST be zero, in conformance with section 3.10 410 of [RFC5996] 412 o Notify Message Type (2 octets): MUST be xxxxx, the value assigned 413 for D-IKE_SUPPORTED by IANA 415 o Flags (8 bits): Specify the IKEv2 Data channel properties 417 * bit 0: 419 0 - Encryption and Integrity protection 420 1 - Integrity-only protection 422 * bit 1-7: 424 Reserved, sender MUST set these bits to zero and receiver 425 MUST ignore it 427 11.2. D-IKE Control and Data packets 429 The first octet in the UDP payload will identify D-IKE control and 430 data packets. D-IKE control packets will carry the IKEv2 header and 431 payloads as defined in RFC 5996 and will be used to negotiate a 432 childless IKEv2 session between UDP client and server. D-IKE data 433 packets will carry encrypted and authenticated UDP application data. 435 1 2 3 436 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 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Type | RESERVED | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | | 441 ~ IKEv2 Header and payloads ~ 442 | or | 443 | D-IKE data payload | 444 | | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 D-IKE Control and Data packets 449 o Type (1 octet, unsigned integer): Identifies D-IKE control and 450 data packet 452 * 0 - D-IKE control packet 453 * 1 - D-IKE data packet 454 * 2 - 7 - RESERVED 456 11.3. D-IKE payload 458 1 2 3 459 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 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Length | RESERVED | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | SPI | 464 | | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Sequence Number | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Initialization Vector | 469 | (length is block size for encryption algorithm) | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 ~ Encrypted/Cleartext Data ~ 472 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | | Padding (0-255 octets) | 474 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 475 | | Pad Length | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 ~ Integrity Checksum Data ~ 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 D-IKE payload 482 o Length (2 octets, unsigned integer): Length in octets of the 483 entire IKEv2 Data packet 485 o Reserved (2 octets): Sender MUST set these bits to zero and 486 receiver MUST ignore these bits 488 o SPI (8 octets): A value used by receiver to lookup the session 489 associated with the packet in order to verify integrity and 490 decrypt the data packet. This value is usually the data packet 491 receiver's IKE SPI 493 o Sequence Number (4 octets): This field identifies the D-IKE packet 494 sequence numbers, used for anti-replay checks 496 12. Security Considerations 498 This protocol variation inherits all the security properties of 499 regular IKEv2 as described in [RFC5996]. The new notification 500 carried in the initial exchange advertises the capability, and cannot 501 be forged or added by an adversary without being detected, because 502 the response to the initial exchange is authenticated with the AUTH 503 payload of the IKE_AUTH exchange. IKEv2 data payload inherits all 504 security properties of ESP protocol defined in [RFC4303]. 506 13. IANA Considerations 508 This document introduces one new IKEv2 Notification Message types as 509 described in Section 11.1. The new Notify Message Types must be 510 assigned values between 16429 and 40959. 512 o D-IKE_SUPPORTED 514 For UDP applications that need a well known port number to secure the 515 application using D-IKE (for example, CoAP over D-IKE), the port 516 number MUST be reserved from IANA. 518 14. Acknowledgements 520 We would like to thank following people (in alphabetical order) for 521 their review comments and valuable suggestions for idea and initial 522 version of the document: Amit Phadnis, Arif Shouqi, Balaji B L, Brian 523 Weis, Cheryl Madson, Frederic Detienne, J P Vasseur, Kalyani 524 Garigipati, Mike Sullenberger, Naresh Sunkara, Nick Doyle, Paul 525 Hoffman, Rajiv Shankar Daulath, Ramesh Nethi, Sandeep Rao, Scott 526 Fluhrer, and Thamil Kandasamy. 528 15. Change Log 530 This section lists all the changes in this document. 532 NOTE TO RFC EDITOR: Please remove this section in before final RFC 533 publication. 535 15.1. Draft -01 537 Reworked the draft with more focus on UDP application security. 538 Updated the problem statement. Added comparision with IPsec and TLS/ 539 DTLS. Updated D-IKE Notify and Data payloads. Added possible 540 extensions. 542 16. References 543 16.1. Normative References 545 [1] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 546 "Internet Key Exchange Protocol Version 2: IKEv2", RFC 547 5996, September 2010. 549 [2] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 550 4303, December 2005. 552 [3] Nir, Y., Tschofenig, H., Deng, H., and R. Singh, "A 553 Childless Initiation of IKEv2 SA", RFC 6023, October 2010. 555 [4] Smyslov, V., "IKEv2 Fragmentation", draft-ietf-ipsecme- 556 ikev2-fragmentation-02 (work in progress), September 2013. 558 [5] Rowles, S., Yeung, A., Tran, P., and Y. Nir, "Group Key 559 Management using IKEv2", draft-yeung-g-ikev2-06 (work in 560 progress), April 2013. 562 [6] Kivinen, T., "Minimal IKEv2", draft-ietf-lwig- 563 ikev2-minimal-00.txt (work in progress), April 2013. 565 [7] Bradner, S., "Key words for use in RFCs to Indicate 566 Requirement Levels", BCP 14, RFC 2119, March 1997. 568 16.2. Informative References 570 [8] Devarapalli, V. and K. Weniger, "Redirect Mechanism for 571 IKEv2", RFC 5685, November 2009. 573 Appendix A. Design decisions 575 This section describes the alternative mechanisms for data 576 communication over IKEv2 that were considered and their drawbacks. 578 A.1. Use of the existing IKEv2 control channel 580 The existing IKEv2 control channel can be used for data transfer 581 using a new IKEv2 exchange type DATA exchange similar to 582 INFORMATIONAL exchange, and a new payload type to encapsulate 583 cleartext data that will be protected by Encrypted payload. 585 A drawback with this approach is that the data packets will incur the 586 overhead of IKEv2 header (28 octets) and a minimum of two generic 587 payload headers (4 octets each) with a total protocol overhead of 36 588 octets per data packet. Also, it is difficult to support 589 unacknowledged data transfer and integrity-only protection for data 590 packets. 592 A.2. IKEv2 header modification 594 IKEv2 header can be modified to allow differentiation between control 595 and data packets using the first four bytes of the header and the 596 rest of the header can be different for control and data packets. A 597 possible way to accomplish this is to move the Exchange type field to 598 the beginning of IKEv2 header. 600 The obvious drawback with this approach is that it is not backward 601 compatible with existing IKEv2 protocol. Also, it makes it difficult 602 to support unacknowledged data transfer and integrity-only protection 603 for data packets. 605 A.3. Use of separate UDP port for data channel 607 A separate UDP port e.g 501 can be used for IKEv2 data channel that 608 allows to leverage the IKEv2 protocol's security and reliability 609 mechanisms and security parameters for data communication while 610 avoiding the overhead of IKEv2 header and generic payload headers for 611 data packets. Use of a fixed UDP port for data channel instead of 612 dynamically negotiated UDP ports has the advantage of not requiring 613 the firewalls to snoop the IKEv2 control channel to be able to 614 determine and allow the traffic on data channel UDP port. 616 A drawback with this approach is that the use of different ports for 617 IKEv2 control and data channels makes it difficult for load balancers 618 to associate an IKEv2 control channel with its data channel when 619 there are multiple IKEv2 initiators behind a PAT device. Also when 620 IKEv2 initiator is behind a PAT device, the data packets from 621 responder will be dropped by the PAT device as port 501 will not be 622 open unless there is data traffic from initiator. 624 Appendix B. Possible extensions 626 This section describes the possible extensions to D-IKE protocol. 628 B.1. Securing TCP client/server applications using D-IKE 630 D-IKE can be used to secure TCP applications using one of the 631 following methods. 633 o While IKE control channel can run over UDP, the IKE data channel 634 can negotiate and run over a TCP session carring D-IKE protected 635 application data. A drawback with this approach is that using 636 differnet sessions for control and data may not be friendly with 637 load balancers 639 o If IKEv2 were to run over TCP, IKEv2 over TCP can be used to 640 secure TCP applications 642 o D-IKE tunnel mode can be defined that can encapsulate TCP or any 643 other protocol over D-IKE tunnel 645 Authors' Addresses 647 Amjad S. Inamdar 648 Cisco Systems India Pvt. Ltd. 649 SEZ Unit, Cessna Business Park 650 Sarjapur Marathahalli Outer Ring Road 651 Bangalore, Karnataka 560087 652 India 654 Phone: +91 80 4426 4834 655 Email: amjads@cisco.com 657 Rajeshwar Singh Janwar 658 Cisco Systems India Pvt. Ltd. 659 SEZ Unit, Cessna Business Park 660 Sarjapur Marathahalli Outer Ring Road 661 Bangalore, Karnataka 560087 662 India 664 Phone: +91 80 4426 2731 665 Email: rsj@cisco.com