A Distributed Monitoring Strategy for Detecting Version Number Attacks in RPL-based Networks

Transcription

1 1 A Distributed Monitoring Strategy for Detecting Version Number Attacks in RPL-based Networks Anthéa Mayzaud, Rémi Badonnel, Isabelle Chrisment LORIA - INRIA Grand Est Université de Lorraine, Nancy, France {anthea.mayzaud,remi.badonnel,isabelle.chrisment}@loria.fr Abstract The Internet of Things is characterized by the largescale deployment of Low power and Lossy Networks (LLN), interconnecting pervasive objects. The RPL protocol has been standardized by IETF to enable a lightweight and robust routing in these constrained networks. A versioning mechanism is incorporated into RPL in order to maintain an optimized topology. However, an attacker can exploit this mechanism to significantly damage the network and reduce its lifetime. After analyzing and comparing existing work, we propose in this paper a monitoring strategy with dedicated algorithms for detecting such attacks and identifying the involved malicious nodes. The performance of this solution is evaluated through extensive experiments, and its scalability is quantified with the support of a monitoring node placement optimization method. Index Terms Security Management, Internet of Things, RPL. I. INTRODUCTION The growing interest for the Internet of Things has resulted in the large-scale deployment of Low power and Lossy Networks [1]. They enable new applications ranging from smart electricity grids [2] to home automation solutions [3] [4]. The constrained devices composing these networks can be integrated with the existing Internet infrastructure, so that they exploit software services already available coupled in conjunction with their control and data gathering capabilities. They constitute however an attractive target for many security attacks. The limited capacity of these devices make traditional security mechanisms difficult to implement. Many deployments make them directly or wirelessly accessible, allowing potential physical and eavesdropping attacks. Also, 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. The recent DDoS (Distributed Denial of Service) attack against the DYN DNS service occurred in October 2016 is an illustrative example of how Internet of Things devices may serve as a vector of attacks, through their exploitation to build a botnet and flood a given service. The Routing Protocol for Low-power and Lossy Networks (RPL) was designed by the IETF RoLL working group to cope with resource constraints of embedded devices in these networks [5]. This protocol organizes nodes into DODAGs (Destination Oriented Directed Acyclic Graphs) and is capable of optimizing the topology for application specific objectives, e.g. energy conservation, by using metrics and/or constraints available to a device. An RPL instance is a set of DODAGs, each with a specific objective function. Several RPL instances can be run within a network. A node can only join a single DODAG in one instance, however it can be part of several DODAGs only if they are in different instances. A node rank value represents its position with respect to the DODAG root. This value always increases in the downward direction. To avoid rebuilding the entire DODAG when a parent node disappears, two local repair mechanisms are introduced by the protocol. The first one allows nodes to temporarily route through neighbors of the same rank, while the other one consists in using an alternative parent. It also provides a global repair feature to rebuild completely the DODAG. The mechanisms that enable RPL to provide this level of flexibility could also be manipulated by malicious nodes to harm the network. In particular, the version number attack can misuse a RPL feature which is normally used for ensuring a loop and error free topology. A malicious node modifies 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. A forced rebuild can cause increased overhead, depletion of energy reserves, channel availability issues and even loops in the routing topology. Previous studies show that such attacks have a significant impact on RPL networks and highlight the importance of addressing them [6], [7]. We propose a strategy based on a distributed monitoring architecture to detect version number attacks in RPL-based environments and to identify the involved malicious nodes. This paper is an extended version of work published in [8]. Our solution consists in outsourcing the detection activities to high order nodes dedicated to monitoring the network passively. This allows to reduce the impact on the other network nodes whose resources are typically scarced. Our main contributions are (1) the analysis and comparison of monitoring solutions for supporting IoT security, (2) the design of a monitoring strategy for detecting version number attacks and its associated algorithms, (3) the deployment and instantiation of the strategy using a distributed and passive monitoring architecture, (4) the performance evaluation of our solution through extensive experiments and (5) the quantification of the proposed solution scalability in accordance with a placement methodology for monitoring nodes.

