idnits 2.17.1 draft-smyslov-ipsecme-ikev2-compact-05.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 (April 3, 2019) is 1843 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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 April 3, 2019 5 Expires: October 5, 2019 7 Compact Format of IKEv2 Payloads 8 draft-smyslov-ipsecme-ikev2-compact-05 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 October 5, 2019. 38 Copyright Notice 40 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . 18 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 70 9.2. Informative References . . . . . . . . . . . . . . . . . 18 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 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 at the IP level, 94 which 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", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in BCP 123 14 [RFC2119] [RFC8174] when, and only when, they appear in all 124 capitals, as shown here. 126 3. Overview 128 The idea behind the protocol is to develop an alternative compact 129 encoding of IKEv2 payloads that meets the following requirements: 131 1. The compact encoding must be applicable to all already defined 132 IKEv2 payloads as well as to future payloads, so it must not 133 depend on payload format. There may be few special cases if 134 specific encoding is justified by much higher efficiency. 136 2. The compact encoding must be easily converted to standard 137 encoding and vice versa. This allows implementations to re-use 138 existing composing/parsing code and to apply compact encoding/ 139 decoding as pre/post process steps in message processing. 141 3. The compact encoding/decoding algorithm must consume low 142 resources in terms of code size, CPU consumption and memory 143 footprint. 145 4. The compact encoding must never increase the payload size and 146 must be effective enough to noticeably decrease the size of most 147 payloads. 149 To meet these requirements the encoding algorithm must be independent 150 from the particular payload format. In other words, it must take any 151 given payload and perform some kind of compression. General purpose 152 lossless compression algorithms are usually not very effective when 153 they are applied to small amount of data. Fortunately format of many 154 IKEv2 payloads has a peculiarity that allows using simple and 155 relatively efficient compression algorithm. 157 Many IKEv2 payloads contain a lot of zero octets. These octets come 158 from the following sources: 160 o Many Payload Headers contain RESERVED fields that must be zeroed 161 according to IKEv2 specification. 163 o Payload length is encoded in two octets, while most IKEv2 payloads 164 are less than 256 octets in size. 166 o Substantial number of IKEv2 parameters is encoded in two octets, 167 while the number of currently defined values for these parameters 168 is less than one hundred (see [IKEV2-IANA]). 170 The idea is to omit these zero octets from the compact payload and 171 supply a bitmap that will indicate which octets were omitted. 173 IKEv2 header also contains some redundancy - in particular the Length 174 field occupies four octets, while IKEv2 messages are extremely 175 unlikely to exceed few Kb in size. However, some middleboxes perform 176 an inspection of IKEv2 header and changing its format will likely 177 interact badly with these middleboxes. Thus, the possible saving of 178 few octets doesn't justify modification of IKEv2 header. 180 4. Compact Representation of IKEv2 Payloads 182 This document defines one generic compact format suitable for 183 compacting any IKEv2 payload and two specific compact formats - one 184 for SA payload and the other for Notify payload containing status 185 notification with no data. The rationale for such a design is the 186 following. 188 One common generic compact format simplifies implementations and 189 allows using it with any currently defined and not yet defined 190 payloads. However, it doesn't provide high level of efficiency. 192 SA payload contains a lot of redundancy and can be encoded in highly 193 efficient way. Moreover, this payload grows up quickly once more new 194 transforms are defined and implementations start using them. In some 195 cases the SA payload can be the largest payload in the IKE_SA_INIT 196 exchange. So, there is a natural desire to encode it differently to 197 gain better result. On the other hand, Notify payload with status 198 notification containing no data is often used in IKEv2 initial 199 exchange to negotiate support for various protocol extensions. So, 200 there are usually several such payloads in the IKE_SA_INIT request 201 and response messages, ant it is anticipated that their number will 202 increase as long as more and more IKEv2 extensions are defined. 203 That's why this payload is also encoded differently to make initial 204 messages more compact. 206 4.1. Compact Generic Payload 208 Generic IKEv2 payload is depicted below (Figure 1) for convenience. 209 It consists of generic payload header followed by payload data. 210 Brief description of generic payload header fields is provided below, 211 readers should refer to Section 3.2 of [RFC7296] for full 212 description. 214 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Next Payload |C| RESERVED | Payload Length | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | | 220 ~ ~ 221 | | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 Figure 1: Generic Payload 226 o Next Payload (1 octet) - Identifier for the payload type of the 227 next payload in the message. 229 o Critical (1 bit) - This bit is set if the current payload cannot 230 be skipped in case the receiver doesn't understand its type and 231 cleared if it is safe to skip this payload. 233 o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on 234 receipt. 236 o Payload Length (2 octets, unsigned integer) - Length in octets of 237 the current payload, including the generic payload header. 239 o Payload Data (variable) - Contains payload specific data. 241 Some payloads have extended headers following the generic payload 242 header. For the purpose of compact payload encoding any extended 243 header is treated as part of payload data. Complete description of 244 IKEv2 Payload formats can be found in Section 3 of [RFC7296]. 246 Figure 2 shows generic compact payload format. 248 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Next Payload |C| Bmap | XBL |Payload Length | ~ 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 253 | | 254 ~ ~ 255 | | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | | 258 ~ ~ 259 | | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 Figure 2: Compact Generic Payload 264 o Next Payload (1 octet) - Identifier for the payload type of the 265 next payload in the message. The value is taken intact from 266 original payload. 268 o Critical (1 bit) - This bit is set if the current payload cannot 269 be skipped in case the receiver doesn't understand its type and 270 cleared if it is safe to skip this payload. The value is taken 271 intact from original payload. 273 o Bmap (4 bits) - Bitmap, contains bitmap where each bit indicates 274 whether one of the four first octets of original Payload Data was 275 zero and thus was omitted from Compacted Payload Data. If the bit 276 is set, then the corresponding octet was zero and was omitted, if 277 the bit is cleared, then either the corresponding octet was copied 278 or it didn't present in the original Payload Data (in case the 279 octet would be outside the original payload). The rightmost bit 280 of the map corresponds to the first of the four octets and the 281 leftmost bit corresponds to the last of these four octets. 283 o XBL (3 bits) - Extended Bitmap Length, specifies the number of 284 Extended Bitmap octets plus one. Note, that by construction this 285 field cannot be zero. 287 o Payload Length (1 octet) - Length in octets of compacted payload 288 not including Extended Bitmap. 290 o Compacted Payload Data (variable) - Contains original payload data 291 with some zero octets omitted. Up to 52 zero octets from the 292 beginning of original payload data can be omitted, the rest of 293 original payload data is always copied. 295 o Extended Bitmap (variable, 0 - 6 octets) - contains extended 296 bitmap. Each octet of this bitmap represents how the 297 corresponding eight octets of the original payload data were 298 handled - original octets corresponding to the set bits were zero 299 and thus were omitted from the compacted payload data, while 300 octets corresponding to the cleared bits were copied. First octet 301 in the Extended Bitmap corresponds to octets from 5 to 12 of the 302 original payload data, next octet - to octets from 13 to 20, etc. 303 Note, that the Bmap field indicates how octets from 1 to 4 were 304 handled. In each octet of extended bitmap the rightmost bit 305 represents the first of corresponding original octets and the 306 leftmost bit represents the last one. 308 An IKEv2 payload can be compacted if it meets two requirements: 310 o The payload length is less than 256 octets. In other words, the 311 high order octet of Payload Length field is zero. 313 o The RESERVED field in the generic payload header is zero. 314 Section 3.2 of [RFC7296] requires that this field must always be 315 zero when preparing payload. 317 If payload doesn't meet these requirement it is included into the 318 message without modification. The regular and compact payloads can 319 be present in any order in the compact IKEv2 message. The receiving 320 side can distinguish between them by analyzing the least significant 321 three bits of RESERVED field in generic payload header. These bits 322 correspond to XBL field in compact generic payload header, and this 323 field will always be non-zero in compact payload while these bits are 324 required to be zero in regular payload. 326 If payload meets the above requirements then it is compacted as 327 follows. 329 1. The Next Payload and Critical fields are copied from original 330 payload. 332 2. The first 4 octets of the original payload data are scanned one 333 by one. If the current octet is zero, then it is omitted from 334 the Compacted Payload data and the corresponding bit (starting 335 from the rightmost bit to the leftmost bit) in Bmap field is set. 336 Otherwise the octet is copied and the corresponding bit is 337 cleared. If there are no more octets in the original payload 338 data then the process stops and the rest of Bmap is zeroed. 340 3. If any more octets left in the original payload data, then the 341 next 48 of them are scanned one by one. Since the Extended 342 Bitmap position isn't known yet a temporary bitmap of six octets 343 is used. If the current octet is zero, then it is omitted from 344 the Compacted Payload Data and the corresponding bit (starting 345 from the rightmost bit to the leftmost bit) in the corresponding 346 octet of a temporary bitmap is set. Otherwise the original octet 347 is copied and the corresponding bit in temporary bitmap is 348 cleared. If there are no more octets in the original payload 349 data then the process stops and the rest bits of the current 350 temporary bitmap octet are zeroed. 352 4. If any more octets left in the original payload data, they are 353 copied to the Compacted Payload Data. 355 5. The Payload Length field is set to indicate the size of Compacted 356 Payload Data plus 3. It will indicate the offset of the Extended 357 Bitmap from the beginning of compact payload. 359 6. The content of the temporary bitmap is copied to the Extended 360 Bitmap field (after the Compacted Payload Data). The temporary 361 bitmap octets are copied one by one up to the first zero octet 362 (if any). In other words, the Extended Bitmap MUST NOT contain 363 zero octets. 365 7. The XBL field is set to the number of octets placed in the 366 Extended Bitmap plus one. 368 4.2. Compact SA Payload 370 SA payload is compacted differently than generic IKEv2 payload. The 371 specific format for Compact SA payload allows achieving very high 372 level of compression. High level of compression is important, 373 because SA payload grows up quickly as more and more cryptographic 374 transforms are defined, get widespread adoption and advertised by 375 Initiators. 377 Unlike generic compact payload, which retains its payload type and is 378 distinguished from regular IKEv2 payload by analyzing the leftmost 379 three bits of RESERVED field of the generic payload header, the 380 Compact SA payload has its own payload type. The reason is that its 381 format (Figure 3) is completely different and the above method cannot 382 be used. The Compact SA payload is denoted CSA, and its payload type 383 is . 385 1 2 3 386 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 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Next Payload | Num Proposals | ~ 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 390 | | 391 ~ ~ 392 | | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 Figure 3: Compact SA Payload 397 o Next Payload (1 octet) - Identifier for the payload type of the 398 next payload in the message. The value is taken intact from 399 original payload. 401 o Num Proposals (1 octet) - Specifies the number of Compact 402 Proposals in this SA payload. 404 o Compact Proposals (variable) - One or more compact proposal 405 substructures. 407 Despite the fact that Compact SA payload has different payload type 408 and different format than regular SA payload, the associated 409 semantics MUST be the same. Regular SA payload can always be 410 compacted if it is compliant with Section 3.3 of [RFC7296]. 412 4.2.1. Compact Proposal Substructure 414 Compact Proposal substructure (Figure 4) resembles regular Proposal 415 substructure lacking first four octets. The Compact Proposal 416 substructure fields are briefly described below. Readers should 417 refer to Section 3.3.1 of [RFC7296] for detailed description of 418 Compact Proposal substructure fields with the same names, as in 419 regular Proposal substructure. 421 1 2 3 422 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 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Proposal Num | Protocol ID | SPI Size |Num Transforms| 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 ~ SPI (variable) ~ 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | | 429 ~ ~ 430 | | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 Figure 4: Compact Proposal Substructure 435 o Proposal Num (1 octet) - Proposal Number. 437 o Protocol ID (1 octet) - Specifies the IPsec protocol identifier 438 for the current negotiation. 440 o SPI Size (1 octet) - Size of SPI. 442 o Num Transforms (1 octet) - Specifies the number of transforms in 443 this proposal. 445 o SPI (variable) - The sending entity's SPI. 447 o Compact Transforms (variable) - One or more compact transform 448 substructures. 450 4.2.2. Compact Transform Substructures 452 Compact Transform substructures are encoded differently depending on 453 Transform Type, Transform ID and presence of attributes to get most 454 effective encoding for common use cases. The leftmost bits of the 455 first octet of the Compact Transform substructure are used to 456 distinguish between different formats. These bits are called Tag. 457 The table below shows how Tag value correlates with Compact Transform 458 substructure format. 460 +----------+-----------------------+-----+-------+---------+--------+ 461 | Tag | Compact Transform | Len | Trans | Trans | Format | 462 | | Format | | Types | IDs | | 463 +----------+-----------------------+-----+-------+---------+--------+ 464 | 0tttvvvv | Short: Generic | 1 | 6-13 | 0-15 | Figure | 465 | | | | | | 5 | 466 | | | | | | | 467 | 100vvvvv | Short: Encryption (no | 1 | 1 | 11-42 | Figure | 468 | | Key Length attribute | | | | 6 | 469 | | or 128-bit key) | | | | | 470 | | | | | | | 471 | 101vvvvv | Short: Encryption | 1 | 1 | 11-42 | Figure | 472 | | (256-bit key) | | | | 6 | 473 | | | | | | | 474 | 110vvvvv | Short: Diffie-Hellman | 1 | 4 | 0, | Figure | 475 | | Group | | | 14-44 | 7 | 476 | | | | | | | 477 | 1110vvvv | Short: PRF | 1 | 2 | 2-15 | Figure | 478 | | | | | | 8 | 479 | | | | | | | 480 | 1110000v | Short: ESN | 1 | 5 | 0-1 | Figure | 481 | | | | | | 9 | 482 | | | | | | | 483 | 1111tttt | Long 1 | 2 | 1-15 | 0-127 | Figure | 484 | | | | | | 10 | 485 | | | | | | | 486 | 1111tttt | Long 2 | 3 | 1-15 | 0-32767 | Figure | 487 | | | | | | 11 | 488 | | | | | | | 489 | 11110000 | Full | 6+ | 0-255 | 0-65535 | Figure | 490 | | | | | | 12 | 491 +----------+-----------------------+-----+-------+---------+--------+ 493 Table 1: Tag values and corresponding Compact Transform formats 495 Short formats are the most efficient Compact Transform formats, they 496 occupy only one octet; long format occupies either two or three 497 octets depending on the Transform ID value. Both short and long 498 formats can be used only for some Transform Types and can represent 499 only limited number of Transform IDs. Moreover, both short and long 500 formats cannot be used if Transform contains any attributes, except 501 if it is the Encryption Transform and it contains the Key Length 502 attribute and the value of the attribute is either 128 or 256. The 503 Table 1 summarizes the restrictions each format implies. 505 Full format imposes no constraints on the Transform Type and 506 Transform ID, as well on the attributes the transform could contain. 508 4.2.2.1. Short Format 510 Short format allows encoding both Transform Type and Transform ID 511 using single octet. It has several variations - a generic short 512 format and a number of specific formats for different Transform Types 513 that take advantage of the concrete Transform IDs defined in 514 [IKEV2-IANA] for these Transform Types. 516 Figures 5-8 show short format encodings for different Transform 517 Types. 519 0 1 2 3 4 5 6 7 520 +-+-+-+-+-+-+-+-+ 521 |T| Type| ID | 522 +-+-+-+-+-+-+-+-+ 524 Figure 5: Generic Short Format 526 o T(ag) (1 bit) - MUST be 0. 528 o Type (3 bits) - Transform Type minus 6. This allows Transform 529 Types from 6 to 13 to be encoded using this format. 531 o ID (4 bits) - Transform ID. 533 0 1 2 3 4 5 6 7 534 +-+-+-+-+-+-+-+-+ 535 | Tag | ENCR ID | 536 +-+-+-+-+-+-+-+-+ 538 Figure 6: Short Format for Encryption 540 o Tag (3 bits) - MUST be either 100 or 101. Tag value 100 indicates 541 that either no Key Length attribute is present in the original 542 Transform or it is present and its value is 128. Tag values 101 543 indicates that Key Length attribute containing value 256 is 544 present in the original Transform. 546 o ENCR ID (5 bits) - Encryption Algorithm Transform ID minus 11. 548 0 1 2 3 4 5 6 7 549 +-+-+-+-+-+-+-+-+ 550 | Tag | GRP ID | 551 +-+-+-+-+-+-+-+-+ 553 Figure 7: Short Format for Diffie-Hellman Group 555 o Tag (3 bits) - MUST be 110. 557 o GRP ID (5 bits) - Value 0 indicates NONE, other values are treated 558 as Diffie-Hellman Group Transform ID minus 14. 560 0 1 2 3 4 5 6 7 561 +-+-+-+-+-+-+-+-+ 562 | Tag | PRFID | 563 +-+-+-+-+-+-+-+-+ 565 Figure 8: Short Format for PRF 567 o Tag (4 bits) - MUST be 1110. 569 o PRFID (4 bits) - Pseudo-random Function Transform ID. This value 570 MUST never be 0 and 1. 572 0 1 2 3 4 5 6 7 573 +-+-+-+-+-+-+-+-+ 574 | Tag |E| 575 +-+-+-+-+-+-+-+-+ 577 Figure 9: Short Format for ESN 579 o Tag (7 bits) - MUST be 1110000. 581 o E ( bit) - Extended Sequence Numbers Transform ID (either 0 or 1). 583 4.2.2.2. Long Format 585 Long format (Figures 10 and 11) is used when Transform doesn't meet 586 requirements for short format encoding, but still meets the following 587 requirements: 589 1. Transform Type is between 1 and 15. At the time this document 590 was written only Transform Types 1 to 5 were defined (see 591 [IKEV2-IANA]). 593 2. Transform has no attributes. 595 3. Transform ID is less than or equal to 32767. 597 Long format allows to effectively encode Transform IDs for Transform 598 Types that don't fit into the short format, e.g. private Transform 599 IDs (if these transforms don't have associated attributes and its 600 value is less than or equal to 32767). 602 Long format can occupy two or three octets depending on the Transform 603 ID value. For values 0-127 only one octet is used to represent the 604 value, for values 128-32767 two octets are used. Values greater than 605 32767 require using full format. 607 1 608 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Tag | Type |L| Trans ID | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 Figure 10: Long Format 1 615 o Tag (4 bits) - MUST be 1111. 617 o Type (4 bits) - The type of transform being specified in this 618 substructure. This field is always non-zero, since Transform Type 619 0 is marked as Reserved in [IKEV2-IANA]. 621 o L (1 bit) - MUST be 0. 623 o Trans ID (7 bits) - The specific instance of the Transform Type 624 being specified. 626 1 2 627 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Tag | Type |L| Transform ID | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 Figure 11: Long Format 2 634 o Tag (4 bits) - MUST be 1111. 636 o Type (4 bits) - The type of transform being specified in this 637 substructure. This field is always non-zero, since Transform Type 638 0 is marked as Reserved in [IKEV2-IANA]. 640 o L (1 bit) - MUST be 1. 642 o Transform ID (15 bits) - The specific instance of the Transform 643 Type being specified. 645 4.2.2.3. Full Format 647 Full format of Compact Transform substructure allows encoding of any 648 transform without restrictions. It is used when transform cannot be 649 encoded neither in short format nor in long format. The format 650 (Figure 12) resembles regular Transform Substructure with all 651 RESERVED fields removed. The Compact Transform substructure fields 652 are briefly described below. Readers should refer to Section 3.3.2 653 of [RFC7296] for detailed description of Compact Transform 654 substructure fields with the same names, as in regular Transform 655 substructure. 657 1 2 3 658 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 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | Tag |Transform Type | Transform Length | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | Transform ID | ~ 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 664 | | 665 ~ ~ 666 | | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 Figure 12: Full Format 671 o Tag (1 octet) - MUST be 11110000. 673 o Transform Type (1 octet) - The type of transform being specified 674 in this substructure. 676 o Transform Length (2 octets, unsigned integer) - The length in 677 octets of the Compact Transform Substructure including Header and 678 Attributes. 680 o Transform ID (2 octets) - The specific instance of the Transform 681 Type being specified. 683 o Transforms Attributes (variable) - Transform attributes. 685 4.3. Compact Notify Payload 687 Notify payloads containing status notifications with no data are 688 often used in IKEv2. This is "de facto" standard way to negotiate 689 various protocol extensions and for that reason usually several such 690 Notify payloads are present in initial IKEv2 exchanges. It is 691 anticipated that the number of IKEv2 extensions will increase and 692 thus the size of initial exchange messages will increase too. This 693 is the reason that this kind of Notify payload is encoded 694 specifically, to get more effective message compression. 696 As well as Compact SA payload, Compact Notify payload has its own 697 payload type. The Compact Notify payload is denoted CN, and its 698 payload type is . 700 1 701 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Next Payload | Notify Type | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 Figure 13: Compact Notify Payload for Status Notification 708 o Next Payload (1 octet) - Identifier for the payload type of the 709 next payload in the message. The value is taken intact from 710 original payload. 712 o Notify Type (1 octet) - The type of notification message minus 713 16384. 715 Despite the fact that Compact Notify payload has different payload 716 type and different format than regular Notify payload, the associated 717 semantics MUST be the same. 719 Notify payload can be encoded as Compact Notify payload if it meets 720 the following requirements (see Section 3.10 of [RFC7296] for Notify 721 payload format): 723 1. Notify Message Type is between 16384 and 16639 (inclusive). This 724 corresponds to status notifications. 726 2. Protocol ID is zero. 728 3. SPI Size is zero, meaning no SPI is present. 730 4. Notification Data is empty. 732 At the time this document was written about 40 percent of status 733 notifications defined in [IKEV2-IANA] met these requirements. If 734 Notify payload doesn't meet these requirements, the generic compact 735 format (Section 4.1) can be tried. 737 5. Compact Format Negotiation 739 Most IKEv2 extensions are negotiated in the following way. The 740 Initiator announces its support for some extension by including 741 corresponding Vendor ID payload or Notify payload containing status 742 notification in the request message of IKE_SA_INIT or IKE_AUTH 743 exchanges. If the Responder supports this extension it returns the 744 same (or some specific) payload to the Initiator in response message. 745 Responder that doesn't support compact format just ignores these 746 payloads in accordance with IKEv2 specification. 748 This method is inappropriate for negotiation of compact format, 749 because Initiator should be able to send an initial request message 750 in compact form and thus it must inform Responder somehow that the 751 message must be parsed differently than regular IKEv2 message. Since 752 compact message may contain regular IKEv2 payloads, it is possible to 753 define a new status notification and to include it without compacting 754 as the very first payload in the initial request. However, this 755 spoils the whole idea of reducing initial messages size, since this 756 payload will increase message size for no good reason. 758 Instead this document specifies a different negotiation mechanism. 759 An alternative initial exchange is defined, ALT_IKE_SA_INIT. 760 Initiator wishing to use compact representations of IKEv2 payloads 761 MUST start creating IKEv2 SA using ALT_IKE_SA_INIT exchange instead 762 of IKE_SA_INIT. The very first ALT_IKE_SA_INIT request may contain 763 compact payloads. If Responder receives ALT_IKE_SA_INIT request and 764 doesn't support compact format, then according to Section 2.21.1 of 765 [RFC7296] it discards the request. It may also send INVALID_SYNTAX 766 notification. For the Initiator receiving no response after several 767 retransmissions or receiving INVALID_SYNTAX notification is an 768 indication that the Responder doesn't support compact format. In 769 this case the Initiator MAY restart initial request using regular 770 IKE_SA_INIT request. 772 If the Responder supports compact format then it response with 773 ALT_IKE_SA_INIT response, confirming to the Initiator that using 774 compact format is successfully negotiated. Once using compact format 775 is negotiated, compact payloads may appear in any message of 776 subsequent exchanges in the context of the IKE SA being negotiated. 777 If IKE SA is rekeyed, then the flag whether compact format is allowed 778 MUST be inherited by the new SA from the old one. 780 The semantics associated with ALT_IKE_SA_INIT exchange MUST be the 781 same, as the semantics associated with IKE_SA_INIT exchange. In 782 other words, when ALT_IKE_SA_INIT exchange is used, the endpoints 783 must behave exactly as if it is IKE_SA_INIT exchange. The only 784 difference (apart from different Exchange Types) is that IKE_SA_INIT 785 messages MUST NOT contain compact payloads, while ALT_IKE_SA_INIT MAY 786 contain them. 788 6. Interaction with other IKEv2 Extensions 790 When using compact encoding with IKEv2 Session Resumption [RFC5723], 791 the flag indicating whether peers negotiated compact format MUST be 792 stored in the resumption ticket and used in an SA created as a result 793 of resumption. 795 7. Security Considerations 797 Compact format of IKEv2 payloads doesn't change security properties 798 of the protocol, which are described in Section 5 of [RFC7296]. 800 8. IANA Considerations 802 This document defines two new Payloads in the "IKEv2 Payload Types" 803 registry: 805 Compact SA Payload CSA 806 Compact Notify Payload CN 808 This document also defines a new Exchange Type in the "IKEv2 Exchange 809 Types" registry: 811 ALT_IKE_SA_INIT 813 9. References 815 9.1. Normative References 817 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 818 Requirement Levels", BCP 14, RFC 2119, 819 DOI 10.17487/RFC2119, March 1997, . 822 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 823 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 824 May 2017, . 826 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 827 Kivinen, "Internet Key Exchange Protocol Version 2 828 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 829 2014, . 831 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 832 (IKEv2) Message Fragmentation", RFC 7383, 833 DOI 10.17487/RFC7383, November 2014, . 836 9.2. Informative References 838 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 839 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 840 DOI 10.17487/RFC5723, January 2010, . 843 [IPSEC-IOT-REQS] 844 Migault, D., Guggemos, T., and C. Bormann, "Requirements 845 for Diet-ESP the IPsec/ESP protocol for IoT", draft-mglt- 846 6lo-diet-esp-requirements-02 (work in progress), July 847 2016. 849 [IKEV2-IANA] 850 "Internet Key Exchange Version 2 (IKEv2) Parameters", 851 . 853 Author's Address 855 Valery Smyslov 856 ELVIS-PLUS 857 PO Box 81 858 Moscow (Zelenograd) 124460 859 RU 861 Phone: +7 495 276 0211 862 Email: svan@elvis.ru