Network Working Group V. Smyslov
Internet-Draft ELVIS-PLUS
Intended status: Standards Track October 7, 2016
Expires: April 10, 2017
Compact Format of IKEv2 Payloads
draft-smyslov-ipsecme-ikev2-compact-00
Abstract
This document describes a method for reducing the size of the
Internet Key Exchange version 2 (IKEv2) messages by using an
alternate 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 more dense encoding. Reducing size of IKEv2 messages is
desirable for low power consumption battery powered devices. It also
helps to avoid IP fragmentation of IKEv2 messages.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 10, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Smyslov Expires April 10, 2017 [Page 1]
Internet-Draft IKEv2 Compact October 2016
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Compact Representation of IKEv2 Payloads . . . . . . . . . . . 7
4.1. Compact Generic Payload . . . . . . . . . . . . . . . . . 7
4.2. Compact SA Payload . . . . . . . . . . . . . . . . . . . . 11
4.2.1. Compact Proposal Substructure . . . . . . . . . . . . 11
4.2.2. Compact Transform Substructures . . . . . . . . . . . 12
4.3. Compact Notify Payload . . . . . . . . . . . . . . . . . . 17
5. Compact Format Negotiation . . . . . . . . . . . . . . . . . . 19
6. Interaction with other IKEv2 Extensions . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
Smyslov Expires April 10, 2017 [Page 2]
Internet-Draft IKEv2 Compact October 2016
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 a 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 a few years).
For this reason the task of reducing the power consumption for such
devices is very important and decreasing messages size is one of the
ways to accomplish it.
Large UDP messages may also cause fragmentation on IP level, which
may interact badly with Network Address Translators (NAT). In
particular, some NATs drop IP fragments that don't contain TCP/UDP
port numbers (non-initial IP fragments), so that the IP datagram
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 more dense encoding,
that allows making IKEv2 messages more compact.
Smyslov Expires April 10, 2017 [Page 3]
Internet-Draft IKEv2 Compact October 2016
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Smyslov Expires April 10, 2017 [Page 4]
Internet-Draft IKEv2 Compact October 2016
3. Overview
The idea behind the protocol is to develop an alternate 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 visa 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.
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 requirement 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 to use 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 are 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
Smyslov Expires April 10, 2017 [Page 5]
Internet-Draft IKEv2 Compact October 2016
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.
Smyslov Expires April 10, 2017 [Page 6]
Internet-Draft IKEv2 Compact October 2016
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 to use it with any currently defined and not yet defined
payloads. However, it doesn't provide high level of efficiency.
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
Smyslov Expires April 10, 2017 [Page 7]
Internet-Draft IKEv2 Compact October 2016
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 doen'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.
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 doen't understand its type and
cleared if it is safe to skip this payload. The value is taken
intact from original payload.
Smyslov Expires April 10, 2017 [Page 8]
Internet-Draft IKEv2 Compact October 2016
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.
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.
Any 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
Smyslov Expires April 10, 2017 [Page 9]
Internet-Draft IKEv2 Compact October 2016
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
cleared. If there are no more octets in the original payload
data then the process stops and the rest of Bmap is zeroed.
3. If any more octets left in the original payload data, then the
next 48 of them are scanned one by one. Since the Extended
Bitmap position isn't known yet a temporary bitmap of six octets
is used. If the current octet is zero, then it is omitted from
the Compacted Payload Data and the corresponding bit (starting
from the rightmost bit to the leftmost bit) in the corresponding
octet of a temporary bitmap is set. Otherwise the original octet
is copied and the corresponding bit in temporary bitmap is
cleared. If there are no more octets in the original payload
data then the process stops and the rest bits of the current
temporary bitmap octet are zeroed..
4. If any more octets left in the original payload data, they are
copied to the Compacted Payload Data.
5. The Payload Length field is set to indicate the size of Compacted
Payload Data plus 3. It will indicate the offset of the Extended
Bitmap from the beginning of compact payload.
6. The content of the temporary bitmap is copied to the Extended
Bitmap field (after the Compacted Payload Data). The temporary
bitmap octets are copied one by one up to the first zero octet
(if any). In other words, the Extended Bitmap MUST NOT contain
zero octets.
7. The XBL field is set to the number of octets placed in the
Extended Bitmap plus one.
Smyslov Expires April 10, 2017 [Page 10]
Internet-Draft IKEv2 Compact October 2016
4.2. Compact SA Payload
SA payload is compacted differently than generic IKEv2 payload. The
specific format for Compact SA payload allows to get 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>.
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
Smyslov Expires April 10, 2017 [Page 11]
Internet-Draft IKEv2 Compact October 2016
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 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 April 10, 2017 [Page 12]
Internet-Draft IKEv2 Compact October 2016
+----------+--------------------------------------+-----+-----------+
| Tag | Compact Transform | Len | Format |
+----------+--------------------------------------+-----+-----------+
| 00xxxxxx | Short form - Encryption (Type 1) | 1 | Figure 5 |
| | | | |
| 01xxxxxx | Short form - Encryption (Type 1) | 2 | Figure 6 |
| | with key length | | |
| | | | |
| 10xxxxxx | Short form - Diffie-Hellman Group | 1 | Figure 7 |
| | (Type 4) | | |
| | | | |
| 110xxxxx | Short form - Integrity (Type 3) | 1 | Figure 8 |
| | | | |
| 1110xxxx | Short form - Pseudo-random Function | 1 | Figure 9 |
| | (Type 2) | | |
| | | | |
| 11110xxx | Short form - Extended Sequence | 1 | Figure 10 |
| | Numbers (Type 5) | | |
| | | | |
| 11111xxx | Long form | 3 | Figure 11 |
| | | | |
| 11111000 | Full form | var | Figure 12 |
+----------+--------------------------------------+-----+-----------+
Table 1: Tag values and corresponding Compact Transform formats
Short forms are the most efficient Compact Transform formats. Most
of them occupy only one octet, except for the Encryption Transform
with key length, which occupy two octets. The Transform can be
encoded using short form if it meets the following requirements:
1. Transform Type is between 1 and 5. At the time the document was
written these Transform Types were the only defined (see
[IKEV2-IANA]).
2. Transform ID is less or equal to the value, specific to each
Transform Type:
* 63 for Transform Type 1 (Encryption Algorithm)
* 15 for Transform Type 2 (Pseudo-random Function)
* 31 for Transform Type 3 (Integrity Algorithm)
* 63 for Transform Type 4 (Diffie-Hellman Group)
* 7 for Transform Type 5 (Extended Sequence Numbers)
Smyslov Expires April 10, 2017 [Page 13]
Internet-Draft IKEv2 Compact October 2016
3. Transform has no attributes, or Transform has Type 1 (Encryption
Algorithm), it has only one attribute of type Key Length (Type
14), the value of this attribute is less than 2048 and the value
is divisible by 8.
If the Transform doesn't meet these requirements, then it cannot be
encoded in short form. In this case either long form (Figure 11) or
full form (Figure 12) must be used. Note, that all the transforms
defined in [IKEV2-IANA] at the time this document was written meet
these requirements.
Figures 5-10 show short form encodings for different Transform Types.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Tag|ENCR Tr ID |
+-+-+-+-+-+-+-+-+
Figure 5: Compact Transform Substructure (Short Form: Encryption)
o Tag (2 bits) - MUST be 00.
o ENCR Tr ID (6 bits) - Encryption Algorithm Transform ID.
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Tag|ENCR Tr ID | Key Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Compact Transform (Short Form: Encryption with Key Length)
o Tag (2 bits) - MUST be 01.
o ENCR Tr ID (6 bits) - Encryption Algorithm Transform ID.
o Key Length (1 octet) - Key Length in bytes (note, that Key Length
attribute in IKEv2 specifies key length in bits).
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Tag| GRP Tr ID |
+-+-+-+-+-+-+-+-+
Figure 7: Compact Transform (Short Form: Diffie-Hellman Group)
Smyslov Expires April 10, 2017 [Page 14]
Internet-Draft IKEv2 Compact October 2016
o Tag (2 bits) - MUST be 10.
o GRP Tr ID (6 bits) - Diffie-Hellman Group Transform ID.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Tag |INTG TrID|
+-+-+-+-+-+-+-+-+
Figure 8: Compact Transform (Short Form: Integrity)
o Tag (3 bits) - MUST be 110.
o INTG TrID (5 bits) - Integrity Algorithm Transform ID.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Tag | PRF |
+-+-+-+-+-+-+-+-+
Figure 9: Compact Transform (Short Form: PRF)
o Tag (4 bits) - MUST be 1110.
o PRF (4 bits) - Pseudo-random Function Transform ID.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Tag | ESN |
+-+-+-+-+-+-+-+-+
Figure 10: Compact Transform (Short Form: ESN)
o Tag (5 bits) - MUST be 11110.
o ESN (3 bits) - Extended Sequence Numbers Transform ID.
Long form (Figure 11) is used when Transform doesn't meet
requirements for short form encoding, but still meets the following
requirements:
1. Transform Type is between 1 and 7. At the time this document was
written only Transform Types 1 to 5 were defined (see
[IKEV2-IANA]).
Smyslov Expires April 10, 2017 [Page 15]
Internet-Draft IKEv2 Compact October 2016
2. Transform has no attributes.
Long form allows to effectively encode Transform IDs for standard
Transform Types that don't fit into the short form, e.g. private
Transform IDs (if these transforms don't have associated attributes).
It is expected that new Transform IDs will be defined more often than
new Transform Types. So, defining effective encoding for standard
Transform Type and arbitrary Transform IDs makes sense.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Compact Transform (Long Form)
o Tag (5 bits) - MUST be 11111.
o Transform Type (3 bits) - The type of transform being specified in
this substructure.
o Transform ID (2 octets) - The specific instance of the Transform
Type being specified.
Full encoding of Compact Transform substructure allows encoding of
any transform without restrictions. It is used when transform cannot
be encoded neither in short form nor in long form. 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: Compact Transform (Full Form)
Smyslov Expires April 10, 2017 [Page 16]
Internet-Draft IKEv2 Compact October 2016
o Tag (1 octet) - MUST be 11111000.
o Transform Type (1 octet) - The type of transform being specified
in this substructure.
o Transform Length (2 octets, unsigned integer) - The length in
octets of the Compact Transform Substructure including Header and
Attributes.
o Transform ID (2 octets) - The specific instance of the Transform
Type being specified.
o Transforms Attributes (variable) - Transform attributes.
4.3. Compact Notify Payload
Notify payloads containing status notifications with no data are
often used in IKEv2. This is "de facto" standard way to negotiate
various protocol extensions and for that reason usually several such
Notify payloads are present in initial IKEv2 exchanges. It is
anticipated that the number of IKEv2 extensions will increase and
thus the size of initial exchange messages will increase too. This
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.
Smyslov Expires April 10, 2017 [Page 17]
Internet-Draft IKEv2 Compact October 2016
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 April 10, 2017 [Page 18]
Internet-Draft IKEv2 Compact October 2016
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.
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
messages MUST NOT contain compact payloads, while ALT_IKE_SA_INIT MAY
contain them.
Smyslov Expires April 10, 2017 [Page 19]
Internet-Draft IKEv2 Compact October 2016
6. Interaction with other IKEv2 Extensions
To be added.
Smyslov Expires April 10, 2017 [Page 20]
Internet-Draft IKEv2 Compact October 2016
7. Security Considerations
To be added.
Smyslov Expires April 10, 2017 [Page 21]
Internet-Draft IKEv2 Compact October 2016
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 new Exchange Type in the "IKEv2 Exchange
Types" registry:
<TBA> ALT_IKE_SA_INIT
Smyslov Expires April 10, 2017 [Page 22]
Internet-Draft IKEv2 Compact October 2016
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,
<http://www.rfc-editor.org/info/rfc2119>.
[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, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2
(IKEv2) Message Fragmentation", RFC 7383, DOI 10.17487/
RFC7383, November 2014,
<http://www.rfc-editor.org/info/rfc7383>.
[IKEV2-IANA]
"Internet Key Exchange Version 2 (IKEv2) Parameters",
<http://www.iana.org/assignments/ikev2-parameters>.
9.2. Informative References
[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.
Smyslov Expires April 10, 2017 [Page 23]
Internet-Draft IKEv2 Compact October 2016
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 April 10, 2017 [Page 24]