2 2 Such an outsourcing strategy only makes sense in IoT infrastructure deployments with high-order resourceful devices. In particular, we consider in our work the practical case of Advanced Measurement Infrastructures (AMI) [9]. These networks are usually divided into two tiers, i.e., the Neighborhood Area Network (NAN) and the Wide Area Network (WAN). The NAN consists of the smart meters that are deployed at residential premises, commercial and industrial buildings, and electricity transformer and feeder points in a specific neighborhood. These smart meters typically communicate by forming an IEEE 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 collected. Unlike the NAN tier, systems in the WAN tier communicate using high-speed wireless or fixed-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 field routers have two interfaces, one that allows it to communicate with the low-power lossy network (typically IEEE ) on the NAN side and another one that provides access to the high-speed wireless or fixed-line networks on the WAN side. It is also possible for these field routers to participate in a NAN-to-NAN mesh, such that the final interconnection of smart meters with head end systems occurs only via the low-power lossy communication channel. The rest of the paper is organized as follows. Section II presents the issue of version number attacks in RPL networks. Section III gives an overview of related work on IoT monitoring architectures. Our distributed monitoring strategy for detecting these attacks is detailed in Section IV. The solution performance is analyzed in Section V, and a scalability evaluation is discussed in Section VI. Finally, Section VII concludes the paper and points out future perspectives. II. VERSION NUMBER ATTACKS IN RPL NETWORKS The RPL protocol is exposed to a large variety of attacks, which can be classified into three main categories. The first 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 traffic, such as eavesdropping attacks or misappropriation attacks. Version number attacks belong to the first category and may significantly reduce the lifetime of an IoT network. They can be performed with a minimal cost for the attacker, and exploit the global repair mechanism to overload the network, which can be seen as part of the immune system of the protocol. The root initiates a global repair, when too many inconsistencies are detected in the network. It consists in rebuilding the Fig. 1. Illustration of a version number attack. The incremented version number initiated by the malicious node v 5 (initial malicious broadcast plotted in red) is automatically propagated by legitimate network nodes (broadcast by relay nodes plotted in purple). entire DODAG by incrementing the version number of the DODAG [5]. This number is carried in a type of control messages called DODAG Information Object (DIO). Each receiving node compares its existing version number against the one received from its parent. When the received version is higher, it must ignore its current rank information, reset trickle timers and initiate a new procedure to join the DODAG. This global repair mechanism guarantees a loop free topology, but is also quite costly. An older value of the version advertised in DIO messages indicates that the node did not migrate to the new version of the DODAG. Such a node should not be chosen as preferred parent by other nodes. Two versions of a DODAG can exist at the same time during a global repair. However, in order to avoid loops, data packets from the old version are allowed to transit in the new version but not the other way. As the convergence of the network has not been reached, the old version is no longer a DODAG and loop free topologies cannot be guaranteed in this situation. To avoid possible inconsistencies in the network, the version number should be propagated unchanged through the DODAG. However, there is no mechanism in RPL to ensure the integrity of the version number provided in received DIO messages. A malicious node may change this value in its own DIO messages to harm the network. Upon receiving a malicious DIO with a new version number, nodes reset their trickle timer, update the version and advertise this new version through DIO messages to their neighborhood as well. This typically results in the propagation of the illegitimate version number through the network (see Figure 1). Such manipulation of the version number in the DIO packets causes both an unnecessary rebuilding of the whole DODAG, and the generation of loops in the topology: since the new version of the DODAG is not built from the root, the topology is no longer acyclic, allowing loops to occur. This can negatively impact energy resources of the nodes, routing of data packets and channel availability. The pattern of this attack makes it difficult for a node to detect it locally. Indeed a malicious DIO packet coming from a parent

3 3 Fig. 2. Classification of IoT monitoring architectures. seems to be legitimate for a node. When it comes from a child, then the node can consider this as due to an inconsistency in the network. Also localization of the malicious DIO source is impossible in a purely local point of view, as nodes have only a view of their neighbors. They need to communicate with each other in order to find the origin of the attack. Version number attacks have already been analyzed in our previous studies such as [6] and [7]. We have shown that this type of attacks has severe consequences for RPL network causing significant control message overhead and building loops in the network, which leads to a reduced lifetime for the network and the loss of data packets. Since many loops are built, the end-to-end delivery ratio decreases also. Authors of [7] have proposed to investigate these attacks under mobility with a probabilistic attacker model. They have also analyzed the impact of these attacks on node energy consumption and show that the batteries of the nodes were severely reduced by the attack. These analyses have confirmed the need for detecting and remediating these attacks. III. RELATED WORK ON IOT MONITORING ARCHITECTURES Monitoring the Internet of Things is a major challenge for detecting security attacks, such as version number attacks, while the resources of network devices are often limited. Traditional monitoring architectures require to be adapted, or new strategies have to be considered in order to cope with the requirements of these networks. Since the IoT paradigm is quite recent, few approaches are specifically dedicated to them, and in particular with respect to the RPL protocol. Most of the existing monitoring solutions are inherited from the wireless sensor networks (WSNs) and the mobile ad hoc networks (MANETs) areas. Some of them also include frameworks that have been specifically designed for security purposes. Existing monitoring architectures may be classified, as presented in Figure 2, into two main categories, that we called respectively active and passive solutions depending on the participation of target nodes in the monitoring tasks. In the following, target nodes and target networks refer to nodes (respectively networks) to be monitored. A. Active Monitoring We consider here as active monitoring a solution that requires target nodes to perform monitoring tasks, for instance send or forward specific traffic 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. 1) Centralized Approaches: Centralized approaches consist in solutions with a central manager. Monitoring agents are deployed on each node and have to collect, store information about the device and send collected data over the network to a global manager. This manager 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 first include in this category traditional management protocols, such as SNMP [10] and NETCONF [11] with their adaptation to resource constrained environments. SNMP permits to monitor, control, and also configure network devices. Each managed device implements an agent responsible for collecting and transmitting data about the device organized in a specific standardized database. NETCONF is used to install, delete and change configuration 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 [12]. 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 [13]. The integration of SNMP agents with their management information base (MIB) on resource constrained

4 4 Fig. 3. DAMON monitoring architecture. Fig. 4. SVELTE monitoring architecture. devices may take away valuable resources. This is especially true on C0 and C1 devices [14], 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 [14]. Using the CoAP protocol [15] to perform network management and monitoring tasks can offer resource reduction since the protocol would be used by the application layer in most cases. As such, there are a few efforts 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 [16]. It utilizes also MIBs and does not rely on connection-oriented communications. Packets are encoded using the Concise Binary Object Representation (CBOR) format [17] which is similar to JSON but optimized for constrained devices. We can notice that theses solutions focus on configuration management and do not necessarily 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, a centralized manager may result in congestion of routes to the sink, and excessive load at the sink due to monitoring data. 2) Decentralized Approaches: Active decentralized approaches also typically rely on agents deployed on each node to collect and send monitoring data. However, other monitoring tasks (such as storing) 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 [18] propose a distributed monitoring solution, called Distributed Architecture for MONitoring mobile networks(damon), for mobile ad-hoc networks (based on the AODV routing protocol), composed of monitoring agents and data repositories storing monitored information, as illustrated by Figure 3. 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. A poller/pollee strategy is introduced in [19], [20] to collect and aggregate monitoring data from a sensor network in a lightweight manner. In particular, authors of [19] 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 defined time period. This can happen when pollees are too far away from the poller. An aggregation mechanism 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, Lahmadi et al. [20] minimize monitoring communication overhead by embedding these communications in data packets. This work is designed for RPL-based LLN 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. 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. 3) 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 solutions presented below are intrusion detection systems (IDS) and are therefore security oriented. The SVELTE framework [21] is specifically 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 minimalist distributed firewall. The approach is considered as hybrid, since lightweight modules are deployed on each node of the network, and modules

