Network Working Group V. Smyslov Internet-Draft ELVIS-PLUS Intended status: Standards Track 6 March 2023 Expires: 7 September 2023 Extended IKEv2 Payload Format draft-smyslov-ipsecme-ikev2-extended-pld-01 Abstract This document describes an extended payload format for the Internet Key Exchange protocol version 2 (IKEv2) messages. This format allows both to decrease an overhead many IKEv2 payloads have and to overcome the current 64 Kbytes limit on the maximum payload size. 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 https://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 7 September 2023. Copyright Notice Copyright (c) 2023 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 (https://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 include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Smyslov Expires 7 September 2023 [Page 1] Internet-Draft Extended IKEv2 Payload Format March 2023 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Making Payloads Smaller . . . . . . . . . . . . . . . . . 3 1.2. Lifting Payload Size Limitation . . . . . . . . . . . . . 4 1.3. Related Work . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Extended Generic Payload Header Format . . . . . . . . . . . 5 3.1. Generic Payload Header for Small Payloads . . . . . . . . 5 3.2. Generic Payload Header for Medium Size Payloads . . . . . 6 3.3. Generic Payload Header for Large Payloads . . . . . . . . 6 4. Specific Compact Payloads . . . . . . . . . . . . . . . . . . 7 4.1. Compact Key Exchange Payload . . . . . . . . . . . . . . 7 4.2. Compact Identification Payload . . . . . . . . . . . . . 7 4.3. Compact Authentication Payload . . . . . . . . . . . . . 8 4.4. Compact Traffic Selectors Payload . . . . . . . . . . . . 8 4.4.1. Compact Traffic Selector . . . . . . . . . . . . . . 8 4.4.2. Compact Configuration Payload . . . . . . . . . . . . 9 4.5. Compact SA Payload . . . . . . . . . . . . . . . . . . . 9 4.5.1. Compact Proposal Substructure . . . . . . . . . . . . 10 4.5.2. Compact Transform Substructure . . . . . . . . . . . 11 4.6. Compact Notify Payload . . . . . . . . . . . . . . . . . 17 5. Extended Format Use Negotiation . . . . . . . . . . . . . . . 18 5.1. Exchange of Status Type Notify Messages . . . . . . . . . 18 5.2. New Initial IKE Exchange . . . . . . . . . . . . . . . . 18 6. Interaction with other IKEv2 Extensions . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 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. The size of the messages typically varies from less than one hundred bytes to several kBytes. Smyslov Expires 7 September 2023 [Page 2] Internet-Draft Extended IKEv2 Payload Format March 2023 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. 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. In addition, new format allows payloads to contain more than 64 Kbytes of data. 1.1. Making Payloads Smaller 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 [I-D.mglt-6lo-diet-esp-requirements]). 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 at the 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 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. Smyslov Expires 7 September 2023 [Page 3] Internet-Draft Extended IKEv2 Payload Format March 2023 1.2. Lifting Payload Size Limitation In addition, the format of IKEv2 payloads defined in [RFC7296] has limitation on the maximum size of a single payload - 64 Kbytes (IKE message itself can be up to 2^32 bytes in length). This limitation was not an issue before because there was no need to transfer large chunks of data. However, this may become an issue with post-quantum algorithms. Some post-quantum key exchange methods, such as McEliece [McEliece], have public key size that exceeds 64 Kbytes. The McEliece cryptosystem withstood years of cryptanalysis since 1978 and still remains unbroken. A more efficient and CCA secure version of McEliece cryptosystem, Classic McEliece [Classic-McEliece], is selected as one of the finalists in NIST post-quantum standardization. Furthermore, this cryptosystem has also been recommended for long-term confidentiality protection of data, see [BSI]. Post-quantum key exchange methods can be used in IKEv2 as defined in [I-D.ietf-ipsecme-ikev2-multiple-ke]. With the introduction of TCP transport for IKEv2 [RFC9329], which allows transferring large amount of data, the limitation on the maximum payload size remains the only technical obstacle for using Classic McEliece (and other post-quantum algorithms with public keys greater than 64 Kbytes) in IKEv2. 1.3. Related Work Related proposals: 1. Compact Format of IKEv2 Payloads [I-D.smyslov-ipsecme-ikev2-compact] 2. Beyond 64KB Limit of IKEv2 Payload [I-D.tjhai-ikev2-beyond-64k-limit] 3. A Larger Internet Key Exchange version 2 (IKEv2) Payload [I-D.nir-ipsecme-big-payload] 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. Smyslov Expires 7 September 2023 [Page 4] Internet-Draft Extended IKEv2 Payload Format March 2023 3. Extended Generic Payload Header Format IKEv2 generic payload header format is defined in Section 3.2 of [RFC7296] and is provided below for convenience. 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: Current Generic Payload Header * Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. * Critical (1 bit) - Inidicates whether the payload is critical (see Section 3.2 of [RFC7296] for details) * Payload Length (2 octets, unsigned integer) - Length in octets of the current payload, including the generic payload header. This specification eliminates the RESERVED field and makes the size of the Payload Length field variable, so that depending on the payload size, three different Generic Payload Header formats are possible. 3.1. Generic Payload Header for Small Payloads If payload size is less than 64 octets, the following format can be used. 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C|0| Pld Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Generic Payload Header for Small Payloads * Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. * Critical (1 bit) - Inidicates whether the payload is critical (see Section 3.2 of [RFC7296] for details) * Pld Len (6 bits, unsigned integer) - Length in octets of the current payload, including the generic payload header. Smyslov Expires 7 September 2023 [Page 5] Internet-Draft Extended IKEv2 Payload Format March 2023 3.2. Generic Payload Header for Medium Size Payloads If payload size is less than 8192 octets, the following format can be used. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C|1|0| Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Generic Payload Header for Medium Size Payloads * Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. * Critical (1 bit) - Inidicates whether the payload is critical (see Section 3.2 of [RFC7296] for details) * Pld Len (13 bits, unsigned integer in network byte order) - Length in octets of the current payload, including the generic payload header. 3.3. Generic Payload Header for Large Payloads If payload size exceeds 8191 octets, the following format is used. Note, that in any case the payload size is limited to 512 Mbytes, which seems to be acceptable for the purposes of IKEv2. 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|1|1| Payload Length ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ | +-+-+-+-+-+-+-+-+ Figure 4: Generic Payload Header for Large Payloads * Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. * Critical (1 bit) - Inidicates whether the payload is critical (see Section 3.2 of [RFC7296] for details) * Pld Len (29 bits, unsigned integer in network byte order) - Length in octets of the current payload, including the generic payload header. Smyslov Expires 7 September 2023 [Page 6] Internet-Draft Extended IKEv2 Payload Format March 2023 4. Specific Compact Payloads To get more compact encoding the format of some payloads is redefined. In most cases the RESERVED fields are removed, however for two payloads, namely the Security Association payload and the Notify payload, more radical changes are made. 4.1. Compact Key Exchange Payload The Compact KE payload is denoted cKE, and its payload type is . 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | KE Method | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ~ Key Exchange Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Compact Key Exchange Payload The KE Method identifies the Key Exchange Method that was used for computing the Key Exchange Data. 4.2. Compact Identification Payload The Compact IDi payload is denoted cIDi, and its payload type is , and the Compact IDr payload is denoted cIDr, and its payload type is . 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID Type | | +-+-+-+-+-+-+-+-+ | | | ~ Identification Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Compact Identification Payload See Section 3.5 of [RFC7296] for the fields description. Smyslov Expires 7 September 2023 [Page 7] Internet-Draft Extended IKEv2 Payload Format March 2023 4.3. Compact Authentication Payload The Compact AUTH payload is denoted cAUTH, and its payload type is . 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth Method | | +-+-+-+-+-+-+-+-+ | | | ~ Authentication Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Compact Authentication Payload See Section 3.8 of [RFC7296] for the fields description. 4.4. Compact Traffic Selectors Payload The Compact TSi payload is denoted cTSi, and its payload type is , and the Compact TSr payload is denoted cTSr, and its payload type is . 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Compact Traffic Selectors Payload See Section 3.13 of [RFC7296] for the fields description. 4.4.1. Compact Traffic Selector Smyslov Expires 7 September 2023 [Page 8] Internet-Draft Extended IKEv2 Payload Format March 2023 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TS Type |IP Protocol ID*| Start Port* | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End Port* | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ Starting Address* ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ Ending Address* ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Compact Traffic Selector See Section 3.13.1 of [RFC7296] for the fields description. 4.4.2. Compact Configuration Payload The Compact CP payload is denoted cCP, and its payload type is . 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CFG Type | | +-+-+-+-+-+-+-+-+ | | | ~ Configuration Attributes ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: Compact Configuration Payload See Section 3.15 of [RFC7296] for the fields description. 4.5. Compact SA Payload SA payload is compacted differently than other compact payload. Not only RESERVED fields are removed, but the format of the Proposal and Transform substructures is completely changed. This approach allows achieving high level of compression. This is important for SA payload, because it grows up quickly as more and more cryptographic transforms are defined, get widespread adoption and advertised by initiators. Smyslov Expires 7 September 2023 [Page 9] Internet-Draft Extended IKEv2 Payload Format March 2023 The Compact SA payload is denoted cSA, and its payload type is . 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: Compact SA Payload * 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, its semantics remains the same. Regular SA payload can always be compacted if it is compliant with Section 3.3 of [RFC7296]. 4.5.1. Compact Proposal Substructure Compact Proposal substructure (Figure 12) 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. 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 12: Compact Proposal Substructure * Proposal Num (1 octet) - Proposal Number. * Protocol ID (1 octet) - Specifies the IPsec protocol identifier for the current negotiation. Smyslov Expires 7 September 2023 [Page 10] Internet-Draft Extended IKEv2 Payload Format March 2023 * SPI Size (1 octet) - Size of SPI. * Num Transforms (1 octet) - Specifies the number of transforms in this proposal. * SPI (variable) - The sending entity's SPI. * Compact Transforms (variable) - One or more compact transform substructures. 4.5.2. Compact Transform Substructure Compact Transform substructures are encoded differently depending on Transform Type, Transform ID and the 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 7 September 2023 [Page 11] Internet-Draft Extended IKEv2 Payload Format March 2023 +==========+===================+=======+=======+=========+========+ | Tag | Compact Transform | Len | Trans | Trans | Format | | | Format | | Types | IDs | | +==========+===================+=======+=======+=========+========+ | 0tttvvvv | Short: Generic | 1 | 13-20 | 0-15 | Figure | | | | | | | 13 | +----------+-------------------+-------+-------+---------+--------+ | 100vvvvv | Short: Encryption | 1 | 1 | 11-42 | Figure | | | (no Key Length | | | | 14 | | | attribute or | | | | | | | 128-bit key) | | | | | +----------+-------------------+-------+-------+---------+--------+ | 101vvvvv | Short: Encryption | 1 | 1 | 11-42 | Figure | | | (256-bit key) | | | | 14 | +----------+-------------------+-------+-------+---------+--------+ | 110vvvvv | Short: Key | 1 | 4 | 0, | Figure | | | Exchange Method | | | 14-44 | 15 | +----------+-------------------+-------+-------+---------+--------+ | 1110vvvv | Short: PRF | 1 | 2 | 2-15 | Figure | | | | | | | 16 | +----------+-------------------+-------+-------+---------+--------+ | 111110vv | Short: ESN | 1 | 5 | 0-3 | Figure | | | | | | | 17 | +----------+-------------------+-------+-------+---------+--------+ | 11110ttt | Long 1 | 2 | 1-31 | 0-63 | Figure | | ttvvvvvv | | | | | 18 | +----------+-------------------+-------+-------+---------+--------+ | 1111110t | Long 2 | 3 | 1-31 | 0-4095 | Figure | | ttttvvvv | | | | | 19 | | vvvvvvvv | | | | | | +----------+-------------------+-------+-------+---------+--------+ | 1111111t | Full | 5-512 | 1-255 | 0-65535 | Figure | | tttttttl | | | | | 20 | | llllllll | | | | | | | vvvvvvvv | | | | | | | vvvvvvvv | | | | | | +----------+-------------------+-------+-------+---------+--------+ Table 1: Tag values and corresponding Compact Transform formats Smyslov Expires 7 September 2023 [Page 12] Internet-Draft Extended IKEv2 Payload Format March 2023 Short format is the most efficient Compact Transform format, it occupies 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. Full format imposes no constraints on the Transform Type and Transform ID, as well on the attributes the transform could contain. Short format allows encoding both Transform Type and Transform ID using single octet. There are several variations of short format - 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. 4.5.2.1. Generic Short Format 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |T| Type| ID | +-+-+-+-+-+-+-+-+ Figure 13: Generic Short Format * T(ag) (1 bit) - MUST be 0. * Type (3 bits) - Transform Type minus 13. This allows Transform Types from 13 to 20 to be encoded using this format. * ID (4 bits) - Transform ID. 4.5.2.2. Short Format for Encryption 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Tag | ENCR ID | +-+-+-+-+-+-+-+-+ Figure 14: Short Format for Encryption Smyslov Expires 7 September 2023 [Page 13] Internet-Draft Extended IKEv2 Payload Format March 2023 * Tag (3 bits) - MUST be either 100 or 101. Tag value 100 indicates that either no Key Length attribute is present in the original Transform or it is present and its value is 128. Tag values 101 indicates that Key Length attribute containing value 256 is present in the original Transform. * ENCR ID (5 bits) - Encryption Algorithm Transform ID minus 11. 4.5.2.3. Short Format for Key Exchange Method 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Tag | KE ID | +-+-+-+-+-+-+-+-+ Figure 15: Short Format for Key Exchange Method * Tag (3 bits) - MUST be 110. * KE ID (5 bits) - Value 0 indicates NONE, other values are treated as Key Exchange Method Transform ID minus 14. 4.5.2.4. Short Format for PRF 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Tag | PRFID | +-+-+-+-+-+-+-+-+ Figure 16: Short Format for PRF * Tag (4 bits) - MUST be 1110. * PRFID (4 bits) - Pseudo-random Function Transform ID. This value MUST never be 0 and 1. 4.5.2.5. Short Format for ESN 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Tag | E | +-+-+-+-+-+-+-+-+ Figure 17: Short Format for ESN * Tag (6 bits) - MUST be 111110. Smyslov Expires 7 September 2023 [Page 14] Internet-Draft Extended IKEv2 Payload Format March 2023 * E (2 bits) - Extended Sequence Numbers Transform ID (either 0 or 1). 4.5.2.6. Long Format Long format (Figures 18 and 19) 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 31. At the time this document was written only Transform Types 1 to 12 were defined (see [IKEV2-IANA]). 2. Transform has no attributes. 3. Transform ID is less than or equal to 4095 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 4095). Long format can occupy two or three octets depending on the Transform ID value. For values 0-63 only one octet is used to represent the value, for values 64-4095 two octets are used. Values greater than 4095 require using full format. 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag | Type | Trans ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 18: Long Format 1 * Tag (5 bits) - MUST be 11110. * Type (5 bits) - The type of the transform being specified in this substructure. * Trans ID (6 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 | Transform ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Smyslov Expires 7 September 2023 [Page 15] Internet-Draft Extended IKEv2 Payload Format March 2023 Figure 19: Long Format 2 * Tag (7 bits) - MUST be 1111110. * Type (5 bits) - The type of the transform being specified in this substructure. * Transform ID (12 bits) - The specific instance of the Transform Type being specified. 4.5.2.7. 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 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 Len | Transform ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ID | | +-+-+-+-+-+-+-+-+ | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 20: Full Format * Tag (7 bits) - MUST be 1111111. * Transform Type (8 bits) - The type of the transform being specified in this substructure. * Transform Len (9 bits, unsigned integer) - The length in octets of the Compact Transform Substructure including Header and Attributes. * Transform ID (2 octets) - The specific instance of the Transform Type being specified. * Transforms Attributes (variable) - Transform attributes. Smyslov Expires 7 September 2023 [Page 16] Internet-Draft Extended IKEv2 Payload Format March 2023 4.6. Compact Notify Payload Notify payloads containing status notifications with no data are often used in IKEv2. This is a "de facto" standard way to negotiate various protocol extensions and for this 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 is the reason that this kind of Notify payload is encoded specifically, to get more effective message compression. 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 21: Compact Notify Payload for Status Notification * Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. The value is taken intact from original payload. * 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 remains 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. Smyslov Expires 7 September 2023 [Page 17] Internet-Draft Extended IKEv2 Payload Format March 2023 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 3.1) can be used. 5. Extended Format Use Negotiation There are two ways to negotiate the use of the extended payload format - either by exchanging status type notifications or by using a new initial IKE exchange type. 5.1. Exchange of Status Type Notify Messages If this functionality is not needed in the IKE_SA_INIT exchange (for example it will only be used to transfer large amount of data), then peers may use a traditional approach for negotiation of various IKE extensions - by exchanging status type notifications indicating the support for the extension. The initiator indicates its support for extended payload format by including a notification of type EXTENDED_PAYLOAD_FORMAT in the IKE_SA_INIT request message. If the responder also supports this format, it includes this notification in the response message. Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni, [N(EXTENDED_PAYLOAD_FORMAT)] --> <-- HDR, SAr1, KEr, Nr, [CERTREQ], [N(EXTENDED_PAYLOAD_FORMAT)] The EXTENDED_PAYLOAD_FORMAT is a Status Type IKEv2 notification. Its Notify Message Type is , Protocol ID and SPI Size are both set to 0. This specification doesn't define any data that this notification may contain, so the Notification Data is left empty. However, future enhancements to this specification may override this. Implementations MUST ignore non-empty Notification Data if they don't understand its purpose. 5.2. New Initial IKE Exchange This above method is inappropriate for negotiation if the initiator needs to send an initial request message in compact form and thus it must inform the responder somehow that the message must be parsed differently than regular IKEv2 message. Smyslov Expires 7 September 2023 [Page 18] Internet-Draft Extended IKEv2 Payload Format March 2023 For this purpose an alternative initial exchange is defined, X_IKE_SA_INIT. An initiator wishing to use compact representations of IKEv2 payloads starts creating IKEv2 SA using the X_IKE_SA_INIT exchange instead of IKE_SA_INIT. In this case even the very first X_IKE_SA_INIT request may contain extended payloads. If the responder receives the X_IKE_SA_INIT request and doesn't support extended 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 extended format. In this case the initiator MAY restart initial request using regular IKE_SA_INIT request if using the extended format was only an optimization. If the responder supports this specification then it response with the X_IKE_SA_INIT response, confirming to the initiator that using extended format is successfully negotiated. Once negotiated, payloads with extended format 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 the extended format is allowed MUST be inherited by the new SA from the old one. The semantics associated with the X_IKE_SA_INIT exchange MUST be the same, as the semantics associated with the IKE_SA_INIT exchange. In other words, when X_IKE_SA_INIT exchange is used, the endpoints must behave exactly as if it is the IKE_SA_INIT exchange. The only difference (apart from different Exchange Types) is that IKE_SA_INIT messages MUST NOT payloads in extended format, while X_IKE_SA_INIT MAY contain them. 6. Interaction with other IKEv2 Extensions When using extended payload format with IKEv2 Session Resumption [RFC5723], the flag indicating whether peers negotiated this format MUST be stored in the resumption ticket and used in an SA created as a result of resumption. 7. Security Considerations Extended payload 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 new Payloads in the "IKEv2 Payload Types" registry: Smyslov Expires 7 September 2023 [Page 19] Internet-Draft Extended IKEv2 Payload Format March 2023 Compact Key Exchange cKE Compact Identification - Initiator cIDi Compact Identification - Responder cIDr Compact Authentication cAUTH Compact Configuration cCP Compact Traffic Selectors - Initiator cTSi Compact Traffic Selectors - Responder cTSr Compact Security Association cSA Compact Notify cN This document also defines a new Exchange Type in the "IKEv2 Exchange Types" registry: X_IKE_SA_INIT This document also defines a new Notify Message Type in the "IKEv2 Notify Message Types - Status Types" registry: EXTENDED_PAYLOAD_FORMAT 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, . 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, . Smyslov Expires 7 September 2023 [Page 20] Internet-Draft Extended IKEv2 Payload Format March 2023 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation", RFC 7383, DOI 10.17487/RFC7383, November 2014, . [RFC9329] Pauly, T. and V. Smyslov, "TCP Encapsulation of Internet Key Exchange Protocol (IKE) and IPsec Packets", RFC 9329, DOI 10.17487/RFC9329, November 2022, . [I-D.mglt-6lo-diet-esp-requirements] Migault, D., Guggemos, T., and C. Bormann, "Requirements for Diet-ESP the IPsec/ESP protocol for IoT", Work in Progress, Internet-Draft, draft-mglt-6lo-diet-esp- requirements-02, 8 July 2016, . [I-D.ietf-ipsecme-ikev2-multiple-ke] Tjhai, C., Tomlinson, M., Bartlett, G., Fluhrer, S., Van Geest, D., Garcia-Morchon, O., and V. Smyslov, "Multiple Key Exchanges in IKEv2", Work in Progress, Internet-Draft, draft-ietf-ipsecme-ikev2-multiple-ke-12, 1 December 2022, . [I-D.smyslov-ipsecme-ikev2-compact] Smyslov, V., "Compact Format of IKEv2 Payloads", Work in Progress, Internet-Draft, draft-smyslov-ipsecme-ikev2- compact-10, 17 September 2021, . [I-D.tjhai-ikev2-beyond-64k-limit] Tjhai, C., Heider, T., and V. Smyslov, "Beyond 64KB Limit of IKEv2 Payloads", Work in Progress, Internet-Draft, draft-tjhai-ikev2-beyond-64k-limit-03, 28 July 2022, . [I-D.nir-ipsecme-big-payload] Nir, Y., "A Larger Internet Key Exchange version 2 (IKEv2) Payload", Work in Progress, Internet-Draft, draft-nir- ipsecme-big-payload-01, 28 January 2023, . Smyslov Expires 7 September 2023 [Page 21] Internet-Draft Extended IKEv2 Payload Format March 2023 [McEliece] McEliece, R. J., "A Public-key Cryptosystem based on Algebraic Coding Theory", DSN Progress Report 42-44, 1978. [Classic-McEliece] Classic McEliece submission team, "Classic McEliece: NIST post-quantum cryptography standardization finalist", 2020, . [BSI] Federal Office for Information Security, "Cryptographic Mechanisms: Recommendations and Key Lengths", 2020, . [IKEV2-IANA] "Internet Key Exchange Version 2 (IKEv2) Parameters", . Author's Address Valery Smyslov ELVIS-PLUS PO Box 81 Moscow (Zelenograd) 124460 Russian Federation Phone: +7 495 276 0211 Email: svan@elvis.ru Smyslov Expires 7 September 2023 [Page 22]