[Research Paper Review] 6LoWPAN Compressed DTLS for CoAP

ABSTRACT

CoAP is being standardized as an application layer protocol for the IoT. CoAP proposes to use DTLS to provide end-to-end security to protect the IoT. DTLS is a heavyweight protocol and its headers are too long to fit in a single IEEE 802.15.4 MTU(The Maximum Transmission Unit(MTU) for 802.15.4 is 127 bytes)

.

-> 6LoWPAN provides header compression mechanisms to reduce the size of upper layer headers.

-> 6LoWPAN header compression mechanisms can be used to compress the security headers as well.

We propose 6LoWPAN header compression for DTLS. We link our compressed DTLS with the 6LoWPAN standard using standardized mechanisms. We show that our proposed DTLS compression significantly reduces the number of additional security bits.

6LoWPAN = IPv6 over Low-power Wireless Personal Area Network

-> Enables the use of IP in IEEE 802.15.4 low power and loosy wireless networks such as wireless sensor network (WSN)

Security is particularly important for the things as they are connected to the untrusted and unreliable Internet.

UDP is mostly used and a new connection-less lightweight Constrained Application Protocol (CoAP) is proposed

-> CoAP proposes to use Datagram Transport Layer Security(DTLS) as a security protocol for automatic key management and data encryption and authentication.

->CoAP with DTLS support is termed as secure-CoAP (CoAPs)

System model

IoT setup having 6LoWPAN that consists of CoAPs enabled nodes and a border router; messages within 6LoWPAN travel in compressed form. The 6LoWPAN border router acts as a bridge between 6LoWPAN and the conventional Internet.

CoAPs enabled devices can securely communicate with Internet hosts such as laptops, smartphones, etc that support DTLS.

* DTLS was designed for the Internet and not for resource constrained IoT devices

  -> We can exploit 6LoWPAN compression capabilities to compress the DTLS headers and messages

DTLS and 6LoWPAN

DTLS is a protocol used to secure datagram traffic for client/server applications.

 -> It is composed of a Record Protocol that carries other protocols such as Handshake, Alert, and application data.

 -> The initial Handshake authenticates the server and optionally the client using a Public Key Infrastructure.

6LoWPAN standard defines IP header Compression(IPHC) for the IP header and next header Compression(NHC) for the IP extension headers and the UDP header.

 -> also defines fragmentation schemes for the packets that do not fit in 127 bytes MTU

 -> apply 6LoWPAN header compression mechanisms in DTLS that contained heavyweight protocol

Integrating compressed DTLS into 6LoWPAN

6LoWPAN standard does not provide ways to compress the UDP payload and the layers above

 -> Recently, 6LoWPAN-GHC has been proposed as a plug-in for 6LoWPAN which can be used to compress the UDP payload

 -> DTLS is being part of the UDP payload can be compressed via 6LoWPAN-GHC

The proposed ID bits in the NHC for UDP-GHC are used to differentiate NHC for UDP from NHC for UDP-GHC.

 -> The ID bit 11010 in the NHC for UDP-GHC indicates that the UDP payload is compressed with 6LoWPAN-GHC

 -> UDP-GHC is defined >> we can compress DTLS by providing GHC for the DTLS messages.

 -> When the 6LoWPAN-GHC for DTLS is completed we use the STOP code, set to 10010000 in the 6LoWPAN-GHC draft, to indicate that the DTLS header compression is completed

6LoWPAN-GHC for the DTLS Record and handshake

Proposal of 6LoWPAN-GHC for compressing the Record and handshake header indicated in two cases in this thesis.

First, Compressing both the Record header and the Handshake header using a single encoding byte

 ->6LoWPAN-GHC for Record + Handshake byte defines an encoding for both the Record header and the Handshake header.

Second, in order to complete the Handshake protocol, we define 6LoWPAN-GHC for the Record header (6LoWPAN-GHC-R)

 -> the fragment field in the Record header is an application data rather than a Handshake header as in the first case.

1. The first four bits in the 6LoWPAN-GHC-RHS represent the ID field.
1. set these bits to 1000.
2. Being needed to comply with 6LoWPAN-GHC encodings
1. Set these bits to 1001
3. Version
1. If 0 - the version will be DTLS latest version and field is elided(생략)
2. If 1 - the version field is carried inline(즉시처리)
4. Epoch
1. If 0 - an 8 bit epoch is used and the left most 8 bits are elided
2. If 1 - all 16 bits of the epoch are carried inline
5. Sequence Number
1. If 0 - a 16 bit sequence number is used and the left most 32 bits are elided.
2. If 1 - all 48 bits of the sequence number are carried inline
3. The case of 6LoWPAN-GHC-R
1. If 00 - 1 16 bit sequence number is used and the left most 32 bits are elided
2. If 01 - a 32 bit sequence number is used and the left most 16 bits are elided
3. If 11 - all 48 bits of the sequence number are carried inline
4. If 10 - sequence number is reserved and are not used
6. Fragment
1. If 0 - the handshake message is not fragmented and the fields fragment_offset and fragment_length are elided
1. This is common case when the handshake message is not bigger than maximum record size
2. If 1 - the fields fragment_offset and fragment_length are carried inline.