5 5 Fig. 5. Architecture of the specification-based IDS detailed in [23]. Fig. 6. EPMOSt monitoring architecture. responsible for heavy processing are run at the root, as described by Figure 4. This IDS aims at detecting sinkholes and selective forwarding attacks, and is robust to identity attacks. A specification-based solution is also described in [22], [23] to detect RPL topological attacks. A model is generated remotely by learning, based on analyzed traces. This one is then used to perform the detection of abnormal cases. Distributed super nodes implement the finite state machine which has been inferred. They are then deployed to monitor target nodes through requests, as illustrated by Figure 5. However, the super nodes do not participate in the target network. 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 impacts their resources. As such, passive monitoring which relies on dedicated probes may offer a relevant compromise to perform network monitoring while preserving node resources. B. Passive Monitoring We define as passive monitoring, architectures where dedicated monitoring nodes called sniffers are deployed in the target network. They collect information about network events and the target nodes, which are not instrumented. These solutions have been widely exploited in WSNs. As in the previous section, passive architectures are classified depending on they are centralized or decentralized. 1) Centralized Approaches: Passive centralized monitoring architectures correspond to solutions where deployed monitoring nodes collect information which are transmitted to a central sink performing the analysis and decision process. In particular, Khan et al. [24] introduce a troubleshooting suite, called Sensor Networks Troubleshooting Suite(SNTS), to facilitate the identification of anomalies in sensor applications. The solution uses dedicated extra nodes which passively listen to communications. The gathered information is then sent to the back-end part of the architecture, where data mining techniques are performed to automate analysis for troubleshooting. In the same manner, LiveNet [25] proposes to reconstruct the complex behavior of a deployed sensor network using multiple passive packet sniffers collocated with the network. Their work focuses on merging the monitoring traces obtained from the different sniffers, estimating the coverage of the monitoring nodes and deducing missing information. In these examples, data analysis is performed offline remotely by a dedicated entity. This allows running complex algorithms, however it may introduce considerable delays in detecting failures or abnormal activities. 2) Decentralized Approaches: In passive monitoring, decentralized architectures refer to approaches where the monitoring tasks (such as data aggregation and analysis, decision making process) are not only 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 sniffers, before forwarding them to a sink for further processing. Authors of [26] design a passive monitoring system, called Passive Monitoring System for WSNs (PMSW), composed of four types of nodes: sensor nodes, sniffing nodes, monitoring nodes and a workstation. Sniffing 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. On this one, the traces are merged using clock-adjusting strategies. The missing traces are inferred based on a finite state machine. Authors also exploit a set of event-based rule descriptions to perform fault diagnosis. In Pimoto [27], 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 sniffers 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 Energy-efficient Passive MOnitoring System (EPMOSt) [28], focuses on reducing energy consumption by passively monitoring WSNs. The monitoring information is provided using an SNMP agent. Sniffers are deployed in the target network, send their collected information to a local monitor node using a dedicated monitoring network, as presented

6 6 TABLE I COMPARISON OF MONITORING APPROACHES. Solutions Storing Pervasiveness Security Level of monitoring RPL Active Passive Centralized Decentralized Hybrid Centralized Decentralized SNMP Yes Yes No Global Possibly NetConf Yes Yes No Global Possibly CoMI Yes Yes No Global Yes DAMON Data rep. Yes No Local No Poller/Pollee Data rep. Yes No Local + Global Yes SVELTE Yes Yes Yes Local + Global Yes Spec. based IDS No Yes Yes Local Yes SNTS No No No Global Possibly LiveNet No No No Global Possibly PMSW No No No Local + Global Possibly Pimoto No No No Local + Global Possibly EPMost No No No Local + Global Possibly Watchdog No Yes No Local Possibly in Figure 6. The local monitor nodes store this data in a distant server which performs the analysis. A sniffer election is performed by sniffers together with the monitor nodes, in order to determine which target nodes are monitored by a given sniffer. While previous approaches rely on hierarchical architectures, the following solution use exclusively a local strategy to perform monitoring in WSNs. Authors of [29] propose also a self-monitoring approach relying 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 WSNs. 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 traffic 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 provide an overall view of the network. We can also observe that there are no direct interactions among the monitoring nodes which could perform a collaborative level of monitoring by crossing collected information. C. Comparison and Limits The detection of attacks against the RPL protocol, such as version number attacks, is particularly challenging due to the resource contraints of network nodes, and the inadequation of purely local monitoring in terms of performance. A specific solution against version number attacks, called Version Number and Rank Authentication (VeRA), enables preventing compromised nodes from impersonating the root and from sending an illegitimate increased version number [30]. It provides integrity of version numbers and ranks advertised in control messages via hash and signature operations. Such an approach is shown to be faulty by the authors of [31] and [32], and another mechanism called TRAIL that uses the root as a trust anchor and monotonically increases node ranks is also proposed by them. Both approaches require maintaining state information on nodes that is likely to reduce already constrained computing resources. New monitoring strategies are required to support the detection of attacks targeting the RPL networks in a lightweight manner. To provide security while being energy efficient for target nodes, we require a monitoring strategy for detecting version number attacks, that (i) does not require target nodes to be instrumented or to store their information; (ii) is pervasive; (iii) is designed for security; (iv) provides several level of monitoring; and (v) can be used in RPL environments. Table I permits to compare the previously mentioned approaches based on five criteria, in accordance with our security monitoring requirements. The first criterion entitled 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 criterion of the proposed solutions indicates whether nodes performing monitoring activities are involved in the target network activities. The security criterion shows whether the architecture has been specifically 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 when data is processed. The next criterion is the level of monitoring. Two values are possible regarding the considered architecture: local which means that the monitoring process is performed locally by monitoring nodes based on local data; and global which indicates that the monitoring process is performed considering all monitoring data from the network. Finally, the RPL criterion indicates whether the considered architecture is designed for or uses

