Jürgen Schönwälder

César Addis

Alexandre Bernardini

Thibault Boeglin

François Cholez

Gaëtan Despuaux

Meihui Hurel

Abdelka- Der Gao

Emmanuel Lahmadi

Kévin Nataf

Rousselle

Thibaut Delarozière

Pierre Kimmel

Sébastien Parisot

Keywords:

Cette thèse n'aurait pas pu voir le jour sans le concours et le soutien de certaines personnes que je tiens à remercier ici.

Tout d'abord je souhaite remercier Maryline Laurent et Michele Nogueira pour le temps qu'elles ont consacré à la relecture de cette thèse ainsi que tous les membres du jury pour l'intérêt qu'ils portent à mes travaux.

Je tiens ensuite à remercier Isabelle Chrisment ma directrice de thèse qui m'a oert cette grande opportunité de réaliser

Introduction

This thesis on monitoring and security for the RPL-based Internet of Things was carried out as part of Flamingo 1 , a Network of Excellence project (ICT-318488) sup- ported by the European Commission under its Seventh Framework Program. The Flamingo project focuses on network service and management for the Future Internet. This European project gave us the opportunity to collaborate with the Jacobs University Bremen, Germany, especially with Anuj Sehgal and Jürgen Schönwälder, Professor in the CNDS research group.

Context

The Internet of Things (IoT) is a paradigm that is increasingly growing in the context of pervasive networks and services. It consists in the extension of the Internet to objects from the physical world, which are interacting with each other in order to reach common goals in many application domains (see Figure 1.1). The high interest for this paradigm has resulted in the large-scale deployment of Low power and Lossy Networks (LLN), such as wireless sensor networks and home automation systems. These networks suer from scarce resources and unreliable links. As an eort to standardize protocols used in the IoT, a dedicated stack has been designed having in mind all these constraints. In particular for the routing layer, the IETF RoLL 2 working group has proposed a new protocol called RPL (Routing Protocol for Low power and Lossy Networks) based on IPv6 and specically designed for Internet of Things networks [START_REF] Winter | RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks[END_REF].

We propose in this thesis to address security monitoring issues regarding the RPL routing protocol in the context of IoT networks. Indeed, the multiple constraints faced by these networks make them particularly vulnerable to security threats. Addressing security in such environments is a real challenge considering all their limitations. Therefore, the proposed solutions have to be as lightweight as possible in order to achieve the best trade-o between security and its induced cost for the network. First, we present the Internet of Things paradigm and the induced Low power and Lossy networks with their routing requirements. We then detail the challenges of this new paradigm and more specically the issues addressed in this thesis. We nally provide an overview of the contributions.

The Internet of Things

The Global Standards Initiative on Internet of Things (IoT-GSI) has dened the IoT as a global infrastructure for the information society which enables advanced services by interconnecting (physical and virtual) things based on existing and evolving interoperable information and communication technologies [3]. This technology has been considered by the US National Intelligence Council (NIC) as one of the "Disruptive Civil Technologies" that will signicantly impact the United States [START_REF]Six Technologies with Potential Impacts on US Interests Out to 2025[END_REF]. The NIC envisions that by 2025 Internet nodes will reside in everyday things such as food packages, furniture, paper documents. Furthermore, the Gartner group forecasts that 6.4 billions of objects will be deployed this year and 20.8 billions will be used by 2020 4 . The IoT enables huge number of new applications in various domains such as detailed in [7]:

• Smart environments,
• Transportation and logistics,

• Healthcare.

Low Power Lossy Networks and Routing Protocols

LLN networks have strong constraints in terms of resources (energy, memory, processing) and their communication links are by nature characterized by a high loss rate and a low throughput. Even though several classes of devices can be employed in these networks, as described in Table 1.1, the available computing resources are quite minimal, when compared to standard computing devices used in most applications today. This means that protocols for the Internet of Things must operate within the resource constraints implied by these devices. Moreover, the trac patterns are not simply dened according to a point-to-point schema. In many cases, the devices may also communicate according to point-to-multipoint and multipoint-to-point schemas. Several proprietary initiatives such as ZigBee 5 or Z-Wave 6 have been proposed to deal with LLN constraints. However, standards have to be designed in order to ensure interoperability among the variety of devices and objects. Regarding the routing layer, the IETF RoLL working group has therefore performed a survey of existing routing protocols specied in RFCs or mature drafts in order to answer whether any IETF standardized protocol can meet LLN requirements [START_REF] Levis | Overview of Existing Routing Protocols for Low Power and Lossy Networks[END_REF]. They have considered the following routing protocols: OSPF [START_REF] Moy | OSPF Version 2[END_REF], IS-IS [6], RIP [START_REF] Malkin | RIP Version 2. RFC 2453[END_REF], OLSR [START_REF] Jacquet | Optimized Link State Routing Protocol (OLSR)[END_REF],

TBRPF [START_REF] Templin | Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)[END_REF], AODV [START_REF] Das | Ad hoc On-Demand Distance Vector (AODV) Routing[END_REF], DSR [START_REF] Maltz | The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4[END_REF], DYMO [START_REF] Chakeres | Dynamic manet on-demand (dymo) routing[END_REF], OLSRv2 [START_REF] Clausen | RFC7181: The Optimized Link State Routing Protocol Version 2[END_REF] and Triggered RIP [START_REF] Meyer | OSPF Version 2. RFC[END_REF].

The comparison has been performed using ve criteria:

• Routing state indicates whether routing state scales reasonably within the memory resources of low-power nodes,

• Loss response indicates how the considered routing protocol deals with link failures and recompute paths,

• Control cost indicates if the considered routing protocol minimize power consumption regarding required control trac.

• Link cost refers to the ability for a protocol to incorporate link properties into routing metrics,

• Node cost refers to the ability for a protocol to incorporate router properties into routing metrics and use node attributes for constraint-based routing. Another eort regarding routing in LLN networks has also been proposed: the Lightweight On-demand Ad hoc Distance-vector -Next Generation routing protocol (LOADng) [START_REF] Lys | The Lightweight On-demand Ad hoc Distance-vector Routing Protocol -Next Generation (LOADng)[END_REF]. This protocol is a simplied version of the AODV protocol which has been extended to be used in Mobile Ad hoc NETworks (MANETs). Unlike the RPL protocol, LOADng is a reactive protocol which means that routes are built on demand by nodes which want to reach another node in the network. As such these solutions inherit advantages and disadvantages of these categories of routing protocols and their use must be chosen according to the considered scenarios. For instance, authors of [START_REF] Vucinic | Performance comparison of the RPL and loadng routing protocols in a home automation scenario[END_REF] have compared the performance of the RPL and LOADng protocols in home automation scenarios. Their conclusion is that for applications in which the response time is important, RPL has performed better than LOADng even if some implementation improvements could be done regarding this protocol.

Also in [START_REF] Elyengui | Loadng routing protocol evaluation for bidirectional data ow in AMI mesh networks[END_REF], authors have evaluated the LOADng protocol for bidirectional data ow in AMI (Advanced Measurement Infrastructure) mesh networks. Their study has showed that LOADng had better results than AODV protocol in all considered cases, however, RPL has outperformed them. Nonetheless, authors have pointed out that the RPL protocol has a more complex processing compared to their LOADng implementation. We also want to highlight the fact that the LOADng protocol is still currently an IETF draft whereas the RPL protocol is an IETF standard.

Problem Statement

The manifest importance of the Internet of Things opens new challenges for both industry and academia. One of the main challenges relates to security. We rst present in this section major questions related to security in the Internet of Things.

We then describe more specically challenges addressed in this thesis.

Security Issues

The extension of the Internet to daily objects introduces a new major attack vector for IT technologies as conrmed by the NIC which stated that to the extent that everyday objects become information-security risks, the IoT could distribute those risks far more widely than the Internet has to date. As an example of this statement, in December 2013, a researcher at Proofpoint company has discovered a botnet not only composed of computers but also of household appliances, smart TVs and even a refrigerator 7 . These types of botnets are now referred as thingbots and show the lack of security which IoT networks suer. The Gartner group also forecasts that worldwild IoT security spend will reach 348$ million in 2016 and 547$ million in 2018 8 . They foresee that more than 25% of identied attacks in enterprises will involve IoT infrastructures by 2020.

Several reasons can explain why the IoT is extremely vulnerable to attacks. First, limited resources of typical IoT devices prevent them from implementing traditional 7 http://investors.proofpoint.com/releasedetail.cfm?releaseid=819799 8 http://www.gartner.com/newsroom/id/3291817

Chapter 1. Introduction security mechanisms usually deployed in Internet infrastructures. Second, deployments of things in many applications make these devices unguarded therefore allowing physical attacks. Third, as communications in the IoT are mostly wireless, they are exposed to eavesdropping attacks. Finally, the probably most important reason is about human interactions with these things. Indeed end users usually have little incentive to make IoT devices secure by changing device passwords for example, and most of vendors do not consider security as a key feature for their products.

Some eorts have been made in order to design security solutions as presented in [7].

However, they all rely on cryptographic methods which take away resources and drastically aects the performance of constrained devices [START_REF] Sehgal | Management of Resource Constrained Devices in the Internet of Things[END_REF] likely to be used in IoT and WSN applications.

Addressed Challenges

The objective of this thesis is to design, implement and evaluate new strategies able to address security monitoring in the RPL-based Internet of Things. The RPL protocol is the IETF routing protocol standard for IoT networks. The proposed solutions should detect behaviors of malicious nodes in order to limit their eects.

The rst challenge of this thesis is therefore to assess security in RPL networks by identifying and characterizing threats targeting the RPL protocol. We also classify them using several factors in order to stress threats to be addressed in preference and quantify their impact.

The second challenge consists in designing monitoring security solutions for previously identied attacks which minimize resource consumption of nodes deployed in the RPL network. These solutions should exploit the mechanisms and typical IoT deployments such as the RPL protocol features or heterogeneity of IoT networks in order to preserve node energy. We carefully evaluate their eciency and their cost regarding the considered security attacks.

Overview of Contributions

We tackle in this thesis security monitoring for the RPL-based Internet of Things as depicted by Figure 1.3. As a rst step we assess security threats targeting the RPL protocol. We then propose security solutions. These two main aspects are organized into specic chapters and are preceded by a state of the art on routing and monitoring in the RPL-based Internet of Things. General conclusions end this manuscript and point out future research perspectives.

State of the Art

Chapter 2 details the RPL protocol functioning from topology building and maintenance to inner repair mechanisms. We also present the main security concerns to which this protocol is exposed to. We provide a state of the art of existing approaches for monitoring and security in RPL-based IoT networks. They are classied 1.3. Overview of Contributions according to several criteria (active/passive, centralized/decentralized) which allows us to discuss their benets and drawbacks in such environments.

Security Assessment

Chapter 3 introduces our taxonomy of the attacks against the RPL protocol considering three main categories including attacks targeting network resources, attacks modifying the topology and attacks related to the trac. We describe these attacks, analyze and compare their properties, and discuss existing counter-measures [START_REF] Mayzaud | A Taxonomy of Attacks in RPLbased Internet of Things[END_REF].

Chapter 4 details and quanties the consequences of two attacks exploiting RPL mechanisms: the DAG inconsistency attack and the version number attack [START_REF] Mayzaud | A Study of RPL DODAG Version Attacks[END_REF][START_REF] Sehgal | Addressing DODAG Inconsistency Attacks in RPL Networks[END_REF].

These attacks are chosen because they target node resources accordingly to the established taxonomy. The obtained results show the importance of addressing them because they can signicantly shorten the network lifetime.

Security Solutions

Chapter 5 proposes dierent local mitigation approaches for DAG inconsistency attacks. A rst solution relying on a xed threshold has been introduced by the RoLL working group [START_REF] Hui | The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams[END_REF]. We show the limits of this solution and introduce new approaches called adaptive threshold and dynamic threshold [START_REF] Sehgal | Addressing DODAG Inconsistency Attacks in RPL Networks[END_REF][START_REF] Mayzaud | Mitigation of topological inconsistency attacks in RPL-based low-power lossy networks[END_REF]. Performance of these mitigation solutions is evaluated through experiments. We also quantify their costs and benets. Besides, we explain why such node-level approach cannot be used to detect or mitigate the version number attack because of its properties.

Chapter 6 presents our security-oriented distributed monitoring architecture which detects complex attacks such as the version number attack and complement our nodelevel approach. This architecture is composed of regular nodes and monitoring nodes and exploits RPL mechanisms to organize them. We detail our detection strategy which relies on dedicated modules deployed on monitoring nodes in order to detect both DAG inconsistency and version number attacks.

Chapter 7 evaluates this architecture and the detection strategy [START_REF] Mayzaud | Using the RPL protocol for supporting passive monitoring in the internet of things[END_REF]. First, we quantify the performance of the overhearing mode of monitoring nodes in our simulation environment. We then study the detection results for our strategy. The monitoring nodes placement is also discussed through formalization of optimization problems.

Introduction

The Internet of Things specics require new methods to perform routing and monitoring. In particular, the Routing Protocol for Low-power Lossy Networks (RPL) was designed by the IETF RoLL 9 working group, with capabilities of resource con- strained nodes in mind [START_REF] Winter | RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks[END_REF]. This protocol is expected to form the basis of many Internet of Things (IoT) applications. It is integrated in a full standard protocol stack designed for the IoT as illustrated by Figure 2.1. The IEEE 802.15.4 protocol is used for both physical and link layers of wireless personal area networks (WPAN)

and is appropriate for low power consumptions, short communication ranges and low ow rates. The 6LowPAN protocol also denes encapsulation and header compression mechanisms allowing IPv6 packets to be sent or received through the IEEE 9 Routing over LLNs Section 2.2 describes the routing protocol for LLNs (RPL), its functioning and its security mechanisms. In Section 2.3, we present and compare existing approaches dedicated to monitoring and security for RPL-based IoT.

The RPL Protocol

The RPL protocol is a distance-vector routing protocol based on IPv6. RPL devices are interconnected according to a specic topology which combines mesh and tree topologies called Destination Oriented Directed Acyclic Graphs (DODAG). A DODAG graph is built from a root node which is the data sink of the graph. A network can operate one or more RPL instances which consist of multiple DODAG graphs as showed in Figure 2.2. Each RPL instance is associated to an objective function which is responsible for calculating the best path depending on a set of metrics and/or constraints. For instance, this function can minimize energy consumption or simply compute the shortest path. A RPL node can join several instances at the same time, but it can only join one DODAG graph per instance such as nodes 13 and 17 in Figure 2.2. These multiple instances enable the RPL protocol to perform dierent optimizations, such as quality-of-service ones. The RPL packets can be forwarded according to three trac patterns as showed in the third DODAG of Figure 2.2: (i) multipoint-to-point trac (MP2P) from leaves to the root via upward routes; (ii) point-to-multipoint trac (P2MP) from the root to leaves us-ing downward routes; and (iii) point-to-point trac (P2P) illustrated by red doted arrows using both upward and downward routes. We detail below the functioning and the main features of the RPL protocol.

Section 2.2.1 presents the dierent control messages introduced by the RPL protocol.

Section 2.2.2 explains how these messages are used to build and maintain the DODAG structures. We then describe loops and inconsistencies issues that may occur in RPL networks along with the RPL repair mechanisms designed to counter them in Section 2.2.3. Finally, Section 2.2.4 introduces security concerns regarding the RPL protocol.

RPL Control Messages

The RPL protocol denes four new ICMPv6 control messages in order to share routing information and manage DODAGs: DIS, DIO, DAO and DAO-ACK messages.

The DIS messages (DODAG Information Solicitation) are typically used for asking routing-related information from the neighbor nodes. These neighbors then reply through the sending of DIO messages (DODAG Information Object). These messages contain the information required by RPL nodes to discover a RPL instance, get their conguration parameters, select a DODAG parent set, and maintain the DODAG graph. In particular, a DIO message is composed of ve main elds corresponding to the RPL instance ID, the DODAG ID, the version number, the rank value and the Mode of Operation (MOP) eld. The RPL instance ID and DODAG ID elds are dened by the root node. They indicate respectively the identier of the RPL instance and the identier of the DODAG graph which is the IPv6 address of the root. The version number of a DODAG is incremented by the root node, each time the DODAG is updated in order to synchronize nodes and maintain communications. The rank value of a node corresponds to its position in the graph with respect to the root. It must always be greater than its parents' rank in order to guarantee the acyclic nature of the graph. This value is always increasing in the downward direction. The MOP eld given by the root allows the maintenance of Chapter 2. Routing and Monitoring in RPL-based Internet of Things downward routes and multicast communications. Nodes joining the DODAG have to match the MOP eld and therefore its properties, in order to participate as a router. If not, the RPL nodes can only join the graph as a leaf node. DIO messages are also used by the root in order to build a new DODAG graph. In that case, the messages are broadcasted by the root to its neighbors. Finally, the DAO messages (Destination Advertisement Object) are used to build downward routes along the DODAG graph. They may be acknowledged with DAO-ACK messages (Destination Advertisement Object Acknowledgement). In that case, a DAO-ACK message is sent back to the sender in unicast by the receiver of a DAO message (DAO parent or DODAG root). All these dierent control messages play an important role in the building and maintenance of DODAGs.

DODAG Building and Maintenance

The DODAG graph is built in a step by step manner. The root initially broadcasts a DIO message as depicted in Figure 2.2. Upon receiving a DIO message, a node adds the sender of the message to its parents list and determines its own rank value by taking into account the objective function referred in the DIO message. It then forwards updated DIO messages to its neighbors. Based on its parent list, the node selects a preferred parent which becomes the default gateway to be used when data has to be sent towards the DODAG root. At the end of this process, all the nodes participating in the DODAG graph have an upward default route to the DODAG root. This route is composed of all the preferred parents. The DIO messages are periodically sent according to a timer set with the trickle algorithm [START_REF] Levis | The trickle algorithm[END_REF] which optimizes the transmission frequency of control messages depending on the network state. It consists in increasing the frequency of messages when an inconsistency is detected. This allows faster recovery. On the other hand, the frequency of messages may be reduced when the network shows stability. A new node may join an existing network by broadcasting a DIS message in order to solicit DIO messages from its neighbors.

The downward routes are then built using the DAO messages. Depending on the mode of operation specied by the root in the DIO messages, routing tables can be maintained by router nodes. In the storing mode, the child unicasts a DAO message to the selected parent which records it. The parent aggregates the routes received from other DAO messages and sends the information to its parent recursively through a DAO message. In the non-storing mode, DAO messages are unicasted to the DODAG root. Intermediate nodes do not store routing information but simply insert their own address to the message in order to complete the reverse path. The DAO messages can be acknowledged with DAO-ACK messages.

Loops, Inconsistencies and Repairs

The RPL protocol integrates mechanisms to avoid loops, detect inconsistencies and repair DODAGs. Count-to-innity phenomena occur when a parent increases its rank value and selects its child as a new parent and the child does the same because 2.2. The RPL Protocol 13 it cannot re-attach to another node and so on. Then, the rank value of both parent and child does not stop to increase. To prevent this, the RPL protocol limits the maximum rank value allowed within the graph. DODAG loops appear when a node does not respect the rank property which means that the DODAG is no longer acyclic. To avoid this, a leaving node must poison its sub-DODAG by advertising an innite rank. The leaving node has also the possibility to use a detaching mechanism, which consists in forming an intermediary oating DODAG and rejoining the main DODAG later.

The RPL protocol can also detect inconsistencies using the datapath validation mechanism [START_REF] Winter | RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks[END_REF]. Routing information is included in data packets within a RPL Option carried in the IPv6 Hop-by-Hop header using several ags. The Down 'O' ag indicates the expected direction up or down of a packet. If a router sets this ag, the packet should be forwarded to a child node using downward routes, otherwise it should be sent to a parent with a lower rank towards the DODAG root. The Rank-Error 'R' ag indicates that a rank error is detected. It occurs when a mismatch is observed between the rank values and the direction of a packet indicated by the Down ag. These two ags are used to detect and repair a so called DAG inconsistency i.e.

a routing loop in the network. Finally, the Forwarding-Error 'F' ag indicates the inability of a node to forward the packet towards the destination in case of downward packets [START_REF] Winter | RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks[END_REF]; this means that routing tables are not up-to-date and this ag is used to clean faulty entries of routing tables.

When inconsistencies are detected, the RPL nodes should trigger repair mechanisms. These mechanisms contribute also to the topology maintenance when node and link failures happen. The local repair mechanism consists in nding an alternative path to route the packets when the preferred parent is not available. A node chooses another parent in its parent list. It is also possible to route packets via a sibling node e.g. node with the same rank. This alternative path may not be the most optimized one. According to [START_REF] Korte | A Study of the RPL Repair Process Using ContikiRPL[END_REF], this local repair mechanism is eective and enables the network to converge again within a reasonable time. When the local repair mechanisms fail due to multiple inconsistencies, the DODAG root can initiate a global repair by incrementing the version number of the DODAG graph. The RPL network is then completely rebuilt.

Protocol Security

The RPL protocol denes several mechanisms that contribute to its security. As previously mentioned, it integrates local and global repair mechanisms as well as loop avoidance and detection techniques. It also denes two security modes that can be used to ensure integrity and condentiality of messages. The pre-installed mode consists in having nodes with pre-installed keys in order to send secure messages.

The authenticated mode goes a step forward and considers that nodes with preinstalled keys can only join a DODAG graph as leaf nodes. They must obtain a key from an authenticated authority to join the graph as a router. However, important features like key-management are left out by the current standard [START_REF] Seeber | Towards A Trust Computing Architecture for RPL in Cyber Physical Systems[END_REF]. Furthermore, cryptographic algorithms are known to occupy the most memory and take many CPU Chapter 2. Routing and Monitoring in RPL-based Internet of Things cycles, thereby greatly aecting the performance of constrained devices likely to be used in IoT and WSN applications. Current RPL implementations, as such, do not enable secure operation modes [START_REF] Ko | Evaluating the Performance of RPL and 6LoWPAN in TinyOS[END_REF]. Typical deployments of such networks base their security on link layer, transport/application layer [START_REF] Popa | Applicability Statement for the Routing Protocol for Low Power and Lossy Networks (RPL) in AMI Networks[END_REF][START_REF] Baccelli | Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control[END_REF] or using end-to-end encryption [START_REF] Rescorla | Datagram Transport Layer Security[END_REF][START_REF] Rescorla | Datagram Transport Layer Security Version 1.2[END_REF]. However, an attacker may bypass security at the link layer by either exploiting a vulnerability or gaining access to a shared key. The attacker can also be a miscongured or faulty node whose behaviour can disturb network functioning.

The RPL protocol is exposed to a large variety of security attacks as showed by the taxonomy described in Chapter 3. The characteristics of LLN networks such as resource constraints, lack of infrastructure, limited physical security, dynamic topology and unreliable links make them particularly vulnerable and dicult to protect against attacks [START_REF] Tsao | A Security Threat Analysis for Routing Protocol for Low-power and Lossy Networks (RPLs)[END_REF]. These ones can be specic to the RPL protocol, but can also be applied to wireless sensor networks or even to wired networks [START_REF] Barbir | Generic Threats to Routing Protocols[END_REF]. RPLbased networks thus require performance and security monitoring solutions that are lightweight and ecient.

Monitoring RPL-based Internet of Things

Many monitoring systems have been proposed for the traditional Internet. However these solutions necessitate to be adapted, or new approaches have to be designed in order to cope with the requirements of IoT networks. Since the IoT paradigm is quite recent, few approaches are specically dedicated to these networks and in particular regarding the RPL protocol. In this study most of the presented monitoring solutions are inherited from the wireless sensor networks (WSNs) and from mobile ad hoc networks (MANETs). Some solutions also include frameworks that have been specically designed for security.

The presented monitoring solutions are classied as presented in Figure 2.3.

We distinguish two main categories: active monitoring architectures presented in Section 2.3.1 and passive monitoring architectures described in Section 2.3.2.

Active Monitoring

In what follows, target nodes and networks refer to nodes (respectively networks) to be monitored. We consider as active monitoring a solution that requires target nodes to perform monitoring tasks, for instance send or forward specic trac messages over the network, collect or store monitoring information or decision-making process.

We have divided active monitoring architectures into three categories: centralized, decentralized and hybrid approaches. is responsible for data aggregation and decision making about collected information.

In IoT networks, it can be deployed on the sink or remotely to a server to which all messages are transmitted by the sink which is interconnected to the Internet.

We rst consider in this category traditional management protocols, such as SNMP [START_REF] Case | Simple Network Management Protocol (SNMP)[END_REF] and NETCONF [START_REF] Enns | Network Conguration Protocol (NETCONF)[END_REF] with their adaptation to resource constrained environments. SNMP permits to monitor, control, and also congure network devices.

Each managed device implements an agent responsible for collecting and transmitting data about the device organized in a specic standardized database. NETCONF is used to install, delete and change conguration on network devices and needs persistent connections to operate. An analysis of the SNMP and NETCONF protocols shows their limits in the context of the Internet of Things [START_REF] Sehgal | Management of Resource Constrained Devices in the Internet of Things[END_REF]. The NETCONF protocol is quite resource heavy due to its reliance on XML. SNMP performs relatively well, as long as authentication and encryption are not utilized since these tasks occupy most of the device resources [START_REF] Kuryla | Evaluation of the Resource Requirements of SNMP Agents on Constrained Devices[END_REF]. The integration of SNMP agents with their management information base (MIB) on resource constrained devices may take away valuable resources. This is especially true on C0 and C1 devices (see Table 1.1 from Chapter 1), where the amount of RAM available to nodes is quite restricted. It is important to note that these devices are likely to be the majority of deployed IoT devices [START_REF] Bormann | Terminology for Constrained-Node Networks[END_REF].

