DTLS Performance in Duty-Cycled Networks

The Datagram Transport Layer Security (DTLS) protocol is the IETF standard for securing the Internet of Things. The Constrained Application Protocol, ZigBee IP, and Lightweight Machine-to-Machine (LWM2M) mandate its use for securing application traffic. There has been much debate in both the standardization and research communities on the applicability of DTLS to constrained environments. The main concerns are the communication overhead and latency of the DTLS handshake, and the memory footprint of a DTLS implementation. This paper provides a thorough performance evaluation of DTLS in different duty-cycled networks through real-world experimentation, emulation and analysis. In particular, we measure the duration of the DTLS handshake when using three duty cycling link-layer protocols: preamble-sampling, the IEEE 802.15.4 beacon-enabled mode and the IEEE 802.15.4e Time Slotted Channel Hopping mode. The reported results demonstrate surprisingly poor performance of DTLS in radio duty-cycled networks. Because a DTLS client and a server exchange more than 10 signaling packets, the DTLS handshake takes between a handful of seconds and several tens of seconds, with similar results for different duty cycling protocols. Moreover, because of their limited memory, typical constrained nodes can only maintain 3-5 simultaneous DTLS sessions, which highlights the need for using DTLS parsimoniously.Comment: International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC - 2015), IEEE, IEEE, 2015, http://pimrc2015.eee.hku.hk/index.htm

Old Wine in New Skins? Revisiting the Software Architecture for IP Network Stacks on Constrained IoT Devices

In this paper, we argue that existing concepts for the design and implementation of network stacks for constrained devices do not comply with the requirements of current and upcoming Internet of Things (IoT) use cases. The IoT requires not only a lightweight but also a modular network stack, based on standards. We discuss functional and non-functional requirements for the software architecture of the network stack on constrained IoT devices. Then, revisiting concepts from the early Internet as well as current implementations, we propose a future-proof alternative to existing IoT network stack architectures, and provide an initial evaluation of this proposal based on its implementation running on top of state-of-the-art IoT operating system and hardware.Comment: 6 pages, 2 figures and table

Information Centric Networking in the IoT: Experiments with NDN in the Wild

This paper explores the feasibility, advantages, and challenges of an ICN-based approach in the Internet of Things. We report on the first NDN experiments in a life-size IoT deployment, spread over tens of rooms on several floors of a building. Based on the insights gained with these experiments, the paper analyses the shortcomings of CCN applied to IoT. Several interoperable CCN enhancements are then proposed and evaluated. We significantly decreased control traffic (i.e., interest messages) and leverage data path and caching to match IoT requirements in terms of energy and bandwidth constraints. Our optimizations increase content availability in case of IoT nodes with intermittent activity. This paper also provides the first experimental comparison of CCN with the common IoT standards 6LoWPAN/RPL/UDP.Comment: 10 pages, 10 figures and tables, ACM ICN-2014 conferenc

Bindings and RESTlets: a novel set of CoAP-based application enablers to build IoT applications

Sensors and actuators are becoming important components of Internet of Things (IoT) applications. Today, several approaches exist to facilitate communication of sensors and actuators in IoT applications. Most communications go through often proprietary gateways requiring availability of the gateway for each and every interaction between sensors and actuators. Sometimes, the gateway does some processing of the sensor data before triggering actuators. Other approaches put this processing logic further in the cloud. These approaches introduce significant latencies and increased number of packets. In this paper, we introduce a CoAP-based mechanism for direct binding of sensors and actuators. This flexible binding solution is utilized further to build IoT applications through RESTlets. RESTlets are defined to accept inputs and produce outputs after performing some processing tasks. Sensors and actuators could be associated with RESTlets (which can be hosted on any device) through the flexible binding mechanism we introduced. This approach facilitates decentralized IoT application development by placing all or part of the processing logic in Low power and Lossy Networks (LLNs). We run several tests to compare the performance of our solution with existing solutions and found out that our solution reduces communication delay and number of packets in the LLN

TCP in the Internet of Things: from ostracism to prominence