7 7 the RPL protocol (Yes/No) or whether it could be adapted for the RPL protocol (Possibly). Based on this table, we can observe that, in active architectures, all the centralized solutions and the SVELTE framework require nodes to store their own monitoring information, while dedicated target nodes perform this task in the other decentralized approaches. On the contrary, the specifically deployed monitoring nodes in passive solutions are responsible for collecting monitoring information. We can also notice that all active monitoring architectures are pervasive, since they require target nodes to be instrumented. They are therefore involved in both monitoring and target network functioning activities. Except the watchdog strategy, monitoring nodes used in passive solutions do not contribute in the target network. The presented monitoring approaches are not designed for security purpose (except the two IDS), even if security related information could be inferred from the collected data. Centralized architectures (active and passive) only provide a global monitoring level, which may lack of reactivity in case of attacks, as all data are processed in a central entity remotely. Some architectures give only a local view of the network, which implies the possibility to miss major events. Other decentralized approaches have the capability to perform local and global level of monitoring. Except the DAMON architecture, which is based on the AODV protocol, other solutions have been designed for RPL networks, or could be adapted to them. All passive solutions from the WSNs can use this protocol, since their implementation does not rely on any particular routing protocol. Based on these criteria, we can conclude that none of the described architectures meet our aforementioned requirements regarding a security-oriented monitoring framework. Indeed, active solutions have to be excluded, since they require to instrument target nodes for collecting and storing (for most of them) monitoring information, which can take away precious resources on constrained devices. We therefore argue in favor of passive monitoring in RPL networks. However, in passive solutions, the deployed monitoring nodes (or sniffers) do not contribute to the target network at all. Deploying an architecture only dedicated to monitoring might represent a considerable cost for the operator. Even if most of these architectures provide local and global level of monitoring, we also want to support collaborative monitoring, and allow monitoring nodes to interact with each other, and get useful complementary information from neighbouring monitoring nodes. 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 efficient, while providing satisfying detection performances with respect to version number attacks. IV. DISTRIBUTED MONITORING STRATEGY FOR DETECTING VERSION NUMBER ATTACKS We present in this section our distributed monitoring strategy for detecting version number attacks and identifying their source in RPL networks. This strategy relies on a distributed monitoring architecture [9] on which we are deploying detection algorithms specifically designed for version number Fig. 7. Detection strategy based on our monitoring architecture. attacks. We first detail the architecture components, then describe the different algorithms that support this detection, and finally discuss monitoring node placement considerations. A. RPL-based Monitoring Architecture The strategy exploits a monitoring architecture that passively observes the network based on dedicated nodes in a distributed manner. This architecture uses RPL protocol mechanisms to perform monitoring and detection operations. Two types of nodes participating in the network compose this architecture depicted on Figure 7: monitored nodes, also called regular nodes (plotted in white), and monitoring nodes (plotted in blue) that implement the detection solution. The monitored nodes, noted V = {v i }, are highly constrained devices that are typical C0 or C1 devices [14]. Their function is to carry out their sensing or actuation tasks, and they constitute the so called regular network. The monitoring nodes (V = {v k }) are on the other side, higher order devices that are at least C2 or better [14]. Since they have higher capabilities, they can perform monitoring and detection activities without impacting their ability to route information in the regular network. They are able to intercept and analyze packets sent by regular nodes and record necessary information. A monitoring node v k can only monitor its neighborhood N v which is composed of k all nodes in its communication range. However, network-level monitoring information is necessary to follow the topology and detect inconsistencies in the network, such as maliciously incremented version number. As such, these monitoring nodes periodically forward the collected monitoring data towards the sink which can perform a distributed detection. In order to preserve regular node resources, the monitoring nodes form a second routing topology, called monitoring network, showed on the upper plane of Figure 7. This network has access strictly limited to monitoring nodes and is used to

