idnits 2.17.1 draft-smyslov-ipsecme-ikev2-compression-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 5, 2016) is 2783 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IKEV2-IANA' == Outdated reference: A later version (-02) exists of draft-mglt-6lo-diet-esp-requirements-01 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Smyslov 3 Internet-Draft ELVIS-PLUS 4 Intended status: Standards Track September 5, 2016 5 Expires: March 9, 2017 7 Compression in the Internet Key Exchange Protocol Version 2 (IKEv2) 8 draft-smyslov-ipsecme-ikev2-compression-02 10 Abstract 12 This document describes a method for reducing the size of the IKEv2 13 messages by using lossless compression. Making IKEv2 messages 14 smaller is desirable for low power consumption battery powered 15 devices. It also helps to avoid IP fragmentation of IKEv2 messages. 16 This document describes how compression is negotiated maintaining 17 backward compatibility and how it is used in IKEv2. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 9, 2017. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 55 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 6 56 3.1. Using Compression in the IKE_SA_INIT Exchange . . . . . . 6 57 3.2. Using Compression in Subsequent Exchanges . . . . . . . . 8 58 4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 10 59 4.1. Compressed Payload . . . . . . . . . . . . . . . . . . . . 10 60 4.2. INVALID_COMPRESSION_ALGORITHM Notification . . . . . . . . 11 61 5. Interaction with other IKEv2 Extensions . . . . . . . . . . . 12 62 5.1. Interaction with IKEv2 Fragmentation . . . . . . . . . . . 12 63 5.2. Interaction with IKEv2 Resumption . . . . . . . . . . . . 12 64 5.3. Interaction with IKEv2 Redirect . . . . . . . . . . . . . 12 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 72 1. Introduction 74 The Internet Key Exchange protocol version 2 (IKEv2) defined in 75 [RFC7296] is used in the IP Security (IPsec) architecture for the 76 purposes of Security Association (SA) parameters negotiation and 77 authenticated key exchange. The protocol uses UDP as the transport 78 for its messages. The size of the IKEv2 messages varies from 79 hundreds bytes to several kBytes. 81 Sending large UDP messages may cause IP fragmentation to take place, 82 which may interact badly with some Network Address Translators (NAT). 83 One of the possible solutions to the problem is IKEv2 fragmentation 84 described in [RFC7383]. However, the IKEv2 fragmentation cannot be 85 used for unencrypted messages and thus cannot be used in the initial 86 IKEv2 exchange called IKE_SA_INIT exchange. Usually the messages of 87 the IKE_SA_INIT exchange are relatively small and this restriction 88 doesn't cause problems. However with adoption more and more new 89 algorithms and new IKEv2 extensions there is a tendency for these 90 messages to become larger and larger for the implementations that 91 support new features. 93 The lossless compression can be used to reduce the size of IKEv2 94 messages. Each IKEv2 message contains different types of data 95 structured in payloads. Depending on the type of payload the 96 compressibility of the data it contains varies greatly. Some types 97 of payloads, like the Nonce payload, contain data that are almost 98 uncompressible. On the other hand, such payloads like the Security 99 Association payload or Notification payload usually have a lot of 100 redundancy in their encoding and hence are highly compressible. 101 Since many emerging IKEv2 extensions add new type of notification or 102 new parameter to the Security Association payload contained in the 103 IKE_SA_INIT messages, the ability to compress these messages would 104 help keep their size bounded. 106 Compression can also be applied to the messages followed the 107 IKE_SA_INIT exchange. In this case the reduced size of the messages 108 would make the necessity to use the IKEv2 fragmentation less likely 109 or would decrease the number of fragments the messages are divided 110 into, which would increase the protocol reliability and productivity. 112 The other field where using compression may be useful is the Internet 113 of Things (IoT) devices utilizing a lower power consumption 114 technology. For many such devices the power consumption for 115 transmitting extra bits over network is much higher than the power 116 consumption for spending extra CPU cycles to compress data before 117 transmission. The appendix A of [IPSEC-IOT-REQS] gives some estimate 118 data. Since many such devices are battery powered without an ability 119 to recharge or to replace the battery which serves for the lifecycle 120 of the device (a few years), the task of reducing the power 121 consuption for such devices is very important. 123 This document specifies how lossless compression is used in IKEv2. 124 In order to enable compression in the IKE_SA_INIT exchange a new 125 payload is introduced that contains other payloads in compressed 126 form. The processing of the Encrypted payload is modified to 127 accommodate compression in subsequent exchanges. The document also 128 specifies how the use of compression is negotiated between the peers 129 maintaining backward compatibility. 131 2. Requirements Language 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 3. Protocol Description 139 Compression is accomodated differently in the initial IKEv2 exchange 140 and in subsequent exchanges. The difference comes out from the fact, 141 that the messages of all the IKEv2 exchanges except the initial 142 exchange contain the Encrypted payload. In this case the compression 143 is added as an additional step while constructing the Encrypted 144 payload. The initial IKEv2 exchange requires introduction a new 145 payload, that would contain other payloads in compressed form. 147 3.1. Using Compression in the IKE_SA_INIT Exchange 149 The use of compression is not negotiated in a usual for IKEv2 manner 150 - by exchanging appropriate Notification or Vendor ID payloads. 151 Instead a different negotiation mechanism is used. 153 If an Initiator wants to use compression for the IKE SA being 154 created, it constructs the IKE_SA_INIT request message in a following 155 way. A new payload which is called Compressed payload and described 156 in the Section 4.1 is included into the request message. This 157 payload contains other payloads in compressed form as well as an 158 indication of what compression algorithm is used. When selecting 159 compression algorithm the Initiator must guess what algorithms are 160 supported by the peer and choose an appropriate one. If the guess is 161 wrong the Responder will inform about this fact and the mutually 162 appropriate algorithm will be negotiated by the cost of an extra 163 round trip and a message recompression. The Critical bit in the 164 Compressed payload header MUST be set to 1. 166 Initiator 167 --------- 168 HDR, C!{SA, KE, [N+], [V+]}, Ni, [N+], [V+] --> 170 Not all payloads that are usually present in the IKE_SA_INIT messages 171 are subject for compression. Some payloads contain random or pseudo- 172 random data that is almost uncompressible. Other payloads must be 173 processed as early as possible, before the responder spends resources 174 decompressing them. In particular, the Nonce payloda and the COOKIE 175 notification payload MUST NOT be included into the Compressed 176 payload. Obviously, if the compression algorithm ID is from private 177 range (241-255), then the corresponding Vendor ID payload MUST NOT be 178 included into the Compressed payload either. See Section 5 for more 179 details about interaction compression with other IKEv2 extensions. 181 If the Responder doesn't support IKEv2 compression, then it is 182 expected to return the UNSUPPORTED_CRITICAL_PAYLOAD notification in 183 response to such request message, as prescribed in the Section 2.5 of 185 [RFC7296]. Depending on the implementation it may also return the 186 INVALID_SYNTAX notification or doesn't respond at all. 188 Legacy Responder 189 ---------------- 190 <-- HDR, N(UNSUPPORTED_CRITICAL_PAYLOAD) 192 or 194 <-- HDR, N(INVALID_SYNTAX) 196 or 198 (No response) 200 If the Initiator receives the UNSUPPORTED_CRITICAL_PAYLOAD 201 notification with the Compressed payload type in its notification 202 data or if it receives the INVALID_SYNTAX notification or if it 203 receives no response after several retransmissions then the Initiator 204 MUST restart the IKE_SA_INIT exchange with no compression. 206 If the Responder supports IKEv2 compression, but doesn't support the 207 particular compression algorithm the Initiator has chosen, then the 208 Responder sends back a new error notification: 209 INVALID_COMPRESSION_ALGORITHM. This notification is described in the 210 Section 4.2. Its notification data contains the list of IDs of 211 compression algorithms supported by the Responder. 213 Responder 214 --------- 215 <-- HDR, N(INVALID_COMPRESSION_ALGORITHM) 217 If the Initiator receives the INVALID_COMPRESSION_ALGORITHM 218 notification, then it looks through the list of algorithms included 219 into the notification data and selects the appropriate one. After 220 that it MUST restart the IKE_SA_INIT exchange using the newly 221 selected algorithm for compression. If no mutually appropriate 222 algorithm found, then the Initiator MUST restart the IKE_SA_INIT 223 exchange with no compression. 225 Once the Responder receives the IKE_SA_INIT request with the 226 appropriate compression algorithm in the Compressed payload, the 227 included payloads are decompressed and along with the outer payloads 228 form the uncompressed request message, which is then processed as 229 usual. If the Responder agrees to use compression in the SA being 230 created then the Responder MUST include the Compressed payload in the 231 response message. The compression algorithm indicated in the 232 Compressed payload MUST be the algorithm from the request. 234 Responder 235 --------- 236 <-- HDR, C!{SA, KE, [N+], [V+]}, Nr, [N+], [V+] 238 If for some reason the Responder doesn't want to use compression in 239 the SA being created (e.g. using compression is disabled by 240 administrator) then it MUST send back an uncompressed IKE_SA_INIT 241 response message. In this case the endpoints MUST NOT use 242 compression in subsequent exchanges. 244 3.2. Using Compression in Subsequent Exchanges 246 Once the endpoints have used compression in the IKE_SA_INIT exchange, 247 they may continue to use it in subsequent exchanges. However 248 compression is used differently in these exchanges. Messages of 249 every IKEv2 exchange except for the initial exchange are protected by 250 an Encrypted payload. With compression the rules for forming and 251 processing of an Encrypted payload are modified as follows. 253 The content of an Encrypted payload is compressed before it is 254 encrypted and authenticated. According to the IKEv2 specification 255 the Next Payload field in an Encrypted payload indicates the payload 256 type of the first payload inside the Encrypted payload. If case of 257 using compression, the Next Payload field in the Encrypted payload 258 MUST be set to XXX (TBA by IANA) - the value for the payload type of 259 a Compressed payload. However, the Compressed payload itself MUST 260 NOT appear inside the Encrypted payload, only its payload type is 261 used to indicate that the content of the Encrypted payload was 262 compressed before encryption. 264 Since in this case the Next Payload field in an Encrypted payload no 265 longer indicates a type of the first inner payload, this information 266 is moved to the Next Payload field of the last inner payload (which 267 is set zero in the IKEv2 specification). This modification is done 268 before the payloads are compresed. 270 Uncompressed: SK(Next=P1) {P1(Next=P2), P2(Next=P3), ... Pn(Next=0)} 271 Compressed: SK(Next=C) {P1(Next=P2), P2(Next=P3), ... Pn(Next=P1)} 273 Preparing payloads for compression 275 This modification doesn't cause ambiguity on the receiver, since the 276 total size of the inner payloads can be easily determined after 277 decryption, and while walking through the list of them the receiver 278 always knows whether the current payload is the last or not. 280 After the use of compression is negotiated in the initial exchange 281 each endpoint is free to decide whether to apply compression or not 282 on per-message basis. However, if applying compression to the 283 content of an Encrypted payload doesn't reduce its size then the 284 compression MUST NOT be used for this message. Implementations MUST 285 be prepared to receive both compressed and uncompressed messages. 287 4. Payload Formats 289 4.1. Compressed Payload 291 The Compressed payload, denoted C!{...} in this document (the 292 exclamation mark means that this payload is critical), contains other 293 payloads in compressed form. The payload type for the Compressed 294 payload is XXX (TBA by IANA). 296 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Next Payload |C| RESERVED | Payload Length | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | First Payload | Algorithm | | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 303 ~ Compressed Payloads ~ 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 Compressed Payload 308 o Next Payload (1 octet) - Identifier for the payload type of the 309 next payload in the message. 311 o Critical (1 bit) - MUST be set to 1. 313 o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on 314 receipt (as specified in [RFC7296]). 316 o Payload Length (2 octets, unsigned integer) - Length in octets of 317 the current payload, including the generic payload header. 319 o First Payload (1 octet) - Identifier for the payload type of the 320 first payload contained in Compressed Payloads field. 322 o Algorithm (1 octet) - ID of the algorithm used to compress inner 323 payloads. The possible values for compression algorithm ID are 324 listed in "IKEv2 Notification IPCOMP Transform IDs" registry in 325 [IKEV2-IANA]. 327 o Compressed Payloads (variable length) - This field contains IKEv2 328 payloads in compressed form. The Next Payload field of the last 329 included payload MUST be set to 0. 331 There MUST NOT be more than one Compressed payloads in a message. 332 The Compressed payload MUST NOT appear inside the Encrypted payload 333 and the Encrypted payload payload MUST NOT appear inside the 334 Compressed payload. 336 4.2. INVALID_COMPRESSION_ALGORITHM Notification 338 The INVALID_COMPRESSION_ALGORITHM notification is sent by Responder 339 if the compression algorithm chosen by Initiator is unappropriate. 340 The Notification Data contains the list of supported compression 341 algorithm IDs. 343 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Next Payload |C| RESERVED | Payload Length | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 ~ Supported Compression Algorithms ~ 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 INVALID_COMPRESSION_ALGORITHM Notification 355 o Protocol ID (1 octet) - MUST be 0. 357 o SPI Size (1 octet) - MUST be 0, meaning no SPI is present. 359 o Notify Message Type (2 octets) - MUST be XXX (TBA by IANA), the 360 value assigned for the INVALID_COMPRESSION_ALGORITHM notification. 362 o Supported Compression Algorithms (variable length) - List of 363 compression algorithm IDs supported by the Responder. Each 364 algorithm ID occupies one octet. The possible values for 365 compression algorithm IDs are listed in "IKEv2 Notification IPCOMP 366 Transform IDs" registry in [IKEV2-IANA]. 368 5. Interaction with other IKEv2 Extensions 370 IKEv2 Compression is compatible with most of the IKEv2 extensions, 371 since It neither affect their operation, nor is affected by them. 372 However, some IKEv2 extensions require special handling. 374 5.1. Interaction with IKEv2 Fragmentation 376 When compression is used with IKEv2 Fragmentation [RFC7383] the 377 compression MUST take place before splitting the original content of 378 the Encrypted payload into chunks. In other words, the content of 379 the Encrypted payload must be compressed as a whole, before it is 380 fragmented. 382 The Compressed payload MUST NOT appear inside the Encrypted Fragment 383 payload and the Encrypted Fragment payload payload MUST NOT appear 384 inside the Compressed payload. 386 5.2. Interaction with IKEv2 Resumption 388 The IKEv2 Session Resumption [RFC5723] defines a mechanism for 389 restoring an IKE SA state after a failure. The newly defined 390 IKE_SESSION_RESUME exchange in conjunction with the usual IKE_AUTH 391 exchange is used to create a new IKE SA that is based on the 392 information contained in the resumption ticket. 394 Implementations supporting compression MUST store the flag whether 395 the compression was negotiated and the negotiated compression 396 algorithm in the resumption ticket and MUST restore these values from 397 the ticket while resuming IKE SA. It means that the use of 398 compression must not be re-negotiated in the IKE_SESSION_RESUME 399 exchange and thus the Compressed payload MUST NOT appear in this 400 exchange. 402 5.3. Interaction with IKEv2 Redirect 404 The IKEv2 Redirect mechanism defined in [RFC5685] allows the 405 responder to redirect the initiator to a different host. The 406 redirect can take place either in the IKE_SA_INIT exchange or later, 407 when IKE SA is already created. 409 All the notifications concerning IKEv2 Redirect that may appear in 410 the IKE_SA_INIT exchange, MUST be placed outside the Compressed 411 payload. This would allow the responder to make a decision whether 412 to redirect the initiator without spending additional recources on 413 decompression. 415 6. Security Considerations 417 It was shown in [COMP-LEAK] that using compression inside an 418 encrypted channel may result in a leakage of some information about a 419 plaintext. Recently some practical exploits were discovered that 420 rely on using compression in security protocols ([CRIME], [BREACH]). 421 However, it is believed that the way a compression is added to the 422 IKEv2 would not weaken the protocol security. The existing exploits 423 rely on an ability for an attacker to insert data into an encrypted 424 stream, i.e. to perform a chosen-plaintext attack. IKEv2 messages 425 don't contain application data, which restricts attacker's ability to 426 perform chosen-plaintext attack. Moreover, the data usually 427 exchanged over the IKE SA contain no secret information and in most 428 cases no sensitive information. The possible exceptions could be 429 some weak Extensible Authentication Protocol (EAP) methods, which 430 might transfer secret information within an IKE SA. It is 431 RECOMMENDED that implementations don't use the IKEv2 Compression for 432 the messages containing the EAP payload if there is a possibility 433 that the EAP method transfers secret information. 435 7. IANA Considerations 437 This document defines new Payload in the "IKEv2 Payload Types" 438 registry: 440 Compressed C 442 This document also defines new Notify Message Types in the "Notify 443 Message Types - Error Types" registry: 445 INVALID_COMPRESSION_ALGORITHM 447 8. References 449 8.1. Normative References 451 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 452 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 453 RFC2119, March 1997, 454 . 456 [RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for 457 the Internet Key Exchange Protocol Version 2 (IKEv2)", 458 RFC 5685, DOI 10.17487/RFC5685, November 2009, 459 . 461 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 462 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 463 DOI 10.17487/RFC5723, January 2010, 464 . 466 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 467 Kivinen, "Internet Key Exchange Protocol Version 2 468 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, 469 October 2014, . 471 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 472 (IKEv2) Message Fragmentation", RFC 7383, DOI 10.17487/ 473 RFC7383, November 2014, 474 . 476 [IKEV2-IANA] 477 "Internet Key Exchange Version 2 (IKEv2) Parameters", 478 . 480 8.2. Informative References 482 [IPSEC-IOT-REQS] 483 Migault, D. and T. Guggemos, "Requirements for Diet-ESP 484 the IPsec/ESP protocol for IoT", 485 draft-mglt-6lo-diet-esp-requirements-01 (work in 486 progress), February 2015. 488 [COMP-LEAK] 489 Kelsey, J., "Compression and Information Leakage of 490 Plaintext", . 493 [CRIME] Rizzo, J. and T. Duong, "The CRIME attack", . 497 [BREACH] Prado, A., Harris, N., and Y. Gluck, "SSL, gone in 30 498 seconds: A BREACH beyond CRIME", . 503 Author's Address 505 Valery Smyslov 506 ELVIS-PLUS 507 PO Box 81 508 Moscow (Zelenograd) 124460 509 RU 511 Phone: +7 495 276 0211 512 Email: svan@elvis.ru