Using the CoAP protocol [START_REF] Shelby | The Constrained Application Protocol (CoAP). RFC 7252[END_REF] to perform network management and monitoring tasks can oer resource reduction since the protocol would be used by the application layer in most cases. As such, there are a few eorts under way to design CoAP based management and monitoring solutions. The ongoing CoMI (CoRE Management Interface) initiative in the IETF is aiming to make SMIv2 function over CoAP [START_REF] Der Stok | CoAP Management Interface[END_REF]. It utilizes also MIBs and does not rely on connection-oriented communications. Packets are encoded using the CBOR 10 format [START_REF] Bormann | Concise Binary Object Representation (CBOR)[END_REF] which is similar to JSON [START_REF] Bray | The JavaScript Object Notation (JSON) Data Interchange Format[END_REF] but optimized for constrained devices.

16

Chapter 2. Routing and Monitoring in RPL-based Internet of Things

We can notice that theses solutions focus on conguration management and do not track network events nor detect anomalies. They can however be exploited to perform security since the state of each node is recorded and certain types of malicious activities can be inferred from collected information. In these approaches, constrained nodes have to maintain internal information and send data. Also, in large networks, centralized manager may result in congestion of routes to the sink, and excessive load at the sink due to monitoring data.

Decentralized Approaches

Active decentralized approaches also typically rely on agents deployed on each node to collect and send monitoring data. However, other monitoring tasks (storing, aggregation, ...) are performed by distributed nodes in the network and are not dedicated to a central manager. Such approaches allow reducing target node load compared to active centralized architectures.

Authors of [START_REF] Ramach | DAMON: A Distributed Architecture for Monitoring Multi-hop Mobile Networks[END_REF] propose a distributed monitoring solution called DAMON A poller/pollee strategy is introduced in [START_REF] Liu | Distributed Monitoring and Aggregation in Wireless Sensor Networks[END_REF][START_REF] Lahmadi | Ecient Distributed Monitoring in 6LoWPAN Networks[END_REF] to collect and aggregate monitoring data from a sensor network in a lightweight manner. In particular, authors of [START_REF] Liu | Distributed Monitoring and Aggregation in Wireless Sensor Networks[END_REF] present a distributed algorithm to select pollers among the WSN nodes while both minimizing the number of required monitoring nodes and the false alarm rate. A false alarm occurs if a pollee does not fail to send its reports but the poller misses all of them within a dened time period. This can happen when pollees are too far away from the poller. Aggregation algorithm is also proposed to reduce the communication overhead induced by such a solution. Each poller aggregates collected data and makes local decisions. Using a similar architecture as described in Figure 2.5, Lahmadi et al. [START_REF] Lahmadi | Ecient Distributed Monitoring in 6LoWPAN Networks[END_REF] minimize monitoring communication overhead by embedding these communications in data packets. This work is designed for RPLbased LLNs networks. Not only the piggybacking process is proposed to tackle communication overhead issue, but authors also present a method to select pollers within the graph. Their evaluation has also showed that the proposed approach is robust to topology changes.

Figure 2.5: Poller-pollee architecture used in [START_REF] Lahmadi | Ecient Distributed Monitoring in 6LoWPAN Networks[END_REF].

Since the monitoring data storing is performed by dedicated nodes, these decentralized solutions permit to reduce device resource usage on target nodes which might represent a better choice compared to active centralized architectures. However, agents still need to be deployed on target nodes to collect and send monitoring data thereby reducing their resources.

Hybrid Approaches

Hybrid approaches refer to architectures where monitoring data processing tasks are shared between a central entity and distributed nodes while target nodes are also instrumented to collect this data. The presented solutions below are Intrusion Detection Systems (IDS) and are therefore security oriented.

The SVELTE framework [START_REF] Raza | SVELTE: Real-time intrusion detection in the Internet of Things[END_REF] is specically designed for the RPL protocol. It is composed of three modules. One is responsible for rebuilding the topology at the sink nodes using requests, the second one carries out the intrusion detection process and the last one is a mini distributed rewall. The approach is hybrid since lightweight modules are deployed on each node of the network and modules responsible for heavy processing are run within the root as described by Figure 2.6. This IDS is designed to detect sinkholes and selective forwarding attacks and is robust to identity attacks.

A specication-based solution is described in [START_REF] Le | Specication-based IDS for Securing RPL from Topology Attacks[END_REF][START_REF] Le | A Specication-Based IDS for Detecting Attacks on RPL-Based Network Topology[END_REF] to detect topological attacks in a RPL-based network. A model is generated remotely by learning the states, transitions and statistics based on analyzed traces. This one is then used to perform In these hybrid approaches, even if data processing is performed by both central and distributed entities, target nodes are still instrumented to collect the required monitoring information which consumes their resources. As such, passive monitoring which relies on dedicated probes may oer a good compromise to perform network monitoring while preserving nodes energy. In the same manner, LiveNet [START_REF] B.-R. Chen | LiveNet: Using Passive Monitoring to Reconstruct Sensor Network Dynamics[END_REF] proposes to reconstruct the complex behavior of a deployed sensor network using multiple passive packet sniers collocated with the network as presented in In these examples, data analysis is performed oine remotely by a dedicated entity. This allows running complex algorithms, however it may introduce considerable delays in detecting failures or abnormal activities.

Decentralized Approaches

In passive monitoring, decentralized architectures refer to approaches where the monitoring tasks (data aggregation and analysis, decision making process) are not only 20

Chapter 2. Routing and Monitoring in RPL-based Internet of Things performed by a central entity. These tasks can be achieved locally by the dedicated monitoring nodes or they can be shared in a two-level hierarchical system where the distributed monitoring nodes gather and aggregate data from the sniers before forwarding them to a sink for further processing.

Authors of [START_REF] Xu | PMSW: a passive monitoring system in wireless sensor networks[END_REF] design a passive monitoring system called PMSW 13 composed of four types of nodes: sensor nodes, sning nodes, monitoring nodes and a workstation. Sning nodes are deployed in the network to collect information regarding the sensors, and connect to a monitoring node. This one is responsible for aggregating collected data and sending them to the workstation. In the workstation, the traces are merged using clock-adjusting strategies, the missing traces are inferred based on a nite state machine. Authors also use descriptions of event-rules based on XML to perform fault diagnosis.

In Pimoto [START_REF] Awad | On the Need for Passive Monitoring in Sensor Networks[END_REF], sensor nodes are divided in so-called islands to which are assigned a monitoring node that passively listens to all communications in the area. These sniers send their collected information over a hierarchical operating system to a server using a second radio channel operated on Bluetooth. The server processes the data afterwards.

Another passive solution called EPMOSt 14 [START_REF] Garcia | EPMOSt: An Energy-Ecient Passive Monitoring System for Wireless Sensor Networks[END_REF] focuses on reducing energy con- sumption by passive monitoring in WSNs. The monitoring information is provided using an SNMP agent. Sniers are deployed in the target network, send their collected information to a local monitoring node using a dedicated monitoring network as presented in Figure 2.9. The local monitoring nodes store this data in a distant server which performs the analysis. A snier election is run by sniers and monitoring nodes, to choose which target nodes are monitored by a given snier.

After having analyzed traces, the server generates reports which are stored in a MIB database.

While previous approaches rely on hierarchical architectures, the following solution use exclusively a local strategy to perform monitoring in WSNs. Authors of [START_REF] Dong | Edge self-monitoring for wireless sensor networks[END_REF] propose a self-monitoring approach which relies on watchdog techniques: some nodes of the network are chosen to perform the monitoring tasks for the target nodes in communication range. Authors analyze the problem of self-monitoring in large-scale wireless sensor networks. They present two distributed algorithms to elect the monitoring nodes among the target nodes in an optimal topology reducing the induced overhead. They provide complexity analysis and cost evaluation of these algorithms.

However, in this case, the monitoring is purely local because there is no monitoring data exchange between monitoring nodes. It is not possible in this solution to take into account the entire network, opening the possibility to miss major events. Also, energy issues are not considered in the selection process of monitoring nodes.

Decentralized passive architectures allow processing monitoring trac locally.

Most of these approaches are based on hierarchical systems where target nodes are monitored from local and global perspectives. In some cases, as in the watchdog approach, this processing is purely local which does not give a global view of the 13 Passive Monitoring System for WSN network. We can also observe that there is no direct interaction among the monitoring nodes which could perform a collaborative level of monitoring by crossing collected information.

Comparison and Limits

In this section, we compare the dierent identied solutions according to several relevant criteria for this thesis as presented in Table 2.1. Among those criteria, storing refers to the fact that target nodes have to store collected information. Gathered information can also be stored in dedicated nodes called data repositories according to the considered approach. The pervasiveness of the proposed solution indicates whether nodes performing monitoring activities are involved in the target network activities. The security property is also considered, it indicates whether the architecture has been designed for security purpose. It can be noted that each monitoring solution could be used to perform security but dedicated algorithms need to be deployed where data is processed. The next criterion is the level of monitoring. While a large majority of mentioned solutions can be adapted to the RPL protocol, a solution able to exploit the RPL mechanisms will be more energy ecient.

Conclusions

In this chapter, we have presented the RPL protocol and detailed its main mechanisms. We have showed how DODAGs are built and maintained using the dierent control messages. First the upward routes are built to reach the sink using DIO messages. According to the advertised mode of operation, the downward routes are then formed through DAO messages in order to reach the dierent nodes participating in the graph. We have also described loops and inconsistencies that may occur in RPL networks and how the protocol standard manages them. In particular, a limited rank value is introduced to address count-to-innity phenomena and detaching mechanisms such as poisoning are designed to prevent them. The data path validation is used to detect and x possible loops in the network while local and global repair mechanisms prevent connectivity loss and ensure optimal topology. We have introduced security concerns regarding the RPL protocol. We have showed that the lack of nodes resources and no currently deployed secured transmissions leave the RPL protocol open to a large variety of attacks.

In such constrained networks, it is necessary to provide a monitoring solution with a minimal impact on the network resources. We have described several monitoring architectures mostly from ad-hoc networks and wireless sensor networks depending on their active/passive and centralized/decentralized natures. These approaches have been compared using several criteria. We have concluded that none of the presented solutions meets our requirements. In RPL-based IoT networks, in order to address security, we need a framework which does not require target nodes be instrumented in order to preserve their resources. To reduce the cost of deploying such an architecture, it should take benet from the RPL protocol features and allows monitoring nodes to participate in the target network by relying on typical IoT deployments.

This solution should also perform multi-level of monitoring to guarantee a satisfying reactivity and a ne granularity of data to address a large variety of threats.

These solutions are necessary to get performance indicators and to detect attacks to which the RPL protocol is exposed. In the next chapter, we propose to identify and classify these attacks.

Chapter 3

Introduction

Attacks targeting RPL networks require to be identied and prioritized according to their consequences in order to design ecient security solutions. In this chapter, we propose to establish a taxonomy of routing attacks against the RPL protocol. We take into account the goals of the attack and which element of the RPL network is impacted. We also describe in this classication existing security solutions we have found in the literature. The taxonomy is depicted in Figure 3.1 and considers three categories of security attacks. The rst category covers attacks targeting the exhaustion of network resources (energy, memory and power). These attacks are particularly damaging for such constrained networks because they greatly shorten the lifetime of the devices and thus the lifetime of the RPL network. The second category includes attacks targeting the RPL network topology. They disturb the normal operation of the network: the topology may be sub-optimized in comparison with a normal convergence of the network or a set of RPL nodes may be isolated from the network. The third category corresponds to attacks against the network trac, such as eavesdropping attacks or misappropriation attacks. Each section of this chapter focuses on a specic category of RPL security attacks.

Attacks against Resources

Attacks against resources typically consist in making legitimate nodes perform unnecessary processing in order to exhaust their resources. This category of attacks aims at consuming node energy, memory or processing. This may impact on the availability of the network by congesting available links and therefore on the lifetime of the network which can be signicantly shortened. We distinguish two subcategories of attacks against resources. The rst one gathers direct attacks where a malicious node will directly generate the overload in order to degrade the network.

The second one contains indirect attacks where the attacker will make other nodes generate a large amount of trac. For instance, such an attack can be performed by building loops in the RPL network so that other nodes produce trac overhead.

Direct Attacks

In case of direct attacks, the attacker is directly responsible for resource exhaustion.

This can typically be done by performing ooding attacks or by executing overloading attacks with respect to routing tables, when the storing mode is active.

Flooding Attacks

Flooding attacks consist in generating a large amount of trac in a network and make nodes and links unavailable. These attacks can be performed by an external or 3.2. Attacks against Resources 27 internal attacker. They exhaust the resources of all the network nodes in the worst case. More specically, using solicitation messages to perform the ooding is called an HELLO ood attack. In RPL networks, an attacker can either broadcast DIS messages to its neighboring nodes which have to reset their trickle timer, or, unicast DIS messages to a node which has to reply with DIO messages. In both cases, this attack leads to network congestion and also to the saturation of the RPL nodes. The consequences of such attacks have been studied in [START_REF] Le | The Impacts of Internal Threats towards Routing Protocol for Low power and lossy Network Performance[END_REF], the authors show that the control message overhead signicantly increases but the delivery ratio is not aected.

However, no solution especially designed for RPL has been proposed.

Routing

Increased Rank Attacks

The increased rank attack consists in voluntarily increasing the rank value of a RPL node in order to generate loops in the network. This attack has been studied in [START_REF] Xie | Routing Loops in DAG-Based Low Power and Lossy Networks[END_REF] through ns-2 simulations. The authors showed that their loop avoidance mechanisms costed more than the attack itself. Concretely, in a RPL network, a rank value is associated to each node and corresponds to its position in the graph structure according to the root node. As previously mentioned, the node rank is always increasing in the downward direction in order to preserve the acyclic structure of the DODAG. When a node determines its rank value, this one must be greater than the rank values of its parents. If a node wants to change its rank value, it has rst to update its parents list by removing the nodes having a higher rank than its new rank value. Once a node has established the set of parents in a DODAG, it selects its preferred parent from this list in order to optimize the routing cost when transmitting a packet to the root node. A malicious node advertises a higher rank value than the one it is supposed to have. Loops are formed when its new preferred parent was in its prior sub-DODAG and only if the attacker does not use loop avoidance mechanisms.

In that case, two attack scenarios are possible as illustrated in Figure 3

DAG Inconsistency Attacks

A RPL node detects a DAG inconsistency when it receives a packet with a Down 'O' bit set from a node with a higher rank and vice-versa [START_REF] Winter | RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks[END_REF] e.g. when the direction of the packet does not match the rank relationship. This can be the result of a loop in the graph. The Rank-Error 'R' bit ag is used to control this problem. When an inconsistency is detected by a node, two scenarios are possible: (i) if the Rank-Error ag is not set, the node sets it and the packet is forwarded. Only one inconsistency along the path is not considered as a critical situation for the RPL network, (ii) if the 'R' bit is already set, the node discards the packet and the trickle timer is reset [START_REF] Levis | The trickle algorithm[END_REF].

As a consequence, control messages are sent more frequently. A malicious node has just to modify the ags or add new ags to the header. The immediate outcome of this attack is to force the reset of the DIO trickle timer of the targeted node. In that case, this node starts to transmit DIO messages more frequently producing local instability in the RPL network. This also consumes the battery of the nodes and impacts the availability of links. All the neighborhood of the attacker is concerned by the attack, since it has to process unnecessary trac. Moreover, by modifying legitimate trac, all the packets are discarded by the targeted node. This causes a blackhole and isolates segments of the network. To mitigate the ooding induced by this attack, [START_REF] Hui | The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams[END_REF] proposes to limit the rate of trickle timer resets due to an RPL Option to no greater than 20 resets per hour, however no reasoning is provided regarding this value. We will present in Chapter 5 two solutions that takes into account network characteristics to detect and mitigate such attacks.

Version Number Attacks

The version number is an important eld of each DIO message. [START_REF] Landsmann | Topology Authentication in RPL[END_REF] proposed an improvement of the previous solution solving some issues they discovered in VeRA. In this thesis we will also propose a detection strategy for these attacks in Chapter 6.

Analysis

We discuss in this section the properties of the identied attacks as well as methods and techniques to address them. Table 3.1 summarizes attacks against resources.

A rst property to be analyzed is the internal (I) or external (E) nature of the attacks. Internal attacks are initiated by a malicious or compromised node of the RPL network. External attacks are performed by nodes that do not belong to the RPL network or are not allowed to access it. We can observe that only the ooding can be performed externally because the attacker does not need to join the graph to perform the DIS ooding since DIS message are used to discover the DODAG. For the rest of the attacks, the malicious node needs to be part of the DODAG to have enough knowledge in order to launch its attacks. TRAIL [START_REF] Landsmann | Topology Authentication in RPL[END_REF] Low (for both solutions)

A second property is to determine if the attack is passive (P) or active (A).

Passive attacks do not modify the behavior of the network. On the contrary, active attacks require the malicious node to perform operations that are observable by other nodes in the network. They are usually more critical than passive attacks which mainly target data condentiality or topology information. Attacks targeting the resources are all active since the attacker has to send packets. A third property is the prerequisites property. The prerequisites are the required conditions to initiate the attack besides the internal/external nature of the attack, such as particular conguration of the network. The storing mode which means maintaining routing tables has to be enabled to launch routing table overload and the RPL option header has to be implemented to run DAG inconsistency attacks.

The next property corresponds to the impact of the attacks. The objective is to quantify the consequences of a successful attack on the network. The impact in this category is evaluated as the type of over-consumed resources (e.g. memory, battery, link availability). We observe that all the attacks consume node battery as they imply additional processing for the nodes. Most of the time, the link availability is also impacted since the attacks require sending a large number of control messages.

The memory is also over-consumed in case of routing table overload attacks.

The fth property corresponds to the CIA acronym standing for condentiality, integrity and availability, and refers to a security reference model. In the context of the RPL protocol, condentiality means the protection of routing information and exchanges. Integrity involves the protection of routing information from unauthorized modication, and availability requires that forwarding services and routing information exchanges are accessible for the nodes. Regarding the identied attacks targeting resources, they systematically impact network availability. Indeed, these attacks involve that the attacker jeopardizes resources of the network (battery, memory, processing, link availability). The integrity is also impacted when the result of the attack supposes that a legitimate resource or legitimate trac is corrupted e.g. routing table of legitimate nodes is altered during routing table overload attacks. Version number modications and DAG inconsistency attacks induce that the integrity of packets is jeopardized.

The two last columns of tables indicate respectively the possible security mechanisms to address the attacks, and their overhead (according to their authors). We saw that RPL provides internal mechanisms which contribute to counter attacks.

For instance, the loop avoidance mechanisms prevent increased rank attacks. The protocol also proposes an optional mitigation mechanism that limits inconsistency attacks impact [START_REF] Hui | The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams[END_REF]. Specic approaches have been designed for the RPL protocol.

The VeRa [START_REF] Dvir | VeRA -Version Number and Rank Authentication in RPL[END_REF] and the TRAIL [START_REF] Landsmann | Topology Authentication in RPL[END_REF] approaches address version number modications. In many cases, it is dicult to evaluate the overhead induced by the security mechanisms because they are still at a conceptual level. Moreover, we cannot really consider that the mechanisms which are inherent to the RPL protocol operation introduce an overhead.

Attacks on Topology

Attacks against the RPL protocol can also target network topology. We distinguish two main categories among these attacks: sub-optimization and isolation.

Chapter 3. Taxonomy of Attacks in RPL Networks

Sub-optimization Attacks

In case of sub-optimization attacks, the network will not converge to the optimal form (i.e optimal paths) inducing poor performance.

Routing Table Falsication Attacks in Storing Mode

In a routing protocol, it is possible to forge or modify routing information to advertise falsied routes to other nodes. This attack can be performed in the RPL network by modifying or forging DAO control messages in order to build fake downward routes. This can only be done when the storing mode is enabled. For instance, a malicious node advertises routes towards nodes that are not in its sub-DODAG. Targeted nodes have then wrong routes in their routing table causing network sub-optimization. As a result, the path can be longer inducing delay, packet drops or network congestion. This has not been studied yet in the context of the RPL protocol.

Sinkhole Attacks

An alternative attack consists in building a sinkhole. Such an attack takes place in two steps. First, the malicious node manages to attract a lot of trac by advertising falsied information data (for instance, up and downward links of superior quality).

Then, after having received the trac in an illegitimate manner, it modies or drops it. In RPL networks, the attack can be easily performed through the manipulation of the rank value as showed in Section 3.4.2.1. Because of this falsied advertisement, the malicious node is more frequently chosen as preferred parent by the other nodes, while it does not provide better performance. Thus, the routes are not optimized for the network. The attack modies the topology and degrades network performance.

Moreover, if the attacker decides to drop all the trac, it also performs a blackhole attack.

This attack was studied in [START_REF] Wallgren | Routing Attacks and Countermeasures in the RPL-Based Internet of Things[END_REF] and [START_REF] Raza | SVELTE: Real-time intrusion detection in the Internet of Things[END_REF], the authors proposed an IDS called SVELTE to counter it. A functionality of this IDS is to build a global view of the network and as a consequence the possibility to detect inconsistencies in the network such as sinkholes as presented in Chapter 2. In [START_REF] Weekly | Evaluating Sinkhole Defense Techniques in RPL Networks[END_REF], the authors investigated defense techniques against sinkholes. The rst technique is called Rank verication and restricts the possibility for the attacker to decrease its rank value. It allows legitimate nodes to check if another node along the path has a fake rank. The second technique is called parent fail-over and operates as an end-to-end acknowledgement. When a root node does not receive enough trac from a node (according to a certain threshold value), it adds this node's address in a DIO message eld. When the node receives the DIO message with its own identity, it blacklists its parent and selects another one. The authors show that a combination of these two techniques provides ecient results in a RPL network.

Wormhole Attacks

Wormhole attacks are dened as the use of a pair of RPL attacker nodes, nodes A and B, linked via a private network connection. An example is depicted in Figure 3.3.

In this scenario, every packet received by node 13 is forwarded through the wormhole to node 21 in order to be replayed later. Since the roles are interchangeable, node 21 may perform the same operations than node 13. In the case of wireless networks, it is easier to perform this attack because the attacker can send through the wormhole the trac addressed to himself as well as all the trac intercepted in the wireless transmissions. The wormhole attack distorts the routing path and is particularly problematic for RPL networks. If an attacker tunnels routing information to another part of the network, nodes which are actually distant, see each other as if they are in the same neighborhood. As a result, they can create non-optimized routes according to the objective function. This attack was studied in [START_REF] Wallgren | Routing Attacks and Countermeasures in the RPL-Based Internet of Things[END_REF] which showed that the RPL protocol cannot solve this attack by itself. The authors explained that countering this type of attack is a research challenge if one node of the wormhole is in the Internet. If both attackers are in the RPL networks, the authors suggested to use geographical data and dierent cryptographic keys at the MAC layer for dierent segments to solve this threat issue. Also the authors of [START_REF] Khan | Wormhole attack prevention mechanism for RPL based LLN network[END_REF] proposed to prevent this attack by using Merkel trees to authenticate nodes and paths.

Routing Information Replay Attacks

A RPL node can also perform routing information replay attacks. It records valid control messages from other nodes and forwards them later in the network. In case of dynamic networks, this attack is quite damaging because the topology and the routing paths are often changed. Replay attacks cause nodes to update their routing tables with outdated data resulting in a false topology. The RPL protocol uses some sequence counters to ensure the freshness of the routing information such as the version number for DIO messages or the path sequence number present in the transit information option of DAO messages [START_REF] Winter | RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks[END_REF]. This attack is mentioned in [START_REF] Rghioui | Denial-of-Service attacks on 6LoWPAN-RPL networks: Issues and practical solutions[END_REF] however the authors neither study the consequences of such an attack nor explained how it can takes place in RPL networks.

Worst Parent Attacks

This attack described in [START_REF] Le | The Impact of Rank Attack on Network Topology of Routing Protocol for Low-Power and Lossy Networks[END_REF] and termed as "Rank attack" consists in choosing systematically the worst preferred parent according to the objective function. The outcome is that the resulting path is not optimized inducing poor performance. This attack cannot be easily tackled because children node rely on their parent to route packets and this attack cannot be monitored by neighbors. However, using a security solution which rebuilds a global view of the graph based on nodes information should detect this attack such as the proposed solution in [START_REF] Raza | SVELTE: Real-time intrusion detection in the Internet of Things[END_REF].

Isolation Attacks

The attacks against the topology can also isolate a node or a subset of nodes in the RPL network which means that these nodes are no longer able to communicate with their parents or with the root.

Blackhole Attacks

In a blackhole attack, a malicious intruder drops all the packets that it is supposed to forward. This attack can be very damaging when combined with a sinkhole attack causing the loss of a large part of the trac. It can be seen as a type of denial-ofservice attack. If the attacker is located at a strategic position in the graph it can isolate several nodes from the network. There is also a variant of this attack called gray hole (or also selective forwarding attack) where the attacker only discards a specic sub-part of the network trac. Chugh et al. [START_REF] Chugh | Case Study of a Black Hole Attack on LoWPAN-RPL[END_REF] investigated the consequences of blackhole attacks in RPL networks through a set of Cooja simulations. They highlighted dierent indicators to detect these attacks such as rate and frequency of DIO messages, packet delivery ratio, loss percentage and delay. The SVELTE IDS proposed in [START_REF] Raza | SVELTE: Real-time intrusion detection in the Internet of Things[END_REF] was designed to detect selective forwarding attacks in such networks.

