Network Working Group V. Smyslov Internet-Draft ELVIS-PLUS Intended status: Standards Track April 2, 2018 Expires: October 4, 2018 Compact Format of IKEv2 Payloads draft-smyslov-ipsecme-ikev2-compact-03 Abstract This document describes a method for reducing the size of the Internet Key Exchange version 2 (IKEv2) messages by using an alternative format for IKE payloads. Standard format of many IKE payloads contains a lot of redundancy. This document takes advantage of this fact and specifies a way to eliminate some redundancy by using denser encoding. Reducing size of IKEv2 messages is desirable for low power consumption battery powered devices. It also helps to avoid IP fragmentation of IKEv2 messages. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 4, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Smyslov Expires October 4, 2018 [Page 1] Internet-Draft IKEv2 Compact April 2018 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Compact Representation of IKEv2 Payloads . . . . . . . . . . 4 4.1. Compact Generic Payload . . . . . . . . . . . . . . . . . 5 4.2. Compact SA Payload . . . . . . . . . . . . . . . . . . . 8 4.2.1. Compact Proposal Substructure . . . . . . . . . . . . 9 4.2.2. Compact Transform Substructures . . . . . . . . . . . 10 4.3. Compact Notify Payload . . . . . . . . . . . . . . . . . 15 5. Compact Format Negotiation . . . . . . . . . . . . . . . . . 17 6. Interaction with other IKEv2 Extensions . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction The Internet Key Exchange protocol version 2 (IKEv2) specified in [RFC7296] is used in the IP Security (IPsec) architecture for the purposes of Security Association (SA) parameters negotiation and authenticated key exchange. The protocol uses UDP as the transport for its messages, which size varies from less than one hundred bytes to several kBytes. Decreasing the size of IKEv2 messages is highly desirable for the Internet of Things (IoT) devices utilizing lower power consumption technology. For some of such devices the power consumption for transmitting extra bits over network is prohibitively high (see appendix A of [IPSEC-IOT-REQS]). Many such devices are battery powered without an ability to recharge or to replace the battery which serves for the life cycle of the device (often several years). For this reason the task of reducing the power consumption for such devices is very important and decreasing messages size is one of the ways to accomplish it. Large UDP messages may also cause fragmentation on IP level, which may interact badly with Network Address Translators (NAT). In particular, some NATs drop IP fragments that don't contain TCP/UDP port numbers (non-initial IP fragments), so that the IP datagram Smyslov Expires October 4, 2018 [Page 2] Internet-Draft IKEv2 Compact April 2018 cannot be reassembled on the receiving end and IKE SA cannot be established. One of the possible solutions to the problem is IKEv2 fragmentation [RFC7383]. However, the IKEv2 fragmentation can only be applied to encrypted messages and thus cannot be used in the initial IKEv2 exchange, IKE_SA_INIT. Usually the IKE_SA_INIT messages are relatively small and don't cause IP fragmentation. However, while more and more new algorithms and protocol extensions are included in IKEv2, these messages become larger and larger thus increasing the risk of IP fragmentation. It is desirable to make IKEv2 messages more compact to help avoid this risk. IKEv2 messages are comprised of data structures called payloads. Each payload consists of a common part (Generic Payload Header) followed by a payload-specific data which is formatted differently depending on the payload's purpose. Section 3 of [RFC7296] lists formats for all standard IKEv2 payloads. As one can see some IKEv2 payloads are formatted in such a way, that there are substantial redundancy in their encoding. This document defines an alternative format for the IKEv2 payloads, which provides denser encoding, that allows making IKEv2 messages more compact. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Overview The idea behind the protocol is to develop an alternative compact encoding of IKEv2 payloads that meets the following requirements: 1. The compact encoding must be applicable to all already defined IKEv2 payloads as well as to future payloads, so it must not depend on payload format. There may be few special cases if specific encoding is justified by much higher efficiency. 2. The compact encoding must be easily converted to standard encoding and vice versa. This allows implementations to re-use existing composing/parsing code and to apply compact encoding/ decoding as pre/post process steps in message processing. 3. The compact encoding/decoding algorithm must consume low resources in terms of code size, CPU consumption and memory footprint. Smyslov Expires October 4, 2018 [Page 3] Internet-Draft IKEv2 Compact April 2018 4. The compact encoding must never increase the payload size and must be effective enough to noticeably decrease the size of most payloads. To meet these requirements the encoding algorithm must be independent from the particular payload format. In other words, it must take any given payload and perform some kind of compression. General purpose lossless compression algorithms are usually not very effective when they are applied to small amount of data. Fortunately format of many IKEv2 payloads has a peculiarity that allows using simple and relatively efficient compression algorithm. Many IKEv2 payloads contain a lot of zero octets. These octets come from the following sources: o Many Payload Headers contain RESERVED fields that must be zeroed according to IKEv2 specification. o Payload length is encoded in two octets, while most IKEv2 payloads are less than 256 octets in size. o Substantial number of IKEv2 parameters is encoded in two octets, while the number of currently defined values for these parameters is less than one hundred (see [IKEV2-IANA]). The idea is to omit these zero octets from the compact payload and supply a bitmap that will indicate which octets were omitted. IKEv2 header also contains some redundancy - in particular the Length field occupies four octets, while IKEv2 messages are extremely unlikely to exceed few Kb in size. However, some middleboxes perform an inspection of IKEv2 header and changing its format will likely interact badly with these middleboxes. Thus, the possible saving of few octets doesn't justify modification of IKEv2 header. 4. Compact Representation of IKEv2 Payloads This document defines one generic compact format suitable for compacting any IKEv2 payload and two specific compact formats - one for SA payload and the other for Notify payload containing status notification with no data. The rationale for such a design is the following. One common generic compact format simplifies implementations and allows using it with any currently defined and not yet defined payloads. However, it doesn't provide high level of efficiency. Smyslov Expires October 4, 2018 [Page 4] Internet-Draft IKEv2 Compact April 2018 SA payload contains a lot of redundancy and can be encoded in highly efficient way. Moreover, this payload grows up quickly once more new transforms are defined and implementations start using them. In some cases the SA payload can be the largest payload in the IKE_SA_INIT exchange. So, there is a natural desire to encode it differently to gain better result. On the other hand, Notify payload with status notification containing no data is often used in IKEv2 initial exchange to negotiate support for various protocol extensions. So, there are usually several such payloads in the IKE_SA_INIT request and response messages, ant it is anticipated that their number will increase as long as more and more IKEv2 extensions are defined. That's why this payload is also encoded differently to make initial messages more compact. 4.1. Compact Generic Payload Generic IKEv2 payload is depicted below (Figure 1) for convenience. It consists of generic payload header followed by payload data. Brief description of generic payload header fields is provided below, readers should refer to Section 3.2 of [RFC7296] for full description. 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Generic Payload o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. o Critical (1 bit) - This bit is set if the current payload cannot be skipped in case the receiver doesn't understand its type and cleared if it is safe to skip this payload. o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on receipt. o Payload Length (2 octets, unsigned integer) - Length in octets of the current payload, including the generic payload header. o Payload Data (variable) - Contains payload specific data. Smyslov Expires October 4, 2018 [Page 5] Internet-Draft IKEv2 Compact April 2018 Some payloads have extended headers following the generic payload header. For the purpose of compact payload encoding any extended header is treated as part of payload data. Complete description of IKEv2 Payload formats can be found in Section 3 of [RFC7296]. Figure 2 shows generic compact payload format. 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| Bmap | XBL |Payload Length | ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Compact Generic Payload o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. The value is taken intact from original payload. o Critical (1 bit) - This bit is set if the current payload cannot be skipped in case the receiver doesn't understand its type and cleared if it is safe to skip this payload. The value is taken intact from original payload. o Bmap (4 bits) - Bitmap, contains bitmap where each bit indicates whether one of the four first octets of original Payload Data was zero and thus was omitted from Compacted Payload Data. If the bit is set, then the corresponding octet was zero and was omitted, if the bit is cleared, then either the corresponding octet was copied or it didn't present in the original Payload Data (in case the octet would be outside the original payload). The rightmost bit of the map corresponds to the first of the four octets and the leftmost bit corresponds to the last of these four octets. o XBL (3 bits) - Extended Bitmap Length, specifies the number of Extended Bitmap octets plus one. Note, that by construction this field cannot be zero. o Payload Length (1 octet) - Length in octets of compacted payload not including Extended Bitmap. Smyslov Expires October 4, 2018 [Page 6] Internet-Draft IKEv2 Compact April 2018 o Compacted Payload Data (variable) - Contains original payload data with some zero octets omitted. Up to 52 zero octets from the beginning of original payload data can be omitted, the rest of original payload data is always copied. o Extended Bitmap (variable, 0 - 6 octets) - contains extended bitmap. Each octet of this bitmap represents how the corresponding eight octets of the original payload data were handled - original octets corresponding to the set bits were zero and thus were omitted from the compacted payload data, while octets corresponding to the cleared bits were copied. First octet in the Extended Bitmap corresponds to octets from 5 to 12 of the original payload data, next octet - to octets from 13 to 20, etc. Note, that the Bmap field indicates how octets from 1 to 4 were handled. In each octet of extended bitmap the rightmost bit represents the first of corresponding original octets and the leftmost bit represents the last one. An IKEv2 payload can be compacted if it meets two requirements: o The payload length is less than 256 octets. In other words, the high order octet of Payload Length field is zero. o The RESERVED field in the generic payload header is zero. Section 3.2 of [RFC7296] requires that this field must always be zero when preparing payload. If payload doesn't meet these requirement it is included into the message without modification. The regular and compact payloads can be present in any order in the compact IKEv2 message. The receiving side can distinguish between them by analyzing the least significant three bits of RESERVED field in generic payload header. These bits correspond to XBL field in compact generic payload header, and this field will always be non-zero in compact payload while these bits are required to be zero in regular payload. If payload meets the above requirements then it is compacted as follows. 1. The Next Payload and Critical fields are copied from original payload. 2. The first 4 octets of the original payload data are scanned one by one. If the current octet is zero, then it is omitted from the Compacted Payload data and the corresponding bit (starting from the rightmost bit to the leftmost bit) in Bmap field is set. Otherwise the octet is copied and the corresponding bit is Smyslov Expires October 4, 2018 [Page 7] Internet-Draft IKEv2 Compact April 2018 cleared. If there are no more octets in the original payload data then the process stops and the rest of Bmap is zeroed. 3. If any more octets left in the original payload data, then the next 48 of them are scanned one by one. Since the Extended Bitmap position isn't known yet a temporary bitmap of six octets is used. If the current octet is zero, then it is omitted from the Compacted Payload Data and the corresponding bit (starting from the rightmost bit to the leftmost bit) in the corresponding octet of a temporary bitmap is set. Otherwise the original octet is copied and the corresponding bit in temporary bitmap is cleared. If there are no more octets in the original payload data then the process stops and the rest bits of the current temporary bitmap octet are zeroed. 4. If any more octets left in the original payload data, they are copied to the Compacted Payload Data. 5. The Payload Length field is set to indicate the size of Compacted Payload Data plus 3. It will indicate the offset of the Extended Bitmap from the beginning of compact payload. 6. The content of the temporary bitmap is copied to the Extended Bitmap field (after the Compacted Payload Data). The temporary bitmap octets are copied one by one up to the first zero octet (if any). In other words, the Extended Bitmap MUST NOT contain zero octets. 7. The XBL field is set to the number of octets placed in the Extended Bitmap plus one. 4.2. Compact SA Payload SA payload is compacted differently than generic IKEv2 payload. The specific format for Compact SA payload allows achieving very high level of compression. High level of compression is important, because SA payload grows up quickly as more and more cryptographic transforms are defined, get widespread adoption and advertised by Initiators. Unlike generic compact payload, which retains its payload type and is distinguished from regular IKEv2 payload by analyzing the leftmost three bits of RESERVED field of the generic payload header, the Compact SA payload has its own payload type. The reason is that its format (Figure 3) is completely different and the above method cannot be used. The Compact SA payload is denoted CSA, and its payload type is . Smyslov Expires October 4, 2018 [Page 8] Internet-Draft IKEv2 Compact April 2018 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload | Num Proposals | ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Compact SA Payload o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. The value is taken intact from original payload. o Num Proposals (1 octet) - Specifies the number of Compact Proposals in this SA payload. o Compact Proposals (variable) - One or more compact proposal substructures. Despite the fact that Compact SA payload has different payload type and different format than regular SA payload, the associated semantics MUST be the same. Regular SA payload can always be compacted if it is compliant with Section 3.3 of [RFC7296]. 4.2.1. Compact Proposal Substructure Compact Proposal substructure (Figure 4) resembles regular Proposal substructure lacking first four octets. The Compact Proposal substructure fields are briefly described below. Readers should refer to Section 3.3.1 of [RFC7296] for detailed description of Compact Proposal substructure fields with the same names, as in regular Proposal substructure. Smyslov Expires October 4, 2018 [Page 9] Internet-Draft IKEv2 Compact April 2018 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Proposal Num | Protocol ID | SPI Size |Num Transforms| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SPI (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Compact Proposal Substructure o Proposal Num (1 octet) - Proposal Number. o Protocol ID (1 octet) - Specifies the IPsec protocol identifier for the current negotiation. o SPI Size (1 octet) - Size of SPI. o Num Transforms (1 octet) - Specifies the number of transforms in this proposal. o SPI (variable) - The sending entity's SPI. o Compact Transforms (variable) - One or more compact transform substructures. 4.2.2. Compact Transform Substructures Compact Transform substructures are encoded differently depending on Transform Type, Transform ID and presence of attributes to get most effective encoding for common use cases. The leftmost bits of the first octet of the Compact Transform substructure are used to distinguish between different formats. These bits are called Tag. The table below shows how Tag value correlates with Compact Transform substructure format. Smyslov Expires October 4, 2018 [Page 10] Internet-Draft IKEv2 Compact April 2018 +----------+--------------------+-----+----------+---------+--------+ | Tag | Compact Transform | Len | Trans | Trans | Format | | | Format | | Types | IDs | | +----------+--------------------+-----+----------+---------+--------+ | 00tttvvv | Short: Generic | 1 | 5-12 | 0-7 | Figure | | | | | | | 5 | | | | | | | | | 010vvvvv | Short: Encryption | 1 | 1 | 11-42 | Figure | | | | | | | 6 | | | | | | | | | 011vvvvv | Short: Encryption | 1 | 1 | 11-42 | Figure | | | (128-bit key) | | | | 6 | | | | | | | | | 100vvvvv | Short: Encryption | 1 | 1 | 11-42 | Figure | | | (256-bit key) | | | | 6 | | | | | | | | | 101vvvvv | Short: Diffie- | 1 | 4 | 14-45 | Figure | | | Hellman Group | | | | 7 | | | | | | | | | 110vvvvv | Short: Integrity | 1 | 3 | 2-33 | Figure | | | | | | | 8 | | | | | | | | | 1110vvvv | Short: PRF | 1 | 2 | 2-17 | Figure | | | | | | | 9 | | | | | | | | | 1111tttt | Long 1 | 2 | 1-15 | 0-127 | Figure | | | | | | | 10 | | | | | | | | | 1111tttt | Long 2 | 3 | 1-15 | 0-32767 | Figure | | | | | | | 11 | | | | | | | | | 11110000 | Full | 6+ | 0-255 | 0-65535 | Figure | | | | | | | 12 | +----------+--------------------+-----+----------+---------+--------+ Table 1: Tag values and corresponding Compact Transform formats Short formats are the most efficient Compact Transform formats, they occupy only one octet; long format occupies either two or three octets depending on the Transform ID value. Both short and long formats can be used only for some Transform Types and can represent only limited number of Transform IDs. Moreover, both short and long formats cannot be used if Transform contains any attributes, except if it is the Encryption Transform and it contains the Key Length attribute and the value of the attribute is either 128 or 256. The Table 1 summarizes the restrictions each format implies. Smyslov Expires October 4, 2018 [Page 11] Internet-Draft IKEv2 Compact April 2018 Full format imposes no constraints on the Transform Type and Transform ID, as well on the attributes the transform could contain. 4.2.2.1. Short Format Short format allows encoding both Transform Type and Transform ID using single octet. It has several variations - a generic short format and a number of specific formats for different Transform Types that take advantage of the concrete Transform IDs defined in [IKEV2-IANA] for these Transform Types. Figures 5-9 show short format encodings for different Transform Types. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Tag|Type | ID | +-+-+-+-+-+-+-+-+ Figure 5: Generic Short Format o Tag (2 bits) - MUST be 00. o Type (3 bits) - Transform Type minus 5. This allows Transform Types from 5 to 12 to be encoded using this format. o ID (3 bits) - Transform ID. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Tag | ENCR ID | +-+-+-+-+-+-+-+-+ Figure 6: Short Format for Encryption o Tag (3 bits) - MUST be either 010 or 011 or 100. Tag value 010 indicates that no Key Length attribute is present in the original Transform. Tag values 011 and 100 indicate that Key Length attribute containing value 128 (tag 011) or 256 (tag 100) is present in the original Transform. o ENCR ID (5 bits) - Encryption Algorithm Transform ID minus 11. Smyslov Expires October 4, 2018 [Page 12] Internet-Draft IKEv2 Compact April 2018 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Tag | GRP ID | +-+-+-+-+-+-+-+-+ Figure 7: Short Format for Diffie-Hellman Group o Tag (3 bits) - MUST be 101. o GRP ID (5 bits) - Diffie-Hellman Group Transform ID minus 14. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Tag | INTG ID | +-+-+-+-+-+-+-+-+ Figure 8: Short Format for Integrity o Tag (3 bits) - MUST be 110. o INTG ID (5 bits) - Integrity Algorithm Transform ID minus 2. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Tag | PRFID | +-+-+-+-+-+-+-+-+ Figure 9: Short Format for PRF o Tag (4 bits) - MUST be 1110. o PRFID (4 bits) - Pseudo-random Function Transform ID minus 2. 4.2.2.2. Long Format Long format (Figures 10 and 11) is used when Transform doesn't meet requirements for short format encoding, but still meets the following requirements: 1. Transform Type is between 1 and 15. At the time this document was written only Transform Types 1 to 5 were defined (see [IKEV2-IANA]). 2. Transform has no attributes. 3. Transform ID is less than or equal to 32767. Smyslov Expires October 4, 2018 [Page 13] Internet-Draft IKEv2 Compact April 2018 Long format allows to effectively encode Transform IDs for Transform Types that don't fit into the short format, e.g. private Transform IDs (if these transforms don't have associated attributes and its value is less than or equal to 32767). Long format can occupy two or three octets depending on the Transform ID value. For values 0-127 only one octet is used to represent the value, for values 128-32767 two octets are used. Values greater than 32767 require using full format. 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag | Type |L| Trans ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: Long Format 1 o Tag (4 bits) - MUST be 1111. o Type (4 bits) - The type of transform being specified in this substructure. This field is always non-zero, since Transform Type 0 is marked as Reserved in [IKEV2-IANA]. o L (1 bit) - MUST be 0. o Trans ID (7 bits) - The specific instance of the Transform Type being specified. 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag | Type |L| Transform ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: Long Format 2 o Tag (4 bits) - MUST be 1111. o Type (4 bits) - The type of transform being specified in this substructure. This field is always non-zero, since Transform Type 0 is marked as Reserved in [IKEV2-IANA]. o L (1 bit) - MUST be 1. o Transform ID (15 bits) - The specific instance of the Transform Type being specified. Smyslov Expires October 4, 2018 [Page 14] Internet-Draft IKEv2 Compact April 2018 4.2.2.3. Full Format Full format of Compact Transform substructure allows encoding of any transform without restrictions. It is used when transform cannot be encoded neither in short format nor in long format. The format (Figure 12) resembles regular Transform Substructure with all RESERVED fields removed. The Compact Transform substructure fields are briefly described below. Readers should refer to Section 3.3.2 of [RFC7296] for detailed description of Compact Transform substructure fields with the same names, as in regular Transform substructure. 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag |Transform Type | Transform Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transform ID | ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: Full Format o Tag (1 octet) - MUST be 11110000. o Transform Type (1 octet) - The type of transform being specified in this substructure. o Transform Length (2 octets, unsigned integer) - The length in octets of the Compact Transform Substructure including Header and Attributes. o Transform ID (2 octets) - The specific instance of the Transform Type being specified. o Transforms Attributes (variable) - Transform attributes. 4.3. Compact Notify Payload Notify payloads containing status notifications with no data are often used in IKEv2. This is "de facto" standard way to negotiate various protocol extensions and for that reason usually several such Notify payloads are present in initial IKEv2 exchanges. It is anticipated that the number of IKEv2 extensions will increase and thus the size of initial exchange messages will increase too. This Smyslov Expires October 4, 2018 [Page 15] Internet-Draft IKEv2 Compact April 2018 is the reason that this kind of Notify payload is encoded specifically, to get more effective message compression. As well as Compact SA payload, Compact Notify payload has its own payload type. The Compact Notify payload is denoted CN, and its payload type is . 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload | Notify Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: Compact Notify Payload for Status Notification o Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. The value is taken intact from original payload. o Notify Type (1 octet) - The type of notification message minus 16384. Despite the fact that Compact Notify payload has different payload type and different format than regular Notify payload, the associated semantics MUST be the same. Notify payload can be encoded as Compact Notify payload if it meets the following requirements (see Section 3.10 of [RFC7296] for Notify payload format): 1. Notify Message Type is between 16384 and 16639 (inclusive). This corresponds to status notifications. 2. Protocol ID is zero. 3. SPI Size is zero, meaning no SPI is present. 4. Notification Data is empty. At the time this document was written about 40 percent of status notifications defined in [IKEV2-IANA] met these requirements. If Notify payload doesn't meet these requirements, the generic compact format (Section 4.1) can be tried. Smyslov Expires October 4, 2018 [Page 16] Internet-Draft IKEv2 Compact April 2018 5. Compact Format Negotiation Most IKEv2 extensions are negotiated in the following way. The Initiator announces its support for some extension by including corresponding Vendor ID payload or Notify payload containing status notification in the request message of IKE_SA_INIT or IKE_AUTH exchanges. If the Responder supports this extension it returns the same (or some specific) payload to the Initiator in response message. Responder that doesn't support compact format just ignores these payloads in accordance with IKEv2 specification. This method is inappropriate for negotiation of compact format, because Initiator should be able to send an initial request message in compact form and thus it must inform Responder somehow that the message must be parsed differently than regular IKEv2 message. Since compact message may contain regular IKEv2 payloads, it is possible to define a new status notification and to include it without compacting as the very first payload in the initial request. However, this spoils the whole idea of reducing initial messages size, since this payload will increase message size for no good reason. Instead this document specifies a different negotiation mechanism. An alternative initial exchange is defined, ALT_IKE_SA_INIT. Initiator wishing to use compact representations of IKEv2 payloads MUST start creating IKEv2 SA using ALT_IKE_SA_INIT exchange instead of IKE_SA_INIT. The very first ALT_IKE_SA_INIT request may contain compact payloads. If Responder receives ALT_IKE_SA_INIT request and doesn't support compact format, then according to Section 2.21.1 of [RFC7296] it discards the request. It may also send INVALID_SYNTAX notification. For the Initiator receiving no response after several retransmissions or receiving INVALID_SYNTAX notification is an indication that the Responder doesn't support compact format. In this case the Initiator MAY restart initial request using regular IKE_SA_INIT request. If the Responder supports compact format then it response with ALT_IKE_SA_INIT response, confirming to the Initiator that using compact format is successfully negotiated. Once using compact format is negotiated, compact payloads may appear in any message of subsequent exchanges in the context of the IKE SA being negotiated. If IKE SA is rekeyed, then the flag whether compact format is allowed MUST be inherited by the new SA from the old one. The semantics associated with ALT_IKE_SA_INIT exchange MUST be the same, as the semantics associated with IKE_SA_INIT exchange. In other words, when ALT_IKE_SA_INIT exchange is used, the endpoints must behave exactly as if it is IKE_SA_INIT exchange. The only difference (apart from different Exchange Types) is that IKE_SA_INIT Smyslov Expires October 4, 2018 [Page 17] Internet-Draft IKEv2 Compact April 2018 messages MUST NOT contain compact payloads, while ALT_IKE_SA_INIT MAY contain them. 6. Interaction with other IKEv2 Extensions When using compact encoding with IKEv2 Session Resumption [RFC5723], the flag indicating whether peers negotiated compact format MUST be stored in the resumption ticket and used in an SA created as a result of resumption. 7. Security Considerations Compact format of IKEv2 payloads doesn't change security properties of the protocol, which are described in Section 5 of [RFC7296]. 8. IANA Considerations This document defines two new Payloads in the "IKEv2 Payload Types" registry: Compact SA Payload CSA Compact Notify Payload CN This document also defines a new Exchange Type in the "IKEv2 Exchange Types" registry: ALT_IKE_SA_INIT 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, . Smyslov Expires October 4, 2018 [Page 18] Internet-Draft IKEv2 Compact April 2018 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation", RFC 7383, DOI 10.17487/RFC7383, November 2014, . 9.2. Informative References [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, DOI 10.17487/RFC5723, January 2010, . [IPSEC-IOT-REQS] Migault, D., Guggemos, T., and C. Bormann, "Requirements for Diet-ESP the IPsec/ESP protocol for IoT", draft-mglt- 6lo-diet-esp-requirements-02 (work in progress), July 2016. [IKEV2-IANA] "Internet Key Exchange Version 2 (IKEv2) Parameters", . Author's Address Valery Smyslov ELVIS-PLUS PO Box 81 Moscow (Zelenograd) 124460 RU Phone: +7 495 276 0211 Email: svan@elvis.ru Smyslov Expires October 4, 2018 [Page 19]