idnits 2.17.1 draft-smyslov-ipsecme-ikev2-compact-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 29, 2017) is 2393 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' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 29, 2017 5 Expires: April 2, 2018 7 Compact Format of IKEv2 Payloads 8 draft-smyslov-ipsecme-ikev2-compact-02 10 Abstract 12 This document describes a method for reducing the size of the 13 Internet Key Exchange version 2 (IKEv2) messages by using an 14 alternative format for IKE payloads. Standard format of many IKE 15 payloads contains a lot of redundancy. This document takes advantage 16 of this fact and specifies a way to eliminate some redundancy by 17 using denser encoding. Reducing size of IKEv2 messages is desirable 18 for low power consumption battery powered devices. It also helps to 19 avoid IP fragmentation of IKEv2 messages. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 2, 2018. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 57 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Compact Representation of IKEv2 Payloads . . . . . . . . . . 4 59 4.1. Compact Generic Payload . . . . . . . . . . . . . . . . . 5 60 4.2. Compact SA Payload . . . . . . . . . . . . . . . . . . . 8 61 4.2.1. Compact Proposal Substructure . . . . . . . . . . . . 9 62 4.2.2. Compact Transform Substructures . . . . . . . . . . . 10 63 4.3. Compact Notify Payload . . . . . . . . . . . . . . . . . 15 64 5. Compact Format Negotiation . . . . . . . . . . . . . . . . . 16 65 6. Interaction with other IKEv2 Extensions . . . . . . . . . . . 17 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 70 9.2. Informative References . . . . . . . . . . . . . . . . . 18 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 73 1. Introduction 75 The Internet Key Exchange protocol version 2 (IKEv2) specified in 76 [RFC7296] is used in the IP Security (IPsec) architecture for the 77 purposes of Security Association (SA) parameters negotiation and 78 authenticated key exchange. The protocol uses UDP as the transport 79 for its messages, which size varies from less than one hundred bytes 80 to several kBytes. 82 Decreasing the size of IKEv2 messages is highly desirable for the 83 Internet of Things (IoT) devices utilizing lower power consumption 84 technology. For some of such devices the power consumption for 85 transmitting extra bits over network is prohibitively high (see 86 appendix A of [IPSEC-IOT-REQS]). Many such devices are battery 87 powered without an ability to recharge or to replace the battery 88 which serves for the life cycle of the device (often several years). 89 For this reason the task of reducing the power consumption for such 90 devices is very important and decreasing messages size is one of the 91 ways to accomplish it. 93 Large UDP messages may also cause fragmentation on IP level, which 94 may interact badly with Network Address Translators (NAT). In 95 particular, some NATs drop IP fragments that don't contain TCP/UDP 96 port numbers (non-initial IP fragments), so that the IP datagram 97 cannot be reassembled on the receiving end and IKE SA cannot be 98 established. One of the possible solutions to the problem is IKEv2 99 fragmentation [RFC7383]. However, the IKEv2 fragmentation can only 100 be applied to encrypted messages and thus cannot be used in the 101 initial IKEv2 exchange, IKE_SA_INIT. Usually the IKE_SA_INIT 102 messages are relatively small and don't cause IP fragmentation. 103 However, while more and more new algorithms and protocol extensions 104 are included in IKEv2, these messages become larger and larger thus 105 increasing the risk of IP fragmentation. It is desirable to make 106 IKEv2 messages more compact to help avoid this risk. 108 IKEv2 messages are comprised of data structures called payloads. 109 Each payload consists of a common part (Generic Payload Header) 110 followed by a payload-specific data which is formatted differently 111 depending on the payload's purpose. Section 3 of [RFC7296] lists 112 formats for all standard IKEv2 payloads. As one can see some IKEv2 113 payloads are formatted in such a way, that there are substantial 114 redundancy in their encoding. This document defines an alternative 115 format for the IKEv2 payloads, which provides denser encoding, that 116 allows making IKEv2 messages more compact. 118 2. Requirements Language 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 3. Overview 126 The idea behind the protocol is to develop an alternative compact 127 encoding of IKEv2 payloads that meets the following requirements: 129 1. The compact encoding must be applicable to all already defined 130 IKEv2 payloads as well as to future payloads, so it must not 131 depend on payload format. There may be few special cases if 132 specific encoding is justified by much higher efficiency. 134 2. The compact encoding must be easily converted to standard 135 encoding and vice versa. This allows implementations to re-use 136 existing composing/parsing code and to apply compact encoding/ 137 decoding as pre/post process steps in message processing. 139 3. The compact encoding/decoding algorithm must consume low 140 resources in terms of code size, CPU consumption and memory 141 footprint. 143 4. The compact encoding must never increase the payload size and 144 must be effective enough to noticeably decrease the size of most 145 payloads. 147 To meet these requirements the encoding algorithm must be independent 148 from the particular payload format. In other words, it must take any 149 given payload and perform some kind of compression. General purpose 150 lossless compression algorithms are usually not very effective when 151 they are applied to small amount of data. Fortunately format of many 152 IKEv2 payloads has a peculiarity that allows using simple and 153 relatively efficient compression algorithm. 155 Many IKEv2 payloads contain a lot of zero octets. These octets come 156 from the following sources: 158 o Many Payload Headers contain RESERVED fields that must be zeroed 159 according to IKEv2 specification. 161 o Payload length is encoded in two octets, while most IKEv2 payloads 162 are less than 256 octets in size. 164 o Substantial number of IKEv2 parameters are encoded in two octets, 165 while the number of currently defined values for these parameters 166 is less than one hundred (see [IKEV2-IANA]). 168 The idea is to omit these zero octets from the compact payload and 169 supply a bitmap that will indicate which octets were omitted. 171 IKEv2 header also contains some redundancy - in particular the Length 172 field occupies four octets, while IKEv2 messages are extremely 173 unlikely to exceed few Kb in size. However, some middleboxes perform 174 an inspection of IKEv2 header and changing its format will likely 175 interact badly with these middleboxes. Thus, the possible saving of 176 few octets doesn't justify modification of IKEv2 header. 178 4. Compact Representation of IKEv2 Payloads 180 This document defines one generic compact format suitable for 181 compacting any IKEv2 payload and two specific compact formats - one 182 for SA payload and the other for Notify payload containing status 183 notification with no data. The rationale for such a design is the 184 following. 186 One common generic compact format simplifies implementations and 187 allows using it with any currently defined and not yet defined 188 payloads. However, it doesn't provide high level of efficiency. 190 SA payload contains a lot of redundancy and can be encoded in highly 191 efficient way. Moreover, this payload grows up quickly once more new 192 transforms are defined and implementations start using them. In some 193 cases the SA payload can be the largest payload in the IKE_SA_INIT 194 exchange. So, there is a natural desire to encode it differently to 195 gain better result. On the other hand, Notify payload with status 196 notification containing no data is often used in IKEv2 initial 197 exchange to negotiate support for various protocol extensions. So, 198 there are usually several such payloads in the IKE_SA_INIT request 199 and response messages, ant it is anticipated that their number will 200 increase as long as more and more IKEv2 extensions are defined. 201 That's why this payload is also encoded differently to make initial 202 messages more compact. 204 4.1. Compact Generic Payload 206 Generic IKEv2 payload is depicted below (Figure 1) for convenience. 207 It consists of generic payload header followed by payload data. 208 Brief description of generic payload header fields is provided below, 209 readers should refer to Section 3.2 of [RFC7296] for full 210 description. 212 1 2 3 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Next Payload |C| RESERVED | Payload Length | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | | 218 ~ ~ 219 | | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 Figure 1: Generic Payload 224 o Next Payload (1 octet) - Identifier for the payload type of the 225 next payload in the message. 227 o Critical (1 bit) - This bit is set if the current payload cannot 228 be skipped in case the receiver doesn't understand its type and 229 cleared if it is safe to skip this payload. 231 o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on 232 receipt. 234 o Payload Length (2 octets, unsigned integer) - Length in octets of 235 the current payload, including the generic payload header. 237 o Payload Data (variable) - Contains payload specific data. 239 Some payloads have extended headers following the generic payload 240 header. For the purpose of compact payload encoding any extended 241 header is treated as part of payload data. Complete description of 242 IKEv2 Payload formats can be found in Section 3 of [RFC7296]. 244 Figure 2 shows generic compact payload format. 246 1 2 3 247 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 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Next Payload |C| Bmap | XBL |Payload Length | ~ 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 251 | | 252 ~ ~ 253 | | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | | 256 ~ ~ 257 | | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 Figure 2: Compact Generic Payload 262 o Next Payload (1 octet) - Identifier for the payload type of the 263 next payload in the message. The value is taken intact from 264 original payload. 266 o Critical (1 bit) - This bit is set if the current payload cannot 267 be skipped in case the receiver doesn't understand its type and 268 cleared if it is safe to skip this payload. The value is taken 269 intact from original payload. 271 o Bmap (4 bits) - Bitmap, contains bitmap where each bit indicates 272 whether one of the four first octets of original Payload Data was 273 zero and thus was omitted from Compacted Payload Data. If the bit 274 is set, then the corresponding octet was zero and was omitted, if 275 the bit is cleared, then either the corresponding octet was copied 276 or it didn't present in the original Payload Data (in case the 277 octet would be outside the original payload). The rightmost bit 278 of the map corresponds to the first of the four octets and the 279 leftmost bit corresponds to the last of these four octets. 281 o XBL (3 bits) - Extended Bitmap Length, specifies the number of 282 Extended Bitmap octets plus one. Note, that by construction this 283 field cannot be zero. 285 o Payload Length (1 octet) - Length in octets of compacted payload 286 not including Extended Bitmap. 288 o Compacted Payload Data (variable) - Contains original payload data 289 with some zero octets omitted. Up to 52 zero octets from the 290 beginning of original payload data can be omitted, the rest of 291 original payload data is always copied. 293 o Extended Bitmap (variable, 0 - 6 octets) - contains extended 294 bitmap. Each octet of this bitmap represents how the 295 corresponding eight octets of the original payload data were 296 handled - original octets corresponding to the set bits were zero 297 and thus were omitted from the compacted payload data, while 298 octets corresponding to the cleared bits were copied. First octet 299 in the Extended Bitmap corresponds to octets from 5 to 12 of the 300 original payload data, next octet - to octets from 13 to 20, etc. 301 Note, that the Bmap field indicates how octets from 1 to 4 were 302 handled. In each octet of extended bitmap the rightmost bit 303 represents the first of corresponding original octets and the 304 leftmost bit represents the last one. 306 An IKEv2 payload can be compacted if it meets two requirements: 308 o The payload length is less than 256 octets. In other words, the 309 high order octet of Payload Length field is zero. 311 o The RESERVED field in the generic payload header is zero. 312 Section 3.2 of [RFC7296] requires that this field must always be 313 zero when preparing payload. 315 If payload doesn't meet these requirement it is included into the 316 message without modification. The regular and compact payloads can 317 be present in any order in the compact IKEv2 message. The receiving 318 side can distinguish between them by analyzing the least significant 319 three bits of RESERVED field in generic payload header. These bits 320 correspond to XBL field in compact generic payload header, and this 321 field will always be non-zero in compact payload while these bits are 322 required to be zero in regular payload. 324 If payload meets the above requirements then it is compacted as 325 follows. 327 1. The Next Payload and Critical fields are copied from original 328 payload. 330 2. The first 4 octets of the original payload data are scanned one 331 by one. If the current octet is zero, then it is omitted from 332 the Compacted Payload data and the corresponding bit (starting 333 from the rightmost bit to the leftmost bit) in Bmap field is set. 334 Otherwise the octet is copied and the corresponding bit is 335 cleared. If there are no more octets in the original payload 336 data then the process stops and the rest of Bmap is zeroed. 338 3. If any more octets left in the original payload data, then the 339 next 48 of them are scanned one by one. Since the Extended 340 Bitmap position isn't known yet a temporary bitmap of six octets 341 is used. If the current octet is zero, then it is omitted from 342 the Compacted Payload Data and the corresponding bit (starting 343 from the rightmost bit to the leftmost bit) in the corresponding 344 octet of a temporary bitmap is set. Otherwise the original octet 345 is copied and the corresponding bit in temporary bitmap is 346 cleared. If there are no more octets in the original payload 347 data then the process stops and the rest bits of the current 348 temporary bitmap octet are zeroed.. 350 4. If any more octets left in the original payload data, they are 351 copied to the Compacted Payload Data. 353 5. The Payload Length field is set to indicate the size of Compacted 354 Payload Data plus 3. It will indicate the offset of the Extended 355 Bitmap from the beginning of compact payload. 357 6. The content of the temporary bitmap is copied to the Extended 358 Bitmap field (after the Compacted Payload Data). The temporary 359 bitmap octets are copied one by one up to the first zero octet 360 (if any). In other words, the Extended Bitmap MUST NOT contain 361 zero octets. 363 7. The XBL field is set to the number of octets placed in the 364 Extended Bitmap plus one. 366 4.2. Compact SA Payload 368 SA payload is compacted differently than generic IKEv2 payload. The 369 specific format for Compact SA payload allows achieving very high 370 level of compression. High level of compression is important, 371 because SA payload grows up quickly as more and more cryptographic 372 transforms are defined, get widespread adoption and advertised by 373 Initiators. 375 Unlike generic compact payload, which retains its payload type and is 376 distinguished from regular IKEv2 payload by analyzing the leftmost 377 three bits of RESERVED field of the generic payload header, the 378 Compact SA payload has its own payload type. The reason is that its 379 format (Figure 3) is completely different and the above method cannot 380 be used. The Compact SA payload is denoted CSA, and its payload type 381 is . 383 1 2 3 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Next Payload | Num Proposals | ~ 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 388 | | 389 ~ ~ 390 | | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 Figure 3: Compact SA Payload 395 o Next Payload (1 octet) - Identifier for the payload type of the 396 next payload in the message. The value is taken intact from 397 original payload. 399 o Num Proposals (1 octet) - Specifies the number of Compact 400 Proposals in this SA payload. 402 o Compact Proposals (variable) - One or more compact proposal 403 substructures. 405 Despite the fact that Compact SA payload has different payload type 406 and different format than regular SA payload, the associated 407 semantics MUST be the same. Regular SA payload can always be 408 compacted if it is compliant with Section 3.3 of [RFC7296]. 410 4.2.1. Compact Proposal Substructure 412 Compact Proposal substructure (Figure 4) resembles regular Proposal 413 substructure lacking first four octets. The Compact Proposal 414 substructure fields are briefly described below. Readers should 415 refer to Section 3.3.1 of [RFC7296] for detailed description of 416 Compact Proposal substructure fields with the same names, as in 417 regular Proposal substructure. 419 1 2 3 420 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 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Proposal Num | Protocol ID | SPI Size |Num Transforms| 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 ~ SPI (variable) ~ 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | | 427 ~ ~ 428 | | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 Figure 4: Compact Proposal Substructure 433 o Proposal Num (1 octet) - Proposal Number. 435 o Protocol ID (1 octet) - Specifies the IPsec protocol identifier 436 for the current negotiation. 438 o SPI Size (1 octet) - Size of SPI. 440 o Num Transforms (1 octet) - Specifies the number of transforms in 441 this proposal. 443 o SPI (variable) - The sending entity's SPI. 445 o Compact Transforms (variable) - One or more compact transform 446 substructures. 448 4.2.2. Compact Transform Substructures 450 Compact Transform substructures are encoded differently depending on 451 Transform Type, Transform ID and presence of attributes to get most 452 effective encoding for common use cases. The leftmost bits of the 453 first octet of the Compact Transform substructure are used to 454 distinguish between different formats. These bits are called Tag. 455 The table below shows how Tag value correlates with Compact Transform 456 substructure format. 458 +----------+---------------------------------------+-----+----------+ 459 | Tag | Compact Transform | Len | Format | 460 +----------+---------------------------------------+-----+----------+ 461 | 00xxxxxx | Short form - Encryption (Type 1) | 1 | Figure 5 | 462 | | | | | 463 | 01xxxxxx | Short form - Encryption (Type 1) with | 2 | Figure 6 | 464 | | key length | | | 465 | | | | | 466 | 10xxxxxx | Short form - Diffie-Hellman Group | 1 | Figure 7 | 467 | | (Type 4) | | | 468 | | | | | 469 | 110xxxxx | Short form - Integrity (Type 3) | 1 | Figure 8 | 470 | | | | | 471 | 1110xxxx | Short form - Pseudo-random Function | 1 | Figure 9 | 472 | | (Type 2) | | | 473 | | | | | 474 | 11110xxx | Short form - Extended Sequence | 1 | Figure | 475 | | Numbers (Type 5) | | 10 | 476 | | | | | 477 | 11111xxx | Long form | 3 | Figure | 478 | | | | 11 | 479 | | | | | 480 | 11111000 | Full form | var | Figure | 481 | | | | 12 | 482 +----------+---------------------------------------+-----+----------+ 484 Table 1: Tag values and corresponding Compact Transform formats 486 Short forms are the most efficient Compact Transform formats. Most 487 of them occupy only one octet, except for the Encryption Transform 488 with key length, which occupy two octets. The Transform can be 489 encoded using short form if it meets the following requirements: 491 1. Transform Type is between 1 and 5. At the time the document was 492 written these Transform Types were the only defined (see 493 [IKEV2-IANA]). 495 2. Transform ID is less or equal to the value, specific to each 496 Transform Type: 498 * 63 for Transform Type 1 (Encryption Algorithm) 500 * 15 for Transform Type 2 (Pseudo-random Function) 502 * 31 for Transform Type 3 (Integrity Algorithm) 504 * 63 for Transform Type 4 (Diffie-Hellman Group) 505 * 7 for Transform Type 5 (Extended Sequence Numbers) 507 3. Transform has no attributes, or Transform has Type 1 (Encryption 508 Algorithm), it has only one attribute of type Key Length (Type 509 14), the value of this attribute is less than 2048 and the value 510 is divisible by 8. 512 If the Transform doesn't meet these requirements, then it cannot be 513 encoded in short form. In this case either long form (Figure 11) or 514 full form (Figure 12) must be used. Note, that all the transforms 515 defined in [IKEV2-IANA] at the time this document was written meet 516 these requirements. 518 Figures 5-10 show short form encodings for different Transform Types. 520 0 1 2 3 4 5 6 7 521 +-+-+-+-+-+-+-+-+ 522 |Tag|ENCR Tr ID | 523 +-+-+-+-+-+-+-+-+ 525 Figure 5: Compact Transform Substructure (Short Form: Encryption) 527 o Tag (2 bits) - MUST be 00. 529 o ENCR Tr ID (6 bits) - Encryption Algorithm Transform ID. 531 1 532 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 |Tag|ENCR Tr ID | Key Length | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 Figure 6: Compact Transform (Short Form: Encryption with Key Length) 539 o Tag (2 bits) - MUST be 01. 541 o ENCR Tr ID (6 bits) - Encryption Algorithm Transform ID. 543 o Key Length (1 octet) - Key Length in bytes (note, that Key Length 544 attribute in IKEv2 specifies key length in bits). 546 0 1 2 3 4 5 6 7 547 +-+-+-+-+-+-+-+-+ 548 |Tag| GRP Tr ID | 549 +-+-+-+-+-+-+-+-+ 551 Figure 7: Compact Transform (Short Form: Diffie-Hellman Group) 553 o Tag (2 bits) - MUST be 10. 555 o GRP Tr ID (6 bits) - Diffie-Hellman Group Transform ID. 557 0 1 2 3 4 5 6 7 558 +-+-+-+-+-+-+-+-+ 559 | Tag |INTG TrID| 560 +-+-+-+-+-+-+-+-+ 562 Figure 8: Compact Transform (Short Form: Integrity) 564 o Tag (3 bits) - MUST be 110. 566 o INTG TrID (5 bits) - Integrity Algorithm Transform ID. 568 0 1 2 3 4 5 6 7 569 +-+-+-+-+-+-+-+-+ 570 | Tag | PRF | 571 +-+-+-+-+-+-+-+-+ 573 Figure 9: Compact Transform (Short Form: PRF) 575 o Tag (4 bits) - MUST be 1110. 577 o PRF (4 bits) - Pseudo-random Function Transform ID. 579 0 1 2 3 4 5 6 7 580 +-+-+-+-+-+-+-+-+ 581 | Tag | ESN | 582 +-+-+-+-+-+-+-+-+ 584 Figure 10: Compact Transform (Short Form: ESN) 586 o Tag (5 bits) - MUST be 11110. 588 o ESN (3 bits) - Extended Sequence Numbers Transform ID. 590 Long form (Figure 11) is used when Transform doesn't meet 591 requirements for short form encoding, but still meets the following 592 requirements: 594 1. Transform Type is between 1 and 7. At the time this document was 595 written only Transform Types 1 to 5 were defined (see 596 [IKEV2-IANA]). 598 2. Transform has no attributes. 600 Long form allows to effectively encode Transform IDs for standard 601 Transform Types that don't fit into the short form, e.g. private 602 Transform IDs (if these transforms don't have associated attributes). 603 It is expected that new Transform IDs will be defined more often than 604 new Transform Types. So, defining effective encoding for standard 605 Transform Type and arbitrary Transform IDs makes sense. 607 1 2 608 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Tag |Type | Transform ID | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 Figure 11: Compact Transform (Long Form) 615 o Tag (5 bits) - MUST be 11111. 617 o Transform Type (3 bits) - The type of transform being specified in 618 this substructure. 620 o Transform ID (2 octets) - The specific instance of the Transform 621 Type being specified. 623 Full encoding of Compact Transform substructure allows encoding of 624 any transform without restrictions. It is used when transform cannot 625 be encoded neither in short form nor in long form. The format 626 (Figure 12) resembles regular Transform Substructure with all 627 RESERVED fields removed. The Compact Transform substructure fields 628 are briefly described below. Readers should refer to Section 3.3.2 629 of [RFC7296] for detailed description of Compact Transform 630 substructure fields with the same names, as in regular Transform 631 substructure. 633 1 2 3 634 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 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | Tag |Transform Type | Transform Length | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Transform ID | ~ 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 640 | | 641 ~ ~ 642 | | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 Figure 12: Compact Transform (Full Form) 647 o Tag (1 octet) - MUST be 11111000. 649 o Transform Type (1 octet) - The type of transform being specified 650 in this substructure. 652 o Transform Length (2 octets, unsigned integer) - The length in 653 octets of the Compact Transform Substructure including Header and 654 Attributes. 656 o Transform ID (2 octets) - The specific instance of the Transform 657 Type being specified. 659 o Transforms Attributes (variable) - Transform attributes. 661 4.3. Compact Notify Payload 663 Notify payloads containing status notifications with no data are 664 often used in IKEv2. This is "de facto" standard way to negotiate 665 various protocol extensions and for that reason usually several such 666 Notify payloads are present in initial IKEv2 exchanges. It is 667 anticipated that the number of IKEv2 extensions will increase and 668 thus the size of initial exchange messages will increase too. This 669 is the reason that this kind of Notify payload is encoded 670 specifically, to get more effective message compression. 672 As well as Compact SA payload, Compact Notify payload has its own 673 payload type. The Compact Notify payload is denoted CN, and its 674 payload type is . 676 1 677 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Next Payload | Notify Type | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 Figure 13: Compact Notify Payload for Status Notification 684 o Next Payload (1 octet) - Identifier for the payload type of the 685 next payload in the message. The value is taken intact from 686 original payload. 688 o Notify Type (1 octet) - The type of notification message minus 689 16384. 691 Despite the fact that Compact Notify payload has different payload 692 type and different format than regular Notify payload, the associated 693 semantics MUST be the same. 695 Notify payload can be encoded as Compact Notify payload if it meets 696 the following requirements (see Section 3.10 of [RFC7296] for Notify 697 payload format): 699 1. Notify Message Type is between 16384 and 16639 (inclusive). This 700 corresponds to status notifications. 702 2. Protocol ID is zero. 704 3. SPI Size is zero, meaning no SPI is present. 706 4. Notification Data is empty. 708 At the time this document was written about 40 percent of status 709 notifications defined in [IKEV2-IANA] met these requirements. If 710 Notify payload doesn't meet these requirements, the generic compact 711 format (Section 4.1) can be tried. 713 5. Compact Format Negotiation 715 Most IKEv2 extensions are negotiated in the following way. The 716 Initiator announces its support for some extension by including 717 corresponding Vendor ID payload or Notify payload containing status 718 notification in the request message of IKE_SA_INIT or IKE_AUTH 719 exchanges. If the Responder supports this extension it returns the 720 same (or some specific) payload to the Initiator in response message. 721 Responder that doesn't support compact format just ignores these 722 payloads in accordance with IKEv2 specification. 724 This method is inappropriate for negotiation of compact format, 725 because Initiator should be able to send an initial request message 726 in compact form and thus it must inform Responder somehow that the 727 message must be parsed differently than regular IKEv2 message. Since 728 compact message may contain regular IKEv2 payloads, it is possible to 729 define a new status notification and to include it without compacting 730 as the very first payload in the initial request. However, this 731 spoils the whole idea of reducing initial messages size, since this 732 payload will increase message size for no good reason. 734 Instead this document specifies a different negotiation mechanism. 735 An alternative initial exchange is defined, ALT_IKE_SA_INIT. 736 Initiator wishing to use compact representations of IKEv2 payloads 737 MUST start creating IKEv2 SA using ALT_IKE_SA_INIT exchange instead 738 of IKE_SA_INIT. The very first ALT_IKE_SA_INIT request may contain 739 compact payloads. If Responder receives ALT_IKE_SA_INIT request and 740 doesn't support compact format, then according to Section 2.21.1 of 741 [RFC7296] it discards the request. It may also send INVALID_SYNTAX 742 notification. For the Initiator receiving no response after several 743 retransmissions or receiving INVALID_SYNTAX notification is an 744 indication that the Responder doesn't support compact format. In 745 this case the Initiator MAY restart initial request using regular 746 IKE_SA_INIT request. 748 If the Responder supports compact format then it response with 749 ALT_IKE_SA_INIT response, confirming to the Initiator that using 750 compact format is successfully negotiated. Once using compact format 751 is negotiated, compact payloads may appear in any message of 752 subsequent exchanges in the context of the IKE SA being negotiated. 753 If IKE SA is rekeyed, then the flag whether compact format is allowed 754 MUST be inherited by the new SA from the old one. 756 The semantics associated with ALT_IKE_SA_INIT exchange MUST be the 757 same, as the semantics associated with IKE_SA_INIT exchange. In 758 other words, when ALT_IKE_SA_INIT exchange is used, the endpoints 759 must behave exactly as if it is IKE_SA_INIT exchange. The only 760 difference (apart from different Exchange Types) is that IKE_SA_INIT 761 messages MUST NOT contain compact payloads, while ALT_IKE_SA_INIT MAY 762 contain them. 764 6. Interaction with other IKEv2 Extensions 766 When using compact encoding with IKEv2 Session Resumption [RFC5723], 767 the flag indicating whether peers negotiated compact format MUST be 768 stored in the resumption ticket and used in an SA created as a result 769 of resumption. 771 7. Security Considerations 773 Compact format of IKEv2 payloads doesn't change security properties 774 of the protocol, which are described in Section 5 of [RFC7296]. 776 8. IANA Considerations 778 This document defines two new Payloads in the "IKEv2 Payload Types" 779 registry: 781 Compact SA Payload CSA 782 Compact Notify Payload CN 784 This document also defines a new Exchange Type in the "IKEv2 Exchange 785 Types" registry: 787 ALT_IKE_SA_INIT 789 9. References 791 9.1. Normative References 793 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 794 Requirement Levels", BCP 14, RFC 2119, 795 DOI 10.17487/RFC2119, March 1997, . 798 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 799 Kivinen, "Internet Key Exchange Protocol Version 2 800 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 801 2014, . 803 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 804 (IKEv2) Message Fragmentation", RFC 7383, 805 DOI 10.17487/RFC7383, November 2014, . 808 [IKEV2-IANA] 809 "Internet Key Exchange Version 2 (IKEv2) Parameters", 810 . 812 9.2. Informative References 814 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 815 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 816 DOI 10.17487/RFC5723, January 2010, . 819 [IPSEC-IOT-REQS] 820 Migault, D., Guggemos, T., and C. Bormann, "Requirements 821 for Diet-ESP the IPsec/ESP protocol for IoT", draft-mglt- 822 6lo-diet-esp-requirements-02 (work in progress), July 823 2016. 825 Author's Address 827 Valery Smyslov 828 ELVIS-PLUS 829 PO Box 81 830 Moscow (Zelenograd) 124460 831 RU 833 Phone: +7 495 276 0211 834 Email: svan@elvis.ru