DAO Inconsistency Attacks in Storing Mode

DAO inconsistencies occur when a node has a downward route that was previously learned from a DAO message, but this route is no longer valid in the routing table of the child node [START_REF] Winter | RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks[END_REF]. RPL provides a mechanism to repair this inconsistency, called DAO inconsistency loop recovery in the data path validation. This optional mechanism allows the RPL router nodes to remove the outdated downward routes using the Forwarding-Error 'F' ag in data packets which indicates that a packet can not be delivered by a child node. The packet with the 'F' ag is sent back to the parent in order to use another neighbor node, as depicted in Figure 3 this attack is to make router nodes discard available downward routes. This makes the topology of the DODAG graph sub-optimal. One possible consequence of this attack is to isolate the sub-DODAG bound to the attacker which can no longer receive packets, as in our example. This also leads to additional congestion (if the packets are forwarded through sub-optimal paths), partitions and instabilities in the network. The consequences for the children nodes include starvation and delay [START_REF] Barbir | Generic Threats to Routing Protocols[END_REF].

To reduce the eects of this attack on the network, RFC 6553 proposes to limit the rate of the downward routing entries discarded due to an 'F' ag to 20 per hour [START_REF] Hui | The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams[END_REF].

Once this value is reached 'F' ag packets are no longer taken into account.

Analysis

Table 3.2 synthesizes attacks targeting the topology. We notice that the attacker has to be both internal and active for these attacks. Indeed, the malicious node has to join the graph to manipulate the topology. The attacks related to routing tables such as routing table falsications and DAO inconsistency attacks need the storing mode to be enabled. Also the RPL option header has to be implemented for the second attack since the malicious node misuses the data path validation which Chapter 3. Taxonomy of Attacks in RPL Networks relies on this header. At least two malicious intruders are required to perform the wormhole attack. only used for downward routing. Therefore, the subnet of the target is modied but the upward trac is not disturbed. All the other attacks can have consequences on both upward and downward trac since they concern all types of packets. In that case, both the subnet and/or the neighborhood can be damaged. These attacks do not target a specic node but try to impact on the overall network trac in general, even if some ltering can also be performed.

Regarding the next property, the availability is impacted in all attacks because to topology attacks such as the Rank verication [START_REF] Dvir | VeRA -Version Number and Rank Authentication in RPL[END_REF], the Parent fail-over [START_REF] Weekly | Evaluating Sinkhole Defense Techniques in RPL Networks[END_REF] or

Merkel trees [START_REF] Khan | Wormhole attack prevention mechanism for RPL based LLN network[END_REF], however the costs of these solutions have not been evaluated yet.

Chugh et al. [START_REF] Chugh | Case Study of a Black Hole Attack on LoWPAN-RPL[END_REF] have dened methods for eciently detecting blackholes in these networks. The SVELTE IDS [START_REF] Raza | SVELTE: Real-time intrusion detection in the Internet of Things[END_REF] is also designed to detect the sinkhole and blackhole attacks. We notice that there is no solution for routing table falsication since this attack has not been studied in the context of the RPL protocol. The worst parent attack also does not have any counter-measures although this threat has been studied [START_REF] Le | The Impact of Rank Attack on Network Topology of Routing Protocol for Low-Power and Lossy Networks[END_REF].

Attacks on Trac

This third category concerns the attacks targeting the RPL network trac. It mainly includes eavesdropping attacks on the one hand, and misappropriation attacks on the other hand.

Eavesdropping Attacks

The pervasive nature of RPL networks may facilitate the deployment of malicious nodes performing eavesdropping activities such as sning and analyzing the trac of the network.

Sning Attacks

A sning attack consists in listening to the packets transmitted over the network.

This attack is very common in wired and wireless networks and compromises the condentiality of communications. An attacker can perform this attack using a compromised device or directly capture the packets from the shared medium in case of wireless networks. The information obtained from the snied packets may include partial topology, routing information and data content. In RPL networks, if an attacker snis control messages, it can access information regarding the DODAG conguration such as DODAG ID, version number, ranks of the nodes located in the neighborhood. By sning data packets, the attacks can not only discover packet content but also have a local view of the topology in the eavesdropped area by looking at source/destination addresses. This attack is dicult to be detected due Chapter 3. Taxonomy of Attacks in RPL Networks to its passive nature. The only way to prevent sning is encryption of messages when the attacker is external. Even if RFC 6550 mentions encryption of control messages as an option, the technical details are left out from the specication making implementation dicult.

Trac Analysis Attacks

Trac analysis aims at getting routing information by using the characteristics and patterns of the trac on a link. This attack can be performed even if the packets are encrypted. The objective is, like sning attacks, to gather information about the RPL network such as a partial view of the topology by identifying parent/children relationships. Thanks to this attack, a malicious node can possibly perform other attacks with the gathered information. The consequences depend on the rank of the attacker. If this one is close to the root node, it can process a large amount of trac and therefore can get more information than when the node is located on the edge of a sub-DODAG.

Misappropriation Attacks

In misappropriation attacks, the identity of a legitimate node is usurped or performance are overclaimed. These attacks are not so damaging for the RPL network per se. However, they are often used as a rst step for other attacks such as those seen in the previous two main categories. They allow the attacker to gain a better understanding of the network and its topology, to get better access or to intercept a large part of the trac.

Decreased Rank Attacks

In a DODAG graph, the lower the rank is, the closer the node is to the root and the more trac this node has to manage. When a malicious node illegitimately advertises a lower rank value, it overclaims its performance. As a result, many legitimate nodes connect to the DODAG graph via the attacker. This results in the attraction of a large part of the trac, as showed in Figure 3.5. Thanks to this operation, the malicious node is capable of performing other attacks such as sinkhole and eavesdropping attacks. In the RPL protocol, an attacker can change its rank value through the falsication of DIO messages. The VeRa [START_REF] Dvir | VeRA -Version Number and Rank Authentication in RPL[END_REF] solution as well as the Rank verication method [START_REF] Weekly | Evaluating Sinkhole Defense Techniques in RPL Networks[END_REF] described in Sections 3.3.1.2 and 3.2.2.3 are able to address this issue. However, authors in [START_REF] Landsmann | Topology Authentication in RPL[END_REF] have showed that VeRa is not secure regarding rank authentication and they proposed improvements to address this issue called TRAIL. They also showed another way to perform this attack by replaying the rank of the attacker's parent which allows it to decrease its rank by one. Since SVELTE [START_REF] Raza | SVELTE: Real-time intrusion detection in the Internet of Things[END_REF] can detect sinkhole attacks it can also detect the decreased rank attack.

Identity Attacks

Identity attacks gather both spoong and sybil attacks. A spoong attack also called Clone ID attack occurs when a malicious node pretends to be a legitimate existing node. In RPL networks, the root node plays a key role in a DODAG graph. It builds and maintains the topology by sending routing information. An attacker may sni the network trac to identify the root node. Once this identication is performed, it can spoof the address of the DODAG root and take the control over the network.

During sybil attacks [START_REF] Douceur | The Sybil Attack[END_REF], one malicious node uses several logical entities on the same physical node. Identity attacks are used as a premise to perform other operations.

In [START_REF] Wallgren | Routing Attacks and Countermeasures in the RPL-Based Internet of Things[END_REF], the authors have showed that the RPL protocol cannot solve this issue by itself and proposed to consider geographical data to detect such attacks.

Analysis

As we can observe in Table 3.3, eavesdropping attacks can be performed externally.

They are usually exploited to gain access to the internal network. As for the other categories, the attacker has to be an insider to perform misappropriation attacks.

Only the eavesdropping attacks have been classied as passive attacks. All the other identied attacks induce that the attacker generates or modies packets. Passive attacks are quite dicult to detect, in particular in RPL networks which are often supported by wireless links. There is no particular prerequisite for attacks on trac.

Regarding attacks on trac, Table 3.3 describes the cases where the consequences can be considered as critical for the RPL network. The eect of eavesdropping attacks depends on the nature of the listened data. For instance, data content may be of high importance for patients in the area of healthcare sensor networks, while the criticality is lower when the objective of the RPL network is simply to collect weather temperatures. In case of misappropriation attacks, the consequences are determined by the location of the malicious or spoofed node. Indeed, when the malicious node has a lower rank, it is closer to the root. It is therefore capable of intercepting a The next property to be discussed is the classication according to the CIA model. The condentiality aspect concerns eavesdropping attacks, where the goal of the attacker is to obtain information about the network conguration. Due to the nature of misappropriation attacks, the integrity property is aected in these cases.

The only way to prevent sning is to use encryption. However, in our security model we assumed that the attacker is able to break the cryptography due to the physical constraints of RPL networks. As mentioned previously, even if cryptographic mechanisms are suggested in the standard, it is dicult to implement them because important feature like key-management are left out by the RFC. Moreover, cryptographic algorithms are known to be resource consuming in terms of memory and computation. Current RPL implementations, as such, do not enable secure operation modes. To our knowledge, there is no current existing solution to prevent trac analysis and identity attacks in RPL networks. However, the decreased rank attack has been widely studied because it is also used in sinkhole attacks and several counter-measures has been proposed.

Conclusions

Considering the nature of RPL networks it is mandatory to identify and analyze the security attacks to which this protocol is exposed. We have therefore proposed, in this chapter, a taxonomy classifying the attacks against the RPL protocol in three main categories. The attacks against resources reduce network lifetime through the generation of fake control messages or the building of loops. The attacks against the topology make the network converge to a sub-optimal conguration or they isolate nodes. Finally, attacks against network trac let a malicious node capture and analyze large part of the trac. Based on this taxonomy, we have compared the properties of these attacks and discussed methods and techniques to avoid or prevent them.

We have showed how the RPL protocol is exposed to a large variety of attacks. In order to complement this analysis, we need to quantify the consequences of these attacks. We therefore want to study further attacks in order to evaluate their behavior and their impact on a RPL network according to relevant metrics.

Chapter 4

The DAG Inconsistency Attack

In this section, we rst present the dierent scenarios for the DAG inconsistency attack. After describing our simulation setup, we detail the evaluation results.

Attack Description

The RPL data path validation mechanism was designed to improve reliability of the protocol. However, a malicious node can misuse it in order to attack the network;

this is called a DAG inconsistency attack. This attack can be used to directly harm a targeted node, or to manipulate packet headers and force the next-hop node to drop the modied packets.

1"

2" 3"

9" 8" 7" 6" 5" 4" 10"

Control'Message' A.ack'Message' R=1$ R=2$ R=2$ R=2$ R=3$ R=3$ R=3$ R=4$ R=4$ R=4$ (a) Direct attack scenario. 1" 2" 5" 4" 3" Data$Packets$ Modified$Packets$ 1" 2" 3" 4" 5" R=1$ R=2$ R=3$ R=4$ R=5$
(b) Indirect attack scenario.

Packet Manipulation Scenario

In this scenario, the malicious intruder modies the IPv6 header of packets it forwards such that the 'R' ag and the 'O' ag representing the wrong direction are set. The receiving node assumes that a DAG inconsistency has taken place and discards the packet. As a result, the malicious node succeeds in forming a black-hole at the nexthop node. This attack could either be carried out on all packets forwarded by the malicious node, or selectively based on source, destination, or even type of message.

The nodes originating the message cannot easily detect this forced black-hole because the packet is not dropped by their next-hop, but by a node that is at least two hops away. If the malicious node itself were to drop the packets, its children could detect this by enabling the promiscuous mode. But the promiscuous mode is not an option in such a scenario since in most RPL networks, a node that is two hops away is usually out of radio range as well [START_REF] Chugh | Case Study of a Black Hole Attack on LoWPAN-RPL[END_REF]. This means, that only the attacker is within the radio range of both the sender and the node that drops the packet.

The modication of header could be detected by nodes with the promiscuous mode enabled, however, it is known to consume node energy, which is not suitable for C0 devices.

In general this approach is an advantageous strategy for the attacker to force another node to drop the packets. Furthermore, if the control packets originating from the malicious node are normal, then the malicious activity is completely hidden.

In this scenario, not only the delivery ratio decreases, but the control overhead of RPL nodes also increases along with deteriorating channel availability and increasing energy consumption.

For example, in the DODAG depicted by Before forwarding data packets from its descendants, nodes 4 and 5, it modies them such that the `O' and `R' ags are set. As a consequence, node 2 drops them, thereby becoming akin to a black-hole. This causes the delivery ratio for nodes 4 and 5, descendants of node 3 to be severely harmed. Node 2 also resets its trickle timer causing an increase in overhead as well.

Simulation Setup

The Contiki 2.6 operating system has been used for evaluating the DAG inconsistency attack since it provides an RPL implementation that works on multiple platforms. However, the RPL implementation provided by Contiki did not support correct handling of data path validation mechanism. While packets with the `R' ag are dropped, the trickle timers are not reset. As such, the implementation was modied to correct this functionality.

The TelosB, also known as the TMote Sky, has been used as the development platform since its computational resources allow it to function as an RPL router node with the Contiki RPL implementation. To permit evaluation under multiple scenarios, instead of building a topology of actual nodes, the compiled binary for a TelosB was used in the Cooja [START_REF] Osterlind | Cross-Level Sensor Network Simulation with COOJA[END_REF] simulator provided by Contiki with Unit Disk

Graph radio attenuation and scattering model (UDGM). This approach provides a method to quantify the DAG inconsistency attack impact under conditions where the lossy IEEE 802.15.4 channel does not cause packet loss. This allows evaluation under ideal conditions, with no external characteristics causing bias in the results.

The Cooja simulator is quite close to real hardware since it uses the MSPSim software to emulate the MSP430 architecture and the performance of a MSP430F1611 microcontroller, which is utilized by the TelosB. A validation of the simulation tool will be provided in Chapter 5.

Impact Quantication

The consequences of the direct attack scenario are rst evaluated using the control message overhead metric. We then study the impact of the packet manipulation scenario based on control message overhead and overall delivery ratio metrics.

Direct Attack Scenario Evaluation

To evaluate the control message overhead caused by the DAG inconsistency attack, the topology showed in Results of this experiment can be seen in Figure 4.2. As expected, the more aggressive the attacker, the higher the overall message overhead in the network. Node 2 experiences the largest increase in control messages since it is directly targeted. Nodes 4 and 5 also experience an increase due to being direct descendants of node 2. The most aggressive attacker tested can increase overhead at the targeted node by over 2000%. We can therefore conclude on the importance of mitigating DAG inconsistency attacks.

Packet Manipulation Scenario Evaluation

To evaluate the eect of the packet manipulation scenario, the topology showed in All other nodes, except the attacker, were congured to send messages to the sink at rates varying from 5 to 20 packets per minute. The packet sending rate is varied, because the attacker, i.e., node 3, silently modies the option headers of the packets it forwards, rather than originating a direct attack.

Chapter 4. Impact Assessment of RPL Attacks

The primary eect of packet manipulation attacks is not to increase overhead, but to cause the next-hop node to drop all packets of the attacker's descendants as explained earlier. The emergence of this black-hole can severely impact the overall delivery ratio of packets, since none of the packets from the attacker's descendants will ever reach the sink. Without a black-hole mitigation approach the overall delivery ratio is only about 33% in our results. This is because only packets from node 2 reach the sink, while the attacker forces node 2 to drop all packets sent by nodes 4 and 5.

The Version Number Attack

In this section we rst describe the version number attack. We then detail our simulation setup. Finally, we study the consequences of this attack in terms of control message overhead, delivery ratio, end-to-end delay, number of loops and inconsistencies.

Attack Description

The version number is used by the root to control the global repair process of RPL and to ensure that all nodes in the DODAG are up-to-date with the routing state.

Every DIO message carries the version number so that nodes which are part of an outdated DODAG version, can join the new DODAG by recalculating their rank and then updating their stored version number. Such a manipulation of the version number in the DIO packets does not only cause an unnecessary rebuild of the whole DODAG but it also generates loops in the topology. This can negatively impact energy reserves of the nodes, routing of data packets and channel availability.

Simulation Setup

We have used the same operating system (Contiki 2.6) and the same target platform (TelosB) to perform an evaluation of the version number attack as previoulsy described in Section 4.2.2. A grid topology of 20 nodes using the UDGM radio model [START_REF] Osterlind | Cross-Level Sensor Network Simulation with COOJA[END_REF], showed in Figure 4.4, was setup for all experiments in Cooja. Across all experiments, node 1 is the DODAG root and also the sink to which all other nodes send messages every twenty seconds to generate background trac. The attacker is designed to constantly send incorrect version numbers, which are greater than the root's. This scenario is adopted because it allows relocation of the attacker to multiple positions easily, making it possible to study the consequences of the attack from dierent locations and neighborhood scenarios within a network. A random back-o of up to six seconds is also added to this periodic transmission time on all nodes so that packet collisions are avoided when possible. The nodes are placed at a regular distance of 30 meters from their vertical and horizontal neighbors. The transmission strength is set such that packets are received successfully by nodes within a 30 meters radius and the signal causes interference with other nodes for a radius of 60 meters. This ensures that every node only has vertical and horizontal neighbors reachable during the simulation, thereby adding predictability and ease of analysis to the results.

Each simulation lasts for a lifetime of fty minutes. One simulation was executed without any attacker in the network to obtain a baseline for comparisons. Further that the network has enough time to settle and a stable RPL topology emerges.

Impact Quantication

The following metrics are used to perform this study: observe that the packet overhead is the highest for node 8 compared to nodes 5, 6 and 7. Since each of these nodes ends up towards the tail-end of their section of the DODAG, it also implies that the further away an attacker is from the root, the more damage it can spread. When the attacker is located at nodes 2 and 5, the produced topologies are analogous to each other, thereby leading to results that are similar in both cases. As such, not only the number of neighbors, but also the distance from the root impacts the level of overhead increase.

Since the position of the attacker can impact the overhead, it is interesting to also investigate which nodes are particularly aected. Only the per node outgoing packet overhead is plotted in Figure 4 on delivery ratio, with it being reduced by up to about 30%. More interestingly, we can see that the path length of the location of the attacker has an eect on the delivery ratio as we have seen on the overhead. However, instead of local maximums for their column, we observe local minimums. There is a strong correlation between the distance of the attacker from the root and the impact of the version number attack on delivery ratio. So, when the attacker is located on nodes 2 and 5, the delivery ratio is exactly the same, and they both also have a path length of 1 to the root. In fact, the correlation between the delivery ratio and path length can be seen across all positions of the attacker, with the attacker located at the bottom of the topology in Figure 4.4, i.e. farthest from the root, leading to worst impact on delivery ratio.

End-to-end delay. The end-to-end delay is also a good measure of a network's performance. The average end-to-end delay for dierent attacker locations can also be seen in Figure 4.7. Any lost packet did not contribute towards calculation of the end-to-end delay. As with other metrics, it is obvious that an attack signicantly impacts end-to-end delay, by almost doubling it as against no attack within the network. Unlike overhead and delivery ratio, there is no strong correlation between location of the attacker and the delay. This is because the delay is aected by a number of elements, such as the channel availability, number of loops, possible alternate routes, neighborhood density, etc. which also cause the high variations observed in Figure 4.7.

Chapter 4. Impact Assessment of RPL Attacks On the other hand, attacker locations closest to the root, but with most amount of neighbors lead to the highest number of inconsistencies and loops. For example, nodes 3 and 6 create more inconsistencies than nodes 2 and 5, which are closer to the root node. This is because both nodes 2 and 5 have fewer neighbors than nodes 3 and 6. As such, the number of loops are closely related to the number of neighbors an attacker has and increases with proximity to the root. Closer proximity to the root likely has this behavior because it forces a rebuild from the root faster as well, causing this to cascade into the rest of the DODAG before a new attack cycle can begin. This interesting relationship of inconsistencies and loops with the location of the attacker means that it would be useful to understand where in the network most of this eect is centered. As such, the number of loops and inconsistencies per node are plotted in Figures 4.9 and 4.10 respectively. It is immediately apparent from these plots that as the location of the attacker changes, the loops and inconsistencies location changes accordingly. Closer analysis reveals that while there might be some loops created in nodes that are farther away from the attacker, the majority of them are located within the direct neighborhood of the attacker. In fact, the bulk of these 4.4. Conclusions loops and inconsistencies are detected by the parent, and alternate parents, of the attackers. This is because most of the packets will be routed towards the preferred parent, or the alternate parent in case of the preferred parent being unavailable. The next highest quantity of loops and inconsistencies is detected at the children of the attackers. For example, when the attacker is located at node 11, the highest number of loops and inconsistencies are detected by parent nodes 7 and 10. The children, nodes 12 and 15, account for the majority of the rest of these anomalous situations.

Conclusions

In this chapter, we have presented two attacks targeting the node resources: the DAG inconsistency and the version number attacks. We have also analyzed their impact.

The DAG inconsistency attack exploits the data path validation to forge fake loops in the network forcing nodes to reset their trickle timer. We have showed two ways of performing this attack: a direct attack scenario where a malicious node directly sends attack messages to a targeted node and a packet manipulation scenario where the malicious node illegitimately modies data packets from other nodes creating a black-hole in the network. Through experiments, we have observed that this attack can increase signicantly the control message overhead of the targeted node and its descendants, reducing their lifetime. In the packet manipulation scenario we have also seen that this attack may have a signicant impact on the delivery ratio.

The version number attack misuses the global repair mechanism provided by the 56 Chapter 4. Impact Assessment of RPL Attacks repair protocol to propagate within the network malicious version number forcing a global rebuild of the DODAG to occur. We have quantied its eects in RPL networks. Through simulations we have discovered that this type of attacks that control message overhead can increase by up to 18 times, thereby impacting energy consumption and channel availability. This in turn can reduce the delivery ratio of packets by up to 30% and nearly double the end-to-end delay in a network. A strong correlation between the position of the attacker and the eect on the network has been also observed. An attacker located as far away from the root as possible causes the highest increase in overhead, and similarly a higher path length between the attacker to the root also causes the higher packet loss. It has been also discovered that loops and rank inconsistencies created by the attack are generally located around the neighborhood of the attacker, with parents or alternate parents experiencing the maximum loops, followed by the descendants.

Through these analyses, we can conclude on the importance of addressing these attacks whose impact may considerably shorten network lifetime. The designed security strategy should be as lightweight as possible to preserve the scarce resources of nodes while being ecient to tackle these threats.

Introduction

We have previously demonstrated the importance of addressing DAG inconsistency and version number attacks because they damage the network by increasing the overhead and reducing the delivery ratio. By analyzing properties of these attacks we have observed that the rst one targets a particular node and impacts mostly the target's descendants while the second one is propagated through the entire DODAG graph. In that context, we can assume that it is possible to locally deploy defense mechanisms to counteract the DAG inconsistency attack, but it is not feasible for the version number attack due to its propagation properties. In this chapter, we propose to investigate local detection and mitigation approaches to limit DAG inconsistency attack impact. 58 Chapter

Local Strategy for Addressing DAG Inconsistency Attack

A sided RFC of RPL [START_REF] Hui | The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams[END_REF] proposes to counteract this attack by using a xed threshold, beyond which all subsequent packets with erroneous header options are ignored. However, the xed threshold is arbitrarily set and does not resolve the black-hole issue either. In this chapter, we present a new solution called adaptive threshold (AT) to mitigate eects of such an attack. This initial AT approach is further improved to dynamically take into account network characteristics while deriving an appropriate threshold for counteracting the DAG inconsistency attack. Our experimental results show that both our proposed approaches can lead to improvements over the xed threshold. Furthermore, our approaches are able to counteract the black-hole scenario while still outperforming the default RPL mitigation strategy. This chapter is organized as follows. Section 5.2 presents the dierent mitigation approaches for the DAG inconsistency attack which are the xed threshold, the adaptive threshold and nally the dynamic threshold. Section 5.3 details our experimental evaluation by comparing the dierent mitigation strategies, discussing the values of the parameters and analyzing the energy consumption of the proposed approaches.

DAG Inconsistency Attack Mitigation

We introduce three detection and mitigation approaches to counter the DAG inconsistency attack. The rst one is proposed by a sided RFC [START_REF] Hui | The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams[END_REF] of the RPL protocol.

It is based on a xed threshold. Since no justication is provided on the threshold value in the RFC, we have proposed an adaptive threshold relying on set parameters which mimics the xed approach under normal conditions. We then improve this solution to be fully dynamic with auto-congured parameters.

Default Mitigation

The default DAG inconsistency attack mitigation strategy of RPL [START_REF] Hui | The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams[END_REF] can be seen in Algorithm 1, where i is a node within the graph with a rank of r i . M represents a packet received by node i from a neighbor j with rank r j . O and R indicate the `O' and `R' ags present in M . The variable count R is the number of received data packets with the `R' ag set and is initialized to 0. λ is a constant set to 20.

Algorithm 1 Default DAG inconsistency mitigation strategy of a node.

if

(O = 1 and r i < r j ) or (O = 0 and r i > r j ) then if R = 1 then count R + + drop(M ) if count R < λ then reset(trickle_timer) end if end if end if

DAG Inconsistency Attack Mitigation 59

Upon receiving a packet with an inconsistency, the node drops it and resets its own trickle timer. To limit the eects of an attack, the number of trickle timer resets is limited to the recommended constant λ = 20 [START_REF] Hui | The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams[END_REF]. Upon reaching this threshold, malformed packets are dropped but the trickle timer is not reset. The variable count R is reset every hour, allowing attackers to once again have a higher impact.

This approach limits the impact of a DAG inconsistency attacks, but the value of the threshold λ = 20 is arbitrarily set. No reasoning is provided to justify this choice or how performance could be improved in case of varying attack scenarios.

Adaptive Mitigation

In order to take into account the current network state and react to varying attack patterns we have developed an adaptive threshold (AT), which determines when to stop resetting the trickle timer. Instead of a constant λ, a function λ(r) is used, which takes the following form:

λ(r) = α + β • e -γ•r (5.1)
where,

r = count R D pkt , α = 5, β = 15
The variable count R stands for the number of received data packets with the `R' ag set and D pkt represents the number of normal forwarded data packets. To allow comparison with the default strategy, the value of β was chosen such that the default λ(r) = 20. The value of α is an asymptote to ensure that threshold never reaches 0. This guarantees that data packet validation is not disabled upon encountering the rst packet with an `R' ag, but only when the situation is deemed an attack.

