idnits 2.17.1 draft-smyslov-ipsecme-ikev2-compact-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 (October 7, 2016) is 2758 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 October 7, 2016 5 Expires: April 10, 2017 7 Compact Format of IKEv2 Payloads 8 draft-smyslov-ipsecme-ikev2-compact-00 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 alternate 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 more dense encoding. Reducing size of IKEv2 messages is 18 desirable for low power consumption battery powered devices. It also 19 helps to 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 10, 2017. 38 Copyright Notice 40 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 57 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Compact Representation of IKEv2 Payloads . . . . . . . . . . . 7 59 4.1. Compact Generic Payload . . . . . . . . . . . . . . . . . 7 60 4.2. Compact SA Payload . . . . . . . . . . . . . . . . . . . . 11 61 4.2.1. Compact Proposal Substructure . . . . . . . . . . . . 11 62 4.2.2. Compact Transform Substructures . . . . . . . . . . . 12 63 4.3. Compact Notify Payload . . . . . . . . . . . . . . . . . . 17 64 5. Compact Format Negotiation . . . . . . . . . . . . . . . . . . 19 65 6. Interaction with other IKEv2 Extensions . . . . . . . . . . . 20 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 69 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 70 9.2. Informative References . . . . . . . . . . . . . . . . . . 23 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 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 a 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 a few 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 more dense encoding, 116 that 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 alternate 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 visa 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 requirement 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 to use 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 to use 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 doen'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 doen'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 Any 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. Section 312 3.2 of [RFC7296] requires that this field must always be zero when 313 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 to get very high level 370 of compression. High level of compression is important, because SA 371 payload grows up quickly as more and more cryptographic transforms 372 are defined, get widespread adoption and advertised by Initiators. 374 Unlike generic compact payload, which retains its payload type and is 375 distinguished from regular IKEv2 payload by analyzing the leftmost 376 three bits of RESERVED field of the generic payload header, the 377 Compact SA payload has its own payload type. The reason is that its 378 format (Figure 3) is completely different and the above method cannot 379 be used. The Compact SA payload is denoted CSA, and its payload type 380 is . 382 1 2 3 383 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 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Next Payload | Num Proposals | ~ 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 387 | | 388 ~ ~ 389 | | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 Figure 3: Compact SA Payload 394 o Next Payload (1 octet) - Identifier for the payload type of the 395 next payload in the message. The value is taken intact from 396 original payload. 398 o Num Proposals (1 octet) - Specifies the number of Compact 399 Proposals in this SA payload. 401 o Compact Proposals (variable) - One or more compact proposal 402 substructures. 404 Despite the fact that Compact SA payload has different payload type 405 and different format than regular SA payload, the associated 406 semantics MUST be the same. Regular SA payload can always be 407 compacted if it is compliant with Section 3.3 of [RFC7296]. 409 4.2.1. Compact Proposal Substructure 411 Compact Proposal substructure (Figure 4) resembles regular Proposal 412 substructure lacking first four octets. The Compact Proposal 413 substructure fields are briefly described below. Readers should 414 refer to Section 3.3.1 of [RFC7296] for detailed description of 415 Compact Proposal substructure fields with the same names, as in 416 regular Proposal substructure. 418 1 2 3 419 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 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Proposal Num | Protocol ID | SPI Size |Num Transforms| 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 ~ SPI (variable) ~ 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | | 426 ~ ~ 427 | | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 Figure 4: Compact Proposal Substructure 432 o Proposal Num (1 octet) - Proposal Number. 434 o Protocol ID (1 octet) - Specifies the IPsec protocol identifier 435 for the current negotiation. 437 o SPI Size (1 octet) - Size of SPI. 439 o Num Transforms (1 octet) - Specifies the number of transforms in 440 this proposal. 442 o SPI (variable) - The sending entity's SPI. 444 o Compact Transforms (variable) - One or more compact transform 445 substructures. 447 4.2.2. Compact Transform Substructures 449 Compact Transform substructures are encoded differently depending on 450 Transform Type, Transform ID and presence of attributes to get most 451 effective encoding for common use cases. The leftmost bits of the 452 first octet of the Compact Transform substructure are used to 453 distinguish between different formats. These bits are called Tag. 454 The table below shows how Tag value correlates with Compact Transform 455 substructure format. 457 +----------+--------------------------------------+-----+-----------+ 458 | Tag | Compact Transform | Len | Format | 459 +----------+--------------------------------------+-----+-----------+ 460 | 00xxxxxx | Short form - Encryption (Type 1) | 1 | Figure 5 | 461 | | | | | 462 | 01xxxxxx | Short form - Encryption (Type 1) | 2 | Figure 6 | 463 | | with key length | | | 464 | | | | | 465 | 10xxxxxx | Short form - Diffie-Hellman Group | 1 | Figure 7 | 466 | | (Type 4) | | | 467 | | | | | 468 | 110xxxxx | Short form - Integrity (Type 3) | 1 | Figure 8 | 469 | | | | | 470 | 1110xxxx | Short form - Pseudo-random Function | 1 | Figure 9 | 471 | | (Type 2) | | | 472 | | | | | 473 | 11110xxx | Short form - Extended Sequence | 1 | Figure 10 | 474 | | Numbers (Type 5) | | | 475 | | | | | 476 | 11111xxx | Long form | 3 | Figure 11 | 477 | | | | | 478 | 11111000 | Full form | var | Figure 12 | 479 +----------+--------------------------------------+-----+-----------+ 481 Table 1: Tag values and corresponding Compact Transform formats 483 Short forms are the most efficient Compact Transform formats. Most 484 of them occupy only one octet, except for the Encryption Transform 485 with key length, which occupy two octets. The Transform can be 486 encoded using short form if it meets the following requirements: 488 1. Transform Type is between 1 and 5. At the time the document was 489 written these Transform Types were the only defined (see 490 [IKEV2-IANA]). 492 2. Transform ID is less or equal to the value, specific to each 493 Transform Type: 495 * 63 for Transform Type 1 (Encryption Algorithm) 497 * 15 for Transform Type 2 (Pseudo-random Function) 499 * 31 for Transform Type 3 (Integrity Algorithm) 501 * 63 for Transform Type 4 (Diffie-Hellman Group) 503 * 7 for Transform Type 5 (Extended Sequence Numbers) 505 3. Transform has no attributes, or Transform has Type 1 (Encryption 506 Algorithm), it has only one attribute of type Key Length (Type 507 14), the value of this attribute is less than 2048 and the value 508 is divisible by 8. 510 If the Transform doesn't meet these requirements, then it cannot be 511 encoded in short form. In this case either long form (Figure 11) or 512 full form (Figure 12) must be used. Note, that all the transforms 513 defined in [IKEV2-IANA] at the time this document was written meet 514 these requirements. 516 Figures 5-10 show short form encodings for different Transform Types. 518 0 1 2 3 4 5 6 7 519 +-+-+-+-+-+-+-+-+ 520 |Tag|ENCR Tr ID | 521 +-+-+-+-+-+-+-+-+ 523 Figure 5: Compact Transform Substructure (Short Form: Encryption) 525 o Tag (2 bits) - MUST be 00. 527 o ENCR Tr ID (6 bits) - Encryption Algorithm Transform ID. 529 1 530 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 |Tag|ENCR Tr ID | Key Length | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 Figure 6: Compact Transform (Short Form: Encryption with Key Length) 537 o Tag (2 bits) - MUST be 01. 539 o ENCR Tr ID (6 bits) - Encryption Algorithm Transform ID. 541 o Key Length (1 octet) - Key Length in bytes (note, that Key Length 542 attribute in IKEv2 specifies key length in bits). 544 0 1 2 3 4 5 6 7 545 +-+-+-+-+-+-+-+-+ 546 |Tag| GRP Tr ID | 547 +-+-+-+-+-+-+-+-+ 549 Figure 7: Compact Transform (Short Form: Diffie-Hellman Group) 551 o Tag (2 bits) - MUST be 10. 553 o GRP Tr ID (6 bits) - Diffie-Hellman Group Transform ID. 555 0 1 2 3 4 5 6 7 556 +-+-+-+-+-+-+-+-+ 557 | Tag |INTG TrID| 558 +-+-+-+-+-+-+-+-+ 560 Figure 8: Compact Transform (Short Form: Integrity) 562 o Tag (3 bits) - MUST be 110. 564 o INTG TrID (5 bits) - Integrity Algorithm Transform ID. 566 0 1 2 3 4 5 6 7 567 +-+-+-+-+-+-+-+-+ 568 | Tag | PRF | 569 +-+-+-+-+-+-+-+-+ 571 Figure 9: Compact Transform (Short Form: PRF) 573 o Tag (4 bits) - MUST be 1110. 575 o PRF (4 bits) - Pseudo-random Function Transform ID. 577 0 1 2 3 4 5 6 7 578 +-+-+-+-+-+-+-+-+ 579 | Tag | ESN | 580 +-+-+-+-+-+-+-+-+ 582 Figure 10: Compact Transform (Short Form: ESN) 584 o Tag (5 bits) - MUST be 11110. 586 o ESN (3 bits) - Extended Sequence Numbers Transform ID. 588 Long form (Figure 11) is used when Transform doesn't meet 589 requirements for short form encoding, but still meets the following 590 requirements: 592 1. Transform Type is between 1 and 7. At the time this document was 593 written only Transform Types 1 to 5 were defined (see 594 [IKEV2-IANA]). 596 2. Transform has no attributes. 598 Long form allows to effectively encode Transform IDs for standard 599 Transform Types that don't fit into the short form, e.g. private 600 Transform IDs (if these transforms don't have associated attributes). 601 It is expected that new Transform IDs will be defined more often than 602 new Transform Types. So, defining effective encoding for standard 603 Transform Type and arbitrary Transform IDs makes sense. 605 1 2 606 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Tag |Type | Transform ID | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 Figure 11: Compact Transform (Long Form) 613 o Tag (5 bits) - MUST be 11111. 615 o Transform Type (3 bits) - The type of transform being specified in 616 this substructure. 618 o Transform ID (2 octets) - The specific instance of the Transform 619 Type being specified. 621 Full encoding of Compact Transform substructure allows encoding of 622 any transform without restrictions. It is used when transform cannot 623 be encoded neither in short form nor in long form. The format 624 (Figure 12) resembles regular Transform Substructure with all 625 RESERVED fields removed. The Compact Transform substructure fields 626 are briefly described below. Readers should refer to Section 3.3.2 627 of [RFC7296] for detailed description of Compact Transform 628 substructure fields with the same names, as in regular Transform 629 substructure. 631 1 2 3 632 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 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Tag |Transform Type | Transform Length | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | Transform ID | ~ 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 638 | | 639 ~ ~ 640 | | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 Figure 12: Compact Transform (Full Form) 645 o Tag (1 octet) - MUST be 11111000. 647 o Transform Type (1 octet) - The type of transform being specified 648 in this substructure. 650 o Transform Length (2 octets, unsigned integer) - The length in 651 octets of the Compact Transform Substructure including Header and 652 Attributes. 654 o Transform ID (2 octets) - The specific instance of the Transform 655 Type being specified. 657 o Transforms Attributes (variable) - Transform attributes. 659 4.3. Compact Notify Payload 661 Notify payloads containing status notifications with no data are 662 often used in IKEv2. This is "de facto" standard way to negotiate 663 various protocol extensions and for that reason usually several such 664 Notify payloads are present in initial IKEv2 exchanges. It is 665 anticipated that the number of IKEv2 extensions will increase and 666 thus the size of initial exchange messages will increase too. This 667 is the reason that this kind of Notify payload is encoded 668 specifically, to get more effective message compression. 670 As well as Compact SA payload, Compact Notify payload has its own 671 payload type. The Compact Notify payload is denoted CN, and its 672 payload type is . 674 1 675 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Next Payload | Notify Type | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 Figure 13: Compact Notify Payload for Status Notification 682 o Next Payload (1 octet) - Identifier for the payload type of the 683 next payload in the message. The value is taken intact from 684 original payload. 686 o Notify Type (1 octet) - The type of notification message minus 687 16384. 689 Despite the fact that Compact Notify payload has different payload 690 type and different format than regular Notify payload, the associated 691 semantics MUST be the same. 693 Notify payload can be encoded as Compact Notify payload if it meets 694 the following requirements (see Section 3.10 of [RFC7296] for Notify 695 payload format): 697 1. Notify Message Type is between 16384 and 16639 (inclusive). This 698 corresponds to status notifications. 700 2. Protocol ID is zero. 702 3. SPI Size is zero, meaning no SPI is present. 704 4. Notification Data is empty. 706 At the time this document was written about 40 percent of status 707 notifications defined in [IKEV2-IANA] met these requirements. If 708 Notify payload doesn't meet these requirements, the generic compact 709 format (Section 4.1) can be tried. 711 5. Compact Format Negotiation 713 Most IKEv2 extensions are negotiated in the following way. The 714 Initiator announces its support for some extension by including 715 corresponding Vendor ID payload or Notify payload containing status 716 notification in the request message of IKE_SA_INIT or IKE_AUTH 717 exchanges. If the Responder supports this extension it returns the 718 same (or some specific) payload to the Initiator in response message. 719 Responder that doesn't support compact format just ignores these 720 payloads in accordance with IKEv2 specification. 722 This method is inappropriate for negotiation of compact format, 723 because Initiator should be able to send an initial request message 724 in compact form and thus it must inform Responder somehow that the 725 message must be parsed differently than regular IKEv2 message. Since 726 compact message may contain regular IKEv2 payloads, it is possible to 727 define a new status notification and to include it without compacting 728 as the very first payload in the initial request. However, this 729 spoils the whole idea of reducing initial messages size, since this 730 payload will increase message size for no good reason. 732 Instead this document specifies a different negotiation mechanism. 733 An alternative initial exchange is defined, ALT_IKE_SA_INIT. 734 Initiator wishing to use compact representations of IKEv2 payloads 735 MUST start creating IKEv2 SA using ALT_IKE_SA_INIT exchange instead 736 of IKE_SA_INIT. The very first ALT_IKE_SA_INIT request may contain 737 compact payloads. If Responder receives ALT_IKE_SA_INIT request and 738 doesn't support compact format, then according to Section 2.21.1 of 739 [RFC7296] it discards the request. It may also send INVALID_SYNTAX 740 notification. For the Initiator receiving no response after several 741 retransmissions or receiving INVALID_SYNTAX notification is an 742 indication that the Responder doesn't support compact format. In 743 this case the Initiator MAY restart initial request using regular 744 IKE_SA_INIT request. 746 If the Responder supports compact format then it response with 747 ALT_IKE_SA_INIT response, confirming to the Initiator that using 748 compact format is successfully negotiated. Once using compact format 749 is negotiated, compact payloads may appear in any message of 750 subsequent exchanges in the context of the IKE SA being negotiated. 752 The semantics associated with ALT_IKE_SA_INIT exchange MUST be the 753 same, as the semantics associated with IKE_SA_INIT exchange. In 754 other words, when ALT_IKE_SA_INIT exchange is used, the endpoints 755 must behave exactly as if it is IKE_SA_INIT exchange. The only 756 difference (apart from different Exchange Types) is that IKE_SA_INIT 757 messages MUST NOT contain compact payloads, while ALT_IKE_SA_INIT MAY 758 contain them. 760 6. Interaction with other IKEv2 Extensions 762 To be added. 764 7. Security Considerations 766 To be added. 768 8. IANA Considerations 770 This document defines two new Payloads in the "IKEv2 Payload Types" 771 registry: 773 Compact SA Payload CSA 774 Compact Notify Payload CN 776 This document also defines new Exchange Type in the "IKEv2 Exchange 777 Types" registry: 779 ALT_IKE_SA_INIT 781 9. References 783 9.1. Normative References 785 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 786 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 787 RFC2119, March 1997, 788 . 790 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 791 Kivinen, "Internet Key Exchange Protocol Version 2 792 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, 793 October 2014, . 795 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 796 (IKEv2) Message Fragmentation", RFC 7383, DOI 10.17487/ 797 RFC7383, November 2014, 798 . 800 [IKEV2-IANA] 801 "Internet Key Exchange Version 2 (IKEv2) Parameters", 802 . 804 9.2. Informative References 806 [IPSEC-IOT-REQS] 807 Migault, D., Guggemos, T., and C. Bormann, "Requirements 808 for Diet-ESP the IPsec/ESP protocol for IoT", 809 draft-mglt-6lo-diet-esp-requirements-02 (work in 810 progress), July 2016. 812 Author's Address 814 Valery Smyslov 815 ELVIS-PLUS 816 PO Box 81 817 Moscow (Zelenograd) 124460 818 RU 820 Phone: +7 495 276 0211 821 Email: svan@elvis.ru