8 8 Algorithm LOCAL ASSESSMENT potential att = NULL; for each DIO received by v k from v i N v k if (VN vi > VN v k potential att = v i send root(m k = (VN vi,v i,n v k )) end if end for do ) and (potential att == NULL) then Fig. 8. LOCAL ASSESSMENT algorithm implemented on monitoring nodes except the root. send collected information and results of detection algorithms. We exploit the multi-instance feature of RPL to build the two networks: one instance for the regular network, noted I R, and one for the monitoring network, noted I M. Figure 7 represents those two instances running at the same time. The two are completely independent which means that if the regular network breaks down at some point because of regular node failure or attacks, the monitoring network can still operate normally. B. Detection Algorithms We detail in this section the different algorithms used in our strategy for detecting version number attacks, considering that only one attacker is present in the network at a given time. Due to the fact that an incremented version number is propagated in the entire graph, a monitoring node cannot decide by itself if this is the result of an attack or not. The monitoring nodes must 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 network. Also, the monitoring nodes can track information regarding their neighborhood, so the regular nodes do not have to carry out this task. To detect an attack and identify malicious nodes, we propose detection and localization algorithms described in Figures 8, 9 and 10. The LOCAL ASSESSMENT algorithm presented in Figure 8 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. The algorithms presented by Figures 9 and 10 are implemented on the root node. The first one detects the attack and gather all monitoring node information into tables. The last algorithm performs the attacker identification by analyzing the collected information. In the LOCAL ASSESSMENT algorithm, a monitoring node v k, upon receiving a greater version number V N v i from v i than its own version number V N v, sends to the root a k message containing the address of the sender v i and the list of its neighbors N v obtained from the different received RPL k control messages. The monitoring node only sends a message the first 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 Algorithm DISTRIBUTED DETECTION anomaly detected = 0 if (VN vj > 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 vi > 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() Fig. 9. DISTRIBUTED DETECTION algorithm implemented on the root. Algorithm LOCALIZATION att list = NULL safe list = NULL for (i=0, i<potential att list.nb, i++) do if (att list == NULL) then add(att list,potential att list[i]) 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 Fig. 10. LOCALIZATION algorithm implemented on the root. the algorithms, the root has the possibility to send a signal message indicating that the monitoring nodes should reset the potential att value, in order to restart the detection process, in case another attacker appears in the network. The DISTRIBUTED DETECTION algorithm (see Figure 9) is supported by the root. 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

9 9 Fig. 11. Version number attack illustrative examples. (a) Attacker located at position 11. (b) Attacker located at position 2. TABLE II POTENTIAL ATTACKER LIST AND NEIGHBORS LIST OBTAINED BY THE ROOT AFTER MESSAGES AGGREGATION. (a) Attacker located at position 11. 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 TABLE III 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 reported by the different monitoring nodes and the neigh list list which is composed of each monitoring node neighbors N v. Once the lists are completed, the root starts the localization procedure described in Figure k 10. This procedure exploits the two previous lists in order to produce two new lists: the att list list composed of nodes considered as malicious and the saf e list list containing all nodes classified as safe. The objective of this procedure is to compare neighborhoods of monitoring nodes in order to eliminate potential attackers. At initialization, the first 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 different 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 the safe list, it is added to the attacker list. The final 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, those 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. In order to illustrate these algorithms, we provide two examples describing the different possibilities using the topology presented in Figure 11. The first 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 the first scenario (see Figure 11a), 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). The different monitoring nodes report to the sink the sender of abnormal messages and the list of their neighbors. At the end of this

10 10 process, the potential attacker list and the neighbors list are established at the root as illustrated by Table II (a). 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. Nodes v 4 and v 1 do the same with relays v 5 and v 3. Once all data is gathered, the sink can start the localization procedure to establish the list of attackers and the list of safe nodes. Table III (a) explains the different stages of those lists obtained by the localization procedure. At initialization, the first 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. Then since the second entry v 11 is already in the attacker list, only the safe list is updated with the neighbors of monitoring node v 10 which are v 5 and v 9. The third entry is v 3 which is already in the safe list, so only the safe list is updated with the corresponding neighbors 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 other regular nodes are considered as safe. The second scenario, illustrated by Figure 11b, where the attacker is located at position 2 shows the case where the localization procedure produces two attackers. Table II (b) details how monitoring data is aggregated by the root v 1 and Table III (b) shows the localization process. Until step 1 we can observe that only node 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 him. As such, this detection algorithm may generate false positive results, in particular when a potential attacker is only covered by one monitoring node. A false positive corresponding to a normal node being detected as malicious by our strategy. The placement of monitoring nodes plays an important role to exculpate network nodes, and therefore to minimize false positive rates. C. Monitoring Node Placement The placement of monitoring nodes should target minimizing false positive rates generated by potential attackers observed by only one monitoring node in the RPL network. We have represented the problem of having at least C% of the nodes covered by at least two monitoring nodes using an optimization model. This constraint can be transformed into having at most (100 - C)% of the nodes covered by only one monitoring node which can be formulated as follows: for a given topology, a given connectivity matrix for all possible monitoring nodes placement in this topology, a given number of monitoring nodes and a given value C, find a configuration of monitoring nodes placement that minimizes the number regular nodes monitored by only one monitoring nodes so that at most (100 - C)% regular nodes are covered by strictly one monitoring node in the network. In that context, we have considered four parameters detailed in Table IV, as inputs to solve this problem. The first parameter is the size of the topology N. The second one is the connectivity matrix detailing the links of possible monitoring nodes TABLE IV REQUIRED INPUTS FOR MONITORING NODES 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 1, N M Number of monitoring nodes [O, 1] C Value indicating a percentage of nodes TABLE V CONSIDERED VARIABLES FOR MODELING. Domain Variable Description 1, N 1, N 1, N 1, N Y W Z Binary variable indicating if Y i is monitoring node (= 1) or not Binary variable indicating if node v i is covered by monitoring node v j Binary variable indicating if Z i is monitored by exactly one monitoring node (= 1) or not 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 monitoring node does not cover itself. The third parameter is the number of monitoring nodes M. The last parameter is the percentage of regular nodes we want to be monitored by at least two monitoring nodes C. The variables used are Y which represents if node v i is monitoring node (Y i = 1) or not (Y i = 0), W indicating if node v i is covered by monitoring node v j (W i,j = 1) or not (W i,j = 0). The last variable is Z and represents if 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 Equations 1 to 6. Equation 1 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 specifics. Equation 2 indicates how many monitoring nodes we choose. The constraint Ca 1 = 100% is given by Equation 3. Equation 4 calculates variable W which is used in Equation 5 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 monitoring node. Equation 6 indicates the constraint that at most (1-C) % of regular nodes are covered by exactly one monitoring node. Y 1 = 1 (1) N Y i = N (2) j=1