Since γ impacts the threshold rate of change, a value is not chosen here. In general, a larger value for γ leads to a smaller threshold being reached quicker. The eect of choosing dierent values for γ is discussed in Section 5.3.3.1.

The adaptive threshold causes λ(r) to change based on network conditions. If an attacker is aggressive, the threshold drops quickly and increases slowly once the attacks stop. Unlike with the xed threshold, count R is not reset every hour, but rather allowed to increase in the absence of attacks. As such, not only is this approach likely to be better than a xed threshold within the rst hour of an attack, but it should perform signicantly better against long running attacks. This also ensures that greater trust is placed in networks where problems have not been encountered for a long time. Of course, a natural limit upon the value of the counter is the bitlength of the variable imposed by the platform. In this case, the counter will reset when the value overows. If any of the counters overows, we recommend resetting all counters (count R and D pkt ) so that the algorithm functions as though it was started in a new network.

As before, count R is the number of received data packets with the `R' ag set. D pkt represents normal data packets forwarded by the node.

Normally, packets with the `R' ag set do not arrive at any nodes, because the network is stable and functions as intended. It has been observed, via experiments carried out during this study, that packets with the `R' ag set arrive only when an attack is performed on the network, or loops form due to serious malfunction of nodes, which is unlikely, unless a software bug exists. Even when the root node initiates a rebuild of the entire network, i.e., a global repair, a maximum of one or two packets containing `R' ags are received from each child. Any given local neighborhood in an RPL network always returns to stability within two packets containing an `R' ag, if the problem is a genuine topological inconsistency.

As such, setting δ to twice the number of neighbors (parents and children represented by Card(neighbors) or in Equation 5.2) permits for each link to send up to two packets with an `R' ag set in case of legitimate loops. λ(r) corresponds to the value of δ in a steady state, i.e., when no packets with `R' ags are received.

Even though not observed during our experiments, it is possible for multiple packets with an `R' ag to arrive as a result of the same inconsistency. This can be especially true in case a node malfunctions, leading to a loop being formed.

Resetting the trickle timer each time a malfunctioning node sends packets with `R' ags leads to unnecessary overhead, especially since a single trickle timer causes aggressive transmissions of DIO messages in any case. To avoid this situation, a convergence timer is introduced in this algorithm. This timer is used to ensure that no further trickle timer resets take place within the amount of time it takes for an RPL neighborhood to typically converge. Previous experiments have showed that time for convergence of a DODAG neighborhood increases by about 2 seconds for every additional 10 neighbors [START_REF] Clausen | A Comparative Performance Study of the Routing Protocols LOAD and RPL with Bi-Directional Trac in Low-power and Lossy Networks (LLN)[END_REF]. The convergence_timer is, as such, set to 2 seconds by default but grows based on neighborhood size of a node.

Since the purpose of introducing a convergence_timer is to block trickle timer resets caused by `R' ag packets arriving within the time it takes for the neighborhood to converge, it no longer makes sense to compare count R with λ(r) to determine whether a trickle reset must occur. Rather, a new counter that keeps track of the number of trickle timer resets, count T , is introduced. The value of count T is reset one hour after the rst `R' ag packet is encountered to allow the repair of genuine loops and because λ(r) does not depend on it. Instead of λ representing the number of `R' ag packets allowed before a trickle timer reset occurs, as with the default mitigation approach, it is now the number of trickle timer resets allowed to be caused by `R' ag packets that arrive while the neighborhood is already considered to be converged.

The overall dynamic threshold approach can be seen in Algorithm 3.

The dynamic threshold allows λ(r) to change based on network conditions. Like the adaptive threshold approach, this mitigation strategy should perform better against long running attacks. This dynamic threshold approach not only does away with arbitrary constant thresholds, as in the case of the default strategy, but by being based purely upon network characteristics it does away with the need for constant parameters to be chosen before deployment [START_REF] Sehgal | Addressing DODAG Inconsistency Attacks in RPL Networks[END_REF] and thereby is more useful in case if (O = 1 and r i < r j ) or (O = 0 and r

i > r j ) then if R = 1 then count R + + if count T < λ(r) then if timer_expired(convergence_timer) then drop(M ) start(convergence_timer) reset(trickle_timer) count T + + end if else if r >= 1 then O ← 0 R ← 0 f orward(M ) else drop(M ) end if end if end if
of unforeseen network conditions as well.

In order to counter the packet manipulation scenario using the dynamic threshold approach, Algorithm 3 allows a node to forward packets with the inappropriate ags in some situations. First, as long as count T is lesser than λ(r), i.e. as long as a direct DAG inconsistency attack or genuine topological error is being corrected, all packets containing the incorrect ags are dropped. However, once this mitigation is over, it is deemed that the network should have returned to normal and any further inconsistency could be a packet manipulation DAG inconsistency attack. As such, if more than 1/ trac received by the node contains the `R' ag, then this is considered a packet manipulation attack. It means that one neighbor only sends messages containing `R' ags. In this case, having given enough chances for the network to x itself, the node clears the ags and forwards the message normally.

The complexity of this algorithm also relies on exponential function such as for the adaptive threshold. The cost of the dynamic threshold computation will be discussed in Section 5.3.4.1.

Mitigation Evaluation

In this section, we rst present our simulation setup along with a validation of our simulation tool. We then detail performance results of the dierent mitigation approaches. After this, we discuss the eect of the introduced parameters before analyzing resource consumption of our local strategy.

Mitigation Evaluation

Simulation Setup

Such as in the previous chapter, the Contiki 2.6 [START_REF] Dunkels | Contiki -a Lightweight and Flexible Operating System for Tiny Networked Sensors[END_REF] operating system and the TelosB platform have been chosen. To allow evaluation under multiple scenarios, instead of building a topology of actual nodes, the compiled binary for a TelosB was used in the Cooja [START_REF] Osterlind | Cross-Level Sensor Network Simulation with COOJA[END_REF] simulator provided by Contiki with Unit Disk Graph radio attenuation and scattering model (UDGM). This approach provides a method of testing the dierent thresholds under conditions where the lossy IEEE 802.15.4 channel does not cause packet loss. This allows evaluation of our approach under ideal conditions, with no external characteristics causing bias in the results.

Simulation Validation. Even though the Cooja approach is expected to be close to real performance, we need to conrm this assumption and validate our simulation approach. As such, the topology showed in Figure 5.1(a), which is the same used for attack analysis in Chapter 4, was setup using real TelosB motes, with node 1, the DODAG root, acting as the sink. All other nodes were congured to send messages to the sink every six seconds. An additional per transmission random back-o period of up to six seconds was utilized to avoid packet collisions and add a degree of irregularity to the transmission scenario. The dynamic threshold mitigation mechanism was deployed to all nodes.

The attacker node, i.e., node 10 in range of the overhead seen in a network of real motes. This indicates that the Cooja simulations provide results which closely mimics reality. Furthermore, the overhead reported by Cooja is on average higher than in reality because the IEEE 802.15.4 channel causes packets to be lost in a deployment of real motes, whereas this does not occur in Cooja.

A larger topology was not used since the eect of a DAG inconsistency attack is limited mostly to the targeted node. Its children and further descendants are aected only to a small degree. A larger topology would only make the overhead greater, but not change the patterns observed with this topology.

Mitigation Performance

We rst evaluate our mitigation algorithms in the direct attack scenario with control message overhead metric. We then analyze the packet manipulation mitigation with the control message overhead and the delivery ratio metrics.

Direct Attack Mitigation

Using the same experimental setup as in Section 5. give the attacker another window of opportunity. The adaptive threshold approach provides such a solution.

Attacks per hour

From Figure 5.4, we can observe that the adaptive threshold is more successful in reducing control message overhead than a xed threshold. An aggressive attack causes the adaptive threshold to reduce rapidly, thereby limiting the impact of the attack. This results in slower attacks being the best strategy. We can also see that 20 attacks/hr is the best strategy for an attacker because the values of α and β were chosen to model the default value of 20 in a steady state. However, if the values of these coecients are changed, so will the periodicity of the optimal attack pattern.

For the most aggressive attacks the dierences are not so signicant since the xed threshold is quickly reached. The adaptive threshold is between 8% (γ = 20) to 13% (γ = 25) better, even in the worst case scenarios. of both approaches is almost the same for aggressive attacks (above 90 attacks per hour). However, the dynamic threshold has better results for slower attacks making a strategy to overcome the mitigation mode dicult.

Time-lines of packet overhead. Since the value of count R is not reset every hour for the adaptive and dynamic thresholds, the attacker does not have a future window of opportunity for causing increased damage. Both these thresholds increase in the absence of an attack, and as such the adaptive and dynamic approaches mitigate long running attacks even better. Results from a two hour long experiment can be seen in Figure 5.6. Only results from the directly attacked node 2 are depicted.

In Figure 5.6, we compare the xed threshold to adaptive and dynamic thresholds.

When using a xed threshold the control messages increase quickly till the threshold is encountered. They then grow at a slow rate, following the trickle timer pattern until the 1 hour mark, when the counter is reset. Once again, the control messages increase quickly until the threshold is encountered. This behavior causes a high control message overhead. The only exception is the period of 20 attacks per hour, because at this rate the threshold is never encountered, thereby causing the largest overhead growth.

On the other hand in Figure 5.6(a), the limit is reached much faster with the adaptive threshold, due to the exponential growth of the function. Coupled with a nonreseting counter, this leads to between 45%-55% savings in the control message overhead. Those results depend on the value chosen for γ (discussed in Section 5.3.3.1).

