Internet DRAFT - draft-smyslov-ipsecme-ikev2-compact
draft-smyslov-ipsecme-ikev2-compact
Network Working Group V. Smyslov
Internet-Draft ELVIS-PLUS
Intended status: Standards Track September 17, 2021
Expires: March 21, 2022
Compact Format of IKEv2 Payloads
draft-smyslov-ipsecme-ikev2-compact-10
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 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 March 21, 2022.
Copyright Notice
Copyright (c) 2021 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
Smyslov Expires March 21, 2022 [Page 1]
Internet-Draft IKEv2 Compact September 2021
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 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
Smyslov Expires March 21, 2022 [Page 2]
Internet-Draft IKEv2 Compact September 2021
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 March 21, 2022 [Page 3]
Internet-Draft IKEv2 Compact September 2021
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 March 21, 2022 [Page 4]
Internet-Draft IKEv2 Compact September 2021
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ <Payload Data> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 March 21, 2022 [Page 5]
Internet-Draft IKEv2 Compact September 2021
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 | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
~ <Compacted Payload Data> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ <Extended Bitmap> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 March 21, 2022 [Page 6]
Internet-Draft IKEv2 Compact September 2021
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 March 21, 2022 [Page 7]
Internet-Draft IKEv2 Compact September 2021
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 more octets are 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 remaining bits of the current
temporary bitmap octet are zeroed.
4. If more octets are 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 <TBA by IANA>.
Smyslov Expires March 21, 2022 [Page 8]
Internet-Draft IKEv2 Compact September 2021
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 | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
~ <Compact 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 March 21, 2022 [Page 9]
Internet-Draft IKEv2 Compact September 2021
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 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 March 21, 2022 [Page 10]
Internet-Draft IKEv2 Compact September 2021
+----------+-----------------------+-----+-------+---------+--------+
| Tag | Compact Transform | Len | Trans | Trans | Format |
| | Format | | Types | IDs | |
+----------+-----------------------+-----+-------+---------+--------+
| 0tttvvvv | Short: Generic | 1 | 6-13 | 0-15 | Figure |
| | | | | | 5 |
| | | | | | |
| 100vvvvv | Short: Encryption (no | 1 | 1 | 11-42 | Figure |
| | Key Length attribute | | | | 6 |
| | or 128-bit key) | | | | |
| | | | | | |
| 101vvvvv | Short: Encryption | 1 | 1 | 11-42 | Figure |
| | (256-bit key) | | | | 6 |
| | | | | | |
| 110vvvvv | Short: Key Exchange | 1 | 4 | 0, | Figure |
| | Method | | | 14-44 | 7 |
| | | | | | |
| 1110vvvv | Short: PRF | 1 | 2 | 2-15 | Figure |
| | | | | | 8 |
| | | | | | |
| 1110000v | Short: ESN | 1 | 5 | 0-1 | 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.
Full format imposes no constraints on the Transform Type and
Transform ID, as well on the attributes the transform could contain.
Smyslov Expires March 21, 2022 [Page 11]
Internet-Draft IKEv2 Compact September 2021
Short formats allow 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.2.2.1. Generic Short Format
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|T| Type| ID |
+-+-+-+-+-+-+-+-+
Figure 5: Generic Short Format
o T(ag) (1 bit) - MUST be 0.
o Type (3 bits) - Transform Type minus 6. This allows Transform
Types from 6 to 13 to be encoded using this format.
o ID (4 bits) - Transform ID.
4.2.2.2. Short Format for Encryption
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Tag | ENCR ID |
+-+-+-+-+-+-+-+-+
Figure 6: Short Format for Encryption
o 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.
o ENCR ID (5 bits) - Encryption Algorithm Transform ID minus 11.
4.2.2.3. Short Format for Key Exchange Method
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Tag | KEM ID |
+-+-+-+-+-+-+-+-+
Figure 7: Short Format for Key Exchange Method
Smyslov Expires March 21, 2022 [Page 12]
Internet-Draft IKEv2 Compact September 2021
o Tag (3 bits) - MUST be 110.
o KEM ID (5 bits) - Key Exchange Method ID. Value 0 indicates NONE,
other values are treated as Key Exchange Method Transform ID minus
14.
4.2.2.4. Short Format for PRF
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Tag | PRFID |
+-+-+-+-+-+-+-+-+
Figure 8: Short Format for PRF
o Tag (4 bits) - MUST be 1110.
o PRFID (4 bits) - Pseudo-random Function Transform ID. This value
MUST never be 0 and 1.
4.2.2.5. Short Format for ESN
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Tag |E|
+-+-+-+-+-+-+-+-+
Figure 9: Short Format for ESN
o Tag (7 bits) - MUST be 1110000.
o E ( bit) - Extended Sequence Numbers Transform ID (either 0 or 1).
4.2.2.6. 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 March 21, 2022 [Page 13]
Internet-Draft IKEv2 Compact September 2021
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 the 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 the 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 March 21, 2022 [Page 14]
Internet-Draft IKEv2 Compact September 2021
4.2.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 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 | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
~ <Transform Attributes> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Full Format
o Tag (1 octet) - MUST be 11110000.
o Transform Type (1 octet) - The type of the 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 March 21, 2022 [Page 15]
Internet-Draft IKEv2 Compact September 2021
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 <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 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 March 21, 2022 [Page 16]
Internet-Draft IKEv2 Compact September 2021
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 March 21, 2022 [Page 17]
Internet-Draft IKEv2 Compact September 2021
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:
<TBA> Compact SA Payload CSA
<TBA> Compact Notify Payload CN
This document also defines a new Exchange Type in the "IKEv2 Exchange
Types" registry:
<TBA> 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,
<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>.
Smyslov Expires March 21, 2022 [Page 18]
Internet-Draft IKEv2 Compact September 2021
[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>.
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>.
[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",
<http://www.iana.org/assignments/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 March 21, 2022 [Page 19]