11 11 i 1, N : i 1, N : 2 N (A i,j.y j ) + Y i 1 (3) j=1 i 1, N : W i,j = A i,j.y j (4) N (W i,j ) + 2.Y i Z i 1 Y i (5) j=1 N Z i (1 C).(N M) (6) j=1 The objective function f obj given in Equation 7, is used 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. f obj = min N Z i (7) i=1 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. Such a strategic placement directly impacts on detection performances. V. PERFORMANCE EVALUATION We have evaluated the performance of our detection strategy through series of experiments by implementing a proof of concept prototype. This prototype is developed in C based on the Contiki operating system and its RPL implementation. While it could be directly deployed over real sensor nodes, we have considered the Cooja simulator, which supports contiki operating system emulation and was used during our experiments. In these latters, we have set up a grid topology of 20 nodes corresponding to the lower plane of Figure 7. The grid topology was chosen because it allows relocation of the attacker to multiple positions easily, making it possible to study the performance of our detection strategy from different locations and neighborhood scenarios within a network. The Contiki 2.7 operating system was used to implement the sink, regular nodes and monitoring nodes. We have considered the attacker implementation proposed in [6]. The Cooja tool [33] was used to run the simulation with the compiled binaries of the different nodes. The radio model used was the DGRM model (Directed Graph Radio Medium) to emulate the links as shown in the lower plane of Figure 7: regular nodes can communicate with their neighbor horizontally and vertically while the monitoring nodes can also listen diagonally. Across all experiments, node v 1 is the DODAG root, acting as the sink to which all other nodes send messages every twenty seconds to generate a background traffic. The attacker is designed to constantly send incorrect version numbers, which are greater than the root s version. Each simulation has lasted ten minutes which is enough to test our detection algorithms since only the first attack message is required for the detection as previously explained. The location of the attacker has been set to one of regular nodes, such that at least one simulation with the TABLE VI DIFFERENT CONFIGURATIONS OF Cov i FOR 4 MONITORING NODES RANKED BY INCREASING Ca 2. Ca 2 (%) Cov 2 (%) Cov 3 (%) Cov 4 (%) attacker located at every regular node is executed. This entire set of simulations is repeated three times for accuracy reasons. Attacks start after five minutes of simulation time, so that the network has enough time to settle and reaches a stable RPL topology. Not only the location of the attacker has been varied but also the location and the number of monitoring nodes. Indeed, we have seen in Section IV-B that 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 different monitoring nodes configurations were chosen to evaluate the number of false positives. A. Placement and Coverage of Monitoring Nodes Since the designed detection solution depends on the coverage of regular nodes by monitoring nodes, we defined 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 nodes. As shown by the second scenario in Section IV-B, Ca 2 is an important parameter for selecting the configurations to be considered, because the number of false positive depends on the neighborhood overlapping of the monitoring nodes. Therefore, monitoring nodes configurations have been selected for different Ca 2 values in order to quantify the impact of the Ca 2 value on the number of false positives. Five different Ca 2 values have been chosen including the lowest and the highest possible values 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. A particular Ca 2 value corresponds to several combination of Cov i. For instance, one configuration with Ca 2 = 12.5% is mentioned on this table VI, while there are actually 3 possible monitoring node configurations. This is because the three possible configurations for Ca 2 = 12.5% have the same Cov i combination. Therefore, one configuration of each combination has been chosen for the simulations. For

12 12 4 monitoring nodes, the number of possible configurations so Ca 1 = 100% is 24. We have also selected configurations with 5 monitoring nodes because the obtained Ca 2 values allow us to have zero false positive. For 5 monitoring nodes, 427 configurations 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 configurations for these Ca 2 values, we have simulated 26 configurations, each one being representative of different Cov i combinations as detailed in Table VII. TABLE VII DIFFERENT CONFIGURATIONS OF Cov i FOR 5 MONITORING NODES RANKED BY INCREASING Ca 2. Ca 2 (%) Cov 2 (%) Cov 3 (%) Cov 4 (%) Cov 5 (%) For each simulated scenario, the false positive rate (FPR) was calculated according to Equation 8, where F P and T N are respectively the number of false positives and the number of true negatives. F P F P R = (8) F P + T N 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. B. Detection Results Across all experiments, our detection strategy has successfully located the attacker, but other regular nodes were sometimes detected as malicious too. Figure 12 details false positive results for the topology presented in the lower plane of Figure 7 where the monitoring nodes are v 1, v 7, v 13 and v 15 and the Ca 2 is 43,75% (maximum value for 4 nodes). We can observe that the FPR is 0 for 13 positions of the attacker. Fig. 12. False positive rates for different location of the attacker when configuration is the topology of Figure 7. TABLE VIII DETAILED DETECTION RESULTS RELATED TO FIGURE 12. Attacker 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 Details about the detection results when the FPR is higher than 0 are given in Table VIII. 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 monitoring nodes could have exonerate it. This is also the case for other positions of the attacker. However, attack relays were not considered as malicious each time. 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 35 configurations. Figure 13 shows the average false positive rate for different values of Ca 2 when varying location of the attacker. Error bars are calculated as standard error of mean of the different possible configurations (Cov i combination) for a particular Ca 2 value. Both figures show that the false positive rate decreases 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. If we have 4 monitoring nodes we can observe in Figure 13a that the maximum value of the FPR is 20% which corresponds to the worst case (no node is covered by at least two monitoring nodes i.e. Ca 2 = 0%), and at best the FPR stands around 1%. We obtain a false positive rate almost null when the Ca 2 is 66,67% (see Figure 13b). Based on these results, we can conclude that monitoring nodes placement is clearly strategic in order to obtain satisfying