We notice a similar phenomenon in from Equation 5.2 increases slowly. The saving for the dierent attack patterns is around 45%. In comparison with Figure 5.6(a), we can see that the adaptive threshold has slightly better results. This is due to the γ chosen here and also because count T in Algorithm 3 is reset every hour to allow legitimate `R' ag packets from neighbors to be correctly handled. While using the dynamic threshold, the increase in overhead will continue after the second hour. This should argue in favor of using the adaptive threshold. However, the adaptive threshold requires setting the γ value, which needs to be learned empirically for every node in the network if optimal performance is desired. The dynamic threshold does not require any such empirically learned values to be congured. As such, because we gain more exibility, the dynamic threshold algorithm is recommended over the adaptive threshold.

Packet Manipulation Mitigation

To evaluate the eect of our mitigation approaches on packet manipulation attacks (Algorithms 2 and 3), the topology showed in Figure 5.1(b) was setup in Cooja, with node 1, the DODAG root, acting as the sink. All other nodes, except the attacker have been congured to send messages to the sink at rates varying from 5 to 20 packets per minute. The packet sending rate is varied, because the attacker, i.e., node 3, silently modies the option headers of the packets it forwards, rather than originating a direct attack.

Packet overhead. The nodes have been congured to use the adaptive threshold, then the dynamic threshold for mitigating packet manipulation. Results in Figure 5.7 show that the adaptive and dynamic thresholds reduce overhead in the network as demonstrated in Section 5.3.2.1. We can also note that the dynamic threshold performs slightly better than the adaptive threshold because, in this conguration, the dynamic threshold is reached faster than the adaptive one due to the number of neighbors of node 2. Compared to the default xed threshold approach a reduction up to 30% can be achieved.

Delivery ratio. The black-hole created at the next-hop node in this scenario can severely impact the overall delivery ratio of packets, since none of the packets from the attacker's descendants will reach the sink. Without a black-hole mitigation approach such as the xed threshold which does not counter this scenario, the overall delivery ratio is only about 33% as showed in Section 4.2.3. This is because only packets from node 2 reach the sink, while the attacker forces node 2 to drop all packets sent by nodes 4 and 5.

On the other hand with the adaptive threshold strategy the overall delivery ratio increases to just above 99%, because node 2 no longer drops packets from nodes 4 and 5 once the threshold is reached. The dynamic threshold approach also has a similar performance, with the delivery ratio being above 99%. These results speak strongly in favor of mitigating packet manipulation based DAG inconsistency attacks via an adaptive or dynamic threshold approach.

However, since the adaptive and dynamic thresholds depend upon dierent parameters, it is also important to check the eect they can have upon the performance of these approaches.

Conguration Parameters Impact

In the adaptive and dynamic threshold, the computation of the threshold λ(r) are based on several parameters. In this section we discuss the eects of γ for the adaptive threshold and and δ for the dynamic threshold on the mitigation eciency.

Adaptive Threshold

Given the same attack periodicity, the value of γ in Equation 5.1 determines the rate at which the threshold changes. Experiments were run with 20 ≤ γ ≤ 35 to gain insights into its impact. Values larger than 35 have not been used because larger values of γ result in the threshold dropping too quickly. This leads to situations where even a single packet with the 'R' ag causes the trickle timer resets to stop.

This means that genuine malfunctions will no longer be repaired either. In our tests we observed that for values over 35, this situation was encountered frequently.

Below 20, the threshold reduces too slowly, thereby making it too permissive and increasing the likelihood of a successful attack.

As can be seen in Figure 5.8, by increasing the value of γ, even in the case of the most ecient attacker, the overhead can be further reduced by around 10%.

Number of Control Packets

Value of Adaptive Threshold Constant ( ) This means that higher values of γ are able to oer more signicant savings in the overhead. However, a rapidly reducing threshold might also impact the repair of genuine loop conditions. Our recommendation is to keep the value of γ between 20 and 35 so that the algorithm is neither too permissive nor too aggressive. The exact value has to be chosen according to the topology conguration by running tests.

20

Dynamic Threshold

The performance of the dynamic threshold approach is closely tied to the size of an attacked node's neighborhood since two parameters and δ depend on it. We have therefore to study the eect of varying neighborhood sizes on the dynamic threshold.

Packet Overhead. The same attack and data packet transmission scenarios from Section 5.3.1 have been used with the topology from Figure 5.9 to evaluate the impact of changing neighborhood sizes. The number of neighbors for node 2, targeted by attacker node 3, was set to 4, 8, 16 and 32 neighbors. A larger neighborhood size was not evaluated since Contiki can only track about 30 neighbors [START_REF] Dawans | On Link Estimation in Dense RPL Deployments[END_REF]; furthermore, due to the limited resources on the TelosB mote, maintaining a list of large number of neighbors can lead to a node being out of resources.

The overhead experienced by node 2 under dierent neighborhood sizes and attack patterns can be seen in Figure 5.10. The dynamic threshold outperforms the default xed threshold approach, in all neighborhood sizes. In fact, the savings are between 20-50% and are mostly impacted by the variation of r because r depends on the number of genuine data packets (cf. Equation 5.2) which increases with the number of neighbors. The major advantage of the dynamic threshold is that after reaching a neighborhood size of at least 16 nodes, the control overhead does not

Mitigation Evaluation

Mitigation Evaluation 73

Delivery Ratio. Figure 5.12 shows the delivery ratio for dierent neighborhood sizes of node 2 from the packet manipulation scenario described in Figure 5.3.2.2.

The experiment has been repeated ve times in order to obtain a standard deviation. In case of two neighbors, which corresponds to the simple scenario used in Section 5.3.2.2, we can see that the delivery ratio is above 99%. The delivery ratio decreases when the number of neighbors is increasing in accordance with the Algorithm 3. However even if the size of the neighborhood is 16 the delivery ratio stay above 99%.

Resource Consumption

To evaluate the eciency of a countermeasure designed for constrained environments it is necessary to assess the cost of our solution.

Memory and Computational Costs

Since Equations 5.1 and 5.2 replace a constant threshold whose complexity is O(1),

we have to also quantify the impact using an exponential function has upon the overall computation costs. The implemented function relies on an approximation of the actual exponential function using a simple loop making the complexity in O(n).

Measuring this impact is even more important since these approaches are expected to be used on resource constrained devices with limited computing abilities. While running the aforementioned experiments, the time taken to calculate the threshold has been also obtained. Table 5.1 shows the average computation time required to obtain the thresholds for multiple attack patterns (20, 45 and 90 attacks/hour) while using a MSP430F1611 microcontroller operating at 1 MHz on the TelosB platform.

Calculation of the dynamic threshold appears to add about 25 ms of computational overhead, and 30 ms for the adaptive threshold. This is because the value of the exponential part of the equation in the dynamic approach is lower than in the adaptive approach.

Using the msp430-size tool, we have determined the memory occupancy of nodes implementing the dierent thresholds. The almost 4 kB increase in ash memory occupancy is due to the usage of a oating point library for calculation of the thresholds. This negative impact can be reduced greatly by using certain optimization, for example, a lookup table with linear interpolation will save not only ash space but also CPU execution time.

Results using such optimizations have not been presented here so that the worst case performance of the algorithms can be quantied.

From the measured worst case values, we observe that the overall impact of both adaptive and dynamic threshold approaches on computational overhead is quite minimal, especially when taking the gains into consideration. Even though the dynamic threshold approach uses a little extra memory, the gains in having auto-congured parameters and providing good performance make it a good choice.

Energy Costs

From the energy model showed in Table 5. computation for all the nodes in the network, while the adaptive (γ=25) and dynamic thresholds approaches are used in comparison to the xed approach. We see that in case of our adaptive and dynamic thresholds the energy spent by the network to process the control message overhead and the computation of thresholds is less than the energy used for the xed threshold strategy. However, when the attacker is the In order to preserve node resources, we exploit typical deployments of IoT infrastructures relying on higher-order devices. This is the case for advanced measurement infrastructures (AMI) which is expected to be organized as showed in Figure 6.1 [19].

This network can be divided into two tiers, i.e., the Neighborhood Area Network We therefore want to outsource monitoring and anomaly detection activities on these higher-order devices that are eld routers. These ones can be interconnected to form an independent network from the LLN network in order to share their information which constitute our monitoring architecture.

This chapter presents our monitoring architecture concepts and details detection algorithms which can be integrated in our solution to address attacks. Section 6.2 introduces our solution, describes its main components and mechanisms based on the RPL protocol. We then propose in Section 6.3 to formalize the placement of 6.2. Proposed Architecture 81 monitoring nodes through an optimization problem. Finally, Section 6.4 presents algorithms deployed on monitoring nodes in order to detect DAG inconsistency and version number attacks.

Proposed Architecture

We propose a security-oriented distributed monitoring architecture for the Internet of Things that passively observes the network. This one allows us to detect threats complementary to the local-node approach, for specic complex attacks which cannot be detected locally or even when dedicated code cannot be implemented on nodes. It is based on dedicated nodes and relies on the RPL protocol mechanisms to perform monitoring operations, so the target nodes do not have the charge of this activity.

We describe both the main components of this architecture and the RPL-oriented features that are exploited to support it on an IoT network.

Overview and Components

Our monitoring architecture described in Figure 6.2 is composed of two types of nodes participating in the network, regular nodes also called target nodes which are monitored, plotted in white, and monitoring nodes plotted in blue. The sink plotted in green is also a monitoring node.

The regular nodes are typically lower order devices that t into the C0 or C1 class of constrained devices. Their primary function is to carry out their assigned sensing Chapter 6. Security-oriented Distributed Monitoring Architecture or actuation task. They form the so called regular network. They communicate with a sink/controller, where all collected sensing data is forwarded or from where actuation commands might be periodically received. This communication occurs over low-power lossy channels and a multi-hop mesh network might be formed in order to enable interconnection between all nodes.

The monitoring nodes are higher-order devices that should be at least C2 or better. As such, their monitoring activities might not have an eect upon their ability to serve their primary purpose of routing information in the regular network.

These monitoring nodes are capable of passively listening to the regular nodes in their radio communication range, while also recording required information.

Since the higher-order devices, instrumented as monitoring nodes, are expected to be deployed in many IoT applications, those nodes participate in the regular network. As such, they are able to intercept and analyze packets sent by regular nodes.

A monitoring node can only monitor its own low-power lossy network neighborhood as represented by circled areas in Figure 6.2(a). However, network-level monitoring information is useful to track the topology and inconsistencies in the network, e.g. topological, security, etc. As such, these monitoring nodes must periodically forward the collected monitoring data towards a sink. To avoid using the resource of constrained nodes, the monitoring nodes form a second routing topology as illustrated by the upper part of Figure 6.2(b). This second network, known as the monitoring network, has access strictly limited to monitoring nodes. Two possibilities can be considered to build the monitoring network depending on the use case.

If the monitoring nodes have an high-speed high-bandwidth access network they can interlink with each other and with the sink, this can be the case in AMI (Advanced Measurement Infrastructure) deployments [19]. The second possibility is to share the same medium as the regular network, the interconnection is feasible using dierent radio ranges for monitoring nodes which is possible considering higher-order devices.

The monitoring network will form an overlay network.

A monitoring node has two possibilities to collect monitoring data:

• the processing of trac (data and control messages) legitimately sent to it by other nodes;

• the overhearing of packets exchanged between other nodes.

Indeed, complementary to the data collected by a monitoring node based on packets it has to process, i.e. data and control messages that are legitimately sent to it, it may enable the promiscuous mode in order to cover a larger amount of packets.

The promiscuous mode allows a node to overhear packets, it is particularly useful for detecting anomalies and potential attacks by snooping data trac not transmitted to it.

RPL-based Mechanisms

This passive monitoring solution is instantiated using the RPL protocol mechanisms. The following introduced notations are gathered in Table 6.1. Applying the RPL protocol to a network leads to the building of a DODAG in a instance I noted D I . We note as D I (V, E) the DODAG graph composed of V nodes linked using E edges. Every node participating in the DODAG has an access to the root or sink S using the E edges which are chosen among all the links available to cope with the objective function. We note N v i the neighborhood of a node v i which is the set of nodes {v k } in the communication range of v i . The neighboring nodes of v i can be parents whose rank is lesser than the rank value of v i , children whose rank is greater or siblings with the same rank value. The rank value of a node v i is noted r i . We exploit the multiinstance feature of RPL to build two networks: a regular network and a monitoring network. An instance in RPL can be seen as a network optimized for specic metrics or constraints given by an objective function. The RPL multi-instance principle is an example of VRF (Virtual Routing and Forwarding): multiple instances of a routing table coexist on the same router at the same time. Those instances are completely independent which means if one network breaks down at some point because of regular node failure or attacks, the second network can operate normally.

Therefore, two instances are running at the same time in our solution. One instance is used for the regular service noted I R wherein the DODAG built is noted D I R composed of V ∪ V nodes i.e. with both regular and monitoring nodes. The second instance called the monitoring instance, I M where the DODAG is noted as D I M also is composed of V nodes as showed in Figure 6.2(b). Using the RPL multiinstance feature presents two main advantages. First, it allows us to preserve regular nodes' resources because monitoring nodes forward their data on their monitoring instance/network. Second, if the regular network malfunctions, the monitoring data will still be forwarded thanks to the monitoring network, which is independent of the regular one.

The sink S is also a monitoring node. A monitoring node, v k is able to collect information regarding its neighborhood N v k as illustrated in Figure 6.2(a), the zone Chapter 6. Security-oriented Distributed Monitoring Architecture covered by a monitoring node is its neighborhood. The collected information allows it to monitor the network and also detect possible anomalies by implementing locally detection algorithms. In Figure 6.2(a), monitoring node v 10 is able to monitor N v 10 = {v 5 , v 9 , v 11 } using passive listening and overhearing. The monitoring node supports the detection of local anomalies based on dedicated detection modules. Collected information as well as detection results can then be aggregated and forwarded to its monitoring neighbor v 4 . Since neighborhoods of nodes v 10 and v 4 overlap, node v 4 checks if information gathered by node v 10 matches its own information in order to rene the detection in a collaborative manner. Node v 4 performs the same process as its predecessor: collects information, runs detection algorithms, aggregates the dierent sources of data and reports it to the next monitoring node which is here the sink. Since the sink collects data from the dierent monitoring nodes, it may detect inconsistencies only observable at a global level.

A monitoring node is able to record the following RPL statistics from intercepted messages:

• Information about the DODAG:

Instance ID observed in messages originating from regular nodes. DODAG ID observed in messages originating from regular nodes. DODAG Root: destination address observed in all data packets from regular nodes. These statistics allow detecting potential miscongurations as well as misbehaviors in the RPL functioning.

DODAG Version

Monitoring Node Placement Formalization

We assume that all regular nodes are covered by at least one monitoring node because information about each node needs to be collected to monitor correctly the network.

A conguration under this constraint can be calculated with the resolution of an optimization problem thanks to integer linear programming. The problem can be formulated as follows: for a given topology and a given connectivity matrix for all possible monitoring nodes placement in this topology, nd a conguration of monitoring nodes placement that minimizes the number of monitoring nodes needed to cover all regular nodes. Table 6.2: Required inputs for monitoring node placement.

Domain

Parameter Description

1, N N

Number of nodes in the topology

1, N × 1, N A
Connectivity matrix for monitoring nodes, A i,j = 1 if node i covers node j

As input to solve this problem we need two parameters detailed in Table 6.2. The rst parameter is the number of nodes (size of the topology) and the second one is the connectivity matrix detailing the links of possible monitoring nodes with other nodes, A i,j = 1 if node v i can listen to node v j . We set the diagonal of this matrix to 0, i.e. ∀i, A i,i = 0 which means that we consider that a possible monitoring node Y , which represents whether node v i is a monitoring node (Y i = 1) or not (Y i = 0).

The constraints are detailed in Equations 6.1 and 6.2:

Y 1 = 1 (6.1) ∀i ∈ 1, N : N j=1 (A i,j .Y j ) + Y i ≥ 1 (6.2)
The objective function f obj is given by Equation 6.3:

f obj = min N j=1 Y j (6.
3) Equation 6.1 indicates that node v 1 is a monitoring node, because in our case node v 1 is the sink and the sink is always a monitoring node in our architecture. It is possible, depending on the topology, to force particular nodes to be monitoring nodes for the conguration calculation. Equation 6.2 species that each regular node is covered by at least one monitoring node. Since the diagonal of the connectivity matrix is 0, we need to add +Y i in the equation so that the model is correct. The objective represented by Equation 6.3 is to minimize the number of monitoring nodes under these dierent constraints. Minimizing the number of monitoring nodes allows us to reduce the cost for their deployment. This solution permits to guarantee that each regular node is covered by at least one monitoring node, however it is also possible to extend the model with new constraints to meet other requirements.

Our architecture is able to monitor network trac but it has been designed having in mind anomaly detection. We therefore propose detection modules deployed on monitoring nodes to identify threats targeting RPL networks.

Detection Modules

We have considered an IoT infrastructure where monitoring nodes can enable the promiscuous mode and implement detection modules to identify unusual behaviors and potential attacks. In this section, we present two algorithms: the rst one allows monitoring nodes to detect the DAG inconsistency attack by overhearing data trac, and the second one to detect and localize the launcher of a version number attack. Chapter 6. Security-oriented Distributed Monitoring Architecture inappropriate in a distributed detection strategy. Finally, the idea of this algorithm is to detect the DAG inconsistency attack in a global view and not to mitigate it.

The main point of the varying thresholds (AT and DT) is to limit the consequences of such an attack. The value of the threshold used in this algorithm is discussed in Section 7.3.1. In our architecture when an attack is identied, the malicious node is reported to an operator who can isolate it.

In order to determine whether the attack is a direct scenario or not, the monitoring node has just to compare the IP address of the direct sender of 'R' ag messages and the IP address of the source. In this scenario, the node v 6 is the attacker and sends attack messages with the 'R' ag enabled to its preferred parent v 2 . The monitoring node v 7 is able to overhear these messages since the attacker is in its neighborhood. As soon as the number of 'R' ag messages reaches the threshold value and if the attacker is the only node to have sent such messages, then it is considered as anomalous.

This algorithm has been designed in case only one malicious node performs the attack. However, if multiple attackers are present at the same time, our algorithm is still able to detect them as long as they are in dierent monitoring node neighborhoods. If several attackers are in the same neighborhood of a monitoring node v k and launch their attacks simultaneously, node v k cannot determine there is an attack because there are several senders of 'R' packets, which is considered as legitimate loops. New conditions should be introduced to manage attackers coalition.

We can observe in this algorithm that monitoring nodes do not have to exchange data in order to identify the attack. However, when the attack is spread all across the network such as in the version number attack, monitoring nodes have to collaborate in order to detect the malicious node.

v i ∈ N v k do if (VN v i > VN v k ) and (potential_att == NULL) then potential_att = v i send_root(M k = (VN v i ,v i ,N v k ))
end if end for

In Algorithm 5, a monitoring node v k , upon receiving a greater version number VN v i from v i than its own version number VN v k , sends to the root a message containing the address of the sender v i and the list of its neighbors N v k obtained from the dierent received DIO messages. The monitoring node only sends a message the rst time it receives an incremented version number. Indeed, since the attacker is in the direct neighborhood of at least one monitoring node there is no need in sending further messages because senders of other incremented version number messages are relays.

We also consider the other neighbors of the monitoring node as safe. Complementary to the algorithms, the root could have the possibility to send a signal message indicating that the monitoring nodes reset the potential_att value, in order to restart the detection process, in case another attacker appears in the network. Algorithm 6 is supported by the root and is used to detect the attack and gather all related monitoring data. Upon receiving either a monitoring message or an incremented version number, the root starts a detection timer to allow all monitoring nodes to send their messages. Two lists are managed by the root node: the potential_att_list list which is composed of all v i nodes reported by the dierent monitoring nodes and the neigh_list list which is composed of each monitoring node neighbors N v k . Once the lists are completed, the root starts the localization procedure described in Algorithm 7.

Algorithm 6 Distributed detection algorithm.

anomaly_detected = 0 if (VN v j > VN v 1 in DIO received from v j ∈ N v 1 ) then anomaly_detected = 1 add(potential_att_list, v j ) add(neigh_list, {N v 1 }) start(detection_timer) end if if (VN v i > VN v 1 in M k received) and (anomaly_detected == 0) then anomaly_detected = 1 start(detection_timer) end if while (potential_att_list.nb != Card(V )) or (!timer_expired(detection_timer)) do for each message M k received from v k ∈ V do add(potential_att_list, v i ) add(neigh_list, {N v k })
end for end while

Localization

This procedure exploits the two previous lists in order to produce two new lists: att_list list composed of nodes considered as malicious and the saf e_list list containing all nodes classied as safe. The objective of this procedure is to compare neighborhoods of monitoring nodes in order to eliminate potential attackers. At initialization, the rst element of the potential attacker list is added to the attacker list, and the other neighbors of the corresponding monitoring node are added to the safe list. While iterating, when the next potential attacker is already in the attacker list or in the safe list, it is ignored, and only the other neighbors are added to the safe list. This means that dierent monitoring nodes have detected the same node as a potential attacker, or that a monitoring node has detected a node as a potential attacker while being chosen as safe by another monitoring node. If the potential attacker is neither in att_list nor in safe_list, it is added to the attacker list. The nal test consists in verifying if some elements of the neighbor list are in the attacker list. This can happen when monitoring messages are received in a disordered manner. In this case, these elements v m have to be removed from the attacker list. We can notice that at the end of the algorithm it is possible to obtain several nodes considered as attackers, when senders of incremented version number are monitored by only one monitoring node.

add(safe_list,{neigh_list[i] \ potential_att_list[i]} else if (potential_att_list[i] ∈ att_list) then add(safe_list,{neigh_list[i]\potential_att_list[i]} else if (potential_att_list[i] ∈ safe_list) then add(safe_list,{neigh_list[i]\potential_att_list[i]} else add(att_list,potential_att_list[i]) add(safe_list,{neigh_list[i] \ potential_att_list[i]}) end if if (neigh_list[i] ∩ att_list = v m , v m = ∅) then remove(att_list,v m )
end if end if end for end procedure

In order to illustrate these algorithms, we provide two examples to describe the dierent possibilities using the topology presented in Figure 6.2(a). The rst scenario shows our detection strategy functioning under normal conditions. The second scenario is used to present a use case where the detection strategy produces false positive results (normal node considered as malicious). In Figure 6.4(a), the attacker is located at position 11, it sends DIO malicious messages to all its neighborhood (plain red arrows) which are relayed by other nodes (in purple dotted arrows). Monitoring nodes v 7 and v 10 receive attack messages from attacker v 11 and send to the sink a message containing the sender of the anomalous message and their neighbors as illustrated by Table 6.4(a). Nodes v 1 and v 4 do the same with relays v 3 and v 5 . Once all data are gathered, the sink can start the localization procedure to establish the list of attackers and the list of safe nodes. At initialization, the rst entry of potential attacker list, v 11 , is added to the attacker list and the corresponding neighbors without the potential attacker {v 3 , v 6 , v 12 } are added to the safe list as described by Table 6.5(a). Then, since the second entry of Table 6.4(a), v 11 , is already in the attacker list, only the safe list is updated with the neighbors of monitoring node v 10 , {v 5 , v 9 }. The third entry of Table 6.4(a) is v 3 which is already in the safe list, so only the safe list is updated with the corresponding neighbor {v 2 }. The same process is repeated for the last entry v 5 which is also already in the safe list. At the end of the algorithm, the only element of the attacker list is v 11 which is correct and all the Chapter 6. Security-oriented Distributed Monitoring Architecture

Monitoring

node Potential attacker Neighbors list

v 7 v 11 {v 3 v 6 v 11 v 12 } v 10 v 11 {v 5 v 9 v 11 } v 1 v 3 {v 2 v 3 } v 4 v 5 {v 2 v 5 v 8 v 9 } (b) Attacker located at position 2.
Monitoring node Potential attacker Neighbors list

v 1 v 2 {v 2 v 3 } v 4 v 2 {v 2 v 5 v 8 v 9 } v 7 v 6 {v 3 v 6 v 11 v 12 } v 10 v 5 {v 5 v 9 v 11 }
other regular nodes are considered as safe.

The second scenario, illustrated by Figure 6.4(b), where the attacker is located at position 2 shows the case where the localization procedure produces two attackers. Table 6.4(a) details how the monitoring data are aggregated by the root v 1 and Table 6.5(b) shows the localization process. Until step 1 we can see that only v 2 is considered as the attacker, however in step 2 node v 6 is also added. The latter is not in the safe list meaning that no other monitoring node could exculpate it. As such, this detection algorithm may generate false positive results, a false positive corresponding to a normal node being detected as malicious by our strategy. The next chapter will show how to minimize the number of false positives.

6.5. Conclusions 93 Table 6.5: States of attacker list and safe list during the localization procedure.

(a) Attacker located at position 11.

Step Attacker list Safe list

Initialization

{v 11 } {v 3 v 6 v 12 }
Step 1

{v 11 } {v 3 v 5 v 6 v 9 v 12 }
Step 2

{v 11 } {v 2 v 3 v 5 v 6 v 9 v 12 }
Step 3

{v 11 } {v 2 v 3 v 5 v 6 v 8 v 9 v 12 }
(b) Attacker located at position 2.

Step Attacker list Safe list

Initialization

{v 2 } {v 3 }
Step 1

{v 2 } {v 3 v 5 v 8 v 9 }
Step 2

{v 2 v 6 } {v 3 v 5 v 8 v 9 v 11 v 12 }
Step 3

{v 2 v 6 } {v 3 v 5 v 8 v 9 v 11 v 12 }

Conclusions

We have proposed in this chapter a security-oriented monitoring architecture for RPL-based Internet of Things. This distributed passive architecture exploits the RPL protocol to support monitoring in a lightweight manner for the regular nodes.

We have described its main components and how they interact based on the RPL protocol. It uses higher-order monitoring nodes typically deployed in many infrastructures such as AMI networks. These nodes are able to passively listen to the network while participating in its operation. The instantiation of our architecture takes benet from the RPL protocol mechanisms such as the multi-instance feature in order to establish two separated routing topologies: a rst instance corresponding to the regular network, and a second instance supporting the security monitoring activities. The regular nodes do not require to be instrumented so that monitoring tasks are operated by higher-order nodes.

We have also proposed dedicated modules to address DAG inconsistency and version number attacks in RPL networks. The rst detection module which targets the DAG inconsistency attack relies on the promiscuous mode of monitoring nodes since the attack takes place in the option header of data packets. The module used to detect the version number attack exploits the ability of monitoring nodes to share their collected information since any local approach cannot be adopted. It permits to identify the malicious node, the attacker localization process being performed by the root after gathering detection information from all monitoring nodes. We have illustrated this strategy through examples showing the possibility for false positive results to occur. As our approach is passive and does not rely on regular nodes, it allows minimizing the impact on the Internet of Things infrastructure. The next chapter details the experimental evaluation of our architecture and its detection modules, in particular performance of the overhearing mode and the eciency of our detection algorithms.

Chapter 7

Architecture Evaluation

Introduction

We have described a whole strategy to detect attacks targeting RPL networks which relies on a distributed architecture and dedicated algorithms.

We propose here, to evaluate our architecture and its detection modules. Figure 7.1 presents the dierent part of this evaluation. We analyze performance and costs of the overhearing mode. The impact of three parameters in the Cooja environment is examined: distance, trac load and neighborhood size. We then investigate the DAG inconsistency attack detection performance with the instantiation of a dedicated scenario in Cooja. We then evaluate the detection strategy for the version number attack. We analyze the number of false positive results according to monitoring node placement conguration in the topology. Since this detection strategy is distributed on the dierent monitoring nodes, we nally investigate the scalability of our approach with the formalization of an optimization problem for dealing with monitoring node placement.

The following of the chapter is organized as follows. Section 7.2 presents our experimental results regarding the overhearing mode. Section 7.3 details results of

Overhearing Evaluation

Our monitoring architecture can exploit the ability of monitoring nodes to overhear their neighbors. A rst study is dedicated to the evaluation of the performance and the cost of this overhearing activity.

Simulation Setup

We have set up a simple scenario composed of three nodes to quantify overhearing performance: a root node, a regular node congured to send data trac periodically and directly to the sink, and a monitoring node with the promiscuous mode enabled which is equidistant from the previous nodes. This scenario allows us to study three parameters separately and measure their potential impact on the overhearing capacity of a monitoring node: (i) the distance from the monitoring node to the node it monitors, (ii) the sending frequency of a regular node and (iii) the number of neighbors of a monitoring node.

This scenario has been implemented in the Contiki 2.7 operating system [START_REF] Dunkels | Contiki -a Lightweight and Flexible Operating System for Tiny Networked Sensors[END_REF].

The TelosB has been chosen as a target platform for regular nodes as in previous experiments. The Cooja simulator has been used during this analysis to execute the code written for the TelosB platform. Since Cooja does not have access to a device model for any higher-order devices, the TelosB platform has not only been used for regular nodes, but also for monitoring nodes. The monitoring node has been congured to enable the promiscuous mode. Each simulation has lasted for a lifetime of eight hours and has been repeated six times for accuracy reasons.

The metrics used to evaluate the dierent parameters are: (i) the success ratio which is the number of overheard data packets over the number of data packets sent by regular nodes in percentage and (ii) the number of overheard packets. Through the simulations it was experienced that the monitoring node can overhear two types of packets: data packets and point-to-point control messages (not destined to itself ) which were ICMPv6 Neighbor Solicitation and Neighbor Advertisement messages.

7.2. Overhearing Evaluation 97

Performance Analysis

In a rst series of experiments, we have analyzed the impact of the distance. For this scenario, the position of the monitoring node has been varied from 15 to 50 meters from both the regular node and the sink. The regular node has been congured to send data every 20 s (180 msg/hr). Table 7.1 gathers results for dierent distances.

Looking at the ratio which is around 36%, we can observe that a monitoring node cannot overhear all messages. This can be explained by the fact that the monitoring node has to process its legitimate trac (control messages) in priority and when its queue is already full, the new arriving overheard packets are dropped. We could deduce that being able to overhear approximately 1 /3 of data packets is low. However, the target platform used is a TelosB, a C1 class device, so it is expected that for a higher-order device the overhearing success ratio would be higher. Also, as explained in Section 6.2, overhearing is not the only source of monitoring data in our strategy, since a monitoring node can also gather data from packets that it legitimately forwards. In this scenario only monitoring data coming from the promiscuous mode is evaluated. As it will be presented in the next section, even if the success ratio seems low it is good enough to detect certain type of anomalies such Denial of Service (DoS) attacks. As we can observe the number of overheard packets do not change over distance such as the ratio, which implies that the distance does not aect the overhearing in the Cooja environment. Success ratio (%) msg/hr to 360 msg/hr. Figure 7.3 shows the number of listened packets using the promiscuous mode by the monitoring node. From Figure 7.2, we can see that the ratio lays between 32% and 39% and is slightly increasing with the frequency. We can therefore conclude that the success ratio is relatively stable (low variation). Since the ratio is stable and the number of sent data packets is increasing, it means that the number of overheard data packets also increases. This is conrmed by Figure 7.

3
where the number of listened data packets increases with the frequency. We can also note that the number of listened control messages is stable (less than 40 messages), which makes sense because the number of nodes does not change over the simulations and the number of overall exchanged control messages is almost the same for each simulation. As a conclusion it can be said that for this environment the overhearing mode has slightly better results with a heavier load, although this improvement is limited (+7% when the trac is multiplied by 8). As such, the overhearing success ratio can be considered as stable with the frequency.

Finally, the number of neighbors has been analyzed in a third series of experiments. For this scenario the topology has been modied so the number of regular nodes has been varied from 2 to 10 including the sink. The new neighbors have been directly connected to the root in the range of the monitoring node. The sending frequency has been set to 180 messages per hour. Table 7.2 gathers the dierent results regarding frequency and number of messages. We can see that the ratio stands between 36.5% and 38.5% which is quite stable. For these simulations we can ex-7.2. Overhearing Evaluation 99 plain the relative stability of the ratio by the fact that not only the number of data packets but also the number of control messages exchanged increases signicantly with the number of neighbors. Indeed, if we consider the number of control messages exchanged between two nodes as stable over the simulations and if we multiply the number of nodes, the number of listened control messages is multiplied as well. The increase of listened data packets is also proportional to the number of neighbors:

for two neighbors we have only one regular node which is sending data packets; if we multiply the number of listened data packets by the number of regular nodes we can see that we are close to the results given by the simulation. For instance, 66 × 3 = 198 which is close to 208, the number of listened data for 4 neighbors (3 regular nodes + 1 sink). Larger neighborhood sizes have not be simulated since the results can be extrapolated from previous observations. The dierent results obtained on the performance of the promiscuous mode for TelosB platform in a Cooja environment are useful information. Indeed, even if the monitoring node can overhear slightly more than a third of transmitted data packets, thanks to the dierent results, an estimation of the actual number of sent data packets can be achieved. Also these results can be helpful when developing detection algorithms. As we know, from the dierent studied scenarios, distance, sending frequency and neighborhood size do not aect much the success ratio.

Cost Analysis

Overhearing packets implies a cost for the monitoring node.

From the energy model provided by Table 7.3, we calculated the cost for receiving monitored packets. In more realistic conditions it is unlikely that regular nodes send so many data packets for their applications (360 msg/hr represents one message every 10 s) and have so many neighbors, we have included extreme cases in our analysis. A trade-o has to be made between cost and eciency. For instance we can optimize the number of monitoring nodes to be deployed but it means that they have to cover more nodes and consequently it costs more in terms of energy. This is also why we proposed in this architecture that the monitoring tasks are supported by higher-order devices so the energy is not as restrictive as it can be on usual C0/C1 devices.

Detection Modules Evaluation

This section aims at evaluating the performance of the detection modules used in our strategy which are deployed on each monitoring node. We rst present results regarding module detecting the DAG inconsistency attack. We then focus on version number attack detection module.

DAG Inconsistency Attack

We present how the DAG inconsistency attack can also be detected using the monitoring architecture. After describing our simulation setup, we detail our detection results. In addition to detect such an attack for every node in the network, we also propose to mitigate it when monitoring nodes are targeted by implementing the dynamic threshold as described in Chapter 5 on them.

Simulation Setup

The topology showed in Figure 7.6 has been implemented in Cooja using the same conguration as Section 7.2. To emulate the behavior of monitoring nodes, Cooja has been setup to ensure that they all (i.e. nodes v 1 , v 2 , v 8 and v 11 ) were within radio range of each other. Across all experiments, node v 1 is the DODAG root and also the sink, nodes v 1 , v 2 , v 8 and v 11 are monitoring nodes. Regular nodes v i have been congured to send data packets to the sink every 20 s. The attacker is designed to send attack messages (packets with down and rank error ags set) every 5 s in average to its preferred parent which means that the attacker is very aggressive.

This corresponds to the extreme case showed in Chapter 5. This frequency has been chosen to study the ability of our architecture to deal with aggressive situation.

The location of the attacker has been varied within the network replacing a regular node in order to analyze the detection performance of our monitoring architecture.

Attacks start after two minutes of simulation time, so that the network has enough time to settle. Each simulation lasts for a lifetime of two hours and is repeated three times for accuracy reasons.

For this scenario, the threshold of Algorithm 4 in Section 6.4 has been set to twice the maximum number of neighbors of a monitoring node (cf. Table 7.4). This value gives the possibility for neighbors to send packets with an `R' ag set in case of and is used as a baseline to compare other results with. It can be seen that the mitigation strategy is successful to limit the control message overhead when the attacker was at positions v 3 , v 4 , v 5 and v 6 . This is explained by the fact that, in those cases, the targeted node was a monitoring node as detailed by Table 7.5.

Since this mitigation is a node-level approach, it has no impact when the target is a regular node. This can be observed in Figure 7.8 when the attacker is located at v 7 , v 9 , v 10 and v 12 . Either the overhead is reduced by up to 600% when the target is a monitoring node or it is nearly unchanged when the target is a regular node.

By exploiting results from Chapters 4 and 5, the benet of the dynamic threshold approach for the same attack pattern (720 attack messages per hour or one attack message every 5 s) is 1100%. The dierence can be explained by the fact that the topology used are dierent and the number of neighbors of the targeted node, which is a parameter of the dynamic mitigation, is not the same.

The DAG inconsistency attack scenario has showed that our monitoring architecture is ecient to detect such an attack in a RPL network. In this scenario, the detection module has been implemented on monitoring nodes for a neighborhood-level detection but the architecture can be exploited so the monitoring nodes exchange data to provide a collaborative detection. By collecting monitoring data to the sink, the architecture might be able to perform a global detection as we will see in the next section.

Version Number Attack

In Section 4. Not only the location of the attacker has been varied but also the location and the number of monitoring nodes. Indeed, in the previous chapter, we have seen that Chapter 7. Architecture Evaluation it was possible to encounter false positives results depending on the fact that a node is monitored by one or several monitoring nodes. The next section details how and why dierent monitoring node congurations were chosen.

Attack Detection Results

In this section, we rst describe our monitoring node placement selection. We then detail the performance results of our detection module.

Monitoring For each simulated scenario, the false positive rate (FPR) has been calculated according to Equation 7.1, where F P and T N are respectively the number of false positives and the number of true negatives. A false positive is a node which has been incorrectly detected as malicious by our detection solution (the node is actually safe). A true negative is a node which has been properly considered as safe.

F P R = F P F P + T N (7.1) Detection Results. Across all experiments the detection successfully identies the attacker but other regular nodes were sometimes detected as malicious too. where the monitoring nodes are v 1 , v 7 , v 13 and v 15 and the Ca 2 is 43,75% (maximum for 4 monitoring nodes). We can observe on Figure 7.10 that the FPR is 0 for 13 positions of the attacker. Details about the detection results when the FPR is more than 0 are given in Table 7.9. When the attacker corresponds to node v 5 , node v 9 is always detected as malicious too, because node v 9 is each time the direct relay of the attacker v 5 and is monitored by only one monitoring node (v 13 ). No other This can be explained by the fact that the attack relays can change depending on the timing for each simulation. For example, when the attacker is v 18 , v 5 is considered as malicious only once, this is because monitoring node v 1 receives only once the attack relay message from v 5 . The other times, the relay node v 6 is also monitored by v 7 which exonerates it. Similar results have been obtained for the other Table 7.9: Detection result details when conguration is the topology of Fig. 7.9

Attacker's position Series 1 Series 2 Series 3

v 5 v 5 , v 9 v 5 , v 9 v 5 , v 9 v 9 v 5 , v 9 v 5 , v 9 v 9 v 18 v 5 , v 18 v 18 v 18
for a particular Ca 2 value. We can see on both gures that the false positive rate decreased for increasing Ca 2 values, which means that the more nodes are covered by at least two nodes, the less is the number of false positives. When there are 4 monitoring nodes we can see in Figure 7.11 that the maximum value of the FPR is 20% which corresponds to the worst case (no node is covered by at least two monitors), and at best the FPR stands around 1%. We only obtain a false positive rate almost null when the Ca 2 is 66,67% (Figure 7.12) with 5 monitoring nodes.

According to these results we can conclude that monitoring nodes placement is strategic in order to obtain satisfying performance in detecting version number attacks. Nevertheless, while the DAG inconsistency attack detection only relies on neighborhood monitoring and such, only 100% coverage is enough (C ov 1 =100%), the version number attack detection requires monitoring node neighborhoods overlapping to perform well. This raises questions about monitoring nodes number and placement to support scaling.

Scalability Evaluation

We analyze the scalability of our solution in line with the considered monitoring node placement. We have showed previously that particular coverage can be required to In the same way that the problem of having all regular nodes covered by at least one monitoring node, i.e. As input to solve this problem we need four parameters detailed in Table 7.10.

The rst parameter is the size of the topology. The second one is the connectivity matrix detailing the links of possible monitoring nodes with other nodes, A i,j = 1 when node v i can listen to node v j . We set the diagonal of this matrix to 0, i.e. ∀i, A i,i = 0 which means that we consider that monitoring node does not cover itself.

The third parameter is the number of monitors. The last parameter is the percentage of regular nodes we want to be monitored by at least two monitoring nodes. The variables used are Y which represents whether node v i is a monitoring node(Y i = 1)

