Internet DRAFT - draft-smyslov-ipsecme-ikev2-extended-pld
draft-smyslov-ipsecme-ikev2-extended-pld
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 <TBA
by IANA>.
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 <TBA
by IANA>, and the Compact IDr payload is denoted cIDr, and its
payload type is <TBA by IANA>.
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
<TBA by IANA>.
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 <TBA
by IANA>, and the Compact TSr payload is denoted cTSr, and its
payload type is <TBA by IANA>.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ <Traffic Selectors> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 <TBA
by IANA>.
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 <TBA
by IANA>.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ <Compact Proposals> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ <Compact Transforms> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | |
+-+-+-+-+-+-+-+-+ |
~ <Transform Attributes> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
<TBA by IANA>.
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 <TBA by IANA >, 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
<TBA> Compact Key Exchange cKE
<TBA> Compact Identification - Initiator cIDi
<TBA> Compact Identification - Responder cIDr
<TBA> Compact Authentication cAUTH
<TBA> Compact Configuration cCP
<TBA> Compact Traffic Selectors - Initiator cTSi
<TBA> Compact Traffic Selectors - Responder cTSr
<TBA> Compact Security Association cSA
<TBA> Compact Notify cN
This document also defines a new Exchange Type in the "IKEv2 Exchange
Types" registry:
<TBA> X_IKE_SA_INIT
This document also defines a new Notify Message Type in the "IKEv2
Notify Message Types - Status Types" registry:
<TBA> 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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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, <https://www.rfc-editor.org/info/rfc7296>.
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,
<https://www.rfc-editor.org/info/rfc5723>.
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,
<https://www.rfc-editor.org/info/rfc7383>.
[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,
<https://www.rfc-editor.org/info/rfc9329>.
[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,
<https://datatracker.ietf.org/doc/html/draft-mglt-6lo-
diet-esp-requirements-02>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-
ikev2-multiple-ke-12>.
[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,
<https://datatracker.ietf.org/doc/html/draft-smyslov-
ipsecme-ikev2-compact-10>.
[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,
<https://datatracker.ietf.org/doc/html/draft-tjhai-ikev2-
beyond-64k-limit-03>.
[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,
<https://datatracker.ietf.org/doc/html/draft-nir-ipsecme-
big-payload-01>.
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,
<https://classic.mceliece.org/>.
[BSI] Federal Office for Information Security, "Cryptographic
Mechanisms: Recommendations and Key Lengths", 2020, <https
://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publication
s/TechGuidelines/TG02102/BSI-TR-02102-1.pdf>.
[IKEV2-IANA]
"Internet Key Exchange Version 2 (IKEv2) Parameters",
<http://www.iana.org/assignments/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]