13 13 (a) Configurations with 4 monitoring nodes. Fig. 13. Average false positive rates obtained with our node placement optimization for different Ca 2 values. (b) Configurations with 5 monitoring nodes. performance in detecting version number attacks. VI. SCALABILITY EVALUATION In order to evaluate the scalability of our solution, we solved the monitoring node placement problem with different sizes of grid topologies from 20 to 1000 nodes and with C=60% using the CPLEX solver [34] under the AMPL environment [35]. The C value was chosen according to previous results from Section V-B because the false positive rate was very low. A script was 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 find a solution was determined empirically by running the solver several times. However the exploratory domain was restrained by solving a similar problem with the objective Ca 1 = 100% for every sizes. The model was also modified to find the minimal number of monitoring nodes so Ca 2 = 100%. Figure 14 shows the minimal number of monitoring nodes required so Ca 2 is at least 60%. The value of C was set to 0.6 because it ensures low false positive rate for the detection algorithm, as shown in Section V-B. We can observe that the number of monitoring nodes required to have the different Ca values is proportional to the number of nodes. However, the gradient is greater for larger values of Ca which means that we need more monitoring nodes for large size of grids. We have also evaluated the performances obtained with other complementary topologies, as presented in Figure 15. We can notice a clear performance degradation with pseudo-randomly generated topologies, where the number of monitoring nodes reaches almost 300 nodes with largest configurations. In the meantime, cluster-based topologies which are more realistic with respect to what we could expect in AMI infrastructures, show performances close to grid topologies. These results are even slightly better than grids, but might be partially due to our grid topology constraints and be influenced by node ranges. VII. CONCLUSIONS After having compared existing IoT monitoring solutions, we have proposed a strategy for detecting version number Fig. 14. Number of monitoring nodes needed to have Ca 1 = 100%,Ca 2 60% and Ca 2 = 100% for different topology sizes. attacks in RPL networks. This one relies on a distributed monitoring architecture which preserves constrained node resources, in the context of AMI infrastructures. We have exploited monitoring node collaboration to identify the attacker, the localization process being performed by the root after gathering detection information from all monitoring nodes. We have evaluated our solution through experiments and have analyzed the performance according to defined metrics. We have shown that the false positive rate of our solution can be reduced by a strategic monitoring node placement. We have also considered the scalability issue, by modeling this placement as an optimization problem. By resolving it, we have quantified and compared the number of required monitoring nodes to ensure an acceptable false positive rate for different topologies. As future work, we are interested in performing complementary experiments in real infrastructures with additional classes of devices implementing the RPL protocol. We also want to evaluate and extend our solution to the case of attacker coalition where are several malicious nodes are involved at the