or not (Y i = 0), W indicating whether node v i is covered by monitoring node v j (W i,j = 1) or not (W i,j = 0). The last variable Z species whether node v i is covered by exactly one monitoring node (Z i = 1) or not (Z i = 0). The total number of variables for this problem is N (N + 2).

The constraints are detailed in Equation 7.2 to 7.7:

Y 1 = 1 (7.2) N i=1 Y i = N (7.3) Chapter 7. Architecture Evaluation ∀i ∈ 1, N : N j=1 (A i,j .Y j ) + Y i ≥ 1 (7.4) ∀(i, j) ∈ 1, N 2 : W i,j = A i,j .Y j (7.5) ∀i ∈ 1, N : 2 - N j=1 (W i,j ) + 2.Y i ≤ Z i ≤ 1 -Y i (7.6) N j=1 Z i ≤ (1 -C).(N -M ) (7.7)
As in the previous chapter, Equation 7.2 is used to set v 1 , the root, as a monitoring node, it is possible to set another particular node to be a monitoring node according to the topology specics. Equation 7.3 indicates how many monitoring nodes we choose. The constraint of having all nodes covered by at least one monitor, is given by Equation 7.4. Equation 7.5 calculates W variable which is used in Equation 7.6 to compute Z. The right part of this equation forces Z i = 0 if v i is a monitoring node or else Z i = 1. The left part is equal to 1 only if N j=1 (W i,j ) is equal to 1 and v i is not a monitoring node, which means that the left part equals 1 when the node v i is monitored by only one monitor. Equation 7.7 indicates the constraint that at most (1-C ) % of regular nodes are covered by exactly one monitoring node.

The objective function f obj is given by Equation 7.8:

f obj = min N i=1 Z i (7.8)
The objective is to minimize the number of regular nodes covered by only one monitoring node i.e. to maximize the number of nodes covered by at least two monitoring nodes. This objective is necessary to compute the Z variable correctly. Indeed if v i is not a monitoring node or a regular node only monitored by one monitoring node, Z i can be equal to 0 or 1. Minimizing the sum on Z forces the default value to 0 in those cases.

We solved this problem with dierent sizes of grid topologies from 20 to 1000 nodes and with C=60% using the CPLEX solver [2] under the AMPL environment [1]. The C value has been chosen according to previous results from Section 7.3.2.2 because the false positive rate was very low. A script has been designed to establish the connectivity matrix of grids of corresponding sizes (4×5, 7×7, 10×10, 20×25, 25×40). The minimal number of monitoring nodes required to nd a solution has been determined empirically by running the solver several times. For instance for a grid of 20 nodes (4×5), 5 monitoring nodes are required to obtain Ca 2 = 100%, it is not possible with 4 monitoring nodes since the highest Ca 2 value is 43.75% as showed in the previous section. We have restrained the exploratory domain by solving the problem stated in Chapter 6 (C a 1 = 100%) for every size. The model has also been modied to nd the minimal number of monitoring nodes so Ca 2 = 100% which means in this case that FPR should be 0. Figure 7.13 shows the minimal as showed in the previous section. We can observe on Figure 7.13 that the number of monitoring nodes required to have the dierent Ca values is proportional to the number of nodes. These results show that our solution supports scalability.

Conclusions

In this chapter, we have evaluated our monitoring architecture through a set of experiments. In particular, we have quantied the performance and cost of the promiscuous mode in that context, considering dierent distances, sending frequencies and neighborhood sizes. Experimental results with the Cooja environment have showed the feasibility of the proposed monitoring approach with respect to trac load and neighborhood size. The cost of the overhearing may seem heavy, this is why it is performed by higher-order devices able to carry out this load. Also it can be envisioned to dynamically adapt the overhearing mode based on network events.

We have then analyzed the detection performance of our dedicated algorithms for the DAG inconsistency attack. Thanks to the overhearing mode of monitoring nodes, we have showed that the detection time was less than 30 s in every conguration of the malicious node. Besides the DAG inconsistency attack detection module, we have deployed the dynamic threshold mitigation, seen in Chapter 5, on monitoring nodes to limit the impact of this attack when they were targeted. The obtained results were consistent with the previous study i.e. the control message overhead has been reduced for monitoring nodes when they were targeted by the attacker.

Regarding the version number attack detection module, we have showed that the attack has been successfully detected for each case. Even if the attacker has been Chapter 7. Architecture Evaluation identied, the detection module may produce false positive results by detecting safe nodes as malicious depending on monitoring node placement. However, we have also demonstrated the false positive rate of our solution can be reduced to 0 by a strategic monitoring node placement.

We have nally considered the scalability of our architecture by proposing an optimization problem which can be easily adapted to dierent topologies. By resolving this problem, we have quantied the number of required monitoring nodes to ensure an acceptable false positive rate in detecting the version number attack for a given size of topology. This evaluation demonstrates that our security monitoring approach is successful in detecting attacks targeting the RPL-based Internet of Things while having a minimal impact on the target nodes.

Chapter 8 General Conclusions

The emergence of the Internet of Things results in the large scale deployment of Low power and Lossy Networks. In order to deal with the requirements of such networks, new communication protocols have been designed, and in particular the RPL protocol which provides a routing solution for these environments. While this paradigm enables new applications for everyday life and business, it also represents major security risks. Indeed, the lack of resources such networks suer make them particularly vulnerable to security threats compromising their availability. In this thesis we have proposed to investigate a security monitoring strategy for addressing the trade-o between security and its induced cost in the RPL-based Internet of Things.

Our contributions are organized into three main axes. We have rst assessed security threats targeting the RPL protocol through the identication and classication of attacks and proposed a dedicated taxonomy. We have analyzed the impact of two RPL specic attacks which are the DAG inconsistency and the version number attacks and showed the importance of addressing them. We have then presented a local strategy to detect and mitigate DAG inconsistency attacks in RPL networks and evaluated its performance and costs. We have designed a security-oriented monitoring architecture in order to complement our node-level approach and address more complex attacks. In a passive and distributed manner, this solution preserves constrained nodes resources by exploiting RPL mechanisms such as the multi-instance feature and by relying on higher-order devices which implement detection modules responsible for identifying the considered security attacks. We have evaluated this architecture through extensive series of experiments and discussed the placement of monitoring nodes in that context.

Achievements

After presenting the challenges for monitoring and security in the RPL-based Internet of Things, we have described the RPL protocol functioning and its mechanisms, and have provided a state of the art on existing monitoring approaches for IoT networks. In order to quantify security threats in RPL networks, we have rst proposed a taxonomy classifying the attacks against the RPL protocol in three categories: attacks that over-consume nodes resources, attacks targeting the topology and attacks against networks trac. Using this classication, we have compared the properties of these attacks and discussed methods and techniques to avoid or prevent them. We have then assessed the impact of two major attacks targeting the RPL protocol: the DAG inconsistency and the version number attacks. The DAG inconsistency attack exploits an RPL loop avoidance mechanism to forge fake loops in the network forcing nodes to send unnecessary control messages. We have showed through our experiments that these attacks can increase considerably the control message overhead of targeted nodes and their descendants, reducing their lifetime. Meanwhile, the version number attack misuses the global repair mechanism of the RPL protocol. This attack leads to the propagation within the network of a malicious version number forcing a global rebuild of the DODAG. Quantifying the impact of such an attack has revealed that the control message overhead can increase signicantly (by up to 18 times compared to a normal scenario). We have also observed the occurrence of many loops in the network, an important decrease of the overall delivery ratio and a strong correlation between location of the attacker and observed eects. Through this impact analysis, we have showed that such attacks can meaningfully consume node energy. It is therefore crucial to address these attacks through the design of appropriate security strategies.

To propose security solutions suitable for RPL environments, we have rst designed a node-level approach in order to deal with DAG inconsistency attacks. Since the RPL protocol proposes a xed threshold solution but gives no justication about the chosen value, we have designed an adaptive approach. This one mimics the xed threshold in a steady state, however it takes into account network characteristics and it adjusts itself under varying attack patterns. Even if we have showed its performance compared to the xed threshold, it relies on pre-congured parameters which can represent an inconvenience depending on network specics. We have improved this solution to be fully dynamic by relying on auto-congured parameters. Our strategy has been evaluated through experiments which have showed its eciency.

In particular, it reduces the control message overhead and increases the delivery ratio. The impact of the considered parameters has also been discussed in an analysis to show their potential limitations. We have performed a cost evaluation of the proposed strategy in terms of computational overhead and energy consumption. This analysis has demonstrated the limited cost of our algorithms and their benets regarding the energy savings (up to 50%). Such a node-level approach is ecient to detect attacks having only a local impact, however, it is not able to identify a malicious node in case the attack is spread across the whole network. Also in some cases, dedicated code cannot be implemented on nodes because they lack of memory or RAM or they cannot be ashed.

In that context, we have designed a security-oriented monitoring architecture which preserves nodes resources by passively listening to network trac. This dis-8.2. Perspectives 117 tributed architecture is based on higher order devices typically used in many IoT applications. It exploits RPL mechanisms and in particular the multi-instance feature to organize the monitoring nodes into an independent topology so the resources of regular nodes are preserved. This solution is also able to perform multi-level detection by implementing local algorithms but also gives the capability for the monitoring nodes to collaborate and to send information to the root in order to have a global view of the network. As such, our architecture meets the dierent requirements provided in Table 2.1 from Chapter 2. We have designed specic modules to address DAG inconsistency and version number attacks. The rst module uses the overhearing capacity of monitoring nodes to track malicious data packets. The second module exploits interactions among monitoring nodes to identify malicious nodes. We have evaluated our monitoring architecture through extensive series of experiments. We have rst quantied the performance and cost of the overhearing mode in Cooja environment, considering several parameters which allows us to show the feasibility of our solution. We have then analyzed the eciency of our detection strategy. It was demonstrated that DAG inconsistency attacks can be detected in a limited time despite the limitations of the overhearing mode. We have also showed that the false positive rate for detecting the version number attack can be notably reduced by considering a strategic monitoring node placement. This evaluation permits to conclude on the eciency of our strategy in detecting security threats. For addressing monitoring node placement, we have nally considered the scalability of our architecture by proposing and resolving optimization models.

Perspectives

The work achieved during this thesis opens several perspectives with respect to IoT security monitoring. We rst discussed possible future work regarding complementary experiments in real testbeds and implementation considerations. We then examine the extension of our security monitoring strategy to new elaborate attacks.

Finally, we consider risk management methods to enhance our solution.

Complementary Experiments in Real Testbeds

We are interested in performing complementary experiments in real testbeds. The Cooja simulator used in this thesis is a valuable environment for testing and debugging code in the Contiki OS with many features. It is also useful for research purpose since simulation results are close to real experiments as we have showed through a simulation validation. Authors of [START_REF] Roussel | Using Cooja for WSN Simulations: Some New Uses and Limits[END_REF] have showed this tool could be used for other OS such as the RIOT OS [5]. However, they have identied issues about time inaccuracies which can biased ne results regarding synchronization and time related performance. As future work, it would as such make sense to deploy our proposed monitoring architecture in a real testbed. This permits to use several classes of devices in order to evaluate the costs of our proposed solution on monitoring nodes. Moreover performance of the overhearing mode could be nely evaluated The growing interest for the Internet of Things (IoT) has resulted in the large scale deployment of Low power and Lossy Networks (LLN) such as home automation systems. These networks are strongly constrained in terms of resources (memory, power and processing) and communicate using unstable links with high error rates and low throughputs. In this context, existing routing protocols for wired networks and for ad-hoc networks do not cope with all these constraints. The IETF RoLL working group has proposed a new routing protocol called RPL based on IPv6 and specically designed for these environments. The RPL protocol is however exposed to a large variety of internal and/or external attacks such as resource consuming attacks, trac interception or loops building attacks. The deployment of security mechanisms may also be quite expensive in terms of resources. Therefore, LLN networks present new challenges in terms of monitoring and security. In this thesis we propose to investigate a security-oriented monitoring approach for addressing the trade-o between security and cost in the Internet of Things. In a rst stage, we assess security threats faced by these networks. In particular, we identify and classify attacks targeting RPL networks through a dedicated taxonomy. We also quantify the consequences of two major attacks called DAG inconsistency attacks and version number attacks causing overconsumption of node resources. The obtained results show the importance of addressing them to preserve RPL-based infrastructures. We then focus our work on security solutions for RPL-based Internet of Things. We propose a local strategy for addressing DAG inconsistency attacks and evaluate it through experiments. In order to detect complex attacks such as version number attacks and to complement our node-level approach, we design a security-oriented distributed monitoring architecture for RPL networks. This solution allows us to preserve constrained nodes energy by performing monitoring and detection activities on dedicated nodes. We show the feasibility of our approach by implementing a prototype able to detect both DAG inconsistency and version number attacks. We quantify the performance and the cost of this architecture and the detection modules.

1 2

 1 1 http://www.fp7-amingo.eu/ 2 Routing over Low power and Lossy networks Chapter 1. Introduction This introduction gives the context and the research questions of this thesis.

Figure 1 . 1 :

 11 Figure 1.1: Extension of the Internet to everyday objects 3 .

3 3 Figure 1 . 2 :

 312 Figure 1.2: Example of IoT applications (based on [7]).

Figure 1 .

 1 Figure 1.2 presents some applications for these domains. For example, in smart environments, IoT technologies permit to save energy by automatically turning o lights and heating when the building is empty, or provide security by monitoring areas at night. In logistics, the IoT enables real-time information processing technology which supports monitoring of products, raw materials and so on. The IoT also opens new possibilities in the healthcare domain by allowing assisted living for elderly or ill persons for instance. The deployed objects from the Internet of Things form specic networks called Low power and Lossy Networks (LLNs) which present particular characteristics.

Figure 1 . 3 :

 13 Figure 1.3: Road map of the contributions.

10 Chapter 2 .

 102 Routing and Monitoring in RPL-based Internet of Things 802.15.4 communication protocol; it is thus used as an adaptation layer. The RPL routing protocol is capable to operate over the two previously mentioned protocols.

Figure 2 . 1 :

 21 Figure 2.1: Overview of the IoT protocol stack.

Figure 2 . 2 :

 22 Figure 2.2: Example of a RPL network composed of two instances and three DODAGs.

2. 3 . 1 . 1 15 Figure 2 . 3 :

 3111523 Figure 2.3: Classication of monitoring architectures.

  11 for mobile ad-hoc networks (AODV routing protocol), composed of monitoring agents and data repositories storing monitored information as illustrated by Figure 2.4.The sinks, collecting monitoring data, vary over time based on their resources and locations, in order to maximize the network lifetime. In this approach, each agent is hosted by a target network node which sends information to the distributed monitoring sinks, thereby increasing the resource consumption of all nodes. DAMON supports sink auto-discovery using beacon messages and the resiliency of agents to sink failures.

Figure 2 . 4 :

 24 Figure 2.4: Architecture used in DAMON.

Figure 2 . 6 :

 26 Figure 2.6: Architecture used in SVELTE.

Figure 2 . 7 :

 27 Figure 2.7: Architecture used in the specication-based IDS from [41].

Figure 2 . 8 .

 28 Their work focuses on merging the monitoring traces obtained from the dierent sniers, estimating the coverage of the monitoring nodes and deducing missing information.

Figure 2 . 8 :

 28 Figure 2.8: Architecture used in LiveNet.

Figure 2 . 9 :

 29 Figure 2.9: Architecture used in EPMOSt.

Figure 3 . 1 :

 31 Figure 3.1: Taxonomy of attacks against RPL networks.

Chapter 3 .

 3 Taxonomy of Attacks in RPL Networks (a) Initial State (b) Final State

Figure 3 . 2 :

 32 Figure 3.2: Rank increased attack in a RPL network.

Figure 3 . 3 :

 33 Figure 3.3: A wormhole attack in a RPL network.

  .4. Once a packet is transmitted downward, it should normally never go up again. When it happens the router sends the packet to the parent that passed it with the Forwarding-Error 'F' bit set and the Down 'O' bit left. When the parent receives the packet with 'F' set it removes the corresponding routing state, clear the 'F' bit, and try to send the packet to another neighbor. If the alternate neighbor still has an inconsistent state the process reiterates.

Figure 3 . 4 :

 34 Figure 3.4: Illustration of a DAO inconsistency attack.

Figure 3 . 5 :

 35 Figure 3.5: Illustration of a decreased rank attack.

Figure 4 . 1 :

 41 Figure 4.1: DAG inconsistency attack scenarios.

  Figure 4.1(b) node 3 is the attacker.

Figure 4 . 2 :

 42 Figure 4.2: Total control message overhead experienced by network presented in Figure 4.1(a) under DAG inconsistency attacks.

Figure 4 .

 4 Figure 4.1(b) was setup in Cooja, with node 1, the DODAG root, acting as the sink.

Figure 4 . 3 :

 43 Figure 4.3: Example of new DODAG iteration.

Figure 4 .

 4 Figure 4.3 illustrates a rebuild of a DODAG due to a global repair process. In red solid arrows, the new DODAG is being built, in blue dashed arrows the old topology is showed. An older value of the version advertised in DIO messages indicates that the node has not migrated to the new version of the DODAG. Such a node should not be considered as a preferred parent by other nodes. While the global rebuild process is ongoing, it is possible for two versions of a DODAG to temporarily coexist. To avoid loops, data packets are permitted to transit from the old version to the new

Figure 4 . 4 :

 44 Figure 4.4: Grid topology used for performing experimental evaluation of the version number attack.

( 1 )Figure 4 . 5 .Figure 4 . 5 :

 14545 Figure 4.5. The error bars show the standard deviation between the ve simulation runs.The incoming and outgoing overhead when there is no attacker (attacker ID 0 in the gure), both are about 1250 packets, which can be considered reasonable for a network of 20 nodes that functions for 50 minutes. However, as soon as an attacker is introduced, the overhead can increase by up to 18 times in the network.At rst glance it appears that the overhead increases as the attacker moves into regions where it has more neighbors. Closer inspection of Figure4.5 reveals that mostly attacker positions in the bottom row of the topology(4, 8, 12, 16 and 20) produce localized maximums in their column of the topology. For example considering attacker position at node 8 and the other nodes of its column(5,6,7), we can

Figure 4 . 6 :

 46 Figure 4.6: Per node outgoing packet overhead for every location of the attacker.

Figure 4 . 7 :

 47 Figure 4.7: Total delivery ratio and end-to-end delay for every location of the attacker.

Figure 4 . 8 :

 48 Figure 4.8: Total number of loops and inconsistencies in the network for every location of the attacker.

Figure 4 . 9 :

 49 Figure 4.9: Total number of loops detected per node for every location of the attacker.

Figure 4 . 10 :

 410 Figure 4.10: Total number of inconsistencies detected per node for every location of the attacker.

  . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.2 DAG Inconsistency Attack Mitigation . . . . . . . . . . . 58 5.2.1 Default Mitigation . . . . . . . . . . . . . . . . . . . . . . . 58 5.2.2 Adaptive Mitigation . . . . . . . . . . . . . . . . . . . . . . 59 5.2.3 Dynamic Mitigation . . . . . . . . . . . . . . . . . . . . . . 60 5.3 Mitigation Evaluation . . . . . . . . . . . . . . . . . . . . . 62 5.3.1 Simulation Setup . . . . . . . . . . . . . . . . . . . . . . . . 63 5.3.2 Mitigation Performance . . . . . . . . . . . . . . . . . . . . 64 5.3.3 Conguration Parameters Impact . . . . . . . . . . . . . . . 69 5.3.4 Resource Consumption . . . . . . . . . . . . . . . . . . . . . 73 5.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Chapter 5 .

 5 Local Strategy for Addressing DAG Inconsistency Attack Algorithm 3 Dynamic DAG inconsistency mitigation strategy of a node.

Figure 5 . 1 :

 51 Figure 5.1: Topologies for mitigation approaches evaluation (same as Figure 4.1).

Figure 5 . 64 Chapter 5 .Figure 5 . 2 :

 564552 Figure 5.2: Comparison of per node outgoing packet overhead for node 2 in the topology from Fig. 5.1(a).

  3.1 the performance of the xed, adaptive and dynamic threshold mitigation approaches have been evaluated using simulations. The attack frequency was varied from 15 to 3600 attacks per hour. Packet Overhead. When using the xed threshold to mitigate the DAG inconsistency attack, we can see from Figure 5.3 that worst case overhead for xed threshold (30 attacks/hr) is reduced by nearly 15%. Aggressive attacks cause the threshold to 5

Figure 5 . 3 :

 53 Figure 5.3: Total control message overhead per node when no mitigation strategy and default mitigation strategy are used.

Figure 5 .Figure 5 . 4 :

 554 Figure 5.5 shows that the dynamic threshold is able to reduce overhead by 20% for aggressive attacks and 50% for slow attacks, when compared to the default xed threshold approach. Comparing Figures 5.4 and 5.5, we can see that the advantage

Figure 5 . 5 :

 55 Figure 5.5: Total control message overhead per node when default mitigation strategy and dynamic threshold are used.

  Fixed threshold and dynamic threshold time-lines.

Figure 5 . 6 :

 56 Figure 5.6: Time-lines of outgoing packet overhead of node 2 in topology of Fig. 5.1(a).

Figure 5 .Figure 5 . 7 :

 557 Figure 5.7: Total control message overhead per node with xed threshold, adaptive threshold (γ = 25) and dynamic threshold (Fig.5.1(b)) .

Figure 5 . 8 :

 58 Figure 5.8: Eect of γ parameter on total control packet overhead experienced by node 2 in topology of Fig. 5.1(a).

Figure 5 . 9 :Figure 5 . 10 :

 59510 Figure 5.9: DAG inconsistency attack scenario used to study the eect of neighborhood size on the dynamic threshold.

Figure 5 . 11 :

 511 Figure 5.11: Outgoing packet overhead experienced by node 2 in the topology of Fig. 5.1(b) with varying sending frequencies and neighborhood sizes.