In the Record header, content_type field is always carried inline; also, msg_type and message_seq fields in the Handshake header are always carried inline.

The length filed in the Record and Handshake headers are always elided as they can be inferred from the lower layer: either from the 6LoWPAN fragmentation header or the IEEE 802.15.4 header

6LoWPAN-GHC for ClientHello

The proposal of 6LoWPAN for the ClientHello message (6LoWPAN-GHC-CH) is that ClientHello message is sent twice during the handshake process -- with cookie and without cookie

1. The first four bits in the 6LoWPAN-GHC-CH represent the ID field.
1. set these bits to 1010.
2. Session ID
1. If 0 - the seesion_id is not available and this field and 8 bits of prefixed length field are elided
1. The actual session_id field in the ClientHello contains 0 to 255 bits;
2. It is always prefixed with an 8 bit field that contains the size of the session_id
3. The ClientHello message uses seesion_id only if the DTLS client wants to resume the old seesion.
2. If 1 - the session_id filed is carried inline.
3. Cookie
1. If 0 - The cookie field is not available and this field and its prefixed 8 bits length field are elided.
1. The actual cookie field in the ClientHello contains 0 to 255 bits;
2. It always has an 8 bit length field that contains the size of the cookie.
2. If 1 - the cookie field is carried inline.
4. Cipher Suits
1. If 0 - the default cipher-suites for the CoAP that supports automatic key management is used and this field and the prefixed 16 bits length field are elided
1. 16 bits and is always prefixed with a 16 bit field that contains the size of the cipher_suites
2. If 1 - the cipher_suites field is carried inline.
5. Compression Method
1. If 0 - the default compression method -> COMPRESSION_NULL is used and this field and the prefixed 8 bit length field are elided.
1. The actual compression_methods field contains 8 to 2^8 - 8 bits;
2. It is always prefixed with an 8 bits field that contains the size of the compression_methods
2. If 1 - the compression_methods field is carried inline.

The random field in the ClientHello is always carried inline whereas the version field is always elided. In the normal case, when using 6LoWPAM-GHC-CH, we only send random field in the ClientHello message and all other field are elided.

6LoWPAN-GHC for ServerHello

The proposal of 6LoWPAN for the ServerHello message(6LoWPAN-GHC-SH)

1. The first four bits in the 6LoWPAN-GHC-SH represent the ID field.
1. set these bits to 1011.
2. Server Version
1. If 0 - the version will be DTLS 1.0 and the field is elided.
1. The DTLS 1.2 standard suggests that the server implementation should use DTLS version 1.0 due to avoiding negotiation in the initial handshake
2. The DTLS clients must not assume that the server does not support higher versions
2. If 1 - the version field is carried inline.
3. Session ID
1. If 0 - the session_id is not available and this field and 8 bits of the prefixed length field are elided
2. If 1- the session_id field is carried inline
4. Cipher Suits
1. If 0 - the default cipher_suites for CoAP that supports automatic key management is used and this field is elided.
2. If 1 - the cipher_suites field is carried inline.
5. Compression Method
1. If 0 - the default compression method -> COMPRESSION_NULL is used and this field is elided
2. If 1 - the compression_methods field is carried inline.

Size Reduction Using 6LoWPAN-GHC

Using 6LoWPAN-GHC compression mechanisms we can significantly reduce DTLS headers sizes.

In this poster abstract we only provide 6LoWPAN-GHC for the Record, Handshake, ClientHello, and ServerHello.

Table I shows

 -> The number of additional bits we send during DTLS message exchanges with and without 6LoWPAN-GHC compression.

 -> Using DTLS compression we can save a significant number of bit. The Record header that is included in all messages when the DTLS is enabled can be compressed by 64 bits (62% of the Record header) for each message.

Conclusions and Future Work

CoAP enabled hosts will be an integral part of the Internet of Things. DTLS is a standard protocol to secure CoAP messages. DTLS can be compressed using 6LoWPAN standardized mechanisms.

---------------------------------------------

번역이 필요하신가요? 그럼 아래 URL에 많은 우수 번역가가 있습니다.

http://inchan.kr/t49q3iapf5

실시간 우수번역가 번역 '번역가들' 

번역가 1251명, 문장 3줄 5분 번역 

영어 중국어 이메일, 영어논문초록, 중국어번역, 회사소개서, 다국어 컨텐츠 번역

http://inchan.kr/t49q3iapf5