idnits 2.17.1 draft-mglt-ipsecme-diet-esp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 3, 2014) is 3707 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'M' is mentioned on line 747, but not defined ** Obsolete normative reference: RFC 4835 (Obsoleted by RFC 7321) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSECME D. Migault (Ed) 3 Internet-Draft Orange 4 Intended status: Standards Track T. Guggemos 5 Expires: September 4, 2014 Orange / LMU Munich 6 D. Palomares 7 Orange / LIP6 - UMPC 8 March 3, 2014 10 Diet-ESP: a flexible and compressed format for IPsec/ESP 11 draft-mglt-ipsecme-diet-esp-00.txt 13 Abstract 15 IPsec/ESP has been designed to secure IP packets exchanged between 16 two nodes. IPsec implements security at the IP layer which makes 17 security transparent to the applications, as opposed to TLS or DTLS 18 that requires application to implement TLS/DTLS. As a result, IPsec 19 enable to define the security rules in a similar way one establishes 20 firewall rules. 22 One of the IPsec's drawbacks is that implementing security on a per 23 packet basis adds overhead to each IP packet. Considering IoT 24 devices, the data transmitted over an IP packet is expected to be 25 rather small, and the cost of sending extra bytes is so high that 26 IPsec/ESP can hardly be used for IoT as it is currently defined in 27 RFC 4303. 29 This document defines Diet-ESP, a protocol that compress and reduce 30 the ESP overhead of IPsec/ESP so that it can fit security and energy 31 efficient IoT requirements. Diet-ESP use already existing mechanism 32 like IKEv2 to negotiate the compression format. Furthermore a lot of 33 information, already existing for an IPsec Security Association, are 34 reused to offer light negotiation in addition to maximum compression. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on September 4, 2014. 53 Copyright Notice 55 Copyright (c) 2014 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 71 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 4. Diet-ESP: Protocol Description . . . . . . . . . . . . . . . 5 74 5. Diet-ESP Context: Format Description . . . . . . . . . . . . 8 75 6. Difference between Diet-ESP and ESP . . . . . . . . . . . . . 11 76 6.1. Packet Alignment . . . . . . . . . . . . . . . . . . . . 11 77 6.2. SAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 6.2.1. Storing SPI SIZE SPI in the SAD . . . . . . . . . . . 11 79 6.2.2. Inbound Security Association Lookup . . . . . . . . . 12 80 6.2.3. Outgoing Security Association Lookup . . . . . . . . 16 81 6.3. Sequence Number . . . . . . . . . . . . . . . . . . . . . 16 82 6.4. Outgoing Packet processing . . . . . . . . . . . . . . . 16 83 6.5. Inbound Packet processing . . . . . . . . . . . . . . . . 17 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 86 9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 18 87 10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 19 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 90 11.2. Informational References . . . . . . . . . . . . . . . . 20 91 Appendix A. Comparison . . . . . . . . . . . . . . . . . . . . . 21 92 A.1. Transmitting 1 Byte without anti-replay . . . . . . . . . 21 93 A.2. Transmitting 1 Byte to multi directional connections. . . 23 94 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 25 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 97 1. Requirements notation 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 2. Introduction 105 The IPsec/ESP [RFC4303] is represented in Figure Figure 1 . It was 106 designed to: 1) provide high level of security as a basis, 2) favor 107 interoperability between implementations 3) scale on large 108 infrastructures. 110 In order to match these goals, ESP format favor mandatory fields with 111 fixed sizes that are designed for the worst case scenarios. This 112 results in a kind of "unique" packet format common to all considered 113 scenarios using ESP. These specific scenarios MAY result in carrying 114 "unnecessary" or "larger then required" fields. This cost of 115 additional bytes were than considered as negligible versus 116 interoperability, and this made ESP very successful over the years. 118 With IoT, requirements become slightly different. For most devices, 119 like sensors, sending extra bytes directly impacts the battery and so 120 the life time of the sensor. Furthermore, IoT scenarios MAY consider 121 that sensors MAY be designed not to interconnect between each other, 122 but instead to be connected to a specific Security Gateway. These 123 kind of dedicated connectivity, for example, does not impose the 124 sensors to be fully interoperable with any other IPsec/ESP 125 implementation. In contrast, it MAY be inter-operable with the 126 Security Gateway and those devices supporting the same sensor's 127 options. 129 In this document, we adapted ESP so IoT devices can use ESP designed 130 for their specific needs or applications. Diet-ESP allows to reduce 131 or remove all fields of the ESP format represented in figure 1. How 132 the fields are reduced is defined in the Diet-ESP Context. This 133 Diet-ESP Context MAY be announced or negotiated between the two 134 peers. How the two devices agree on using the same Diet-ESP Context 135 is out of scope of this document. Diet-ESP Context consist of a byte 136 that fully defines the parameters present in a Diet-ESP packet, 137 creating a Diet-ESP packet format agreement between compliant 138 devices. 140 0 1 2 3 141 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 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- 143 | Security Parameters Index (SPI) | ^Int. 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- 145 | Sequence Number | |ered 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- 147 | Payload Data* (variable) | | ^ 148 ~ ~ | | 149 | | |Conf. 150 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- 151 | | Padding (0-255 bytes) | |ered* 152 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 153 | | Pad Length | Next Header | v v 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ 155 | Integrity Check Value-ICV (variable) | 156 ~ ~ 157 | | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 Figure 1: ESP Packet Description 162 3. Terminology 164 This document uses the following terminology: 166 - IoT: Internet of Things 168 - ESP: ESP like described in [RFC4303]. 170 - ESP-packet: The concatenation of the following fields: 172 - ESP-Header: The concatenation of the SPI and SN 174 - ESP Payload: The concatenation of the following two fields. 175 The ESP Payload is usually encrypted. 177 - Data Payload: The application payload. It MAY include 178 a transport layer header. 180 - ESP-Trailer: The Padding concatenated with the Pad 181 Length and Next Header fields. 183 - ESP ICV The ICV generated throw the specified algorithm. 185 - Diet-ESP: Diet version of ESP like described in this document. 187 - Diet-ESP Context: The Context that describes the Diet-ESP packet 188 format (see Section 5). 190 - Diet-ESP-packet: The concatenation of the following fields: 192 - Diet-ESP-Header: The concatenation of the SPI and SN if they 193 appear in the packet. 195 - Diet-ESP Payload: The concatenation of the following two 196 fields. The Diet-ESP Payload is usually encrypted. 198 - Data Payload: The application payload. If the 199 transport layer header is present, it MAY be 200 removed. 202 - Diet-ESP-Trailer: The Padding concatenated with the 203 Pad Length and Next Header fields if they appear in 204 the packet. 206 - Diet-ESP ICV: The ICV generated throw the specified 207 algorithm and MAYBE truncated by Diet-ESP. 209 4. Diet-ESP: Protocol Description 211 This section describes how each field of the ESP can be compressed. 213 SPI SIZE: ESP Security Policy Index is 32 bits long. Diet-ESP omits, 214 leaves unchanged, or reduces the SPI to 8, 16 or 24 bits. The length 215 of the SPI should be guided by 1) the number of simultaneous inbound 216 SA the device is expected to handle and 2) reliability of the IP 217 addresses in order to identify the proper SA for incoming packets. 218 More specifically, a sensor with a single connection to a Security 219 Gateway, may bind incoming packets to the proper SA based only in its 220 IP addresses. In that case, the SPI MAY not be necessary. Other 221 scenarios may consider using the SPI to index the SAs or may consider 222 having multiple ESP channels with the same host from a single host. 223 In that case it may choose a reduced length for the SPI. Note that 224 reducing the size of the SPI may expose the system to security flows. 225 See Section 8 for more details. Note also that the value 0 for the 226 SPI is note allowed to be sent on the wire as described in [RFC4303]. 228 For those cases where a regular SPI of 32 bits has been negotiated 229 (e.g. via IKEv2 [RFC5996]), the resulting SPI used for Diet-ESP 230 packets corresponds to the high order bits of that 32 bits SPI (see 231 Section 6 for further explanations). 233 SN SIZE: ESP Sequence Number is 32 bit and extended SN is 64 bit 234 long. Diet-ESP omits, leaves unchanged or reduces SN to 8, 16, 24 235 bits. The length of the SN should be guided by 1) how the receiving 236 side handles the SN, 2) the number of packets expected to be sent 237 over Diet-ESP channel, and 3) how the node is willing to use IKEv2 to 238 re-key when SN are expired. SN are used to address replay attacks, 239 thus removing SN may expose the system to security flaws. See 240 Section 8 for more details. If SN is used, a 32 bits value may not 241 be required. Table 1 shows the lifetime of one SA before re-keying 242 is required in case the SN expires. 244 +----------+------------------+-------------------+-----------------+ 245 | SN | 1 packet per | 1 packet per | 1 packet per | 246 | Length | second | minute | hour | 247 +----------+------------------+-------------------+-----------------+ 248 | 8 bit | 4min 16sec | 4h 16min | 10 days 16h | 249 | 16 bit | 18h 12min 16sec | 6 weeks 3 days | ~7 years 25 | 250 | | | 12h | weeks | 251 | 24 bit | ~27 weeks 5 days | 31 years 47 weeks | ~1,915 years | 252 | 32 bit | ~136 years | ~8,171 years | ~490,293 years | 253 +----------+------------------+-------------------+-----------------+ 255 Table 1: Lifetime of one Security Association with different sizes of 256 Sequence Numbers compared to different use cases. 258 Note that SN and SPI MUST be aligned to a multiple of the Alignment 259 value (ALIGN). 261 NH: Diet-ESP is able to remove the Next Header field from the ESP- 262 Trailer if the underlying protocol can be derived from the Traffic 263 Selector (TS) within the SA. More specifically, the next header 264 indicates whether the encrypted ESP payload is an IP packet, a UDP 265 packet, a TCP packet or no next header. The NH can only be removed 266 if this has been explicitly specified in the SA or if the device has 267 a single application. Suppose a device sets an ESP channel with 268 another peer only considering the IP addresses as TS without 269 specifying the transport protocols or (or upper layer protocols). If 270 the device uses this channel for multiple upper layer protocols (like 271 HTTP and tnftp), then the NH cannot be removed as the receiver would 272 not be able to determine whether incoming packets are HTTP or tnftp. 274 Note that removing the Next Header impacts how encryption is 275 performed. For example, the use of AES-CBC [RFC3602] mode requires 276 the last block to be padded to reach a 128 bit alignment. In this 277 case removing the Next Header increases the padding by the Next 278 Header length, which is 8 bits. In this case, removing the Next 279 Header provides few advantages, as it does not reduce the ESP packet 280 length. With AES-CBC, the only advantage of removing the Next Header 281 would be for data with the last block of 15 bytes. In that case, ESP 282 pad with 15 modulo 16 bytes, set the 1 byte pad length field to 15 283 and add the one byte Next Header field. This leads to 15 + 15 + 1 + 284 1 bytes to be sent. On the other hand, removing the Next Header 285 would require only the concatenation of the pad length byte with a 0 286 value, which leads to 16 bytes to be sent. 288 Other modes like AES-CTR [RFC3686] do not have block alignment 289 requirements. Using AES-CTR with ESP only requires the 32 bit 290 alignment - mostly for OS implementation. In fact if an n byte 291 alignment is required (for encryption or for packet format), data of 292 length k * n + n - 1 bytes, k an integer, takes advantage of removing 293 the Next Header and reduces the data to be sent over n bytes. In the 294 case of sensor network it is very likely that data of fixed size k * 295 n + n - 1 will be used. Furthermore, if 32 bits alignment is reduced 296 to 8 bits alignment, Next Header is always an additional unnecessary 297 byte being sent. 299 PAD: With ESP, all packets have a Pad Length field. This field is 300 usually present because ESP requires a 32 bits alignment which is 301 performed with padding. Diet-ESP considers that some devices may use 302 8 bits alignment, in which case padding is not necessary. Similarly, 303 sensors may send application data that has fixed length matching the 304 alignment. Note that alignment may be required by the device (8-bit, 305 16-bit, or more generally 32-bit), but it may also be required by the 306 encryption block size (AES-CBC uses 128 bit blocks). With ESP these 307 scenarios would result in an unnecessary Pad Length field always set 308 to zero. Diet-ESP considers those case with no padding, and thus the 309 Pad Length field can be omitted. 311 ALIGN: Alignment for Padding and Pad Length. ESP is designed for 32 312 bit alignment. This is mostly an OS implementation and hardware 313 design requirements for regular PC processors. IoT may not have 314 these requirements. Having no alignment requirements or a 16 bits 315 alignment requirement prevents or reduces the number of padding bytes 316 to be sent. As a result Diet-ESP considers alternative alignment 317 (8-bit, 16 bit, 32 bit) so to reduce the number of padding bytes. 319 Note that when PAD requires the Pad Length field to be present, ALIGN 320 provides the minimum alignment padding considers. More specifically, 321 ALIGN gives more priority to the hardware or OS implementation than 322 to the encryption algorithm used. In fact with AES-CTR padding will 323 be performed based on the value provided by ALIGN. However, AES-CBC 324 padding is performed on the AES block basis (128 bits). This value 325 overwrites the one provided by ALIGN. 327 IH: With ESP using the tunnel mode, the inner IP Header is sent in 328 every ESP Payload. This extra bytes sent do not carry relevant 329 information over sent packets. As a result Diet-ESP indicates the IP 330 header has been omitted, and MUST be rebuilt by the receiver. These 331 information are negotiated via IKE and are stored in the SA. 333 TH: With ESP the transport header is transmitted in every packet. 334 This layer may not provide relevant information, especially for UDP 335 transport layer. The port parameters may be negotiated via IKE and 336 stored in the SA. As a result Diet-ESP indicates that the transport 337 protocol header (TH) has been removed from the encrypted ESP Payload. 338 This option can only be used if the header can be restored or if it 339 is unnecessary for the further packet procession. Other protocols 340 than UDP are considered out of scope of this document. TCP, for 341 example, includes information that are not as easy to restore, like 342 options, controls or windows. In order to use other transport layer 343 protocols within specific configuration, additional information may 344 be provided in the future. 346 ICV: ESP negotiates Authentication protocols. These protocols 347 generate an ICV of a length defined by the authentication protocol 348 negotiated for the SA. These authentication protocols do not provide 349 ways to perform weak authentication, as it only reduces the size of 350 the ICV. IoT is interested in weak authentication as it may sends a 351 small amount of bytes, and the trade-of between battery life time and 352 security may be worth. As a result Diet-ESP indicates the number of 353 bytes of the ICV. Diet-ESP considers sending the whole ICV or the 354 first 1 byte resp (2, 4, 8, 12, 16, 32) bytes. Note that Note that 355 reducing the size of the SPI may expose the system to security flows. 356 See Section 8 for more details. 358 5. Diet-ESP Context: Format Description 360 This section describes the Diet-ESP Context that contains all 361 necessary parameters for Diet-ESP. 363 0 1 364 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 365 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 366 |SPI SIZE|SN SIZE |NH|P |ALIGN|TH|IH| ICV | X| 367 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 369 Figure 2: Diet-ESP Context 371 With the fields defined as below: 373 - SPI SIZE (3 bits): specifies the size of the SPI field length of 374 the Diet-ESP header in byte. Values can be from 0 to 4. A 375 zero value means the SPI does not appear in the Diet-ESP 376 packet. The size depends on the use case, the connection 377 should be used for. 379 - 000: indicates a 0 bit SPI. The SPI is removed from the 380 packet. 382 - 001: indicates an 8 bit SPI in each Diet-ESP-packet. 384 - 010: indicates a 16 bit SPI in each Diet-ESP-packet. 386 - 011: indicates a 24 bit SPI in each Diet-ESP-packet. 388 - 100: indicates a 32 bit SPI in each Diet-ESP-packet. This 389 configuration is according to the RFC 4303 [RFC4303] 391 - 101: Unassigned 393 - 110: Unassigned 395 - 111: Unassigned 397 - SN SIZE (3 bits): specifies the size of the Sequence Number field 398 within the Diet-ESP header in byte. Values can be from 0 to 4. 399 A zero value means the SN does not appear in the Diet-ESP 400 packet. The size depends on the use case, the connection 401 should be used for. 403 - 000: indicates a 0 bit SN. The SN is removed from the 404 packet and anti-replay is disabled on the receiver. 406 - 001: indicates an 8 bit SN in each Diet-ESP-packet. 408 - 010: indicates a 16 bit SN in each Diet-ESP-packet. 410 - 011: indicates a 24 bit SN in each Diet-ESP-packet. 412 - 100: indicates a 32 bit SN in each Diet-ESP-packet. This 413 configuration is according to the RFC 4303 [RFC4303] 415 - 101: Unassigned 417 - 110: Unassigned 419 - 111: Unassigned 421 - NH (1 bit): specifies if the Next Header field appears in the 422 Diet-ESP trailer. NH unset to 0 indicates the Next Header 423 field is present and NH set to 1 indicates the Next Header is 424 omitted. 426 - P (1 bit): specifies if the Pad Length field appears in the Diet- 427 ESP trailer. P unset to 0 indicates the Pad Length field is 428 present and P set to 1 indicates the Pad Length is omitted. 430 - ALIGN (2 bits): specifies Padding, Padding Length as follows: 432 - 00: indicates an 8 bit alignment. The field Pad Length is 433 omitted and the Diet-ESP packet never has Padding. 435 - 01: indicates a 16 bit alignment. The field Pad Length is 436 always present. 438 - 10: indicates a 32 bit alignment. The field Pad Length is 439 always present. 441 - 11: Unassigned 443 - TH (1 bit): specifies if the transport layer field appears in the 444 Diet-ESP Payload Data. TH unset to 0 indicates the Transport 445 header field is present and TH set to 1 indicates the transport 446 header is omitted. In this case, the transport protocol MUST 447 be specified in the SA with its associated port. If a non 448 unique port or a non unique transport protocol is specified, 449 this bit MUST be unset to 0. Otherwise, the device will not be 450 able to rebuilt the transport header. This document only 451 considers UDP. 453 - IH (1 bit): specifies if the inner IP address field appears in the 454 Diet-ESP Payload Data. This bit is only significant for the 455 tunnel mode. With IPsec transport mode, IH SHOULD be set to 0 456 and ignored. With tunnel mode IH unset to 0 indicates the 457 inner IP header field is present and IH set to 1 indicates the 458 inner IP header is omitted. 460 - ICV (2 bits): specifies the transmitted number of bytes to 461 authenticate the Diet-ESP packet. Note that ICV is optional so 462 if one chose not to perform authentication, it SHOULD negotiate 463 the authentication algorithm to NULL as defined in [RFC4835]. 464 The minimum length greater than 0 for ICV is 96 bits and can be 465 generated with the following hash functions: HMAC-MD5-96 466 [RFC2403], HMAC-SHA1-96 [RFC2404], AES-CMAC-96 [RFC4494], AES- 467 XCBC-MAC-96 [RFC3566]. As a result ICV only specifies size 468 lower than 96 bits. 470 - 000: ICV is left untouched as it is specified by the 471 authentication algorithm. 473 - 001: Diet-ESP ICV consists of the 8 most significant bits of 474 ESP ICV. 476 - 010: Diet-ESP ICV consists of the 16 most significant bits 477 of ESP ICV. 479 - 011: Diet-ESP ICV consists of the 32 most significant bits 480 of ESP ICV. 482 - 100: Diet-ESP ICV consists of the 64 most significant bits 483 of ESP ICV. 485 - 101: Unassigned 487 - 110: Unassigned 489 - 111: Unassigned 491 - X (1 bit): Extension bit. When set to 1, this bit indicates an 492 additional byte carry information. In this document, this bit 493 MUST be set to 0. 495 6. Difference between Diet-ESP and ESP 497 This section details how to use Diet-ESP to send and receive 498 messages. The use of Diet-ESP is based on the IPsec architecture 499 [RFC4301] and ESP [RFC4303]. We suppose the reader is familiar with 500 these documents and list here the adaptation that MAY be involved by 501 Diet-ESP. 503 6.1. Packet Alignment 505 In ESP each packet has a fixed alignment to 32 bits. For Diet-ESP 506 each device has an internal parameter that defines the minimal kernel 507 alignment that is acceptable. ALIGN SHOULD be a the maximum of the 508 peer's minimal alignment. 510 Diet-ESP Context with SPI SIZE + SN SIZE that is not a multiple of 511 ALIGN MUST be rejected. 513 6.2. SAD 515 6.2.1. Storing SPI SIZE SPI in the SAD 517 For devices using a single SPI SIZE value (e.g. sensors), the SA will 518 be indexed with the SPI as described in ESP. More specifically, SPI 519 is used as the index in the SAD. The only difference is that it has 520 smaller size in the ESP header. If the only supported SPI SIZE is 521 zero, the lookup has to be performed with the IP address. Some 522 implementations MAY use a specific SPI value in their SAD for 523 unspecified SPIs. 525 For devices that allow multiple SPI SIZE, like some IoT generic end 526 points or IoT Security Gateways, SAD lookup has to deal with SPI of 527 different sizes. The SPI stored in the SAD MAY be converted from an 528 SPI of any size to a standard 4 bytes SPI. This means that for 529 inbound packets a conversion from SPI SIZE byte SPI to 4 byte SPI is 530 performed before the SAD lookup. 532 The SPI of the SA may be negotiated using IKEv2 [RFC5996]. Regular 533 IKEv2 implementation negotiate a 4 byte SPI. In order to be able to 534 use regular IKEv2 for Diet-ESP, the following convention is used. 535 The SPI considered in Diet-ESP consists in the SPI SIZE low power 536 bytes of 32 bit SPI negotiated with IKEv2. Only this value should be 537 considered in the SAD. How the SPI SIZE SPI is represented in the 538 SAD is another issue addressed above. 540 6.2.2. Inbound Security Association Lookup 542 For devices that are configured with a single SPI SIZE value can 543 process inbound packet as defined in [RFC4301]. As such, no 544 modifications is required by Diet-ESP. 546 Detecting Inbound Security Association: Identifying the SA for 547 incoming packets is a one of the main reasons the SPI is send in each 548 packet on the wire. For regular ESP (and AH) packets, the Security 549 Association is detected as follows: 551 1. Search the SAD for a match on {SPI, destination address, source 552 address}. If an SAD entry matches, then process the inbound ESP 553 packet with that matching SAD entry. Otherwise, proceed to step 554 2. 556 2. Search the SAD for a match on {SPI, destination address}. If the 557 SAD entry matches, then process the inbound ESP packet with that 558 matching SAD entry. Otherwise, proceed to step 3. 560 3. Search the SAD for a match on only {SPI} if the receiver has 561 chosen to maintain a single SPI space for AH and ESP, or on {SPI, 562 protocol} otherwise. If an SAD entry matches, then process the 563 inbound ESP packet with that matching SAD entry. Otherwise, 564 discard the packet and log an auditable event. 566 For device that are dealing with different SPI SIZE SPI, the way 567 inbound packets are handled differs from the [RFC4301]. In fact, 568 when a inbound packet is received, the peer does not know the SPI 569 SIZE. As a result, it does not know the SPI that applies to the 570 incoming packet. The different values could be the 0 (resp. 1, 2, 3 571 and 4) first bytes of the IP payload. 573 Since the size of the SPI is not known for incoming packets, the 574 detection of inbound SAs has to be redefined in a Diet-ESP 575 environment. In order to ensure a detection of a SA the above 576 described regular detection have to be done for each supported SPI 577 size (in most cases 5 times). In most common cases this will return 578 a unique Security Association. 580 If there is more than one SA matching the lookup, the authentication 581 MUST be performed for all found SAs to detect the SA with the correct 582 key. In case there is no match, the packet MUST be dropped. Of 583 course this can lead into DoS vulnerability as an attacker recognizes 584 an overlap of one or more IP-SPI combinations. Therefore it is 585 highly recommended to avoid different values of the SPI SIZE for one 586 tuple of Source and Destination IP address. Furthermore this 587 recommendation becomes mandatory if NULL authentication is supported. 588 This is easy to implement as long as the sensors are not mobile and 589 do not change their IP address. 591 The following optimizations MAY be considered for sensor that are not 592 likely to perform mobility or multihoming features provided by MOBIKE 593 [RFC4555] or any change of IP address during the lifetime of the SA. 595 Optimization 1 - SPI SIZE is mentioned inside the SPI: The SPI SIZE 596 is defined as part of the SPI sent in each packet. Therefore the 597 receiver has to choose the most significant 2 bits of the SPI in the 598 following way in order to recognize the right size for incoming Diet- 599 ESP packets: 601 00: SPI SIZE of 1 byte is used. 603 01: SPI SIZE of 2 byte is used. 605 10: SPI SIZE of 3 byte is used. 607 11: SPI SIZE of 4 byte is used. 609 If the the value 0 is chosen for the SPI SIZE this option does not 610 feasible. 612 Optimization 2 - IP address based lookup: IP addressed based search 613 is one optimization one MAY choose to avoid several SAD lookups. It 614 is based on the IP address and the stored SPI SIZE, which MUST be the 615 same value for each SA of one IP address. Otherwise it can't neither 616 be ensured that an SA is found nor that the correct one is found. 618 Note that in case of mobile IP the SPI SIZE MUST be updated for all 619 SAs related to the new IP address which may cause in renegotiation. 620 Figure Figure 3 shows this lookup described below. 622 1. Search most significant SA as follows: 624 1.1 Search the first SA for a match on {destination address, 625 source address}. If an SA entry matches, then process to step 626 2. Otherwise, proceed to step 1.2. 628 1.2 Search the first SA for a match on {source address}. If an SA 629 entry matches, then process to step 2. Otherwise, drop the 630 packet. 632 2. Identify the size of the compressed SPI for the found SA, stored 633 in the Diet-ESP context. Note that all SAs to one IP address MUST 634 have the same value for the SPI SIZE. Then go to step 3. 636 3. If the SPI SIZE is NOT zero, read the SPI SIZE SPI from the packet 637 and perform a regular SAD lookup as described in [RFC4301]. If 638 the SPI SIZE is zero, the SA from step 1 is unique and can be 639 used. 641 Note that some implementation MAY collect all SPI matching the IP 642 addresses in step 2 to avoid an additional lookup over the whole SAD. 643 This is implementation dependant. 645 +-----------+ 646 | START | 647 +-----------+ 648 | 649 V 650 +-----------------+ 651 | find 1st SA to | 652 | IP address |------------------+ 653 +-----------------+ | 654 | | 655 ____V____ V 656 yes / \ +-----+ 657 +------/ SPI_SIZE \ /----->|'---'| 658 | \ = 0 ? / / | SAD | 659 | \_________/ / + + 660 | |no / '---' 661 | V / 662 | +-----------------+ / 663 | | find 1st SA to |--/ 664 | | SPI +IP | 665 | | address | 666 | +-----------------+ 667 | | 668 | V 669 | +-----------------+ 670 | | Diet-ESP packet | 671 +-->| procession | 672 +-----------------+ 674 Figure 3: SAD lookup for incoming packets. 676 If the sensor is likely to change its IP address, the outcome MAY be 677 a given IP address associated to different SPI SIZE. This case MAY 678 occur if one IP address has been used by a device not anymore online, 679 but the SA has not been removed. The IP has then been provided to 680 another device. In this case the Diet-ESP Context SHOULD NOT be 681 accepted by the Security Gateway when the new Diet-ESP Context is 682 provided to the Security Gateway. At least the Security Gateway can 683 check the previous peer is reachable and then delete the SA before 684 accepting the new SA. 686 Another case MAY be that a sensor got two interfaces with different 687 IP addresses, negotiates a different SPI SIZE on each interface and 688 then use MOBIKE to move the IPsec channels from one interface to the 689 other. In this case, the Security Gateway SHOULD NOT accept the 690 update, or force a renegotiation of the SPI SIZE for all SAs, 691 basically by re-keying the SAs. 693 6.2.3. Outgoing Security Association Lookup 695 Outgoing lookups for the SPI are performed in the same way as it is 696 done in ESP. The Traffic Selector for the packet is searched and the 697 right SA is read from the SA. The SPI used in the packet MUST be 698 reduced to the value stored in SPI SIZE. 700 6.3. Sequence Number 702 Sequence number in ESP [RFC4303] can be of 4 bytes or 8 bytes for 703 extended ESP. Diet-ESP introduces different sizes. One way to deal 704 with this is to add a MAX_SN value that stores the maximum value the 705 SN can have. Any new value of the SN will be check against this 706 MAX_SN. 708 6.4. Outgoing Packet processing 710 NH, TH, IH, P indicate fields or payloads that are removed from the 711 Diet-ESP packet. How the Diet-ESP packet is generated depends on the 712 Payload Data of lPD bytes, BLCK the block size of the encryption 713 algorithm and the device alignment ALIGN. We note M = MAX(BLCK, 714 ALIGN). Although not normative the resulting Diet-ESP packet should 715 be and explained below. We consider the Diet-ESP Payload as 716 described in Section 3 718 - 1: if TH is set to 1, then remove the transport layer of the 719 Payload Data. 721 - 2: if IH is set to 1, and the IPsec mode is tunnel, then remove 722 the inner IP address of the Payload Data. 724 - 3: if PAD is set to 0 and NH is set to 0: Diet-ESP considers both 725 fields Pad Length and Next Header. The Diet-ESP Payload is the 726 encryption of the following clear text: Payload Data | Padding 727 of Pad Length bytes | Pad Length field | Next Header field. 728 The Pad Length value is such that lPD + 2 + Pad Length = 0 [M]. 730 - 4: if PAD is set to 0 and NH is set to 1: Diet-ESP considers the 731 Pad Length field but removes the Next Header field. The ESP 732 Payload is the encryption of the following clear text: Payload 733 Data | Padding of Pad Length bytes | Pad Length field | Next 734 Header field. The Pad Length value is such that lPD + 1 + Pad 735 Length = 0 [M]. 737 - 5: if PAD is set to 1 and NH is set to 0: Diet-ESP considers the 738 Next Header but do not consider the Pad Length field or the 739 Padding Field. This is valid as long as lPD + 1 = 0 [M]. If M 740 = 1 as it is the case for AES-CTR this equation is always true. 742 On the other hand the use of specific block size requires the 743 application to send specific length of application data. 745 - 6: if PAD is set to 1 and NH is set to 1: Diet-ESP does consider 746 neither the Next Header field nor the Pad Length field nor the 747 Padding Field. This is valid as long as lAD = 0 [M]. If M = 1 748 as it is the case for AES-CTR this equation is always true. On 749 the other hand the use of specific block size requires the 750 application to send specific length of application data. 752 6.5. Inbound Packet processing 754 Decryption is for performed the other way around. 756 After SAD lookup, authenticating and decrypting the Diet-ESP payload 757 the original packet is rebuild as follows: 759 - 1: if PAD is set to 1 and NH is set to 1: Diet-ESP does consider 760 neither the Next Header field nor the Pad Length field nor the 761 Padding Field. The Next Header field of the IP packet is set 762 to the protocol defined for incoming traffic within the Traffic 763 Selector of the SA. Because there is no Padding it is 764 disregarded. 766 - 2: if PAD is set to 1 and NH is set to 0: Diet-ESP considers the 767 Next Header but do not consider the Pad Length field or the 768 Padding Field. The Next Header field of the IP packet is set 769 to the value within the Diet-ESP trailer. 771 - 3: if PAD is set to 0 and NH is set to 1: Diet-ESP considers the 772 Pad Length field but removes the Next Header field. The Next 773 Header field of the IP packet is set to the protocol defined 774 for incoming traffic within the Traffic Selector of the SA. 775 The Pad Length field is read and the Padding is removed from 776 the Data Payload which results the original Data Payload. 778 - 4: if PAD is set to 0 and NH is set to 0: Diet-ESP considers both 779 fields Pad Length and Next Header. The Next Header field of 780 the IP packet is set to the value within the Diet-ESP trailer. 781 The Pad Length field is read and the Padding is removed from 782 the Data Payload which results the original Data Payload. 784 - 5: if IH is set to 1, and the IPsec mode is tunnel and the IP 785 header is reconstructed. The source and destination address 786 and the Next Header field are read from the Traffic Selector. 787 The Payload Length is calculated including the size of the 788 transport header, regardless if it is removed with TH or not. 789 All other IP-header values are set to common defaults or have 790 to be negotiated otherwise which is out of scope of this 791 document. 793 -6: if TH is set to 1, the Transport layer header is restored with 794 the information in the Security Association. Section 4 795 describes some differences between the different protocols. In 796 this document we focus on UDP which can be easily restored with 797 the ports inside the Traffic Selector. The Length field can be 798 calculated and the checksum can be left as 0 according to 799 [RFC0768] 801 7. IANA Considerations 803 There are no IANA consideration for this document. 805 8. Security Considerations 807 This section lists security considerations related to the Diet-ESP 808 protocol. 810 Small SPI SIZE exposes the device to DoS. For a device, the number 811 of SA is related to the number of SPI. For systems using small SPI 812 SIZE values as index of their database, the number of simultaneous 813 communications is limited by the SPI SIZE. This means that a given 814 device initiating SPI SIZE communications can isolate the system. In 815 order to leverage this vulnerability, one can consider receiving 816 systems that generate 32 bits SPI with a hash function that considers 817 different parameters associated to the reduced SPI. For example, if 818 one use the IP addresses as well as the reduced SPI, the number of 819 SPI becomes SPI SIZE per IP address. This may be sufficient as 820 sensors are not likely to perform multiple communications. 822 Small size of ICV reduces the authentication strength. For example 8 823 bits mean that authentication can be spoofed with a probability of 1/ 824 256. Standard value considers a length of 96 bit for reliable 825 authentication. If specified, the ICV field is truncated after the 826 given number of bits which, for sure, has to be mentioned while 827 incoming packet procession as well. For removing authentication ESP 828 NULL has to be negotiated, as described in RFC4303. 830 Removing the SN prevents protection against replay attack. 832 9. NAT Considerations 834 This section lists considerations related to the use of Diet-ESP in 835 NAT environments. 837 Diet-ESP is a protocol designed for the IoT, assuming to work in an 838 IPv6 environment. However, ESP is designed to work in every IP 839 environment whereas Diet-ESP can be delivered in other IP 840 environments like IPv4 as well. This environment MAY cause the need 841 of NAT. In IPsec, UDP encapsulation is used to deal with NAT 842 environments as described in [RFC3948]. Because UDP cannot define 843 the underlying protocol with a Next Header, IKEv2 traffic is 844 distinguished from ESP or AH traffic by sending the Non-ESP Marker (4 845 bytes ZERO) after the UDP header. As the SPI is considered to never 846 be ZERO this clearly identifies IKEv2 traffic. 848 In context of Diet-ESP the SPI MAY not be present in the Diet-ESP- 849 header, which MAY corrupt this mechanism in case: 851 - the 4 byte SN is ZERO 853 - the SN is absent and the first 4 byte of the encrypted payload are 854 ZERO 856 - the compressed SN is ZERO AND the remaining bytes of the encrypted 857 payload are ZERO 859 Therefore an implementer has to define a way to ensure the first 4 860 bytes are NOT zero. We suggest the negotiated SPI to be at least 1 861 byte if UDP encapsulation is enabled. 863 10. Acknowledgment 865 Diet-ESP is a joint work between Orange and Ludwig-Maximilians- 866 Universitaet Munich. 868 11. References 870 11.1. Normative References 872 [I-D.raza-6lowpan-ipsec] 873 Raza, S., Duquennoy, S., and G. Selander, "Compression of 874 IPsec AH and ESP Headers for Constrained Environments", 875 draft-raza-6lowpan-ipsec-01 (work in progress), September 876 2013. 878 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 879 August 1980. 881 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 882 Requirement Levels", BCP 14, RFC 2119, March 1997. 884 [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within 885 ESP and AH", RFC 2403, November 1998. 887 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 888 ESP and AH", RFC 2404, November 1998. 890 [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm 891 and Its Use With IPsec", RFC 3566, September 2003. 893 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 894 Algorithm and Its Use with IPsec", RFC 3602, September 895 2003. 897 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 898 Counter Mode With IPsec Encapsulating Security Payload 899 (ESP)", RFC 3686, January 2004. 901 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 902 Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 903 3948, January 2005. 905 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 906 Internet Protocol", RFC 4301, December 2005. 908 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 909 4303, December 2005. 911 [RFC4494] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96 912 Algorithm and Its Use with IPsec", RFC 4494, June 2006. 914 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 915 (MOBIKE)", RFC 4555, June 2006. 917 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 918 Requirements for Encapsulating Security Payload (ESP) and 919 Authentication Header (AH)", RFC 4835, April 2007. 921 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 922 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 923 5996, September 2010. 925 11.2. Informational References 927 [RFC5856] Ertekin, E., Jasani, R., Christou, C., and C. Bormann, 928 "Integration of Robust Header Compression over IPsec 929 Security Associations", RFC 5856, May 2010. 931 Appendix A. Comparison 933 This section compares the proposed Diet ESP with 6LoWPAN ESP 934 [I-D.raza-6lowpan-ipsec] related to IoT use cases. It shows the 935 different ESP packet sent with the two compression methods. In each 936 case the maximum possible compression is used and the underlying UDP 937 header is compressed as much as possible. The big advantage of Diet 938 ESP compression removing the UDP header appears. Furthermore there 939 are no additional compression configuration bytes to be sent in each 940 packet, like done in 6LoWPAN compression, because the configuration 941 is negotiated at the beginning of the communication the during the 942 IKEv2 [RFC5996] negotiation. Diet ESP uses the idea of ROHC[RFC5856] 943 compression removing the disadvantage that the whole packet has to be 944 sent once at the beginning of the connection, because it considers 945 that a lot of information of the Security Association can be reused 946 to decompress the packet. 948 Both comparisons are using 8 bits alignment. The figures are aligned 949 to 16 bits to improve the readability. 951 A.1. Transmitting 1 Byte without anti-replay 953 6LoWPAN offers compression of the Sequence Number to 8, 16, 24 bit 954 has to be sent in each packet, even if it is not going to be used. 956 6LoWPAN does not offer to reduce the ICV as it is not removed with 957 NULL-authentication. Diet-ESP offers reducing to fair securely 64 958 bits. 960 AES-CTR is used for encryption. 962 Figure 4a and 4b show this comparison. The advantage of Diet ESP for 963 this example is 96 bits. 965 0 1 966 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 967 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 968 0| initialization vector | 969 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 970 16| initialization vector | 971 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 972 32| initialization vector | 973 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 974 48| initialization vector | 975 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 976 64| 1 byte data | ICV | 977 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 978 80| ICV | 979 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 980 96| ICV | 981 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 982 112| ICV | 983 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 984 128| ICV | 985 +--+--+--+--+--+--+--+--+ 987 Figure 4a) 1 byte Data Payload with Diet-ESP. (no SPI, no SN, no PAD, 988 no NH) 990 0 1 991 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 992 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 993 0| Id | SPI | SN | SN | 994 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 995 16| initialization vector | 996 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 997 32| initialization vector | 998 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 999 48| initialization vector | 1000 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1001 64| initialization vector | 1002 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1003 80| Id |0 |C | P |source port| dest port | 1004 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1005 96| length | 1006 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1007 112| 1 byte data | pad length | 1008 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1009 128| next header | ICV | 1010 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1011 144| ICV | 1012 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1013 160| ICV | 1014 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1015 176| ICV | 1016 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1017 192| ICV | 1018 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1019 208| ICV | 1020 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1021 224| ICV | 1022 +--+--+--+--+--+--+--+--+ 1024 Figure 4b) 1 byte data payload with 6LoWPAN ESP. (no SPI, 8 bits SN, 1025 8 bits pad length, 8 bits 6LoWPAN NH) 1027 A.2. Transmitting 1 Byte to multi directional connections. 1029 Having multiple connections to one host implies the use of the SPI to 1030 identify the correct Security Association. Diet ESP allows the 1031 reduction to 8, 16 and 24 bit. 6LoWPAN ESP offers quite the same 1032 reductions, except 24 bit. In most sensor use cases 254 possible 1033 connection are more than enough, whereas the following two pictures 1034 show the advantage of Diet ESP against 6LoWPAN ESP for an 8 bit SPI. 1035 Since there is no possibility to remove the SN with 6LoWPAN it has to 1036 be at least 8 Bit. 1038 6LoWPAN offers compression of the Sequence Number to 8, 16, 24 bit 1039 has to be sent in each packet, even if it is not going to be used. 1041 6LoWPAN does not offer to reduce the ICV as it is not removed with 1042 NULL-authentication. Diet-ESP offers reducing to fair securely 64 1043 bits. 1045 AES-CTR is used for encryption. 1047 Figure 5a and 5b show this comparison. In case of an 8 bit SPI the 1048 advantage is 96 bits. For a 24 bit SPI the advantage would be 104 1049 bits. 1051 0 1 1052 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1053 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1054 0| SPI | initialization vector | 1055 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1056 16| initialization vector | 1057 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1058 32| initialization vector | 1059 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1060 48| initialization vector | 1061 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1062 64| initialization vector | 1 byte data | 1063 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1064 80| ICV | 1065 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1066 96| ICV | 1067 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1068 112| ICV | 1069 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1070 128| ICV | 1071 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1073 Figure 5a) 1 byte Data Payload with Diet-ESP. (8 bits SPI, no SN, no 1074 PAD, no NH) 1076 0 1 1077 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1078 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1079 0| Id | SPI | SN | SPI | 1080 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1081 16| SN | initialization vector | 1082 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1083 32| initialization vector | 1084 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1085 48| initialization vector | 1086 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1087 64| initialization vector | 1088 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1089 80| initialization vector | Id |0 |C | P | 1090 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1091 96|source port| dest port | length | 1092 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1093 112| length | 1 byte data | 1094 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1095 128| pad length | next header | 1096 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1097 144| ICV | 1098 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1099 160| ICV | 1100 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1101 176| ICV | 1102 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1103 192| ICV | 1104 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1105 208| ICV | 1106 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1107 224| ICV | 1108 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1110 Figure 5b) 1 byte data payload with 6LoWPAN ESP. (32 bits SPI, 16 1111 bits SN, 8 bits pad length, 8 bits 6LoWPAN NH) 1113 Appendix B. Document Change Log 1115 [draft-mglt-dice-diet-esp-00.txt]: First version published. 1117 [draft-mglt-ipsecme-diet-esp-00.txt]: 1118 NAT consideration added. 1119 Comparison actualized to new Version of 6LoWPAN ESP. 1121 Authors' Addresses 1123 Daniel Migault 1124 Orange 1125 38 rue du General Leclerc 1126 92794 Issy-les-Moulineaux Cedex 9 1127 France 1129 Phone: +33 1 45 29 60 52 1130 Email: daniel.migault@orange.com 1132 Tobias Guggemos 1133 Orange / LMU Munich 1134 Am Osteroesch 9 1135 87637 Seeg, Bavaria 1136 Germany 1138 Email: tobias.guggemos@gmail.com 1140 Daniel Palomares 1141 Orange / LIP6 - UMPC 1142 10, Rue du Moulin 1143 92170 Vanves, Ille-de-France 1144 France 1146 Email: daniel.palomares@orange.com