Figure 5 . 12 : 2 (

 5122 Figure 5.12: Global delivery ratio for dierent neighborhood sizes of node 2 (Fig.5.1(b)) with dynamic threshold.

  3, we have determined that the amount of energy taken up by the adaptive threshold (γ=25) computation is approximately 22.68 µJ, which is the amount of energy required to keep the processor running for the computation time of 31.25 ms. On the other hand, computing the dynamic threshold uses about 18.14 µJ, since the time to compute the threshold is about 25 ms. This means that for attack frequencies of 20, 45 and 90 attacks per hour, the total energy spent over a period of one hour on computing the adaptive threshold is about 0.45 mJ, 1.02 mJ and 2.04 mJ respectively, for the adaptive threshold (γ=25). On the other hand, this is about 0.36 mJ, 0.81 mJ, 1.63 mJ respectively for the dynamic threshold. Figure5.13 presents the energy consumed at the attacked node to calculate the adaptive and the dynamic thresholds. The consumed energy increases by a signicant amount when the attacker becomes more aggressive. This is because aggressive attacks lead to more threshold calculations, as such, more energy is consumed. However, looking only at the energy consumed in calculation of the overhead is not a good measure for energy consumption since such attacks also cause additional packet overhead, which leads to additional consumption by the radio. Since the radio tends to be the most energy hungry device on constrained nodes, we have to factor this into the energy consumption as well. The upper part of Figure5.14 shows the energy consumption caused by the control message overhead and threshold computation for all the nodes in the network. The lower part of Figure 5.14 presents the change in energy consumption caused by the control message overhead and threshold

Figure 5 . 13 :

 513 Figure 5.13: Energy required for adaptive (γ=25) and dynamic thresholds computation under dierent attack patterns.

Figure 6 . 1 :

 61 Figure 6.1: Typical AMI network [19].

(

  NAN) and the Wide Area Network (WAN). The NAN consists of the smart meters that are deployed at (1) residential premises, (2) commercial and industrial buildings and (3) electricity transformer and feeder points in a specic neighborhood. These smart meters typically communicate by forming an IEEE 802.15.4 based mesh network that uses IPv6 for addressing individual devices. The RPL routing protocol is likely to be used to form the routing topology in the NAN tier. The WAN tier usually consists of the utility providers head end systems where metering data is typically collected. Unlike the NAN tier, systems in the WAN tier communicate using high-speed wireless or xed-line access technologies. Field routers controlled by the utility providers, deployed on supply poles in a neighborhood, act as a bridge between the NAN and WAN tiers. These eld routers have two interfaces, one that allows it to communicate with the low-power lossy network (typically IEEE 802.15.4) on the NAN side and another one that provides access to the high-speed wireless or xed-line networks on the WAN side. It is also possible for these eld routers to participate in a NAN-to-NAN mesh, such that the nal interconnection of smart meters with head end systems occurs only via the low-power lossy communication channel.

  (a) Monitoring nodes snooping packets transmitted by nodes in radio range. (b) Building of two RPL instances.

Figure 6 . 2 :

 62 Figure 6.2: Example of our passive monitoring architecture exploiting the RPL multiinstance feature.

Figure 6 .

 6 Figure 6.2(a) presents an example of a DODAG where node v 1 is the root. Multiple

  observed from RPL control messages originating at each regular node. Node Objective Function observed from RPL control messages originating at each regular node. • Information specic to a node: Node DODAG Rank observed from RPL control messages originating at each regular node. Minimum Rank Increase: the option observed in control messages advertised by a non-root node. Maximum Rank Increase the option observed in control messages advertised by a non-root node. • Information about the repair mechanisms: Local Repairs Triggered the number of local repairs triggered by a node. Global Repairs Triggered the number of global repairs triggered by a node, i.e. higher DODAG version advertised by a non-root node. • Information about Control Messages: 6.3. Monitoring Node Placement Formalization 85 DIO Message Count the number of RPL DIO control messages observed from a node. DIS Message Count the number of RPL DAO control messages observed from a node. DAO Message Count the number of RPL DAO control messages observed from a node. Delay between DAO messages observed by timing the frequency of DAO message reception from each regular node. • Information related to the Data Path Validation: O-Bit Set the number of packets observed from a regular node with the O-Bit set. F-Bit Set the number of packets observed from a regular node with the F-Bit set. R-Bit Set the number of packets observed from a regular node with the F-Bit set.

Figure 6 . 3 :

 63 Figure 6.3: DAG inconsistency attack illustration where node 6 is the malicious node.

Figure 6 .

 6 Figure 6.3 shows an example of a direct attack scenario. In this scenario, the

  Number AttackWhile the DAG inconsistency attack exploits information contained in data packets, the version number on the other hand misuses the version number included in DIO control messages. Due to the fact that an incremented version number is propagated within the entire graph, a monitoring node cannot decide by itself whether there is an attack or not. The monitoring nodes have therefore to share monitoring information to identify the malicious node. Our monitoring architecture is designed to allow monitoring nodes to collaborate together thanks to the monitoring instance. Also, the monitoring nodes can track information regarding their neighborhood, so the regular nodes do not have to carry out this task. To detect this attack and locate the malicious node we propose Algorithms 5, 6 and 7. The local assessment algorithm presented in Algorithm 5 is deployed on monitoring nodes except the root and allows monitoring nodes to report to the root the sender of an incremented version number in their neighborhood. Algorithms 6 and 7 are implemented on the root node. The rst one detects the attack and gathers all monitoring node information into tables. The last algorithm performs the attacker identication by analyzing the collected information. Algorithm 5 Local assessment algorithm. potential_att = NULL; for each DIO received by v k from

  for (i=0, i<potential_att_list.nb, i++) do if (att_list == NULL) then add(att_list,potential_att_list[i])

  (a) Attacker located at position 11. (b) Attacker located at position 2.

Figure 6 . 4 :

 64 Figure 6.4: Version number attack illustrations.

Figure 7 . 1 :

 71 Figure 7.1: Monitoring architecture and detection strategy evaluation.

Figure 7 . 2 :

 72 Figure 7.2: Average success ratio while varying sending frequency.

Figure 7 . 3 :

 73 Figure 7.3: Average number of listened packets in one hour while varying sending frequency.

Figure 7 .Table 7 . 3 :Figure 7 . 5 Figure 7 . 4 .

 7737574 Figure 7.4 shows the energy consumption of a monitoring node with two neighbors while the sending frequency of regular node is varied from 45 to 360 packets per hour.

Figure 7 . 4 :

 74 Figure 7.4: Energy consumed by the overhearing mode for a monitoring node while varying sending frequency (2 neighbors).

7. 3 .Figure 7 . 5 :

 375 Figure 7.5: Energy consumed by the overhearing mode while varying neighborhood size for one hour.

Figure 7 . 6 :

 76 Figure 7.6: Scenario used to perform the DAG inconsistency attack.

7. 3 .Figure 7 . 7 :Table 7 . 5 :v 1 v 1 v 2 v 2 v 5 v 6 v 3 v 4 7. 3 . 1 . 3

 377754313 Figure 7.7: Detection time of the DAG inconsistency attack for dierent location of attacker.

Figure 7 .Figure 7 . 8 :

 778 Figure 7.8 presents the overall outgoing control message overhead experienced by the network per node. The left bar represents the overhead with the mitigation enabled and the right bar without mitigation. v 0 means a scenario without attacker

  3 we have studied the version number attack. The pattern of this attack makes it hard to detect or mitigate locally since there is no possibility to identify precisely the malicious node. The Algorithms 5, 6 and 7 allow detecting and locating an attacker which performs the version number attack. They exploit the 7.3. Detection Modules Evaluation 105 collaboration among the monitoring nodes of our architecture.7.3.2.1 Simulation SetupWe evaluate the performance of the Algorithms 5, 6 and 7 through experiments by implementing a Proof of Concept prototype. We have set up the same grid topology of 20 nodes such as in Section 4.3 as presented in Figure7.9. The same implementation of the attacker has been used for these simulations. The Contiki 2.7 operating system has been used to implement the sink, regular nodes and monitoring nodes.Due to technical issues with the Contiki code, monitoring nodes have been congured to print required data for detection while Algorithms 6 and 7 have been implemented and run oine using Matlab scripts to produce the dierent results. The Cooja tool has been used to run the simulation with the compiled binaries of the dierent nodes.The radio model used was the DGRM model (Directed Graph Radio Medium) to emulate the links as showed in Figure7.9: regular nodes can communicate with their neighbors horizontally and vertically, while the monitoring nodes can also listen diagonally since they are higher-order devices in our architecture. Across all experiments, node v 1 is the DODAG root and the sink to which all other nodes send messages every twenty seconds. The attacker is designed to constantly send incorrect version numbers, which are greater than the root's. Each simulation has lasted ten minutes which is enough to test our detection algorithms since only the rst attack message is taken into account. The location of the attacker has been varied to one of each regular node.This entire set of simulations has been repeated three times for accuracy reasons. Attacks have been started after ve minutes of simulation time, so that the network has enough time to settle and a stable RPL topology emerges.

Figure 7 . 9 :

 79 Figure 7.9: Grid topology of 20 nodes used to perform version number attacks.

Figure 7 .

 7 Figure 7.10 details false positive results for the topology presented in Figure 7.9

Figures 7 .Figure 7 . 10 :

 7710 Figures 7.11 and 7.12 show average false positive rate for the dierent values of Ca 2 with varying location of the attacker. Error bars are calculated as standard error of the mean (SEM) of the dierent possible congurations (C ov i combination)

Figure 7 . 11 :

 711 Figure 7.11: Average false positive rate for dierent Ca 2 values with 4 monitoring nodes.

Figure 7 . 12 :

 712 Figure 7.12: Average false positive rate for dierent Ca 2 values with 5 monitoring nodes.

Figure 7 . 13 :

 713 Figure 7.13: Number of monitoring nodes required to have Ca 1 = 100%, Ca 2 ≥ 60% and Ca 2 = 100% for dierent topology sizes

  Their comparison has pointed out their limits in the context of RPL-based Internet 116 Chapter 8. General Conclusions of Things.

••

  Le ag 'O' indique la direction attendue du paquet, i.e., vers le haut ou le bas. Si un n÷ud place ce ag à 1 le paquet est destiné à un descendant, sinon le paquet est supposé être envoyé à un parent avec un rang inférieur, vers la racine du DODAG. Le ag 'R' indique si une erreur de rang a été détectée par un n÷ud transférant le paquet. Ce ag est mis à 1 lorsqu'un n÷ud observe une incohérence entre la direction supposée du paquet indiquée par le ag 'O' et le rang du n÷ud qui vient de le transférer. Le ag 'R' est utilisé pour réparer ce type d'anomalie appelée incohérence DODAG. Concrètement, à la première incohérence détectée, le n÷ud place ce ag à 1 et transfère le message. Lors de la réception d'un autre paquet avec le ag positionné à 1 et l'incohérence à nouveau détectée, le paquet est supprimé et le temporisateur Trickle est réinitialisé de sorte que les messages de contrôle sont envoyés plus rapidement, an de refaire converger la topologie et réparer la boucle. Deux principaux mécanismes de réparation sont utilisés dans les réseaux RPL en cas d'incohérences ou de pannes: la réparation locale et globale. La réparation locale consiste à trouver un chemin alternatif pour router les paquets. Par exemple, lorsque que la communication avec le parent préféré est rompue, un n÷ud peut choisir un autre parent pour transférer ses paquets. Si aucun autre parent n'est disponible, il peut aussi envoyer les paquet à un frère, i.e., un n÷ud de même rang. Si les réparations locales ne susent pas, la racine peut initier une réparation globale en incrémentant le numéro de version du DODAG. Ceci a pour résultat la reconstruction complète du graphe. 132 Résumé de la thèse en français 3 Taxonomie des attaques contre le protocole RPL Les diérentes attaques visant le protocole RPL ont été répertoriées ainsi que les contre-mesures existantes dans cette section. Elles ont de plus été classiées selon qu'elles menaçaient en priorité les ressources des n÷uds (surconsommation d'énergie par exemple), la topologie du réseau et enn le trac comme le montre la Figure 1. Les attaques de la première catégorie ont pour but de consommer l'énergie, la mémoire ou le temps de calcul des n÷uds. On distingue dans cette catégorie les attaques dites directes et indirectes. Dans le cas des attaques directes un n÷ud malveillant génère directement la surcharge; pour la seconde sous-catégorie, le n÷uds malveillant fait en sorte que les cibles génèrent la surcharge. Les attaques de la seconde catégorie visent la topologie du réseau. Plus précisément, ces attaques peuvent engendrer une sous-optimisation du réseau (les routes sont plus longues que ce qu'elles devraient être par exemple) ou l'isolation de n÷uds dans le réseau. Enn la dernière catégorie concerne les attaques ciblant le trac que nous avons sous-diviser en deux: l'écoute du trac an d'accéder au contenu des données et à leur condentialité et le détournement du trac qui vise à usurper certaines propriétés comme l'identité d'autres n÷uds.

Figure 1 :

 1 Figure 1: Taxonomie des attaques contre les réseaux RPL

4. 1 Figure 2 :

 12 Figure 2: Nombre de messages de contrôle envoyé par n÷ud sous diérents scenarios d'attaque

Figure 3 :Figure 4 :Figure 5 : 7 .7

 3457 Figure 3: Nombre total de boucles par n÷ud pour chaque position de l'attaquant.

Figure 6 :

 6 Figure 6: Temps de détection par n÷ud de surveillance pour diérentes positions de l'attaquant.

Figure 7 :Figure 8 :

 78 Figure 7: Taux de faux positifs moyen pour diérentes valeurs de Ca 2 avec 5 n÷uds de supervision.

  Keywords: Internet of Things, LLN, RPL, Security, Monitoring

Table 1 .

 1 1: Classes of constrained devices used in the Internet of Things (IoT)[START_REF] Bormann | Terminology for Constrained-Node Networks[END_REF].

	Device Classes	RAM	ROM
	C0	< 10 KiB < 100 KiB
	C1	∼ 10 KiB ∼ 100 KiB
	C2	∼ 50 KiB ∼ 250 KiB

Table 1 .

 1 2: Protocol comparison results[START_REF] Levis | Overview of Existing Routing Protocols for Low Power and Lossy Networks[END_REF].

	Protocol	Routing state	Loss response	Control cost	Link cost	Node cost
	OSPF/IS-IS	fail	fail	fail	pass	fail
	OLSRv2	fail	?	?	pass	pass
	TBRPF	fail	pass	fail	pass	?
	RIP	pass	fail	pass	?	fail
	AODV	pass	fail	pass	fail	fail
	DYMO	pass	?	pass	?	?
	DSR	fail	pass	pass	fail	fail

Table 1 .

 1 2 gathers obtained results regarding aforementioned criteria. For each criteria, pass indicates that a given protocol has satisfactory performance according to the considered criterion; fail meaning the opposite. The value ? indicates lacks in the protocol so that authors could not conclude if the test has succeeded regarding the criterion. We can observe that no existing routing protocols meet requirements of LLN networks as dened by the RoLL working group. As a result, RoLL has proposed a new proactive routing protocol called RPL standardized by RFC 6550[START_REF] Winter | RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks[END_REF].

	1.2. Problem Statement

  Table Overload Attacks in Storing Mode

	It is also possible to perform direct attacks against resources by overloading the RPL
	routing tables. The RPL protocol is a proactive protocol. This means that the RPL
	router nodes build and maintain routing tables when the storing mode is enabled
	for those nodes. The principle of routing table overload is to announce fake routes
	using the DAO messages which saturate the routing table of the targeted node.
	This saturation prevents the build of new legitimate routes and impacts network
	functioning. It may also result in a memory overow. Let us consider the example of
	the DODAG 2 described in Figure 2.2 in Section 2.2 and assume that node 12 plays
	the role of the attacker. Nodes 12 and 13 send a DAO message in order to add the
	corresponding entries in the routing table of node 11. The attacker, node 12, sends
	multiple forged DAO messages to node 11 with false destinations. As a consequence,
	node 11 builds all the corresponding entries in its routing table. Afterwards, when
	the other nodes including node 13 are sending legitimate DAO messages with respect
	to new routes, the node 11 is no longer able to record them because its routing table
	is overloaded. This attack is not specically mentioned in the literature but it is part
	of overload attacks more generally [66].
	3.2.2 Indirect Attacks
	Indirect attacks correspond to attacks where the malicious node makes other nodes
	generate an overload for the network. It includes: increased rank attacks, DAG
	inconsistency attacks and version number attacks.

Table 3 .

 3

				1: Summary of attacks on resources.
	Attacks	I/E A/P Prerequisites	Impact	CIA	Mitigation/ Protection	Overhead
	Flooding	I/E	A	-	Link/Battery	A	None	None
	Routing Table Overload	I	A	Storing Mode	Memory/Battery A/I	None	None
	Increased Rank Attack	I	A	-	Battery/Link	A	RPL loop detection and avoidance mechanisms [80]	None (by default in RPL)
	DAG In-consistency Attack	I	A	Option Header	Battery/Link A/I	Limitation of timer resets [32]	Low
	Version Number Attack	I	A	-	Battery/Link A/I	VersionNumber and Rank Authentication [28],

Table 3 .

 3 2: Summary of attacks on topology.

	Attacks	I/E A/P Prerequisites	Impact	CIA	Mitigation/ Protection	Overhead
	Routing Table Fals.	I	A	Storing Mode	Target's Subnet, D	A/I	None	None
	Sinkhole	I	A	-	Attacker's Subnet and Neighborhood, D/U	A/I	SVELTE [63], Rank verication [28] and Parent fail-over [79]	Low, No evaluation
	Wormhole	I	A	2 intruders min.	Attackers Subnet, D/U	A/I	Geographical data [78], Merkel trees [34]	No evaluation (for both)
	Routing Infor-mation Replay	I	A	-	Attacker's Neighborhood, D/U	A/I	Sequence Number [80]	None (by default in RPL)
	Worst Parent	I	A	-	Attacker's Subnet, D/U	A/I	None	None
							Monitoring of	Depends on
	Blackhole	I	A	-	Attacker's Subnet, D/U	A/I	counters [18], Parent fail-over [79],	the solution, No
							SVELTE[63]	evaluation
	DAO In-consis-tency	I	A	Storing Mode, Option Header	Target's Subnet, D	A/I	Limitation of discarding routing state [32]

Low

In this table, the impact characterizes how the topology of the network is aected (modied or isolated) and what type of trac is concerned (e.g. downward (D) or upward trac (U)). We consider two main areas that may be impacted: (1) the neighborhood of a RPL node corresponding to nodes in the direct vicinity such as parents, children, and siblings nodes, and (2) the subnet of a node. We can observe in that table that routing table falsication and DAO inconsistency attacks are characterized by a similar impact. Indeed, these two attacks corrupt the routing tables of the target. Only downward trac is concerned because routing tables are

  3.4. Attacks on Trac 37 the malicious node modies the topology and then isolates nodes or degrades network performance through sub-optimization. The integrity is also impacted by attacks targeting topology. For instance, routing table falsication attacks and DAO inconsistency attacks alter routing tables. Decreased rank attacks induce that the integrity of packets is jeopardized. Moreover, the routing information held by legitimate nodes such as parent identity, freshness or routing path are corrupted during routing information replay, sinkhole, wormhole, blackhole and worst parent attacks.Replay attacks can be countered by sequence numbers implemented by default in the RPL protocol; also the optional mechanism proposed in RFC 6553 mitigates the eects of DAO inconsistency. The cost of this mitigation is low because it consists in implementing a xed threshold. Dierent authors proposed several counter-measures

Table 3 .

 3 3: Summary of attacks on trac.

	Attacks	I/E A/P Prerequisites	Impact	CIA	Mitigation/ Protection	Overhead
	Sning	I/E	P	-	Critical data	C	Encryption [80]	Depends on the
								algorithms
	Trac Analysis	I/E	P	-	Critical data	C	None	None
	Decreased Rank	I	A	-	Node's rank	I	VeRA [28], TRAIL [40], Rank verication [79],	Low, Low, Not evaluated,
							SVELTE [63]	Low
	Identity attack	I	A	-	Node's rank	I	None	None

larger amount of data and the opportunities to attack the RPL network are bigger.

  loops in the network. Meanwhile the version number attack exploits the global repair mechanism provided by the RPL protocol to ensure an optimized topology.A malicious node may modify the version number associated to a topology, thereby forcing a rebuild of the entire routing tree. Since the version number is included in control messages by parents, there is no mechanism provided by the standardized protocol to guarantee the integrity of the advertised version number.We focus on the DAG inconsistency attack in Section 4.2 and present two possible ways for a malicious node to perform it. The consequences of these attack scenarios are evaluated through experiments. We then analyze in Section 4.3 the version number attack and also assess its impact on a RPL network.

	44	Chapter 4. Impact Assessment of RPL Attacks
	Impact Assessment of RPL
		Attacks
	Contents
	We have showed in Chapter 3 that the DAG inconsistency attack exploits the RPL
	data path validation feature which is used to avoid and detect possible loops within
	the network. Packet information is transported in an IPv6 option header. Three
	ags are dened: the down 'O' ag indicating the expected direction of a packet,
	the rank-error 'R' ag signaling if a mismatch occurred between the down ag and
	the actual direction of the packet and the forwarding-error 'F' ag used to indicate
	whether a node cannot reach a destination. The attack consists in manipulating
	the 'O' and 'R' ags in the IPv6 option header of regular data packets to introduce

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.2 The DAG Inconsistency Attack . . . . . . . . . . . . . . . 44 4.2.1 Attack Description . . . . . . . . . . . . . . . . . . . . . . . 44 4.2.2 Simulation Setup . . . . . . . . . . . . . . . . . . . . . . . . 46 4.2.3 Impact Quantication . . . . . . . . . . . . . . . . . . . . . 46 4.3 The Version Number Attack . . . . . . . . . . . . . . . . .

48

4.3.1 Attack Description . . . . . . . . . . . . . . . . . . . . . . . 48 4.3.2 Simulation Setup . . . . . . . . . . . . . . . . . . . . . . . . 49 4.3.3 Impact Quantication . . . . . . . . . . . . . . . . . . . . . 50 4.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.1 Introduction

Quantifying the impact of attacks is important to design ecient and accurate security strategies. We consider in this chapter two attacks specic to RPL: the DAG inconsistency attack and the version number attack because they target the node resources, as presented in our taxonomy, which implies a shortened lifetime of the network. fake

  4.2.1.1 Direct Attack ScenarioA malicious intruder can directly attack its neighborhood by sending packets that have the `R' ag and the wrong direction set. For instance, if a parent is targeted,

	the attacker can send packets with the `O' and `R' ags set, since packets with `O'
	ag are intended for descendant nodes. The parent will detect an inconsistency and
	thus, drop the packet and restart its trickle timer.
	Resetting the trickle timer causes control messages to be sent more frequently
	which leads to local instability in the network. This increased control message over-
	head reduces channel availability and increases energy consumption which can lead
	to a shortened network lifetime in case nodes are battery operated. Since nodes in
	RPL networks are likely to be resource constrained, they are unlikely to support
	multi-tasking or large packet buers. As such, time spent on processing malicious
	packets could lead to loss of genuine ones.

Figure 4.1(a) depicts a scenario where such an attack takes place. In this case,

a stable network topology of ten nodes is formed using RPL. Node 10 assumes the role of an attacker by sending messages, with the `O' and `R' ags set, to node 2, its parent. Node 2 resets its trickle timer, thereby ooding its neighborhood with control messages and aecting nodes 4 and 5 as well.

Table 5 .

 5

	Type of threshold	20 attacks/hr	45 attacks/hr	90 attacks/hr
	Adaptive threshold (γ=20)	28 ms	31 ms	31 ms
	Adaptive threshold (γ=25)	28 ms	30 ms	31 ms
	Dynamic threshold	26 ms	25 ms	24 ms

1: Average computation time (ms) to calculate adaptive and dynamic thresholds for dierent attack patterns.

Table 5

 5 4%) of statically allocated RAM. It is important to note that the base Contiki system is also already a part of this. The almost 8% increase in ash usage, for both approaches, can be reduced by optimization. On the other hand, there is almost no change in the amount of statically allocated RAM required.

	.2 gathers the obtained re-

Table 5 .

 5 2: Memory occupancy of the dierent thresholds.

	Type of threshold	Flash memory (kB)	RAM (kB)
	Fixed threshold	41.96 (87.4%)	8.63 (86.3%)
	Adaptive threshold	45.61 (95%)	8.64 (86.4%)
	Dynamic threshold	45.73 (95%)	8.64 (86.4%)

Table 5 .

 5 3: Energy model for the CC2420 radio and MSP430F1611 microcontroller operating at 1 MHz on the TelosB platform.

	Operation	Current	Voltage	Part
	Transmit (Tx) 18.8 mA	2.2 V	CC2420 [17]
	Receive (Rx)	17.4 mA	2.2 V	CC2420 [17]
	Processing	0.33 mA	2.2 V	MSP430F1611 [75]

Table 6 .

 6 1: Summary of considered notations.

	Notation	Meaning
	I R , I M	regular instance, monitoring instance
	V , v i	set of all regular nodes, particular regular node i
	V , v k	set of all monitoring nodes, monitoring node k
	r i	rank value of node i
	N vi	neighborhood of node v i

