No abstract

SUMMARYRPL is a routing protocol for low-power and lossy networks. A malicious node can manipulate header options used by RPL to create topological inconsistencies, thereby causing denial of service attacks, reducing channel availability, increased control message overhead, and higher energy consumption at the targeted node and its neighborhood. RPL overcomes these topological inconsistencies via a fixed threshold, upon reaching which all subsequent packets with erroneous header options are ignored. However, this threshold value is arbitrarily chosen and the performance can be improved by taking into account network characteristics. To address this we present a mitigation strategy that allows nodes to dynamically adapt against a topological inconsistency attack based on the current network conditions. Results from our experiments show that our approach outperforms the fixed threshold and mitigates these attacks without significant overhead.

No abstract

Abstract. The IETF designed the Routing Protocol for Low power and Lossy Networks (RPL) as a candidate for use in constrained networks. Keeping in mind the different requirements of such networks, the protocol was designed to support multiple routing topologies, called DODAGs, constructed using different objective functions, so as to optimize routing based on divergent metrics. A DODAG versioning system is incorporated into RPL in order to ensure that the topology does not become stale and that loops are not formed over time. However, an attacker can exploit this versioning system to gain an advantage in the topology and also acquire children that would be forced to route packets via this node. In this paper we present a study of possible attacks that exploit the DODAG version system. The impact on overhead, delivery ratio, end-to-end delay, rank inconsistencies and loops is studied.

Most devices deployed in the Internet of Things (IoT) are expected to suffer from resource constraints. Using specialized tools on such devices for monitoring IoT networks would take away precious resources that could otherwise be dedicated towards their primary task. In many IoT applications such as Advanced Metering Infrastructure (AMI) networks, higher order devices are expected to form the backbone infrastructure, to which the constrained nodes would connect. It would, as such, make sense to exploit the capabilities of these higher order devices to perform network monitoring tasks. We propose in this paper a distributed monitoring architecture that takes benefits from specificities of the IoT routing protocol RPL to passively monitor events and network flows without having impact upon the resource constrained nodes. We describe the underlying mechanisms of this architecture, quantify its performances through a set of experiments using the Cooja environment. We also evaluate its benefits and limits through a use case scenario dedicated to anomaly detection.

RPL is a routing protocol for low-power and lossy constrained node networks. A malicious node can manipulate header options used by RPL to track DODAG inconsistencies, thereby causing denial of service attacks, increased control message overhead, and black-holes at the targeted node. RPL counteracts DODAG inconsistencies by using a fixed threshold, upon reaching which all subsequent packets with erroneous header options are ignored. However, the fixed threshold is arbitrary and does not resolve the black-hole issue either. To address this we present a mitigation strategy that allows nodes to dynamically adapt against a DODAG inconsistency attack. We also present the forced black-hole attack problem and a solution that can be used to mitigate it. Results from our experiments show that our proposed approach mitigates these attacks without any significant overhead.

No abstract

The methods defined in RFC 7252 for the Constrained Application Protocol (CoAP) only allow access to a complete resource, not to parts of a resource. In case of resources with larger or complex data, or in situations where resource continuity is required, replacing or requesting the whole resource is undesirable. Several applications using CoAP need to access parts of the resources.