© 2018 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.TCP has traditionally been neglected as a transport-layer protocol for the Internet of Things (IoT). However, recent trends and industry needs are favoring TCP presence in IoT environments. In this article, we describe the main IoT scenarios where TCP will be used. We then analyze the historically claimed issues of TCP in the IoT context. We argue that, in contrast to generally accepted wisdom, most of those possible issues fall in one of the following categories: i) are also found in well-accepted IoT end-to-end reliability mechanisms, ii) can be solved, or iii) are not actual issues. Considering the future prominent role of TCP in the IoT, we provide recommendations for lightweight TCP implementation and suitable operation in such scenarios, based on our IETF standardization work on the topic.Postprint (author's final draft

Securing Internet of Things with Lightweight IPsec

Real-world deployments of wireless sensor networks (WSNs) require secure communication. It is important that a receiver is able to verify that sensor data was generated by trusted nodes. In some cases it may also be necessary to encrypt sensor data in transit. Recently, WSNs and traditional IP networks are more tightly integrated using IPv6 and 6LoWPAN. Available IPv6 protocol stacks can use IPsec to secure data exchange. Thus, it is desirable to extend 6LoWPAN such that IPsec communication with IPv6 nodes is possible. It is beneficial to use IPsec because the existing end-points on the Internet do not need to be modified to communicate securely with the WSN. Moreover, using IPsec, true end-to-end security is implemented and the need for a trustworthy gateway is removed. In this paper we provide End-to-End (E2E) secure communication between an IP enabled sensor nodes and a device on traditional Internet. This is the first compressed lightweight design, implementation, and evaluation of 6LoWPAN extension for IPsec on Contiki. Our extension supports both IPsec's Authentication Header (AH) and Encapsulation Security Payload (ESP). Thus, communication endpoints are able to authenticate, encrypt and check the integrity of messages using standardized and established IPv6 mechanisms

A Low-Power CoAP for Contiki

Internet of Things devices will by and large be battery-operated, but existing application protocols have typically not been designed with power-efficiency in mind. In low-power wireless systems, power-efficiency is determined by the ability to maintain a low radio duty cycle: keeping the radio off as much as possible. We present an implementation of the IETF Constrained Application Protocol (CoAP) for the Contiki operating system that leverages the ContikiMAC low-power duty cycling mechanism to provide power efficiency. We experimentally evaluate our low-power CoAP, demonstrating that an existing application layer protocol can be made power-efficient through a generic radio duty cycling mechanism. To the best of our knowledge, our CoAP implementation is the first to provide power-efficient operation through radio duty cycling. Our results question the need for specialized low-power mechanisms at the application layer, instead providing low-power operation only at the radio duty cycling layer

Evolving SDN for Low-Power IoT Networks

Software Defined Networking (SDN) offers a flexible and scalable architecture that abstracts decision making away from individual devices and provides a programmable network platform. However, implementing a centralized SDN architecture within the constraints of a low-power wireless network faces considerable challenges. Not only is controller traffic subject to jitter due to unreliable links and network contention, but the overhead generated by SDN can severely affect the performance of other traffic. This paper addresses the challenge of bringing high-overhead SDN architecture to IEEE 802.15.4 networks. We explore how traditional SDN needs to evolve in order to overcome the constraints of low-power wireless networks, and discuss protocol and architectural optimizations necessary to reduce SDN control overhead - the main barrier to successful implementation. We argue that interoperability with the existing protocol stack is necessary to provide a platform for controller discovery and coexistence with legacy networks. We consequently introduce {\mu}SDN, a lightweight SDN framework for Contiki, with both IPv6 and underlying routing protocol interoperability, as well as optimizing a number of elements within the SDN architecture to reduce control overhead to practical levels. We evaluate {\mu}SDN in terms of latency, energy, and packet delivery. Through this evaluation we show how the cost of SDN control overhead (both bootstrapping and management) can be reduced to a point where comparable performance and scalability is achieved against an IEEE 802.15.4-2012 RPL-based network. Additionally, we demonstrate {\mu}SDN through simulation: providing a use-case where the SDN configurability can be used to provide Quality of Service (QoS) for critical network flows experiencing interference, and we achieve considerable reductions in delay and jitter in comparison to a scenario without SDN