idnits 2.17.1 draft-smyslov-ipsecme-ikev2-compression-00.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 (December 25, 2015) is 3035 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 December 25, 2015 5 Expires: June 27, 2016 7 Compression in the Internet Key Exchange Protocol Version 2 (IKEv2) 8 draft-smyslov-ipsecme-ikev2-compression-00 10 Abstract 12 This document describes a method for reducing the size of IKEv2 13 messages by means of lossless compression. Making IKEv2 messages 14 smaller is desirable for low power consumption battery powered IoT 15 devices. It also helps 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 June 27, 2016. 36 Copyright Notice 38 Copyright (c) 2015 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 IKE Fragmentation . . . . . . . . . . . . . . 12 63 5.2. Interaction IKE Resumption . . . . . . . . . . . . . . . . 12 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 67 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 68 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 71 1. Introduction 73 The Internet Key Exchange protocol version 2 (IKEv2) defined in 74 [RFC7296] is used in the IP Security (IPsec) architecture for the 75 purposes of Security Association (SA) parameters negotiation and 76 authenticated key exchange. The protocol uses UDP as the transport 77 for its messages. The size of the messages varies from hundreds 78 bytes to several kBytes. 80 Sending large UDP messages may cause IP fragmentation to take place, 81 which may interact badly with some Network Address Translators (NAT). 82 One of the possible solutions to the problem is IKEv2 fragmentation 83 described in [RFC7383]. However, the IKEv2 fragmentation cannot be 84 used for unencrypted messages and thus cannot be used in the initial 85 IKEv2 exchange called IKE_SA_INIT exchange. Usually the messages of 86 the IKE_SA_INIT exchange are relatively small and this restriction 87 doesn't cause problems. However with adoption more and more new 88 algorithms and new IKEv2 extensions there is a tendency for these 89 messages to become larger and larger for the implementations that 90 support new features. 92 The lossless compression can be used to reduce the size of IKEv2 93 messages. Each IKEv2 message contains different types of data 94 structured in payloads. Depending on the type of payload the 95 compressibility of the data it contains varies greatly. Some types 96 of payloads, like the Nonce payload, contain data that are almost 97 uncompressable. On the other hand, such payloads like the Security 98 Association payload or Notification payload usually have a lot of 99 redundancy in their encoding and hence are highly compressable. 100 Since many emerging IKEv2 extensions add new type of notification or 101 new parameter to the Security Association payload contained in the 102 IKE_SA_INIT messages, the ability to compress these messages would 103 help keep their size bounded. 105 Compression can also be applied to the messages followed the 106 IKE_SA_INIT exchange. In this case the reduced size of the messages 107 would make the necessity to use the IKEv2 fragmentation less likely 108 or would decrease the number of fragments the messages are divided 109 into, which would increase the protocol reliability and productivity. 111 The other field where using compression may be useful is the Internet 112 of Things (IoT) devices utilizing a lower power consumption 113 technology. For many such devices the power consumption for 114 transmitting extra bits over network is much higher than the power 115 consumption for spending extra CPU cycles to compress data before 116 transmission. The appendix A of [IPSEC-IOT-REQS] gives some estimate 117 data. Since many such devices are battery powered without an ability 118 to recharge or to replace the battery which serves for the lifecycle 119 of the device (a few years), the task of reducing the power 120 consuption for such devices is very important. 122 This document specifies how lossless compression is used in IKEv2. 123 In order to enable compression in the IKE_SA_INIT exchange a new 124 payload is introduced that contains other payloads in compressed 125 form. The processing of the Encrypted payload is modified to 126 accommodate compression in subsequent exchanges. The document also 127 specifies how the use of compression is negotiated between the peers 128 maintaining backward compatibility. 130 2. Requirements Language 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 3. Protocol Description 138 Compression is accomodated differently in the initial IKEv2 exchange 139 and in subsequent exchanges. The difference comes out from the fact, 140 that the messages of all the IKEv2 exchanges except the initial 141 exchange contain the Encrypted payload. In this case the compression 142 is added as an additional step while constructing the Encrypted 143 payload. The initial IKEv2 exchange requires introduction a new 144 payload, that would contain other payloads in compressed form. 146 3.1. Using Compression in the IKE_SA_INIT Exchange 148 The use of compression is not negotiated in a usual for IKEv2 manner 149 - by exchanging appropriate Notification or Vendor ID payloads. 150 Instead a different negotiation mechanism is used. 152 If an Initiator wants to use compression for the IKE SA being 153 created, it constructs the IKE_SA_INIT request message in a following 154 way. A new payload which is called Compressed payload and described 155 in the Section 4.1 is included into the request message. This 156 payload contains other payloads in compressed form as well as an 157 indication of what compression algorithm was used. When selecting 158 compression algorithm the Initiator must guess what algorithms are 159 supported by the peer and choose an appropriate one. If its guess is 160 wrong the Responder will inform about this situation and the mutually 161 appropriate algorithm will be negotiated by the cost of an extra 162 round trip and a message recompression. The Critical bit in the 163 Compressed payload header MUST be set to 1. 165 Initiator 166 --------- 167 HDR, C!{SA, KE, [N+], [V+]}, Ni, [N+], [V+] --> 169 Not all payloads that are usually present in the IKE_SA_INIT messages 170 are subject for compression. Some payloads may contain random or 171 pseudo-random data that is almost uncompressable. Other payloads 172 must be processed as early as possible, before the responder spens 173 resources decompressing them. In particular, the Nonce payloda and 174 the COOKIE notification payload MUST NOT be included into the 175 Compressed payload. Obviously, if the compression algorithm ID is 176 from private range (241-255), then the corresponding Vendor ID 177 payload MUST NOT be compressed. See Section 5 for more details about 178 interaction compression with other IKEv2 extensions. 180 If the Responder doesn't support IKEv2 compression, then it is 181 expected to return the UNSUPPORTED_CRITICAL_PAYLOAD notification in 182 response to such request message, as prescribed in the Section 2.5 of 184 [RFC7296]. Depending on the implementation it may also return the 185 INVALID_SYNTAX notification or doesn't respond at all. 187 Legacy Responder 188 ---------------- 189 <-- HDR, N(UNSUPPORTED_CRITICAL_PAYLOAD) 191 or 193 <-- HDR, N(INVALID_SYNTAX) 195 or 197 (No response) 199 If the Initiator receives the UNSUPPORTED_CRITICAL_PAYLOAD 200 notification with the Compressed payload type in its notification 201 data or if it receives the INVALID_SYNTAX notification or if it 202 receives no response after several retransmissions then the Initiator 203 MUST restart the IKE_SA_INIT exchange with no compression. 205 If the Responder supports IKEv2 compression, but doesn't support the 206 particular compression algorithm the Initiator has chosen, then the 207 Responder sends back a new error notification: 208 INVALID_COMPRESSION_ALGORITHM. This notification is describe in the 209 Section 4.2. Its notification data contains the list of IDs of 210 compression algorithms supported by the Responder. 212 Responder 213 --------- 214 <-- HDR, N(INVALID_COMPRESSION_ALGORITHM) 216 If the Initiator receives the INVALID_COMPRESSION_ALGORITHM 217 notification, then it looks through the list of algorithms included 218 into the notification data and selects the appropriate one. After 219 that it MUST restart the IKE_SA_INIT exchange using the newly 220 selected algorithm for compression. If no mutually appropriate 221 algorithm found, then the Initiator MUST restart the IKE_SA_INIT 222 exchange with no compression. 224 Once the Responder receives the IKE_SA_INIT request with the 225 compression algorithm in the Compressed payload that is appropriate 226 to it, the compressed payloads are decompressed and along with the 227 outer payloads form the uncompressed request message, which is then 228 processed as usual. If the Responder agrees to use compression in 229 the SA being created then the Responder MUST include the Compressed 230 payload in response message. The compression algorithm indicated in 231 the Compressed payload MUST be the algorithm from the request messge. 233 Responder 234 --------- 235 <-- HDR, C!{SA, KE, [N+], [V+]}, Nr, [N+], [V+] 237 If for some reason the Responder doesn't want to use compression for 238 the SA being created (e.g. using compression is disabled by 239 administrator) then it MUST send back an uncompressed IKE_SA_INIT 240 response message. In this case the endpoints MUST NOT use 241 compression in subsequent exchanges. 243 3.2. Using Compression in Subsequent Exchanges 245 Once the endpoints have used compression in the IKE_SA_INIT exchange, 246 they may continue to use it in subsequent exchanges. However 247 compression is used differently in this exchanges. Messages of every 248 IKEv2 exchange apart from the initial exchange are protected by an 249 Encrypted payload. With compression the algorithms for forming and 250 processing of an Encrypted payload are modified as follows. 252 The content of an Encrypted payload is compressed before it is 253 encrypted and authenticated. The Next Payload field in an Encrypted 254 payload usually indicates the payload type of the first payload 255 inside an Encrypted payload. If compression is used then the Next 256 Payload field in the Encrypted payload MUST be set to XXX (TBA by 257 IANA) - the value for the payload type of a Compressed payload. 258 However, the Compressed payload itself MUST NOT appear inside the 259 Encrypted payload, only its payload type is used to indicate that the 260 content of the Encrypted payload was compressed before encryption. 262 Since in this case the Next Payload field in an Encrypted payload no 263 longer indicates a type of the first inner payload, this information 264 is moved to the Next Payload field of the last inner payload (which 265 must be zero in IKEv2). This modification is done before the 266 payloads are compresed. 268 Uncompressed: SK(Next=P1) {P1(Next=P2), P2(Next=P3), ... Pn(Next=0)} 269 Compressed: SK(Next=C) {P1(Next=P2), P2(Next=P3), ... Pn(Next=P1)} 271 Preparing payloads for compression 273 This modification doesn't cause ambiguity on the receiver, since the 274 total size of the inner payloads can be easily determined after 275 decryption, and while walking through the list of them the receiver 276 always knows whether the current payload is the last or not. 278 After the use of compression is negotiated in the initial exchange 279 each endpoint is free to decide whether to apply compression or not 280 on per-message basis. However, if applying compression to the 281 content of an Encrypted payload doesn't reduce its size then the 282 compression MUST NOT be used for this message. Implementations MUST 283 be prepared to receive both compressed and uncompressed messages. 285 4. Payload Formats 287 4.1. Compressed Payload 289 The Compressed payload, denoted C!{...} in this document (the 290 exclamation mark means that this payload is critical), contains other 291 payloads in compressed form. The payload type for the Compressed 292 payload is XXX (TBA by IANA). 294 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Next Payload |C| RESERVED | Payload Length | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | First Payload | Algorithm | | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 301 ~ Compressed Payloads ~ 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Compressed Payload 306 o Next Payload (1 octet) - Identifier for the payload type of the 307 next payload in the message. 309 o Critical (1 bit) - MUST be set to 1. 311 o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on 312 receipt (as specified in [RFC7296]). 314 o Payload Length (2 octets, unsigned integer) - Length in octets of 315 the current payload, including the generic payload header. 317 o First Payload (1 octet) - Identifier for the payload type of the 318 first payload contained in Compressed Payloads field. 320 o Algorithm (1 octet) - ID of the algorithm used to compress inner 321 payloads. The possible values for compression algorithm ID are 322 listed in "IKEv2 Notification IPCOMP Transform IDs" registry in 323 [IKEV2-IANA]. 325 o Compressed Payloads (variable length) - This field contains IKEv2 326 payloads in compressed form. The Next Payload field of the last 327 included payload MUST be set to 0. 329 There MUST NOT be more than one Compressed payloads in a message. 330 The Compressed payload MUST NOT appear inside the Encrypted payload 331 and the Encrypted payload payload MUST NOT appear inside the 332 Compressed payload. 334 4.2. INVALID_COMPRESSION_ALGORITHM Notification 336 The INVALID_COMPRESSION_ALGORITHM notification is sent by Responder 337 if the compression algorithm chosen by Initiator is unappropriate. 338 The Notification Data contains the list of supported compression 339 algorithm IDs. 341 1 2 3 342 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 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Next Payload |C| RESERVED | Payload Length | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 |Protocol ID(=0)| SPI Size (=0) | Notify Message Type | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 ~ Supported Compression Algorithms ~ 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 INVALID_COMPRESSION_ALGORITHM Notification 353 o Protocol ID (1 octet) - MUST be 0. 355 o SPI Size (1 octet) - MUST be 0, meaning no SPI is present. 357 o Notify Message Type (2 octets) - MUST be XXX (TBA by IANA), the 358 value assigned for the INVALID_COMPRESSION_ALGORITHM notification. 360 o Supported Compression Algorithms (variable length) - List of 361 compression algorithm IDs supported by the Responder. Each 362 algorithm ID occupies one octet. The possible values for 363 compression algorithm IDs are listed in "IKEv2 Notification IPCOMP 364 Transform IDs" registry in [IKEV2-IANA]. 366 5. Interaction with other IKEv2 Extensions 368 IKE Compression is compatible with most of IKE extensions, since It 369 neither affect their operation, nor is affected by them. However, 370 some IKE extensions require special handling. 372 5.1. Interaction IKE Fragmentation 374 When IKE Compression is used with IKE Fragmentation [RFC7383] the 375 compression MUST take place before splitting the original content of 376 the Encrypted payload into chunks. In other words, the content of 377 the Encrypted payload must be compressed as a whole, before it is 378 fragmented. 380 The Compressed payload MUST NOT appear inside the Encrypted Fragment 381 payload and the Encrypted Fragment payload payload MUST NOT appear 382 inside the Compressed payload. 384 5.2. Interaction IKE Resumption 386 IKE Resumption [RFC5723] defines a mechanism for restoring an IKE SA 387 state after a failure. If the peers support IKE Compression then the 388 flag whether the compression was negotiated and the compression 389 algorithm MUST be restored from the resumption ticket while resuming 390 IKE SA. In other words the use of compression must not be re- 391 negotiated in the IKE_SESSION_RESUME exchange and thus the Compressed 392 payload MUST NOT appear in this exchange. 394 6. Security Considerations 396 It was shown in [COMP-LEAK] that using compression inside an 397 encrypted channel may result in a leakage of some information about a 398 plaintext. Recently some practical exploits were discovered that 399 rely on using compression in security protocols ([CRIME], [BREACH]). 400 However, it is believed that the way a compression is added to the 401 IKEv2 would not weaken the protocol security. The existing exploits 402 rely on an ability for an attacker to insert data into an encrypted 403 stream, i.e. to perform a chosen-plaintext attack. IKEv2 messages 404 don't contain application data, which restricts attacker's ability to 405 perform chosen-plaintext attack. Moreover, the data usually 406 exchanged over the IKEv2 SA contain no secret information and in most 407 cases no sensitive information. The possible exceptions could be 408 some weak Extensible Authentication Protocol (EAP) methods, which 409 might transfer secret information within an IKE SA. It is 410 RECOMMENDED that implementations don't use the IKE Compression for 411 the messages containing the EAP payload if there is a possibility 412 that the EAP method transfers secret information. 414 7. IANA Considerations 416 This document defines new Payload in the "IKEv2 Payload Types" 417 registry: 419 Compressed C 421 This document also defines new Notify Message Types in the "Notify 422 Message Types - Error Types" registry: 424 INVALID_COMPRESSION_ALGORITHM 426 8. References 428 8.1. Normative References 430 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 431 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 432 RFC2119, March 1997, 433 . 435 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 436 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 437 DOI 10.17487/RFC5723, January 2010, 438 . 440 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 441 Kivinen, "Internet Key Exchange Protocol Version 2 442 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, 443 October 2014, . 445 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 446 (IKEv2) Message Fragmentation", RFC 7383, DOI 10.17487/ 447 RFC7383, November 2014, 448 . 450 [IKEV2-IANA] 451 "Internet Key Exchange Version 2 (IKEv2) Parameters", 452 . 454 8.2. Informative References 456 [IPSEC-IOT-REQS] 457 Migault, D. and T. Guggemos, "Requirements for Diet-ESP 458 the IPsec/ESP protocol for IoT", 459 draft-mglt-6lo-diet-esp-requirements-01 (work in 460 progress), February 2015. 462 [COMP-LEAK] 463 Kelsey, J., "Compression and Information Leakage of 464 Plaintext", . 467 [CRIME] Rizzo, J. and T. Duong, "The CRIME attack", . 471 [BREACH] Prado, A., Harris, N., and Y. Gluck, "SSL, gone in 30 472 seconds: A BREACH beyond CRIME", . 477 Author's Address 479 Valery Smyslov 480 ELVIS-PLUS 481 PO Box 81 482 Moscow (Zelenograd) 124460 483 RU 485 Phone: +7 495 276 0211 486 Email: svan@elvis.ru