idnits 2.17.1 draft-raza-dice-compressed-dtls-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6282], [RFC6347]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 10, 2014) is 3699 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: 'IEEE802.15.4' is mentioned on line 90, but not defined == Missing Reference: 'RFC2119' is mentioned on line 127, but not defined == Unused Reference: 'KEYWORDS' is defined on line 506, but no explicit reference was found in the text == Unused Reference: 'RFC4303' is defined on line 516, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Duplicate reference: RFC6282, mentioned in 'RFC4303', was also mentioned in 'RFC6282'. -- Possible downref: Non-RFC (?) normative reference: ref. 'WiSec13' -- Possible downref: Non-RFC (?) normative reference: ref. 'Lithe13' Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DICE Working Group S. Raza 3 Internet-Draft SICS, Stockholm 4 Intended Status: Standard Track H. Shafagh 5 ETH Zurich 6 O. Dupont 7 Cisco Systems, Paris 8 Expires: September 11, 2014 March 10, 2014 10 Compression of Record and Handshake Headers for Constrained Environments 11 draft-raza-dice-compressed-dtls-00 13 Abstract 15 This document describes header compression mechanisms for the 16 Datagram Transport Layer Security (DTLS) [RFC6347] based on the 17 encoding scheme standardized in [RFC6282]. The DTLS Record Header 18 (RH), Handshake Header (HH), and optionally handshake message headers 19 are compressed using Next Header Compression (NHC) defined in 20 [RFC6282]. This document neither invalidates any encoding schemes 21 proposed in 6LoWPAN [RFC6282] nor compromises the end-to-end security 22 properties provided by DTLS. This document aims to increase the 23 applicability of DTLS and, thus, CoAPs [draft-ietf-core-coap-18] in 24 constrained environments. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 11, 2014. 43 Copyright and License Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Linking DTLS Header Compression with 6LoWPAN . . . . . . . . . 4 63 3. LOWPAN_NHC for the Record Header . . . . . . . . . . . . . . . 4 64 4. LOWPAN_NHC for the Record Plus Handshake Headers . . . . . . . 6 65 5. LOWPAN_NHC for the Handshake Messages . . . . . . . . . . . . . 7 66 6. Summary of DTLS header sizes with and without Compression . . . 10 67 7. Implementation Considerations . . . . . . . . . . . . . . . . . 10 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 11 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 70 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 73 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 76 1 Introduction 78 To protect CoAP transmissions, Datagram TLS (DTLS) has been proposed 79 as the primary security protocol. Analogous to TLS-protected HTTP 80 (HTTPs), the DTLS-secured CoAP protocol is termed CoAPs. DTLS is a 81 chatty protocol and requires numerous message exchanges to establish 82 a secure session. While DTLS supports a wide range of cryptographic 83 primitives for peer authentication and payload protection, it was 84 originally designed for network scenarios where message length was 85 not a critical design criterion. Therefore, it is inefficient to use 86 the DTLS protocol, as it is, for constrained devices. To cope with 87 constrained resources and the size limitations of IEEE 802.15.4-based 88 networks, 6LoWPAN header compression mechanisms are defined. 89 [RFC6282] defines how IPv6 datagrams can be routed over IEEE 802.15.4 90 [IEEE802.15.4]-based networks. [RFC6282] defines header compression 91 schemes that can significantly reduce the size of IP, IP extensions, 92 and UDP headers. It is particularly beneficial to apply the 6LoWPAN 93 header compression mechanisms to compress other protocols having 94 well-defined header fields, such as DTLS. This document provides 95 header compression for the DTLS Record, Handshake, and handshake 96 messages headers with 6LoWPAN header compression mechanisms. This 97 enables the routing of heavy-weight IP traffic to resource- 98 constrained [IEEE802.15.4]-based wireless network. 100 The DTLS header compression defined in this documents does not 101 compromise the DTLS ability to provide end-to-end security between 102 constrained nodes and hosts on the Internet. The security in 103 [IEEE802.15.4]-based IP networks or what is more commonly known 104 6LoWPAN networks is particularly important as we connect the insecure 105 Internet with the vulnerable wireless network. The purpose of DTLS 106 header compression is twofold. First, achieving energy efficiency by 107 reducing the message size, since communication requires more energy 108 than computation. Second, avoiding 6LoWPAN fragmentation that is 109 applied when the size of a datagram is larger than the link layer 110 MTU. Avoiding fragmentation, whenever possible, is also important 111 from the security point of view as the 6LoWPAN protocol is vulnerable 112 to fragmentation attacks [WiSec13]. 114 Generic Header Compression (GHC) [draft-bormann-6lowpan-ghc-06], 115 analogous to NHC, is also defined to allow upper layer (UDP payload 116 and above) header compression. 6LoWPAN-GHC is a generic compression 117 scheme for all headers and header-like structures, and is not 118 targeted for the DTLS protocol; also, it is generally a slightly less 119 efficient approach. It is an alternative to the approach presented in 120 this document and it is worth evaluating the two approaches for the 121 DTLS Record and Handshake headers. 123 1.1 Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 2. Linking DTLS Header Compression with 6LoWPAN 130 [RFC6282] defines the general format of NHC that can be used to 131 encode DTLD headers. In order to apply 6LoWPAN header compression 132 mechanisms to compress headers in the UDP payload, we either require 133 a modification in the current NHC encodings for UDP in the 6LoWPAN 134 standard, or need to define a new NHC for UDP with different ID bits. 135 The first solution requires modification in the current standard and 136 hence is not a favorable solution. The second solution, that is used 137 in this document, is an extension to the 6LoWPAN standard; a similar 138 approach is adapted to distinguish NHC from GHC [draft-bormann- 139 6lowpan-ghc-06]. The ID bits 11110 in the NHC for UDP, as defined in 140 the 6LoWPAN standard, indicate that the UDP payload is not 141 compressed. We define the ID bits 11011 in the NHC for UDP to 142 indicate that the UDP payload is compressed with 6LoWPAN_NHC. The ID 143 bits 11011 are currently unassigned in the 6LoWPAN standard. Figure 1 144 shows our proposed NHC for UDP that allows compression of UDP 145 payload; in the case of DTLS, the UDP payload contains the NHC 146 compressed DTLS headers. 148 0 1 2 3 4 5 6 7 149 +---+---+---+---+---+---+---+---+ 150 | 1 | 1 | 0 | 1 | 1 | C | P | 151 +---+---+---+---+---+---+---+---+ 153 Figure 1: 6LOWPAN_NHC for UDP which allows compression of UDP payload 155 3. LOWPAN_NHC for the Record Header 157 The Record protocol adds header fields of 13 bytes length to each 158 packet that is sent throughout the lifetime of a device that uses 159 DTLS. The header compression proposed in this section reduces the 160 Record header length to 4 bytes (plus one byte for the NHC). In 161 contrary to the handshake header and messages, the Record header 162 remains un-encrypted in all cases. Thus it can always be compressed 163 using the mechanism explained in this section. 165 In order to provide header compression for the Record and Handshake 166 headers, this document discusses two cases. In the first case, the 167 Record header fragment field contains a handshake message; the next 168 section defines header compression regarding this case. In the second 169 case, the fragment field in the Record header is not a handshake 170 message, it is mostly application data, or could be a DTLS alert 171 message or ChangeCipherSpec. Figure 2 shows 6LoWPAN_NHC encoding for 172 the Record header (LOWPAN_NHC_R). 174 0 1 2 3 4 5 6 7 175 +---+---+---+---+---+---+---+---+ 176 | 1 | 0 | 0 | 1 | V | EC| SN | 177 +---+---+---+---+---+---+---+---+ 179 Figure 2: Proposed LOWPAN NHC encoding for the DTLS Record header 181 The encoded bits have the following functions: 183 o The first four bits in the NHC represent the NHC ID we define for 184 the Record header. These are set to 1001. 186 o Version (V): If 0, the version is the DTLS latest version which is 187 1.2, and the field is omitted. If 1, the version field is carried 188 inline. 190 o Epoch (EC): If 0, an 8 bit epoch is used and the left most 8 bits 191 are omitted. If 1, all 16 bits of the epoch are carried inline. In 192 most cases the actual epoch is either 0 or 1. Therefore, an 8 bit 193 epoch is used most of the time, allowing for a higher space. 195 o Sequence Number (SN): The sequence number consists of 48 bits, of 196 which some are leading zeros. If SN is set to 00, a 16 bit 197 sequence number is used and the left most 32 bits are omitted. If 198 01, a 24 bit sequence number is used and the left most 24 bits are 199 omitted. If 10, a 32 bit sequence number is used and the left most 200 16 bits are omitted. If 11, all 48 bits of the sequence number are 201 carried inline. The SN field in the Record header contains a value 202 1 for the first packet sent, and it is incremented sequentially 203 for the subsequent packets. Note that by using 16-bit sequence 204 number we do not limit the size of sequence number to 2^(16-1), 205 but propose to use 16 bits for the sequence number prior to the 206 transmission of the 2^16th packet on a DTLS connection. From the 207 2^16 to 2^(24-1) we propose to use 24-bit sequence numbers. Follow 208 the same procedure for the 32-bit sequence numbers as well. 209 However, the sender and the receiver sequence-number-counters must 210 be reset prior to sending the 2^48th packet. 212 In the Record header, content_type field is always carried inline. 213 The length field in the Record header is omitted as we expect only 214 one DTLS record per UDP packet in constrained environments. While a 215 source device inside a 6LoWPAN sends one DTLS record per UDP packet, 216 a typical destination device on the conventional Internet side may 217 send multiple DTLS records in a single UDP packet. However, as the 218 6BR performs the compression/decompression of incoming packets, there 219 is the possibility to enforce one DTLS record per UDP packet before 220 routing these packets in 6LoWPAN networks. The length field can be 221 deduced from the lower layers: either from the 6LoWPAN header or the 222 IEEE 802.15.4 header. Figure 3 shows a sample NHC compressed IP/UDP 223 packet secured with the Record protocol. 225 | octet 1 | octet 2 | octet 3 | octet 4 | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | LOWPAN_IPHC | Hop Limit | Source Address| 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Source Address| Destination Address | LOWPAN_NHC_UDP| 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 |S Port |D Port | Checksum | LOWPAN_NHC_R | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Content Type | Epoch | Sequence Number | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | | 236 + Initialization Vector (IV) [16 bytes for AES] + 237 | | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Application Data Fragment (Variable Size) | 240 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | | | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 243 | | 244 + MAC (Variable Size) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | | padding |Padding Length | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Figure 3: A sample NHC compressed IP/UDP packet containing an 249 application data such as a CoAP message. 251 4. LOWPAN_NHC for the Record Plus Handshake Headers 253 In the case where the Record header fragment field contains a 254 handshake message, we compress both the Record header and the 255 Handshake header using a single encoding byte and define 6LoWPAN_NHC 256 for Record+Handshake (6LoWPAN_NHC_RH). The Handshake protocol 257 requires 12 bytes of the handshake header. Using the proposed 258 6LoWPAN_NHC_RH the handshake header length is reduced to 3 bytes. 259 Figure 4 shows 6LoWPAN NHC encoding for the Record+Handshake 260 headers. 262 0 1 2 3 4 5 6 7 263 +---+---+---+---+---+---+---+---+ 264 | 1 | 0 | 0 | 1 | V |EC |SN | F | 265 +---+---+---+---+---+---+---+---+ 267 Figure 4: LOWPAN_NHC encoding for the DTLS Record plus Handshake headers 269 The encoded bits have the following functions: 271 o The first four bits represent the ID field that is used to 272 distinguish 6LoWPAN_NHC_RH from other encodings, and to comply 273 with 6LoWPAN_NHC encoding scheme. In case of 6LoWPAN_NHC_RHS we 274 set the ID bits to 1000. 276 o The Version (V) and Epoch (EC) are encoded using the same scheme 277 presented in Section 3. 279 o If SN is set to 0, a 16 bit sequence number is used and the left 280 most 32 bits are omitted. If 1, all 48 bits of the sequence number 281 are carried inline. 283 o Fragment (F): If 0, the handshake message is not fragmented and the 284 fields fragment_offset and fragment_length are omitted. This is 285 the common case, which occurs when a handshake message is not 286 larger than the maximum record size. If 1, the fields 287 fragment_offset and fragment_length are carried inline. 289 In contrary to the scheme defined in Section 3, the content_type 290 field is always omitted as it is obvious based on the ID bits that 291 the content type is the Handshake protocol. The message_type and 292 message_sequence fields of the Handshake header are always carried 293 inline. The length field in the Handshake headers is always omitted 294 as it can be deduced from the lower layers: either from the 6LoWPAN 295 header or the IEEE 802.15.4 header. We have to un-compress layer-wise 296 from lower to higher layers until the UDP header is uncompressed. 297 Then the length of the UDP payload is known and the DTLS payload 298 length can be calculated. 300 With this combined encoding scheme the 25 bytes of Record plus 301 Handshake headers are bring down to 6 bytes (plus one additional byte 302 for the 6LoWPAN_NHC_RH). Considering that a handshake process 303 consists of 10 messages, sending 18 less bytes for each message is a 304 very significant saving. This contributes to the feasibility of using 305 the chatty handshake protocol for constrained nodes. 307 5. LOWPAN_NHC for the Handshake Messages 308 The Handshake protocol consists of 10 messages, all having well- 309 defined headers. We can compress some of the handshake messages. Two 310 of the handshake messages with most number of header fields are 311 ClientHello and ServerHello. Using the 6LoWPAN_NHC for the 312 ClientHello message (6LoWPAN_NHC_CH) defined in this document, we can 313 omit all ClientHello fields except the random field. The minimum 314 possible size of a ClientHello message without the random field is 10 315 bytes: version (2), session_id length(1), cookie length (1), 316 cipher_suites length (2), cipher_suites (2), compression_methods 317 length (1), compression_methods (1). By appling 6LoWPAN_NHC_CH the 318 minimum possible size of a ClientHello message without a random field 319 is 1 byte that is used to encode 6LoWPAN_NHC_CH. This is the common 320 case when DTLS is used to secure CoAP messages. Figure 5 depicts the 321 NHC encoding for the ClientHello message. 323 0 1 2 3 4 5 6 7 324 +---+---+---+---+---+---+---+---+ 325 | 1 | 0 | 1 | 0 | SI| C |CS |CM | 326 +---+---+---+---+---+---+---+---+ 328 Figure 5: LOWPAN_NHC encoding for the DTLS ClientHello Message 330 The function of each compressed header field is described below: 332 o The first four bits in the 6LoWPAN_NHC_CH represent the ID field 333 which are set to 1010. 335 o Session ID (SI) and Cookie (C): If 0, the session_id and/or cookie 336 fields are not available and these fields and 8 bits of the 337 prefixed length fields are omitted. In the (D)TLS protocol, 338 session_id is empty if no session is available, or if the client 339 wishes to generate new security parameters. The ClientHello 340 message uses session_id only if the DTLS client wants to resume 341 the old session. If SI or C is set to 1, the session_id and/or 342 cookie fields are carried inline. 344 o Cipher Suites (CS): If 0, the default (mandatory) cipher suite for 345 CoAP that supports automatic key management is used and this field 346 and the prefixed 16 bits length field are omitted. In the current 347 CoAP draft, TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 is a mandatory 348 cipher suite. If CS is set to 1, the cipher_suites field is 349 carried inline. 351 o Compression Methods (CM): If 0, the default compression method, 352 i.e., COMPRESSION_NULL is used and this field and the prefixed 8 353 bits length field are omitted. If CM is set to 1, the 354 compression_methods field is carried inline. 356 The random field in the ClientHello is always carried inline whereas 357 the version field is always omitted. The version contains the same 358 value as in the DTLS Record header. In case of TLS/SSL the version 359 field was defined to let a TLS client specify an older version to be 360 compatible with an SSL client, which is rarely used in practice. All 361 current versions of web browsers use the same TLS version in Record 362 and ClientHello. DTLS 1.2 (adapted from TLS 1.2) mentions that the 363 client sends its latest supported version in the ClientHello message. 364 All DTLS versions (1.0 and 1.2) have compatible ClientHello messages. 365 If the server does not support this version, then the ServerHello 366 message contains its supported version. If the client is not capable 367 of handling server's version, it terminates the connection with a 368 protocol version alert. 370 Figure 6 shows a sample compressed IP/UDP datagram that contains a 371 ClientHello. 373 | octet 1 | octet 2 | octet 3 | octet 4 | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | LOWPAN_IPHC | Hop Limit | Source Address| 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Source Address| Destination Address | LOWPAN_NHC_UDP| 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 |S Port |D Port | Checksum | LOWPAN_NHC_RHS| 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Epoch | Sequence Number | Message Type | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Message Sequence | LOWPAN_NHC_C | | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 385 | | 386 + Client Random (32 bytes) + 387 | | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 Figure 6: A sample NHC compressed IP/UDP packet containing the 391 ClientHello message. 393 This document also proposes 6LoWPAN_NHC for the ServerHello message 394 (LOWPAN_NHC_SH). ServerHello is very similar to ClientHello except 395 that the length of the cipher_suites and compression_methods fields 396 are fixed to 16 and 8 bits, respectively. Figure 7 shows the 6LoWPAN- 397 NHC encoding for the ServerHello message. 399 0 1 2 3 4 5 6 7 400 +---+---+---+---+---+---+---+---+ 401 | 1 | 0 | 1 | 1 | V |SI |CS |CM | 402 +---+---+---+---+---+---+---+---+ 404 Figure 7: LOWPAN_NHC encoding for the DTLS ServerHello Message 406 The function of each compressed header field is described below: 408 o The first four bits in the 6LoWPAN_NHC_SH represent the ID field 409 set to 1011. 411 o Version (V): In order to avoid version negotiation in the initial 412 handshake, the DTLS 1.2 standard suggests that the server 413 implementation should use DTLS version 1.0. If V is set to 0, the 414 version is DTLS 1.0 and the version field is omitted. However the 415 DTLS 1.2 clients must not assume that the server does not support 416 higher versions or it will eventually negotiate DTLS 1.0 rather than 417 DTLS 1.2. If V is set to 1, the version field is carried inline. 419 o Session ID (SI), Cipher Suite (CS), and Compression Method (CM) are 420 encoded in a similar fashion as discussed above for the ClientHello 421 message. In order to not compromise security the random field in the 422 ServerHello, like in the ClientHello message, is always carried 423 inline. 425 6. Summary of DTLS header sizes with and without Compression 427 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 428 | | Without | With | 429 + DTLS Header +Compression [bytes]+Compression [bytes]+ 430 | | | | 431 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 432 | Record | 13 | 4* or 5 | 433 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 434 | Handshake | 12 | 3 | 435 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 436 | ClientHello | 10** | 1 | 437 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 438 | ServerHello | 6** | 1 | 439 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 441 * For Record plus handshake case (Section 4) the size is 4. 442 ** Without the random field 444 Table 1: With the header compression defined in this document we 445 can clearly reduce significant communication overhead in resource- 446 constrained networks. 448 7. Implementation Considerations 450 We provide an open source implementation of the proposed compression 451 scheme in the Contiki operating system. The implementation is 452 released under BSD license and can be obtained at the following URI: 453 http://www.shahidraza.info/resources/CoAP-DTLS.zip. We also evaluate 454 the compressed DTLS and the details are published in Lithe 455 [Lithe13]. 457 8. Security Considerations 459 The compression scheme proposed in this document does not compromise 460 any of the security provided by the DTLS Record header and the 461 Handshake header. In particular, the SN field is compressed in an on- 462 demand fashion, as described in Section 3. In order to overcome 463 replay attacks, it is recommended that the communication end-points 464 re-establish a connection using handshake before the sequence number 465 overflows. However, in constrained environments, different 466 implementations can decide the overflow size; 2^16, 2^24, 2^32, or 467 2^48. This leads to a trade-off between the overhead incurred by 468 establishing a new secure connection (i.e. a re-handshake) and by 469 sending more bits of sequence number. The random number field, 470 Initialization Vector (IV), and Message Authentication Code (MAC) are 471 also not compressed to take full advantage of DTLS security. 473 9. IANA Considerations 475 [RFC6282] creates a new IANA registry for the LOWPAN_NHC header type. 476 This document requests the assignment of following contents: 478 11011XXX: The 6LOWPAN_NHC encoding for the UDP header where the UDP 479 is compressed with LOWPAN_NHC. 481 1000XXXX: The 6LOWPAN_NHC encoding for the Record plus Handshake 482 headers (LOWPAN_NHC_RH). 484 1001XXXX: The 6LOWPAN_NHC encoding for the Record header 485 (LOWPAN_NHC_R). 487 1010XXXX: The 6LOWPAN_NHC encoding for the DTLS ClientHello message 488 (LOWPAN_NHC_CH) 490 1011XXXX: The 6LOWPAN_NHC encoding for the DTLS ServerHello message 491 (LOWPAN_NHC_SH) 493 The Capital letter X in bit positions represent class-specific bit 494 assignments as defined in Section 3, 4, and 5. 496 10. Acknowledgements 498 The work is funded by CALIPSO, Connect All IP-based Smart Objects, 499 funded by the European Commission under FP7 with contract number FP7- 500 ICT-2011.1.3-288879. 502 11. References 504 11.1. Normative References 506 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 507 Requirement Levels", BCP 14, RFC 2119, March 1997. 509 [RFC6282] Hui, J., Ed., and P. Thubert, "Compression Format for IPv6 510 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 511 September 2011. 513 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 514 Security Version 1.2", RFC 6347, January 2012. 516 [RFC4303] J. Hui, P. Thubert, "Compression Format for IPv6 Datagrams 517 over IEEE 802.15.4-Based Networks", RFC 6282, September 518 2011 519 11.2. Informative References 521 [WiSec13] R. Hummen, J. Hiller, H. Wirtz, M. Henze, H. Shafagh, and 522 K. Wehrle, "6LoWPAN fragmentation attacks and mitigation 523 mechanisms," in Proceedings of the 6th ACM Conference on 524 Security and Privacy in Wireless and Mobile Networks, Apr. 525 2013, Budapest, Hungry. 527 [Lithe13] S. Raza, H. Shafagh, K. Hewage, R. Hummen, Thiemo Voigt, 528 "Lithe: Lightweight Secure CoAP for the Internet of 529 Things". IEEE Sensors Journal, 13(10), 3711-3720, October 530 2013. 532 Authors' Addresses 534 Shahid Raza 535 SICS Swedish ICT AB (SICS) 536 Isafjordsgatan 22, 16440 Kista 537 SWEDEN 539 Phone: +46-(0)768831797 540 EMail: shahid@sics.se 541 Hossein Shafagh 542 ETH Zurich 543 Universitatstrasse 6, CH-8092 Zurich 544 SWITZERLAND 546 Phone: +41 44 63 26136 547 EMail: shafagh@ethz.ch 549 Olivier Dupont 550 Cisco 551 Cisco Systems, Paris 552 FRANCE 554 Phone: +33 158 043 480 555 Email: odupont@cisco.com