Table 6 .

 6 3: Considered variables for modeling. can be seen in the next chapter). Only one variable is used here (cf. Table6.3),

	Domain	Variable Description
	1, N	Y	Binary variable indicating whether Y i is a monitoring node (= 1) or not
	does not cover itself. This facilitates the formalization of more complex problems by
	excluding monitoring nodes from specic constraints focusing on regular nodes only
	(as it

  Contents 7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 95 7.2 Overhearing Evaluation . . . . . . . . . . . . . . . . . . . . 96 7.2.1 Simulation Setup . . . . . . . . . . . . . . . . . . . . . . . . 96 7.2.2 Performance Analysis . . . . . . . . . . . . . . . . . . . . . 97 7.2.3 Cost Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 99

7.3 Detection Modules Evaluation . . . . . . . . . . . . . . . . 100 7.3.1 DAG Inconsistency Attack . . . . . . . . . . . . . . . . . . 101 7.3.2 Version Number Attack . . . . . . . . . . . . . . . . . . . . 104 7.4 Scalability Evaluation . . . . . . . . . . . . . . . . . . . . . 109 7.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Table 7 .

 7

	15 20	30	40 50

1: Performance while varying the distance. Distance (m)

Table 7 .

 7 2: Performance while varying the neighborhood size.

	Number of neighbors	2	4	6	8	10
	Success ratio (%)	36.5 38.5 37.5 38.5 38
	Number of listened data packets/hr 66 208 337 482 612

Table 7 .

 7 4 summarizes the regular nodes monitored by the dierent monitoring nodes as it is showed in Figure7.6. The table7.5 shows for each location of the attacker which node was the targeted node.Monitored neighborhood {v3 , v 4 } {v 3 , v 5 , v 6 } {v 5 , v 6 , v 7 , v 9 } {v 3 , v 4 , v 10 , v 12 }According to Figure7.7 and Table7.4 we can observe that the attack has been successfully detected in every case; which means that all monitoring nodes have detected the attacker when it was in their neighborhood. In general the detection time stands between 2 min 20 s and 2 min 25 s, since the attack has started after 2 min it means that it has been detected in less than 30 s. However when the monitoring node has been directly targeted (cf. Table7.5), the detection time is shorter or equal, for example when the attacker is located at node v 3 and node v 1 is targeted, the detection time is 2 min 21 s while it is 2 min 25 s for node v 2 and 2 min 23 s for node v 11 . When a monitoring node is targeted the overhearing mode is useless because the attack packets are directly addressed to this node. A lesser or

	Table 7.4: Neighborhood of the dierent monitoring nodes
	Monitoring nodes	v 1	v 2	v 8	v 11

Table 7 .

 7 Node Placement Selection. Since the version number attack detection module depends on the coverage of regular nodes by monitoring nodes, we dened the following metrics: (i) Cov i representing the percentage of regular nodes covered by exactly i monitoring nodes (i ∈ [1, M ], M is the number of monitoring nodes); (ii) Ca i representing the percentage of regular nodes covered by at least i monitoring nodes, e.g. Ca 2 = Cov 2 + Cov 3 + Cov 4 for M = 4. In all cases, we target Ca 1 equals to 100% because all regular nodes should be covered by at least one monitoring node since the architecture is able to monitor all regular nodes. Ca 2 is also an important parameter for selecting the congurations to be considered, because the number of false positives depends on the monitoring node neighborhood overlapping. Therefore, monitoring nodes congurations have been selected for different Ca 2 values in order to quantify the impact of this metric on the number of false positives. 6: Number of possible congurations for 4 monitoring nodes ranked by increasing Ca 2 .Five dierent Ca 2 values have been chosen including the lowest and the highest possible values (corresponding to worst and best cases) for 4 and 5 monitoring nodes in the considered topology. The minimal number of required monitoring nodes is 4 so that Ca 1 equals to 100%. This value is given by the resolution of an Integer Linear Program (ILP) with our grid topology under the constraint that the sink, v 1 , is a monitoring node. The rest of the monitoring nodes are chosen among all the other nodes. For 4 monitoring nodes, the number of possible congurations so Ca 1 = 100% is 24 as described in Table7.6. This result has been obtained from a program that 7.3. Detection Modules Evaluation 107 computes all correct congurations. A particular Ca 2 value corresponds to several combination of Cov i . Table7.7 shows the dierent conguration possibilities for selected values of Ca 2 . One representative of each conguration possibility has been run. For instance, we can observe in Table7.6 that for Ca 2 = 12.5% there are 3 possible monitoring node congurations, while, in Table7.7 only one conguration with Ca 2 = 12.5% is available. This is because the three possible congurations for Ca 2 = 12.5% have the same Cov i combination.

	Ca 2 (%) Number of congurations
	0	2
	6.25	0
	12.5	3
	18.75%	5
	25	2
	31.25	6
	37.5	3
	43.75	3

Table 7 .

 7 7: Dierent congurations of Cov i for 4 monitoring nodes ranked by increasing Ca 2 .We have also selected congurations with 5 monitoring nodes because the obtained Ca 2 values allow us to have zero false positive as illustrated by Figure7.12.For 5 monitoring nodes, 427 congurations can be run. As for 4 monitoring nodes, we have selected 5 Ca 2 values including the lowest and the highest values (13.33%, 26.67%, 46.67%, 60% and 66.67%). Among the possible congurations for these Ca 2 values, we have simulated 26 congurations, each one being a representative of dierent Cov i combinations as detailed in Table7.8.

	Ca 2 (%) Cov 2 (%) Cov 3 (%) Cov 4 (%)
	0	0	0	0
	12.5	12.5	0	0
	25	25	0	0
	25	18.75	6.25	0
	37.5	37.5	0	0
	43.75	37.5	6.25	0
	43.75	31.25	12.5	0

Table 7 .

 7 8: Dierent congurations of Cov i for 5 monitoring nodes ranked by increasing Ca 2 . Ca 2 (%) Cov 2 (%) Cov 3 (%) Cov 4 (%) Cov 5 (%)

	13.33	13.33	0	0	0
	13.33	0	13.33	0	0
	26.67	26.67	0	0	0
	26.67	20	6.67	0	0
	26.67	13.33	13.34	0	0
	26.67	13.33	6.67	6.67	0
	26.67	6.67	20	0	0
	46.67	46.67	0	0	0
	46.67	40	6.67	0	0
	46.67	33.33	13.34	0	0
	46.67	33.33	6.67	6.67	0
	46.67	26.67	20	0	0
	46.67	20	26.67	0	0
	60	60	0	0	0
	60	53.33	6.67	0	0
	60	53.33	0	6.67	0
	60	46.67	13.33	0	0
	60	46.67	6.67	6.66	0
	60	40	20	0	0
	60	40	13.33	6.67	0
	60	40	6.67	13.33	0
	60	33.33	26.67	0	0
	66.67	60	6.67	0	0
	66.67	60	0	6.67	0
	66.67	53.33	13.34	0	0
	66.67	53.33	6.67	6.67	0
	monitoring nodes could have exonerated it. This is also the case for other positions
	of the attacker. However, attack relays were not considered as malicious each time.

Table 7 .

 7 Ca 1 = 100% (seeChapter 6); it is also possible to represent with an optimization model the problem of having at least C% of regular nodes covered by at least two monitoring nodes, i.e. Ca 2 ≥ C% while Ca 1 = 100%. This constraint is transformed into having at most (100 -C)% of regular nodes covered by exactly one monitoring node, i.e. Cov 1 < (100-C )% while Ca 1 = 100%. The problem 10: Required inputs for monitoring node placement.

	7.4. Scalability Evaluation

Table 7 .

 7 11: Considered variables for modeling.

	Domain	Variable Description
	1, N	Y	Binary variable indicating whether Y i is a monitoring node (= 1) or not
	1, N × 1, N	W	Binary variable indicating if node v i is covered by a monitoring node v j
	1, N	Z	Binary variable indicating if v i is monitored by exactly one monitoring node (= 1) or not

  7.5Energy consumed by the overhearing mode while varying neighborhood size for one hour. . . . . . . . . . . . . . . . . . . . . . . . . . . False positive rates for dierent location of attacker when conguration is the topology of Fig. 7.9. . . . . . . . . . . . . . . . . . . . . . 7.11 Average false positive rate for dierent Ca 2 values with 4 monitoring nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.12 Average false positive rate for dierent Ca 2 values with 5 monitoring nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.13 Number of monitoring nodes required to have Ca 1 = 100%, Ca 2 ≥ 60% and Ca 2 = 100% for dierent topology sizes . . . . . . . . . . . 1 Taxonomie des attaques contre les réseaux RPL . . . . . . . . . . . . .10 Required inputs for monitoring node placement. . . . . . . . . . . . 111 7.11 Considered variables for modeling. . . . . . . . . . . . . . . . . . . . 111 (i.e. vers la racine) sont construites. Pour établir les routes descendantes, un n÷ud doit envoyer un message DAO à son parent contenant le préxe des n÷uds situés dans son sous-DODAG. Lorsque le message se propage vers le haut, les préxes sont agrégés et les routes descendantes deviennent disponibles pour les parents. Mécanismes de protection existants. RPL intègre diérents mécanismes an d'éviter les boucles, détecter les incohérences et réparer le graphe. Le rang joue un rôle important pour construire une topologie sans boucle. En eet, un n÷ud ne peut choisir qu'un parent dont le rang est inférieur au sien, autrement dit tous les n÷uds se trouvant dans le sous-DODAG d'un n÷ud ont un rang supérieur à ce n÷ud. Si un n÷ud ne respecte pas cette propriété du rang, le graphe n'est plus acyclique. De plus, an d'éviter les boucles, si un n÷ud doit changer son rang, il doit utiliser un mécanisme de poisoning (en annonçant un rang inni) ou de déconnexion ( en formant un DODAG temporaire). Dans les cas où des boucles apparaissent dans le graphe, le protocole RPL fournit une fonctionnalité appelée validation du chemin de données 18 . Des informations de contrôle sont transportées dans les paquets de données via des ags placés dans l'en-tête d'extension IPv6 Hop-By-Hop:

	130 2. Protocole de routage RPL	Résumé de la thèse en français 131
	mitigation locaux pour l'attaque d'incohérence DAG. Nous présentons ensuite une ar-les routes ascendantes
		chitecture de supervision orientée sécurité dans la section 6 ainsi que des algorithmes
	7.6	Scenario used to perform the DAG inconsistency attack. . . . . . . . de détection conçus pour les deux attaques précédemment étudiées. Nous évaluons
	7.7	Detection time of the DAG inconsistency attack for dierent location cette architecture dans la section 7 avant de conclure cette thèse en section 8.
		of attacker. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
	7.8 7.9 7.10 Résumé de la thèse en français Per node outgoing packet overhead, for every location of the attacker when no mitigation and dynamic mitigation is deployed on monitoring nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Grid topology of 20 nodes used to perform version number attacks. . 2 Protocole de routage RPL Le protocole RPL est un protocole de routage à vecteur de distance utilisant IPv6, spécialement conçu par l'IETF pour répondre aux besoins des réseaux LLN. Cette
	section présente le fonctionnement de ce protocole et les mécanismes de protection Supervision et Sécurité pour l'Internet des existants.
	Ob jets utilisant le protocole de routage RPL
	Topologie, instance et fonction objectif. Les n÷uds RPL s'interconnectent en 1 Introduction formant une topologie spécique appelée DODAG 17 , c'est-à -dire un graphe acyclique
		Plus particulièrement, trois nouveaux messages sont dénis: (1) DODAG Informa-
		tion Solicitation (DIS), (2) DODAG Information Object (DIO) et (3) Destination Ad-
		vertisement Object (DAO). Un nouveau n÷ud peut rejoindre un réseau déjà formé en
		diusant un message DIS pour solliciter en réponse un message DIO qui contient des
		informations sur le DODAG comme le numéro de version et l'identiant du DODAG,
		l'identiant de l'instance et l'OF utilisée. Un n÷ud peut également attendre de re-
		cevoir un message DIO diusé périodiquement par ses voisins. La fréquence d'envoi
		des messages DIO est déterminée par un temporisateur fondé sur l'algorithme Trickle
	Ces solutions se doivent d'exploiter les fonctionnalités du protocole RPL et les par-(appelé également temporisateur Trickle). À la moindre anomalie dans le réseau, le
	ticularités de l'IdO comme l'hétérogénéité des n÷uds pour préserver au mieux des temporisateur Trickle est réinitialisé pour permettre à la topologie de reconverger
	ressources déjà fortement contraintes. Nous évaluerons également l'ecacité et le plus rapidement.
	coût des solutions proposées. Après avoir reçu un message DIO, le n÷ud calcule son rang en utilisant l'OF
	Les travaux de cette thèse sont organisés comme suit. La section 2 présente spéciée dans ce message. Le rang d'un n÷ud correspond à son emplacement dans le
	succinctement le protocole de routage RPL. Nous proposons une taxonomie des at-graphe par rapport à la racine. La valeur du rang augmente toujours en descendant
	taques visant ce protocole dans la section 3. La section 4 analyse en détail diérentes dans le graphe. C'est donc la racine qui a le rang le plus petit dans le graphe.
	attaques identiées dans la section précédente à savoir l'attaque d'incohérence DAG Si un n÷ud reçoit des DIOs de voisins diérents, l'émetteur avec le meilleur rang
	et l'attaque sur le numéro de version. La section 5 montre plusieurs mécanismes de (le plus petit donc) est choisi comme le parent préféré vers lequel seront envoyés
	16 Routing Protocol for LLNs 15 Low power and Lossy Networks tous les messages à destination de la racine. À la n de ce processus seulement
		129

2 Nombre de messages de contrôle envoyé par n÷ud sous diérents scenarios d'attaque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Nombre total de boucles par n÷ud pour chaque position de l'attaquant.134 4 Nombre de messages de contrôle total envoyés par le réseau quand la mitigation par seuil xe et celle par seuil adaptatif sont déployées. . 5 Nombre de messages de contrôle total envoyés par le réseau quand la mitigation par seuil xe et celle par seuil dynamique sont déployées. 6 Temps de détection par n÷ud de surveillance pour diérentes positions de l'attaquant. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Taux de faux positifs moyen pour diérentes valeurs de Ca 2 avec 5 n÷uds de supervision. . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Nombre de n÷uds de supervision nécessaires pour obtenir diérentes valeurs de Ca pour plusieurs tailles de topologie. . . . . . . . . . . . 128 List of Tables 7L'Internet des Objets (IdO) se traduit par le déploiement de réseaux avec pertes et à faible puissance appelés réseaux LLN 15 . Ces réseaux permettent à de nombreux équipements embarqués comme des sondes ou des capteurs de pouvoir communiquer entre eux. Un protocole de routage appelé RPL 16 a été spécialement conçu par l'IETF pour répondre aux contraintes spéciques qu'impose ce type de réseaux. Cependant, ce protocole reste exposé à de nombreuses attaques de sécurité. Si des mécanismes de protection existent, leur mise en ÷uvre est coûteuse c'est pourquoi notre objectif dans cette thèse est de proposer des stratégies de supervision de la sécurité ecaces qui consomment peu de ressources. Ces solutions doivent être capable de détecter des comportements malveillants de n÷uds dans le réseau an d'en limiter les eets. Dans un premier temps, nous nous intéresserons à l'évaluation de la sécurité dans les réseaux RPL en identiant et caractérisant les diérentes menaces auxquelles sont soumis ces types de réseaux. Nous classerons également ces menaces selon plusieurs critères an de mettre en avant celles à traiter en priorité. Grâce à cette évaluation, nous allons dans un second temps concevoir des solutions de supervision de sécurité qui minimisent la consommation des n÷uds du réseau pour les attaques identiées. orienté dirigé vers une destination qui est la racine du réseau. Un réseau RPL contient au moins une instance RPL qui elle-même se compose d'un ou plusieurs DODAGs. Chaque instance RPL est associée à une fonction objectif (OF) qui permet d'optimiser la topologie en fonction d'un ensemble de contraintes et/ou de métriques comme la préservation de l'énergie, le chemin le plus court ou la qualité des liens. Un n÷ud peut faire partie d'un seul DODAG par instance, mais peut participer à plusieurs instances simultanément. Messages de contrôle et construction du DODAG. La construction et la maintenance des DODAGs sont réalisées grâce à des messages de contrôle ICMPv6.

  Le travail réalisé durant cette thèse ouvre de nombreuses perspectives dans le cadre de la supervision de sécurité dans l'Internet des Objets. Premièrement, nous nous intéressons à poursuivre nos expériences dans des environnements réels et aussi à porter l'implémentation de notre stratégie à d'autres OS qui se sont développés au cours de cette thèse comme RIOT ou OpenWSN. Nous voulons aussi étendre notre étude à de nouveaux scenarios d'attaques, notamment le cas de coalition d'attaquants mais aussi considérer d'autres attaques abordées dans notre taxonomie et même des attaques visant d'autres protocoles de la pile réseau. À long terme, nous envisageons d'intégrer notre solution au sein d'un framework de gestion de risque. La gestion de risque ore de nouvelles perspectives pour activer ou désactiver dynamiquement des mécanismes de sécurité dans les réseaux RPL an de prévenir et limiter des attaques tout en préservant les ressources du réseau. 'intérêt grandissant pour l'Internet des Objets s'est traduit par le déploiement à grande échelle de réseaux dits à basse puissance et avec pertes (LLN). Ces réseaux sont fortement contraints en matière de ressources (mémoire, CPU, batterie) et communiquent via des liens instables, à bas débit avec de forts taux d'erreur. Dans ce contexte, les protocoles de routages existants pour les réseaux laires et pour les réseaux ad-hoc ne sont pas adaptés pour ces caractéristiques. Le groupe de travail RoLL à l'IETF a proposé un nouveau protocole de routage appelé RPL fondé sur IPv6 et spéciquement conçu pour ces environnements. Cependant, le protocole RPL est exposé à de nombreuses attaques internes et/ou externes comme les attaques consommant les ressources ou les attaques d'interception de trac. La mise en place de mécanismes de sécurité peut aussi représenter un coût considérable. C'est pourquoi, les réseaux LLN introduisent de nouveaux enjeux quant à leur supervision et leur sécurité. Dans le cadre de cette thèse, nous proposons d'étudier une approche de supervision pour la sécurité de l'Internet des Objets an de répondre au compromis entre sécurité et coût dans l'Internet des Objets. Nous évaluons tout d'abord les menaces auxquelles sont soumis les réseaux RPL. En particulier, nous identions et classions les attaques visant le protocole RPL au travers d'une taxonomie. Nous quantions également les conséquences de deux attaques appelées l'attaque d'incohérence DAG et l'attaque du numéro de version qui provoquent la surconsommation des ressources des n÷uds du réseau. Les résultats obtenus montrent l'importance de gérer ces attaques pour préserver les infrastructures de l'Internet des Objets. Nous nous concentrons ensuite sur les solutions pour la sécurité dans les réseaux RPL. Nous proposons une stratégie locale qui détecte et limite les attaques d'incohérences DAG. Dans le but de détecter des attaques complexes comme les attaques sur le numéro de version et de compléter notre approche locale, nous présentons une architecture de supervision distribuée orientée sécurité pour les réseaux RPL. Cette solution nous permet de préserver l'énergie des n÷uds contraints en eectuant les activités de surveillance et de détection sur des n÷uds dédiés. Nous montrons la faisabilité de notre approche en implantant une preuve de concept capable de détecter les attaques d'incohérence DAG et les attaques sur le numéro de version. Nous quantions ensuite les performances de cette architecture ainsi que la stratégie de détection proposée.

	Résumé / Abstract

L

Mots-clés: Internet des Objets, LLN, RPL, Sécurité, Supervision

http://www.zigbee.org/

http://www.z-wave.com/modules/ZwaveStart/

congurations from Tables 7.7 and 7.8.

Remerciements

Local No Poller/Pollee Data rep. Yes No Local + Global Yes Hybrid SVELTE Yes Yes Yes Local + Global Yes Spec. based IDS Maybe LiveNet No No No Global Maybe Decentralized PMSW No No No Local + Global Maybe Pimoto No No No Local + Global Maybe EPMost No No No Local + Global Maybe Watchdog No Yes No Local Maybe

Chapter 5. Local Strategy for Addressing DAG Inconsistency Attack

To counter the packet manipulation DAG inconsistency attack, an extension was made to the adaptive threshold. Nodes behave normally until the number of messages indicating an inconsistency becomes greater than the threshold obtained from Equation 5.1 and this threshold reaches the α value. This situation indicates either an attack against the node, or a malfunction of the node forwarding such packets.

To rectify the situation, the node clears the `O' and `R' ags before forwarding the packets normally. The complete packet manipulation mitigation strategy, combined with the adaptive threshold mitigation approach, can be seen in Algorithm 2. The complexity of this algorithm depends on the complexity of the exponential function used to compute the threshold. Section 5.3.4.1 will discuss the cost of the proposed algorithm. Since no additional resources are used by this approach, the cost of protecting the network against black-hole scenarios is quite low.

Algorithm 2 Adaptive DAG inconsistency mitigation of a node.

if (O = 1 and r i < r j ) or (O = 0 and r i > r j ) then if R = 1 then if count R < λ(r) then

end if end if end if

The adaptive threshold approach relies on set parameters, which need to be chosen in the implementation. This can lead to sub-optimal optimizations and so we have improved our mitigation approach via the design of a fully dynamic threshold, which is based on network characteristics.

Dynamic Mitigation

We have designed the dynamic threshold (DT) in order to avoid using pre-congured parameters while beneting from advantage of the adaptive threshold. The new dynamic threshold λ(r) used to determine whether the trickle timer should be reset is: most aggressive (3200 attacks per hour) the curves become closer. This is because, in case of aggressive attacks the threshold is computed more often, leading to a higher energy cost. For all attack patterns, the dynamic algorithm has better results than the adaptive threshold as observed in the lower part of Figure 5.14. In fact, the dynamic threshold approach can provide nearly 50% energy savings in certain attack scenarios.

Conclusions

While the RPL protocol provides a xed threshold based approach as an option to mitigate the DAG inconsistency attack, the value of the threshold is arbitrarily chosen and can be improved by taking into account network characteristics. Towards this goal, we have rst designed an adaptive mechanism that mimics the xed threshold when there is no attack. This approach has been improved by a fully dynamic solution. Both of these approaches have been evaluated in our analysis and they have both outperformed the xed threshold. In particular, the overhead can be reduced between 20%-50% and in case of packet manipulation scenarios, which are not mitigated by the default RPL approach, our method can improve the delivery ratio to 99% as against 33% for the default RPL mitigation approach. We have discussed the conguration parameters impact. We have concluded that we should remain cautious for the γ parameter in the adaptive threshold in order to repair genuine loops and that the dynamic approach still outperforms the default mitigation even with large size of neighborhood. We have performed a cost analysis of our proposed strategy and we have showed that energy savings of up to 50% can be obtained. Due to the drawback of picking pre-deployment constants that need to be determined empirically for the adaptive approach, the dynamic approach is recommended since 5.4. Conclusions 77 it derives all parameters from the network neighborhood size. The performance of our two approaches is quite similar in case of aggressive attacks. However, in all other scenarios the dynamic threshold has outperformed the adaptive threshold. We therefore recommend the dynamic threshold for use.

We have proposed a node-level solution to counteract the DAG inconsistency attack. We can note that specic attack patterns such as the version number attack cannot be addressed by such a node-based approach because the attack is propagated through the entire network making it impossible to detect in a node-level perspective.

In that context, we propose in the next chapter of this thesis to complement this approach through a distributed security-oriented monitoring architecture for RPLbased IoT environments able to address these cases.

Introduction

We have previously proposed a node-level mitigation approach to address the DAG inconsistency attack. While we have demonstrated that the cost of this solution was reasonable, in some cases, attacks, such as the version number attack, have specic characteristics such that similar local-node methods cannot be ecient nor feasible in that context. We therefore propose to extend our solution to these cases with a passive distributed monitoring architecture designed for security. The originality of our approach comes in particular from the fact that the architecture exploits the RPL protocol to eciently organize monitoring nodes. Node-level security strategy and distributed strategy are complementary according to network characteristics. Indeed, on one hand, the distributed strategy allows providing a global view and raising alarms to a network administrator, while, on the other hand, the node-level strategy permits to limit the impact of ongoing attacks. Thanks to this architecture, we can also handle cases where specic code, such as the node-level mitigation, cannot be deployed on nodes (no physical access, proprietary motes, no more capacity, etc.).

DAG Inconsistency Attack

The DAG inconsistency attack exploits the data path validation feature of RPL which is used to avoid and detect possible loops within the network. We have previously proposed a mitigation strategy deployed on each regular node in the network to counter such threats. When specic code cannot be deployed on regular nodes and/or when a global view is needed, we want to exploit our designed architecture to perform the security strategy using distributed detection algorithms. In order to detect such an attack, the promiscuous mode has to be enabled on monitoring nodes since it targets data trac. In our architecture each monitoring node implements Algorithm 4 to identify this type of anomaly. Algorithm 4

In Algorithm 4, R_ag represents the rank error ag in data packets. A monitoring node v k tracks for each neighbor v i ∈ N v k the number of rank error ags count_R i they have set. If this counter reaches the threshold value then the monitoring node has to check if v i is the only node which has sent such packets. In this case, the 'R' ag packets are not originated from a legitimate loop and the anomaly is detected. The dierent count_R i values are reset every hour in order to allow nodes to send legitimate 'R' ag packets.The threshold value has to be chosen carefully because it limits the number of 'R' ag packets a node can send, legitimately or not.

We have adopted a xed threshold in this approach such as the default mitigation presented in Chapter 5 for three reasons. First, it allows us to test easily the ability of our architecture and our algorithm to detect the DAG inconsistency attack.

Second, the varying thresholds (adaptive and dynamic thresholds) as presented in Chapter 5 cannot be used in this context because they were designed for a local-node detection, as such, the chosen parameters depending on node-level information are Chapter 8. General Conclusions and detection algorithms could be adapted accordingly. Also all of our experiments were run using the Contiki OS. At the beginning of this thesis, it was the most complete project that implemented the RPL protocol and was widely used in research area. However, this operating system presents some drawbacks, for instance, the lack of documentation and issues related to coding as pointed out in [START_REF] Roussel | A critical analysis of Contiki's network stack for integrating new MAC protocols[END_REF][START_REF] Roussel | Lessons Learned through Implementation and Performance Comparison of Two MAC/RDC Protocols on Dierent WSN OS[END_REF] and that we have encountered regarding the multi-instance mechanism. Also, since then, new projects have been developed and are beginning to be really popular. This is especially the case for the RIOT OS [5] and the OpenWSN project [4]. These OS open new perspectives to deploy and test our security strategy for RPL networks.

Extension to New Attacks

We are also planning to enhance our solution by considering new attack scenarios. First, our detection strategy could be adapted to counter attacker coalition by rening the proposed algorithms since we have considered during our analysis that only one attacker was performing attacks at a time. An attacker coalition is characterized by several malicious nodes involved at the same time in the network. Also, the dierent implemented solutions could be optimized for better performance and for resource saving. For instance, the overhearing mode of monitoring nodes known to be resource consuming which we have used to detect the DAG inconsistency attack could be dynamically enabled by taking into account network events.

As future work, it can additionally be envisioned to extend our study to new attacks from our established taxonomy, not only those which target node resources but also topology and trac related threats. We can note that more and more analysis regarding attacks targeting the RPL protocol are performed in the literature which can facilitate the extension of this work. Indeed, at the beginning of this thesis only few studies regarding security in RPL networks were available. Not only our work can be expanded by considering other attacks targeting the RPL protocol but it can also be enhanced by considering attacks targeting other protocols in the network stack. Several existing works can be exploited for this purpose such as [START_REF] Le | 6LoWPAN: a study on QoS security threats and countermeasures using intrusion detection system approach[END_REF] and [START_REF] Pongle | A survey: Attacks on RPL and 6LoWPAN in IoT[END_REF] which focused on 6LoWPAN protocol security.

Risk Management Framework

Risk management oers new perspectives to dynamically activating or deactivating security mechanisms in RPL-based networks, in order to prevent and limit attacks while maintaining network performances. We therefore envisage to improve our framework by considering these methods. The risk management process is composed of two main activities: risk assessment and risk treatment. Risk assessment consists in quantifying the potentiality of attacks through detection methods. Risk assessment aims also at quantifying the consequences of successful attacks. The objective is to assess the relative importance of nodes in the RPL network, and to analyze how the attack against a given node may impact on the functioning of the overall network.

The risk treatment activity consists then in selecting and applying the required se-8.2. Perspectives 119 curity mechanisms while keeping in mind the cost of the solution. In this thesis, we can notice that we have performed some steps in this direction, especially regarding the risk assessment process since we have classied attacks in a taxonomy, quantied the impact of two attacks and designed a detection strategy relying on a monitoring architecture. We have also proposed countermeasures related to the risk treatment process. Risk management methods and algorithms could support the selection and activation of these dierent countermeasures within our monitoring architecture.

Publications

Publications