DICE Working Group S. Raza Internet-Draft SICS, Stockholm Intended Status: Standard Track H. Shafagh ETH Zurich O. Dupont Cisco Systems, Paris Expires: September 11, 2014 March 10, 2014 Compression of Record and Handshake Headers for Constrained Environments draft-raza-dice-compressed-dtls-00 Abstract This document describes header compression mechanisms for the Datagram Transport Layer Security (DTLS) [RFC6347] based on the encoding scheme standardized in [RFC6282]. The DTLS Record Header (RH), Handshake Header (HH), and optionally handshake message headers are compressed using Next Header Compression (NHC) defined in [RFC6282]. This document neither invalidates any encoding schemes proposed in 6LoWPAN [RFC6282] nor compromises the end-to-end security properties provided by DTLS. This document aims to increase the applicability of DTLS and, thus, CoAPs [draft-ietf-core-coap-18] in constrained environments. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 11, 2014. Copyright and License Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. Raza, Shafagh & Dupont Expires September 11, 2014 [Page 1] INTERNET DRAFT Compressed-DTLS-for-6LoWPAN March 10, 2014 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. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Linking DTLS Header Compression with 6LoWPAN . . . . . . . . . 4 3. LOWPAN_NHC for the Record Header . . . . . . . . . . . . . . . 4 4. LOWPAN_NHC for the Record Plus Handshake Headers . . . . . . . 6 5. LOWPAN_NHC for the Handshake Messages . . . . . . . . . . . . . 7 6. Summary of DTLS header sizes with and without Compression . . . 10 7. Implementation Considerations . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Raza, Shafagh & Dupont Expires September 11, 2014 [Page 2] INTERNET DRAFT Compressed-DTLS-for-6LoWPAN March 10, 2014 1 Introduction To protect CoAP transmissions, Datagram TLS (DTLS) has been proposed as the primary security protocol. Analogous to TLS-protected HTTP (HTTPs), the DTLS-secured CoAP protocol is termed CoAPs. DTLS is a chatty protocol and requires numerous message exchanges to establish a secure session. While DTLS supports a wide range of cryptographic primitives for peer authentication and payload protection, it was originally designed for network scenarios where message length was not a critical design criterion. Therefore, it is inefficient to use the DTLS protocol, as it is, for constrained devices. To cope with constrained resources and the size limitations of IEEE 802.15.4-based networks, 6LoWPAN header compression mechanisms are defined. [RFC6282] defines how IPv6 datagrams can be routed over IEEE 802.15.4 [IEEE802.15.4]-based networks. [RFC6282] defines header compression schemes that can significantly reduce the size of IP, IP extensions, and UDP headers. It is particularly beneficial to apply the 6LoWPAN header compression mechanisms to compress other protocols having well-defined header fields, such as DTLS. This document provides header compression for the DTLS Record, Handshake, and handshake messages headers with 6LoWPAN header compression mechanisms. This enables the routing of heavy-weight IP traffic to resource- constrained [IEEE802.15.4]-based wireless network. The DTLS header compression defined in this documents does not compromise the DTLS ability to provide end-to-end security between constrained nodes and hosts on the Internet. The security in [IEEE802.15.4]-based IP networks or what is more commonly known 6LoWPAN networks is particularly important as we connect the insecure Internet with the vulnerable wireless network. The purpose of DTLS header compression is twofold. First, achieving energy efficiency by reducing the message size, since communication requires more energy than computation. Second, avoiding 6LoWPAN fragmentation that is applied when the size of a datagram is larger than the link layer MTU. Avoiding fragmentation, whenever possible, is also important from the security point of view as the 6LoWPAN protocol is vulnerable to fragmentation attacks [WiSec13]. Generic Header Compression (GHC) [draft-bormann-6lowpan-ghc-06], analogous to NHC, is also defined to allow upper layer (UDP payload and above) header compression. 6LoWPAN-GHC is a generic compression scheme for all headers and header-like structures, and is not targeted for the DTLS protocol; also, it is generally a slightly less efficient approach. It is an alternative to the approach presented in this document and it is worth evaluating the two approaches for the DTLS Record and Handshake headers. 1.1 Terminology Raza, Shafagh & Dupont Expires September 11, 2014 [Page 3] INTERNET DRAFT Compressed-DTLS-for-6LoWPAN March 10, 2014 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 RFC 2119 [RFC2119]. 2. Linking DTLS Header Compression with 6LoWPAN [RFC6282] defines the general format of NHC that can be used to encode DTLD headers. In order to apply 6LoWPAN header compression mechanisms to compress headers in the UDP payload, we either require a modification in the current NHC encodings for UDP in the 6LoWPAN standard, or need to define a new NHC for UDP with different ID bits. The first solution requires modification in the current standard and hence is not a favorable solution. The second solution, that is used in this document, is an extension to the 6LoWPAN standard; a similar approach is adapted to distinguish NHC from GHC [draft-bormann- 6lowpan-ghc-06]. The ID bits 11110 in the NHC for UDP, as defined in the 6LoWPAN standard, indicate that the UDP payload is not compressed. We define the ID bits 11011 in the NHC for UDP to indicate that the UDP payload is compressed with 6LoWPAN_NHC. The ID bits 11011 are currently unassigned in the 6LoWPAN standard. Figure 1 shows our proposed NHC for UDP that allows compression of UDP payload; in the case of DTLS, the UDP payload contains the NHC compressed DTLS headers. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 | 1 | 0 | 1 | 1 | C | P | +---+---+---+---+---+---+---+---+ Figure 1: 6LOWPAN_NHC for UDP which allows compression of UDP payload 3. LOWPAN_NHC for the Record Header The Record protocol adds header fields of 13 bytes length to each packet that is sent throughout the lifetime of a device that uses DTLS. The header compression proposed in this section reduces the Record header length to 4 bytes (plus one byte for the NHC). In contrary to the handshake header and messages, the Record header remains un-encrypted in all cases. Thus it can always be compressed using the mechanism explained in this section. In order to provide header compression for the Record and Handshake headers, this document discusses two cases. In the first case, the Record header fragment field contains a handshake message; the next section defines header compression regarding this case. In the second case, the fragment field in the Record header is not a handshake Raza, Shafagh & Dupont Expires September 11, 2014 [Page 4] INTERNET DRAFT Compressed-DTLS-for-6LoWPAN March 10, 2014 message, it is mostly application data, or could be a DTLS alert message or ChangeCipherSpec. Figure 2 shows 6LoWPAN_NHC encoding for the Record header (LOWPAN_NHC_R). 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 | 0 | 0 | 1 | V | EC| SN | +---+---+---+---+---+---+---+---+ Figure 2: Proposed LOWPAN NHC encoding for the DTLS Record header The encoded bits have the following functions: o The first four bits in the NHC represent the NHC ID we define for the Record header. These are set to 1001. o Version (V): If 0, the version is the DTLS latest version which is 1.2, and the field is omitted. If 1, the version field is carried inline. o Epoch (EC): If 0, an 8 bit epoch is used and the left most 8 bits are omitted. If 1, all 16 bits of the epoch are carried inline. In most cases the actual epoch is either 0 or 1. Therefore, an 8 bit epoch is used most of the time, allowing for a higher space. o Sequence Number (SN): The sequence number consists of 48 bits, of which some are leading zeros. If SN is set to 00, a 16 bit sequence number is used and the left most 32 bits are omitted. If 01, a 24 bit sequence number is used and the left most 24 bits are omitted. If 10, a 32 bit sequence number is used and the left most 16 bits are omitted. If 11, all 48 bits of the sequence number are carried inline. The SN field in the Record header contains a value 1 for the first packet sent, and it is incremented sequentially for the subsequent packets. Note that by using 16-bit sequence number we do not limit the size of sequence number to 2^(16-1), but propose to use 16 bits for the sequence number prior to the transmission of the 2^16th packet on a DTLS connection. From the 2^16 to 2^(24-1) we propose to use 24-bit sequence numbers. Follow the same procedure for the 32-bit sequence numbers as well. However, the sender and the receiver sequence-number-counters must be reset prior to sending the 2^48th packet. In the Record header, content_type field is always carried inline. The length field in the Record header is omitted as we expect only one DTLS record per UDP packet in constrained environments. While a source device inside a 6LoWPAN sends one DTLS record per UDP packet, a typical destination device on the conventional Internet side may Raza, Shafagh & Dupont Expires September 11, 2014 [Page 5] INTERNET DRAFT Compressed-DTLS-for-6LoWPAN March 10, 2014 send multiple DTLS records in a single UDP packet. However, as the 6BR performs the compression/decompression of incoming packets, there is the possibility to enforce one DTLS record per UDP packet before routing these packets in 6LoWPAN networks. The length field can be deduced from the lower layers: either from the 6LoWPAN header or the IEEE 802.15.4 header. Figure 3 shows a sample NHC compressed IP/UDP packet secured with the Record protocol. | octet 1 | octet 2 | octet 3 | octet 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LOWPAN_IPHC | Hop Limit | Source Address| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address| Destination Address | LOWPAN_NHC_UDP| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S Port |D Port | Checksum | LOWPAN_NHC_R | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Content Type | Epoch | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Initialization Vector (IV) [16 bytes for AES] + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Application Data Fragment (Variable Size) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + MAC (Variable Size) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | padding |Padding Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: A sample NHC compressed IP/UDP packet containing an application data such as a CoAP message. 4. LOWPAN_NHC for the Record Plus Handshake Headers In the case where the Record header fragment field contains a handshake message, we compress both the Record header and the Handshake header using a single encoding byte and define 6LoWPAN_NHC for Record+Handshake (6LoWPAN_NHC_RH). The Handshake protocol requires 12 bytes of the handshake header. Using the proposed 6LoWPAN_NHC_RH the handshake header length is reduced to 3 bytes. Figure 4 shows 6LoWPAN NHC encoding for the Record+Handshake headers. Raza, Shafagh & Dupont Expires September 11, 2014 [Page 6] INTERNET DRAFT Compressed-DTLS-for-6LoWPAN March 10, 2014 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 | 0 | 0 | 1 | V |EC |SN | F | +---+---+---+---+---+---+---+---+ Figure 4: LOWPAN_NHC encoding for the DTLS Record plus Handshake headers The encoded bits have the following functions: o The first four bits represent the ID field that is used to distinguish 6LoWPAN_NHC_RH from other encodings, and to comply with 6LoWPAN_NHC encoding scheme. In case of 6LoWPAN_NHC_RHS we set the ID bits to 1000. o The Version (V) and Epoch (EC) are encoded using the same scheme presented in Section 3. o If SN is set to 0, a 16 bit sequence number is used and the left most 32 bits are omitted. If 1, all 48 bits of the sequence number are carried inline. o Fragment (F): If 0, the handshake message is not fragmented and the fields fragment_offset and fragment_length are omitted. This is the common case, which occurs when a handshake message is not larger than the maximum record size. If 1, the fields fragment_offset and fragment_length are carried inline. In contrary to the scheme defined in Section 3, the content_type field is always omitted as it is obvious based on the ID bits that the content type is the Handshake protocol. The message_type and message_sequence fields of the Handshake header are always carried inline. The length field in the Handshake headers is always omitted as it can be deduced from the lower layers: either from the 6LoWPAN header or the IEEE 802.15.4 header. We have to un-compress layer-wise from lower to higher layers until the UDP header is uncompressed. Then the length of the UDP payload is known and the DTLS payload length can be calculated. With this combined encoding scheme the 25 bytes of Record plus Handshake headers are bring down to 6 bytes (plus one additional byte for the 6LoWPAN_NHC_RH). Considering that a handshake process consists of 10 messages, sending 18 less bytes for each message is a very significant saving. This contributes to the feasibility of using the chatty handshake protocol for constrained nodes. 5. LOWPAN_NHC for the Handshake Messages Raza, Shafagh & Dupont Expires September 11, 2014 [Page 7] INTERNET DRAFT Compressed-DTLS-for-6LoWPAN March 10, 2014 The Handshake protocol consists of 10 messages, all having well- defined headers. We can compress some of the handshake messages. Two of the handshake messages with most number of header fields are ClientHello and ServerHello. Using the 6LoWPAN_NHC for the ClientHello message (6LoWPAN_NHC_CH) defined in this document, we can omit all ClientHello fields except the random field. The minimum possible size of a ClientHello message without the random field is 10 bytes: version (2), session_id length(1), cookie length (1), cipher_suites length (2), cipher_suites (2), compression_methods length (1), compression_methods (1). By appling 6LoWPAN_NHC_CH the minimum possible size of a ClientHello message without a random field is 1 byte that is used to encode 6LoWPAN_NHC_CH. This is the common case when DTLS is used to secure CoAP messages. Figure 5 depicts the NHC encoding for the ClientHello message. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 | 0 | 1 | 0 | SI| C |CS |CM | +---+---+---+---+---+---+---+---+ Figure 5: LOWPAN_NHC encoding for the DTLS ClientHello Message The function of each compressed header field is described below: o The first four bits in the 6LoWPAN_NHC_CH represent the ID field which are set to 1010. o Session ID (SI) and Cookie (C): If 0, the session_id and/or cookie fields are not available and these fields and 8 bits of the prefixed length fields are omitted. In the (D)TLS protocol, session_id is empty if no session is available, or if the client wishes to generate new security parameters. The ClientHello message uses session_id only if the DTLS client wants to resume the old session. If SI or C is set to 1, the session_id and/or cookie fields are carried inline. o Cipher Suites (CS): If 0, the default (mandatory) cipher suite for CoAP that supports automatic key management is used and this field and the prefixed 16 bits length field are omitted. In the current CoAP draft, TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 is a mandatory cipher suite. If CS is set to 1, the cipher_suites field is carried inline. o Compression Methods (CM): If 0, the default compression method, i.e., COMPRESSION_NULL is used and this field and the prefixed 8 bits length field are omitted. If CM is set to 1, the compression_methods field is carried inline. Raza, Shafagh & Dupont Expires September 11, 2014 [Page 8] INTERNET DRAFT Compressed-DTLS-for-6LoWPAN March 10, 2014 The random field in the ClientHello is always carried inline whereas the version field is always omitted. The version contains the same value as in the DTLS Record header. In case of TLS/SSL the version field was defined to let a TLS client specify an older version to be compatible with an SSL client, which is rarely used in practice. All current versions of web browsers use the same TLS version in Record and ClientHello. DTLS 1.2 (adapted from TLS 1.2) mentions that the client sends its latest supported version in the ClientHello message. All DTLS versions (1.0 and 1.2) have compatible ClientHello messages. If the server does not support this version, then the ServerHello message contains its supported version. If the client is not capable of handling server's version, it terminates the connection with a protocol version alert. Figure 6 shows a sample compressed IP/UDP datagram that contains a ClientHello. | octet 1 | octet 2 | octet 3 | octet 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LOWPAN_IPHC | Hop Limit | Source Address| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address| Destination Address | LOWPAN_NHC_UDP| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S Port |D Port | Checksum | LOWPAN_NHC_RHS| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Epoch | Sequence Number | Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Sequence | LOWPAN_NHC_C | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + Client Random (32 bytes) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: A sample NHC compressed IP/UDP packet containing the ClientHello message. This document also proposes 6LoWPAN_NHC for the ServerHello message (LOWPAN_NHC_SH). ServerHello is very similar to ClientHello except that the length of the cipher_suites and compression_methods fields are fixed to 16 and 8 bits, respectively. Figure 7 shows the 6LoWPAN- NHC encoding for the ServerHello message. 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 | 0 | 1 | 1 | V |SI |CS |CM | +---+---+---+---+---+---+---+---+ Raza, Shafagh & Dupont Expires September 11, 2014 [Page 9] INTERNET DRAFT Compressed-DTLS-for-6LoWPAN March 10, 2014 Figure 7: LOWPAN_NHC encoding for the DTLS ServerHello Message The function of each compressed header field is described below: o The first four bits in the 6LoWPAN_NHC_SH represent the ID field set to 1011. o Version (V): In order to avoid version negotiation in the initial handshake, the DTLS 1.2 standard suggests that the server implementation should use DTLS version 1.0. If V is set to 0, the version is DTLS 1.0 and the version field is omitted. However the DTLS 1.2 clients must not assume that the server does not support higher versions or it will eventually negotiate DTLS 1.0 rather than DTLS 1.2. If V is set to 1, the version field is carried inline. o Session ID (SI), Cipher Suite (CS), and Compression Method (CM) are encoded in a similar fashion as discussed above for the ClientHello message. In order to not compromise security the random field in the ServerHello, like in the ClientHello message, is always carried inline. 6. Summary of DTLS header sizes with and without Compression +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | | Without | With | + DTLS Header +Compression [bytes]+Compression [bytes]+ | | | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | Record | 13 | 4* or 5 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | Handshake | 12 | 3 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | ClientHello | 10** | 1 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | ServerHello | 6** | 1 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+ * For Record plus handshake case (Section 4) the size is 4. ** Without the random field Table 1: With the header compression defined in this document we can clearly reduce significant communication overhead in resource- constrained networks. 7. Implementation Considerations We provide an open source implementation of the proposed compression Raza, Shafagh & Dupont Expires September 11, 2014 [Page 10] INTERNET DRAFT Compressed-DTLS-for-6LoWPAN March 10, 2014 scheme in the Contiki operating system. The implementation is released under BSD license and can be obtained at the following URI: http://www.shahidraza.info/resources/CoAP-DTLS.zip. We also evaluate the compressed DTLS and the details are published in Lithe [Lithe13]. 8. Security Considerations The compression scheme proposed in this document does not compromise any of the security provided by the DTLS Record header and the Handshake header. In particular, the SN field is compressed in an on- demand fashion, as described in Section 3. In order to overcome replay attacks, it is recommended that the communication end-points re-establish a connection using handshake before the sequence number overflows. However, in constrained environments, different implementations can decide the overflow size; 2^16, 2^24, 2^32, or 2^48. This leads to a trade-off between the overhead incurred by establishing a new secure connection (i.e. a re-handshake) and by sending more bits of sequence number. The random number field, Initialization Vector (IV), and Message Authentication Code (MAC) are also not compressed to take full advantage of DTLS security. 9. IANA Considerations [RFC6282] creates a new IANA registry for the LOWPAN_NHC header type. This document requests the assignment of following contents: 11011XXX: The 6LOWPAN_NHC encoding for the UDP header where the UDP is compressed with LOWPAN_NHC. 1000XXXX: The 6LOWPAN_NHC encoding for the Record plus Handshake headers (LOWPAN_NHC_RH). 1001XXXX: The 6LOWPAN_NHC encoding for the Record header (LOWPAN_NHC_R). 1010XXXX: The 6LOWPAN_NHC encoding for the DTLS ClientHello message (LOWPAN_NHC_CH) 1011XXXX: The 6LOWPAN_NHC encoding for the DTLS ServerHello message (LOWPAN_NHC_SH) The Capital letter X in bit positions represent class-specific bit assignments as defined in Section 3, 4, and 5. Raza, Shafagh & Dupont Expires September 11, 2014 [Page 11] INTERNET DRAFT Compressed-DTLS-for-6LoWPAN March 10, 2014 10. Acknowledgements The work is funded by CALIPSO, Connect All IP-based Smart Objects, funded by the European Commission under FP7 with contract number FP7- ICT-2011.1.3-288879. 11. References 11.1. Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6282] Hui, J., Ed., and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, September 2011. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. [RFC4303] J. Hui, P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, September 2011 11.2. Informative References [WiSec13] R. Hummen, J. Hiller, H. Wirtz, M. Henze, H. Shafagh, and K. Wehrle, "6LoWPAN fragmentation attacks and mitigation mechanisms," in Proceedings of the 6th ACM Conference on Security and Privacy in Wireless and Mobile Networks, Apr. 2013, Budapest, Hungry. [Lithe13] S. Raza, H. Shafagh, K. Hewage, R. Hummen, Thiemo Voigt, "Lithe: Lightweight Secure CoAP for the Internet of Things". IEEE Sensors Journal, 13(10), 3711-3720, October 2013. Authors' Addresses Shahid Raza SICS Swedish ICT AB (SICS) Isafjordsgatan 22, 16440 Kista SWEDEN Phone: +46-(0)768831797 EMail: shahid@sics.se Raza, Shafagh & Dupont Expires September 11, 2014 [Page 12] INTERNET DRAFT Compressed-DTLS-for-6LoWPAN March 10, 2014 Hossein Shafagh ETH Zurich Universitatstrasse 6, CH-8092 Zurich SWITZERLAND Phone: +41 44 63 26136 EMail: shafagh@ethz.ch Olivier Dupont Cisco Cisco Systems, Paris FRANCE Phone: +33 158 043 480 Email: odupont@cisco.com Raza, Shafagh & Dupont Expires September 11, 2014 [Page 13]