14 14 Fig. 15. Comparison of performances with Ca 2 60% for different topologies (grid, pseudo-random and cluster-based topologies) same time in the network. We are also planning to enhance our architecture with other detection modules for addressing additional attacks [36]. ACKNOWLEDGMENT This work was funded by Flamingo, a Network of Excellence project (ICT ) supported by the European Commission under its Seventh Framework Programme. REFERENCES [1] L. Atzori, A. Iera, and G. Morabito, The Internet of Things: A Survey, Computer Networks, vol. 54, no. 15, pp , [2] D. Popa, N. Cam-Winget, and J. Hui, Applicability Statement for the Routing Protocol for Low Power and Lossy Networks (RPL) in AMI Networks, Internet Engineering Task Force, Internet-Draft draft-ietfroll-applicability-ami-13, may 2016, work in Progress. [3] E. Baccelli, R. Cragie, P. V. der Stok, and A. Brandt, Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control, RFC 7733, feb [4] M. Ersue, D. Romascanu, J. Schönwälder, and A. Sehgal, Management of Networks with Constrained Devices: Use Cases, IETF Internet Draft <draft-ietf-opsawg-coman-use-cases-02>, July [5] T. Winter, P. Thubert, A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, J. Vasseur, and R. Alexander, RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks, RFC 6550, IETF, [6] A. Mayzaud, A. Sehgal, R. Badonnel, I. Chrisment, and J. Schönwälder, A Study of RPL DODAG Version Attacks, in Proc. of the International Conference on Autonomous Infrastructure, Management and Security (AIMS), [7] A. Ahmet, S. F. Oktug, and S. B. O. Yalcin, RPL Version Number Attacks: In-dept Study, in Proc. of IEEE/IFIP Network Operations and Management Symposium (NOMS), Istanbul, Turkey, Apr [8] A. Mayzaud, R. Badonnel, and I. Chrisment, Detecting Version Number Attacks in RPL-based Networks using a Distributed Monitoring Architecture, in Proc. of the 12th IEEE/IFIP/In Assoc. with ACM SIGCOMM International Conference on Network and Service Management (CNSM), Montreal, Canada, October [9] A. Mayzaud, A. Sehgal, R. Badonnel, I. Chrisment, and J. Schönwälder, Using the RPL Protocol for Supporting Passive Monitoring in the Internet of Things, in Proc. of the IEEE/IFIP Network Operations and Management Symposium (NOMS), Istanbul, Turkey, Apr [10] J. Case, M. Fedor, M. Schoffstall, and J. Davin, Simple Network Management Protocol (SNMP), RFC 1157 (Historic), Internet Engineering Task Force, May [11] R. Enns, M. Bjorklund, A. Bierman, and J. Schönwälder, Network Configuration Protocol (NETCONF), RFC 6241, Oct [12] A. Sehgal, V. Perelman, S. Kuryla, and J. Schönwälder, Management of Resource Constrained Devices in the Internet of Things, IEEE Communications Magazine, vol. 50, no. 12, pp , [13] S. Kuryla and J. Schönwälder, Evaluation of the Resource Requirements of SNMP Agents on Constrained Devices, in 5th Conference on Autonomous Infrastructure, Management and Security (AIMS 2011), Springer LNCS 6734, Nancy, France, June [14] C. Bormann, M. Ersue, and A. Keranen, Terminology for Constrained- Node Networks, IETF RFC 7228, May [15] Z. Shelby, K. Hartke, and C. Bormann, The Constrained Application Protocol (CoAP), RFC 7252 (Proposed Standard), June [16] P. V. der Stok and A. Bierman, CoAP Management Interface, Internet Engineering Task Force, Internet-Draft draft-vanderstokcore-comi-09, mar 2016, work in Progress. [Online]. Available: [17] C. Bormann and P. Hoffman, Concise Binary Object Representation (CBOR), RFC 7049 (Proposed Standard), Internet Engineering Task Force, Oct [18] K. N. Ramach, E. M. Belding-royer, and K. C. Almeroth, DAMON: A Distributed Architecture for Monitoring Multi-hop Mobile Networks, in IEEE SECON, Santa Clara, CA, USA, October [19] C. Liu and G. Cao, Distributed Monitoring and Aggregation in Wireless Sensor Networks, in 30th IEEE International Conference on Computer Communications (INFOCOM), San Diego, CA, USA, March [20] A. Lahmadi, A. Boeglin, and O. Festor, Efficient Distributed Monitoring in 6LoWPAN Networks, in 9th International Conference on Network and Service Management (CNSM), Switzerland, October [21] S. Raza, L. Wallgren, and T. Voigt, SVELTE: Real-time intrusion detection in the Internet of Things, Ad Hoc Networks, vol. 11, no. 8, pp , [22] A. Le, J. Loo, Y. Luo, and A. Lasebae, Specification-based IDS for Securing RPL from Topology Attacks, in Proc. of IFIP Wireless Days (WD), Niagara Falls, Canada, October 2011, pp [23] A. Le, J. Loo, K. K. Chai, and M. Aiash, A Specification-Based IDS for Detecting Attacks on RPL-Based Network Topology, Information, vol. 7, no. 2, [24] M. M. H. Khan, L. Luo, C. Huang, and T. Abdelzaher, SNTS: Sensor Network Troubleshooting Suite, in Proceedings of the 3rd IEEE International Conference on Distributed Computing in Sensor Systems, ser. DCOSS 07. Berlin, Heidelberg: Springer-Verlag, [25] B.-r. Chen, G. Peterson, G. Mainland, and M. Welsh, LiveNet: Using Passive Monitoring to Reconstruct Sensor Network Dynamics, in Distributed Computing in Sensor Systems, ser. Lecture Notes in Computer Science, S. Nikoletseas, B. Chlebus, D. Johnson, and B. Krishnamachari, Eds. Springer Berlin Heidelberg, 2008, vol. 5067, pp [26] X. Xu, J. Wan, W. Zhang, C. Tong, and C. Wu, PMSW: a passive monitoring system in wireless sensor networks. International Journal of Network Management, vol. 21, no. 4, pp , [27] A. Awad, R. Nebel, R. German, and F. Dressler, On the Need for Passive Monitoring in Sensor Networks, in Digital System Design Architectures, Methods and Tools, DSD th EUROMICRO Conference on, Sept 2008, pp [28] F. P. Garcia, R. M. C. Andrade, C. T. Oliveira, and J. N. de Souza, EPMOSt: An Energy-Efficient Passive Monitoring System for Wireless Sensor Networks, Sensors, vol. 14, no. 6, p , [29] D. Dong, X. Liao, Y. Liu, C. Shen, and X. Wang, Edge self-monitoring for wireless sensor networks, IEEE Transactions on Parallel and Distributed Systems, vol. 22, no. 3, pp , March [30] A. Dvir, T. Holczer, and L. Buttyan, VeRA - Version Number and Rank Authentication in RPL, in Proc. of the 8th IEEE International Conference on Mobile Adhoc and Sensor Systems (MASS), Hangzhou, China, October 2011, pp [31] H. Perrey, M. Landsmann, O. Ugus, M. Wählisch, and T. C. Schmidt, TRAIL: Topology Authentication in RPL, Tech. Rep., [32] M. Landsmann, H. Perrey, O. Ugus, M. Wählisch, and T. C. Schmidt, Topology Authentication in RPL, in Proc. of INFOCOM. Poster, [33] Cooja, the Contiki Network Simulator. [Online]. Available: [34] IBM ILOG CPLEX Optimization Studio. [Online]. Available: [35] A Mathematical Programming Language (AMPL). [Online]. Available: [36] A. Mayzaud, R. Badonnel, and I. Chrisment, A Taxonomy of Attacks in RPL-based Internet of Things, International Journal of Network Security, vol. 18, no. 3, pp , May 2016.

15 15 Anthéa Mayzaud successfully received a PhD Degree in Computer Science from the University of Lorraine, France in She graduated a Master Degree in Computer Science from the TELECOM Nancy Engineering School part of the University of Lorraine in Her research interests, as a member of the MADYNES (Management of dynamic networks and services) Project Team at LO- RIA - INRIA Nancy Grand Est, France, include the analysis of security issues related to the Internet of Things, and in particular attacks against networked objects implementing the RPL routing protocol, and the design of light-weight security solutions for them based on risk management techniques. Rémi Badonnel is an Associate Professor of Computer Science in the TELECOM Nancy Engineering School at the University of Lorraine, France. He is a permanent research staff member of the MADYNES Team at LORIA - INRIA Nancy Grand Est, France. Previously he worked on change management methods and algorithms for data centers at IBM T.J. Watson in USA, and on autonomous smart systems at the University College of Oslo in Norway. His research interests are mainly focused on network and service management, smart and autonomic environments, security and defense techniques, orchestration and chaining of services, cloud infrastructures and internet of things. Isabelle Chrisment is a Professor of Computer Science in the TELECOM Nancy Engineering School at University of Lorraine, France. She received her PhD in Computer Science in 1996 from the University of Nice-Sophia Antipolis and her Habilitation Degree in 2005 from Henri Poincare University, Nancy. She is also leading the MADYNES INRIA Project Team. Her research area is related to network monitoring and security and especially within dynamics and large-scale networks such as peer-to-peer, ad hoc and sensor networks.