| IPSECME | D. Migault (Ed) |
| Internet-Draft | Orange |
| Intended status: Standards Track | T. Guggemos |
| Expires: September 04, 2014 | Orange / LMU Munich |
| D. Palomares | |
| Orange / LIP6 - UMPC | |
| March 03, 2014 |
Diet-ESP: a flexible and compressed format for IPsec/ESP
draft-mglt-ipsecme-diet-esp-00.txt
IPsec/ESP has been designed to secure IP packets exchanged between two nodes. IPsec implements security at the IP layer which makes security transparent to the applications, as opposed to TLS or DTLS that requires application to implement TLS/DTLS. As a result, IPsec enable to define the security rules in a similar way one establishes firewall rules.
One of the IPsec's drawbacks is that implementing security on a per packet basis adds overhead to each IP packet. Considering IoT devices, the data transmitted over an IP packet is expected to be rather small, and the cost of sending extra bytes is so high that IPsec/ESP can hardly be used for IoT as it is currently defined in RFC 4303.
This document defines Diet-ESP, a protocol that compress and reduce the ESP overhead of IPsec/ESP so that it can fit security and energy efficient IoT requirements. Diet-ESP use already existing mechanism like IKEv2 to negotiate the compression format. Furthermore a lot of information, already existing for an IPsec Security Association, are reused to offer light negotiation in addition to maximum compression.
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 September 04, 2014.
Copyright (c) 2014 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 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.
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].
The IPsec/ESP [RFC4303] is represented in Figure Figure 1 . It was designed to: 1) provide high level of security as a basis, 2) favor interoperability between implementations 3) scale on large infrastructures.
In order to match these goals, ESP format favor mandatory fields with fixed sizes that are designed for the worst case scenarios. This results in a kind of "unique" packet format common to all considered scenarios using ESP. These specific scenarios MAY result in carrying "unnecessary" or "larger then required" fields. This cost of additional bytes were than considered as negligible versus interoperability, and this made ESP very successful over the years.
With IoT, requirements become slightly different. For most devices, like sensors, sending extra bytes directly impacts the battery and so the life time of the sensor. Furthermore, IoT scenarios MAY consider that sensors MAY be designed not to interconnect between each other, but instead to be connected to a specific Security Gateway. These kind of dedicated connectivity, for example, does not impose the sensors to be fully interoperable with any other IPsec/ESP implementation. In contrast, it MAY be inter-operable with the Security Gateway and those devices supporting the same sensor's options.
In this document, we adapted ESP so IoT devices can use ESP designed for their specific needs or applications. Diet-ESP allows to reduce or remove all fields of the ESP format represented in figure 1. How the fields are reduced is defined in the Diet-ESP Context. This Diet-ESP Context MAY be announced or negotiated between the two peers. How the two devices agree on using the same Diet-ESP Context is out of scope of this document. Diet-ESP Context consist of a byte that fully defines the parameters present in a Diet-ESP packet, creating a Diet-ESP packet format agreement between compliant devices.
0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- | Security Parameters Index (SPI) | ^Int. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- | Sequence Number | |ered +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- | Payload Data* (variable) | | ^ ~ ~ | | | | |Conf. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- | | Padding (0-255 bytes) | |ered* +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Pad Length | Next Header | v v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ | Integrity Check Value-ICV (variable) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ESP Packet Description
This document uses the following terminology:
This section describes how each field of the ESP can be compressed.
SPI SIZE: ESP Security Policy Index is 32 bits long. Diet-ESP omits, leaves unchanged, or reduces the SPI to 8, 16 or 24 bits. The length of the SPI should be guided by 1) the number of simultaneous inbound SA the device is expected to handle and 2) reliability of the IP addresses in order to identify the proper SA for incoming packets. More specifically, a sensor with a single connection to a Security Gateway, may bind incoming packets to the proper SA based only in its IP addresses. In that case, the SPI MAY not be necessary. Other scenarios may consider using the SPI to index the SAs or may consider having multiple ESP channels with the same host from a single host. In that case it may choose a reduced length for the SPI. Note that reducing the size of the SPI may expose the system to security flows. See Section 8 for more details. Note also that the value 0 for the SPI is note allowed to be sent on the wire as described in [RFC4303].
For those cases where a regular SPI of 32 bits has been negotiated (e.g. via IKEv2 [RFC5996]), the resulting SPI used for Diet-ESP packets corresponds to the high order bits of that 32 bits SPI (see Section 6 for further explanations).
SN SIZE: ESP Sequence Number is 32 bit and extended SN is 64 bit long. Diet-ESP omits, leaves unchanged or reduces SN to 8, 16, 24 bits. The length of the SN should be guided by 1) how the receiving side handles the SN, 2) the number of packets expected to be sent over Diet-ESP channel, and 3) how the node is willing to use IKEv2 to re-key when SN are expired. SN are used to address replay attacks, thus removing SN may expose the system to security flaws. See Section 8 for more details. If SN is used, a 32 bits value may not be required. Table 1 shows the lifetime of one SA before re-keying is required in case the SN expires.
| SN Length | 1 packet per second | 1 packet per minute | 1 packet per hour |
|---|---|---|---|
| 8 bit | 4min 16sec | 4h 16min | 10 days 16h |
| 16 bit | 18h 12min 16sec | 6 weeks 3 days 12h | ~7 years 25 weeks |
| 24 bit | ~27 weeks 5 days | 31 years 47 weeks | ~1,915 years |
| 32 bit | ~136 years | ~8,171 years | ~490,293 years |
Note that SN and SPI MUST be aligned to a multiple of the Alignment value (ALIGN).
NH: Diet-ESP is able to remove the Next Header field from the ESP-Trailer if the underlying protocol can be derived from the Traffic Selector (TS) within the SA. More specifically, the next header indicates whether the encrypted ESP payload is an IP packet, a UDP packet, a TCP packet or no next header. The NH can only be removed if this has been explicitly specified in the SA or if the device has a single application. Suppose a device sets an ESP channel with another peer only considering the IP addresses as TS without specifying the transport protocols or (or upper layer protocols). If the device uses this channel for multiple upper layer protocols (like HTTP and tnftp), then the NH cannot be removed as the receiver would not be able to determine whether incoming packets are HTTP or tnftp.
Note that removing the Next Header impacts how encryption is performed. For example, the use of AES-CBC [RFC3602] mode requires the last block to be padded to reach a 128 bit alignment. In this case removing the Next Header increases the padding by the Next Header length, which is 8 bits. In this case, removing the Next Header provides few advantages, as it does not reduce the ESP packet length. With AES-CBC, the only advantage of removing the Next Header would be for data with the last block of 15 bytes. In that case, ESP pad with 15 modulo 16 bytes, set the 1 byte pad length field to 15 and add the one byte Next Header field. This leads to 15 + 15 + 1 + 1 bytes to be sent. On the other hand, removing the Next Header would require only the concatenation of the pad length byte with a 0 value, which leads to 16 bytes to be sent.
Other modes like AES-CTR [RFC3686] do not have block alignment requirements. Using AES-CTR with ESP only requires the 32 bit alignment - mostly for OS implementation. In fact if an n byte alignment is required (for encryption or for packet format), data of length k * n + n - 1 bytes, k an integer, takes advantage of removing the Next Header and reduces the data to be sent over n bytes. In the case of sensor network it is very likely that data of fixed size k * n + n - 1 will be used. Furthermore, if 32 bits alignment is reduced to 8 bits alignment, Next Header is always an additional unnecessary byte being sent.
PAD: With ESP, all packets have a Pad Length field. This field is usually present because ESP requires a 32 bits alignment which is performed with padding. Diet-ESP considers that some devices may use 8 bits alignment, in which case padding is not necessary. Similarly, sensors may send application data that has fixed length matching the alignment. Note that alignment may be required by the device (8-bit, 16-bit, or more generally 32-bit), but it may also be required by the encryption block size (AES-CBC uses 128 bit blocks). With ESP these scenarios would result in an unnecessary Pad Length field always set to zero. Diet-ESP considers those case with no padding, and thus the Pad Length field can be omitted.
ALIGN: Alignment for Padding and Pad Length. ESP is designed for 32 bit alignment. This is mostly an OS implementation and hardware design requirements for regular PC processors. IoT may not have these requirements. Having no alignment requirements or a 16 bits alignment requirement prevents or reduces the number of padding bytes to be sent. As a result Diet-ESP considers alternative alignment (8-bit, 16 bit, 32 bit) so to reduce the number of padding bytes.
Note that when PAD requires the Pad Length field to be present, ALIGN provides the minimum alignment padding considers. More specifically, ALIGN gives more priority to the hardware or OS implementation than to the encryption algorithm used. In fact with AES-CTR padding will be performed based on the value provided by ALIGN. However, AES-CBC padding is performed on the AES block basis (128 bits). This value overwrites the one provided by ALIGN.
IH: With ESP using the tunnel mode, the inner IP Header is sent in every ESP Payload. This extra bytes sent do not carry relevant information over sent packets. As a result Diet-ESP indicates the IP header has been omitted, and MUST be rebuilt by the receiver. These information are negotiated via IKE and are stored in the SA.
TH: With ESP the transport header is transmitted in every packet. This layer may not provide relevant information, especially for UDP transport layer. The port parameters may be negotiated via IKE and stored in the SA. As a result Diet-ESP indicates that the transport protocol header (TH) has been removed from the encrypted ESP Payload. This option can only be used if the header can be restored or if it is unnecessary for the further packet procession. Other protocols than UDP are considered out of scope of this document. TCP, for example, includes information that are not as easy to restore, like options, controls or windows. In order to use other transport layer protocols within specific configuration, additional information may be provided in the future.
ICV: ESP negotiates Authentication protocols. These protocols generate an ICV of a length defined by the authentication protocol negotiated for the SA. These authentication protocols do not provide ways to perform weak authentication, as it only reduces the size of the ICV. IoT is interested in weak authentication as it may sends a small amount of bytes, and the trade-of between battery life time and security may be worth. As a result Diet-ESP indicates the number of bytes of the ICV. Diet-ESP considers sending the whole ICV or the first 1 byte resp (2, 4, 8, 12, 16, 32) bytes. Note that Note that reducing the size of the SPI may expose the system to security flows. See Section 8 for more details.
This section describes the Diet-ESP Context that contains all necessary parameters for Diet-ESP.
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |SPI SIZE|SN SIZE |NH|P |ALIGN|TH|IH| ICV | X| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 2: Diet-ESP Context
With the fields defined as below:
This section details how to use Diet-ESP to send and receive messages. The use of Diet-ESP is based on the IPsec architecture [RFC4301] and ESP [RFC4303]. We suppose the reader is familiar with these documents and list here the adaptation that MAY be involved by Diet-ESP.
In ESP each packet has a fixed alignment to 32 bits. For Diet-ESP each device has an internal parameter that defines the minimal kernel alignment that is acceptable. ALIGN SHOULD be a the maximum of the peer's minimal alignment.
Diet-ESP Context with SPI SIZE + SN SIZE that is not a multiple of ALIGN MUST be rejected.
For devices using a single SPI SIZE value (e.g. sensors), the SA will be indexed with the SPI as described in ESP. More specifically, SPI is used as the index in the SAD. The only difference is that it has smaller size in the ESP header. If the only supported SPI SIZE is zero, the lookup has to be performed with the IP address. Some implementations MAY use a specific SPI value in their SAD for unspecified SPIs.
For devices that allow multiple SPI SIZE, like some IoT generic end points or IoT Security Gateways, SAD lookup has to deal with SPI of different sizes. The SPI stored in the SAD MAY be converted from an SPI of any size to a standard 4 bytes SPI. This means that for inbound packets a conversion from SPI SIZE byte SPI to 4 byte SPI is performed before the SAD lookup.
The SPI of the SA may be negotiated using IKEv2 [RFC5996]. Regular IKEv2 implementation negotiate a 4 byte SPI. In order to be able to use regular IKEv2 for Diet-ESP, the following convention is used. The SPI considered in Diet-ESP consists in the SPI SIZE low power bytes of 32 bit SPI negotiated with IKEv2. Only this value should be considered in the SAD. How the SPI SIZE SPI is represented in the SAD is another issue addressed above.
For devices that are configured with a single SPI SIZE value can process inbound packet as defined in [RFC4301]. As such, no modifications is required by Diet-ESP.
Detecting Inbound Security Association: Identifying the SA for incoming packets is a one of the main reasons the SPI is send in each packet on the wire. For regular ESP (and AH) packets, the Security Association is detected as follows:
For device that are dealing with different SPI SIZE SPI, the way inbound packets are handled differs from the [RFC4301]. In fact, when a inbound packet is received, the peer does not know the SPI SIZE. As a result, it does not know the SPI that applies to the incoming packet. The different values could be the 0 (resp. 1, 2, 3 and 4) first bytes of the IP payload.
Since the size of the SPI is not known for incoming packets, the detection of inbound SAs has to be redefined in a Diet-ESP environment. In order to ensure a detection of a SA the above described regular detection have to be done for each supported SPI size (in most cases 5 times). In most common cases this will return a unique Security Association.
If there is more than one SA matching the lookup, the authentication MUST be performed for all found SAs to detect the SA with the correct key. In case there is no match, the packet MUST be dropped. Of course this can lead into DoS vulnerability as an attacker recognizes an overlap of one or more IP-SPI combinations. Therefore it is highly recommended to avoid different values of the SPI SIZE for one tuple of Source and Destination IP address. Furthermore this recommendation becomes mandatory if NULL authentication is supported. This is easy to implement as long as the sensors are not mobile and do not change their IP address.
The following optimizations MAY be considered for sensor that are not likely to perform mobility or multihoming features provided by MOBIKE [RFC4555] or any change of IP address during the lifetime of the SA.
Optimization 1 - SPI SIZE is mentioned inside the SPI: The SPI SIZE is defined as part of the SPI sent in each packet. Therefore the receiver has to choose the most significant 2 bits of the SPI in the following way in order to recognize the right size for incoming Diet-ESP packets:
If the the value 0 is chosen for the SPI SIZE this option does not feasible.
Optimization 2 - IP address based lookup: IP addressed based search is one optimization one MAY choose to avoid several SAD lookups. It is based on the IP address and the stored SPI SIZE, which MUST be the same value for each SA of one IP address. Otherwise it can't neither be ensured that an SA is found nor that the correct one is found. Note that in case of mobile IP the SPI SIZE MUST be updated for all SAs related to the new IP address which may cause in renegotiation. Figure Figure 3 shows this lookup described below.
Note that some implementation MAY collect all SPI matching the IP addresses in step 2 to avoid an additional lookup over the whole SAD. This is implementation dependant.
+-----------+
| START |
+-----------+
|
V
+-----------------+
| find 1st SA to |
| IP address |------------------+
+-----------------+ |
| |
____V____ V
yes / \ +-----+
+------/ SPI_SIZE \ /----->|'---'|
| \ = 0 ? / / | SAD |
| \_________/ / + +
| |no / '---'
| V /
| +-----------------+ /
| | find 1st SA to |--/
| | SPI +IP |
| | address |
| +-----------------+
| |
| V
| +-----------------+
| | Diet-ESP packet |
+-->| procession |
+-----------------+
Figure 3: SAD lookup for incoming packets.
If the sensor is likely to change its IP address, the outcome MAY be a given IP address associated to different SPI SIZE. This case MAY occur if one IP address has been used by a device not anymore online, but the SA has not been removed. The IP has then been provided to another device. In this case the Diet-ESP Context SHOULD NOT be accepted by the Security Gateway when the new Diet-ESP Context is provided to the Security Gateway. At least the Security Gateway can check the previous peer is reachable and then delete the SA before accepting the new SA.
Another case MAY be that a sensor got two interfaces with different IP addresses, negotiates a different SPI SIZE on each interface and then use MOBIKE to move the IPsec channels from one interface to the other. In this case, the Security Gateway SHOULD NOT accept the update, or force a renegotiation of the SPI SIZE for all SAs, basically by re-keying the SAs.
Outgoing lookups for the SPI are performed in the same way as it is done in ESP. The Traffic Selector for the packet is searched and the right SA is read from the SA. The SPI used in the packet MUST be reduced to the value stored in SPI SIZE.
Sequence number in ESP [RFC4303] can be of 4 bytes or 8 bytes for extended ESP. Diet-ESP introduces different sizes. One way to deal with this is to add a MAX_SN value that stores the maximum value the SN can have. Any new value of the SN will be check against this MAX_SN.
NH, TH, IH, P indicate fields or payloads that are removed from the Diet-ESP packet. How the Diet-ESP packet is generated depends on the Payload Data of lPD bytes, BLCK the block size of the encryption algorithm and the device alignment ALIGN. We note M = MAX(BLCK, ALIGN). Although not normative the resulting Diet-ESP packet should be and explained below. We consider the Diet-ESP Payload as described in Section 3
Decryption is for performed the other way around.
After SAD lookup, authenticating and decrypting the Diet-ESP payload the original packet is rebuild as follows:
There are no IANA consideration for this document.
This section lists security considerations related to the Diet-ESP protocol.
Small SPI SIZE exposes the device to DoS. For a device, the number of SA is related to the number of SPI. For systems using small SPI SIZE values as index of their database, the number of simultaneous communications is limited by the SPI SIZE. This means that a given device initiating SPI SIZE communications can isolate the system. In order to leverage this vulnerability, one can consider receiving systems that generate 32 bits SPI with a hash function that considers different parameters associated to the reduced SPI. For example, if one use the IP addresses as well as the reduced SPI, the number of SPI becomes SPI SIZE per IP address. This may be sufficient as sensors are not likely to perform multiple communications.
Small size of ICV reduces the authentication strength. For example 8 bits mean that authentication can be spoofed with a probability of 1/256. Standard value considers a length of 96 bit for reliable authentication. If specified, the ICV field is truncated after the given number of bits which, for sure, has to be mentioned while incoming packet procession as well. For removing authentication ESP NULL has to be negotiated, as described in RFC4303.
Removing the SN prevents protection against replay attack.
This section lists considerations related to the use of Diet-ESP in NAT environments.
Diet-ESP is a protocol designed for the IoT, assuming to work in an IPv6 environment. However, ESP is designed to work in every IP environment whereas Diet-ESP can be delivered in other IP environments like IPv4 as well. This environment MAY cause the need of NAT. In IPsec, UDP encapsulation is used to deal with NAT environments as described in [RFC3948]. Because UDP cannot define the underlying protocol with a Next Header, IKEv2 traffic is distinguished from ESP or AH traffic by sending the Non-ESP Marker (4 bytes ZERO) after the UDP header. As the SPI is considered to never be ZERO this clearly identifies IKEv2 traffic.
In context of Diet-ESP the SPI MAY not be present in the Diet-ESP-header, which MAY corrupt this mechanism in case:
Therefore an implementer has to define a way to ensure the first 4 bytes are NOT zero. We suggest the negotiated SPI to be at least 1 byte if UDP encapsulation is enabled.
Diet-ESP is a joint work between Orange and Ludwig-Maximilians-Universitaet Munich.
| [RFC5856] | Ertekin, E., Jasani, R., Christou, C. and C. Bormann, "Integration of Robust Header Compression over IPsec Security Associations", RFC 5856, May 2010. |
This section compares the proposed Diet ESP with 6LoWPAN ESP [I-D.raza-6lowpan-ipsec] related to IoT use cases. It shows the different ESP packet sent with the two compression methods. In each case the maximum possible compression is used and the underlying UDP header is compressed as much as possible. The big advantage of Diet ESP compression removing the UDP header appears. Furthermore there are no additional compression configuration bytes to be sent in each packet, like done in 6LoWPAN compression, because the configuration is negotiated at the beginning of the communication the during the IKEv2 [RFC5996] negotiation. Diet ESP uses the idea of ROHC[RFC5856] compression removing the disadvantage that the whole packet has to be sent once at the beginning of the connection, because it considers that a lot of information of the Security Association can be reused to decompress the packet.
Both comparisons are using 8 bits alignment. The figures are aligned to 16 bits to improve the readability.
6LoWPAN offers compression of the Sequence Number to 8, 16, 24 bit has to be sent in each packet, even if it is not going to be used.
6LoWPAN does not offer to reduce the ICV as it is not removed with NULL-authentication. Diet-ESP offers reducing to fair securely 64 bits.
AES-CTR is used for encryption.
Figure 4a and 4b show this comparison. The advantage of Diet ESP for this example is 96 bits.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0| initialization vector |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
16| initialization vector |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
32| initialization vector |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
48| initialization vector |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
64| 1 byte data | ICV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
80| ICV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
96| ICV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
112| ICV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
128| ICV |
+--+--+--+--+--+--+--+--+
Figure 4a) 1 byte Data Payload with Diet-ESP. (no SPI, no SN, no PAD, no NH)
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0| Id | SPI | SN | SN |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
16| initialization vector |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
32| initialization vector |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
48| initialization vector |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
64| initialization vector |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
80| Id |0 |C | P |source port| dest port |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
96| length |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
112| 1 byte data | pad length |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
128| next header | ICV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
144| ICV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
160| ICV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
176| ICV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
192| ICV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
208| ICV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
224| ICV |
+--+--+--+--+--+--+--+--+
Figure 4b) 1 byte data payload with 6LoWPAN ESP. (no SPI, 8 bits SN, 8 bits pad length, 8 bits 6LoWPAN NH)
Having multiple connections to one host implies the use of the SPI to identify the correct Security Association. Diet ESP allows the reduction to 8, 16 and 24 bit. 6LoWPAN ESP offers quite the same reductions, except 24 bit. In most sensor use cases 254 possible connection are more than enough, whereas the following two pictures show the advantage of Diet ESP against 6LoWPAN ESP for an 8 bit SPI. Since there is no possibility to remove the SN with 6LoWPAN it has to be at least 8 Bit.
6LoWPAN offers compression of the Sequence Number to 8, 16, 24 bit has to be sent in each packet, even if it is not going to be used.
6LoWPAN does not offer to reduce the ICV as it is not removed with NULL-authentication. Diet-ESP offers reducing to fair securely 64 bits.
AES-CTR is used for encryption.
Figure 5a and 5b show this comparison. In case of an 8 bit SPI the advantage is 96 bits. For a 24 bit SPI the advantage would be 104 bits.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0| SPI | initialization vector |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
16| initialization vector |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
32| initialization vector |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
48| initialization vector |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
64| initialization vector | 1 byte data |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
80| ICV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
96| ICV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
112| ICV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
128| ICV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 5a) 1 byte Data Payload with Diet-ESP. (8 bits SPI, no SN, no PAD, no NH)
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0| Id | SPI | SN | SPI |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
16| SN | initialization vector |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
32| initialization vector |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
48| initialization vector |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
64| initialization vector |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
80| initialization vector | Id |0 |C | P |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
96|source port| dest port | length |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
112| length | 1 byte data |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
128| pad length | next header |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
144| ICV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
160| ICV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
176| ICV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
192| ICV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
208| ICV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
224| ICV |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 5b) 1 byte data payload with 6LoWPAN ESP. (32 bits SPI, 16 bits SN, 8 bits pad length, 8 bits 6LoWPAN NH)
[draft-mglt-dice-diet-esp-00.txt]: First version published.
[draft-mglt-ipsecme-diet-esp-00.txt]:
NAT consideration added.
Comparison actualized to new Version of 6LoWPAN ESP.