Internet DRAFT - draft-raza-dice-compressed-dtls
draft-raza-dice-compressed-dtls
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]
