Project Topics
Get Complete Project Material File(s) Now! »
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) tobe 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.
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 thedevice 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 rst consider in this category traditional management protocols, such as SNMP [14] and NETCONF [30] 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 [72]. 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 [38]. 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 [11].
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 [62] propose a distributed monitoring solution called DAMON11 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.
Passive Monitoring
We dene as passive monitoring, architectures where dedicated monitoring nodes called sniers 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 classied whether they are centralized or decentralized.
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. [35] introduce a troubleshooting suite called SNTS12 to facilitate the identication of anomalies in sensor applications. The solution uses dedicated extra nodes which passively listen to communications. The gathered information is then sent in the back-end part of the architecture where data mining techniques are performed to automate analysis for troubleshooting.
In the same manner, LiveNet [16] proposes to reconstruct the complex behavior of a deployed sensor network using multiple passive packet sniers collocated with the network as presented in Figure 2.8. Their work focuses on merging the monitoring traces obtained from the dierent sniers, estimating the coverage of the monitoring nodes and deducing missing information.
Routing 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].
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 [80] 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 [46]. 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, [32] 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.
Table of contents :
1 Introduction
1.1 Context
1.1.1 The Internet of Things
1.1.2 Low Power Lossy Networks and Routing Protocols
1.2 Problem Statement
1.2.1 Security Issues
1.2.2 Addressed Challenges
1.3 Overview of Contributions
2 Routing and Monitoring in RPL-based Internet of Things
2.1 Introduction
2.2 The RPL Protocol
2.2.1 RPL Control Messages
2.2.2 DODAG Building and Maintenance
2.2.3 Loops, Inconsistencies and Repairs
2.2.4 Protocol Security
2.3 Monitoring RPL-based Internet of Things
2.3.1 Active Monitoring
2.3.2 Passive Monitoring
2.3.3 Comparison and Limits
2.4 Conclusions
3 Taxonomy of Attacks in RPL Networks
3.1 Introduction
3.2 Attacks against Resources
3.2.1 Direct Attacks
3.2.2 Indirect Attacks
3.2.3 Analysis
3.3 Attacks on Topology
3.3.1 Sub-optimization Attacks
3.3.2 Isolation Attacks
3.3.3 Analysis
3.4 Attacks on Trac
3.4.1 Eavesdropping Attacks
3.4.2 Misappropriation Attacks
3.4.3 Analysis
3.5 Conclusions
4 Impact Assessment of RPL Attacks
4.1 Introduction
4.2 The DAG Inconsistency Attack
4.2.1 Attack Description
4.2.2 Simulation Setup
4.2.3 Impact Quantication
4.3 The Version Number Attack
4.3.1 Attack Description
4.3.2 Simulation Setup
4.3.3 Impact Quantication
4.4 Conclusions
5 Local Strategy for Addressing DAG Inconsistency Attack
5.1 Introduction
5.2 DAG Inconsistency Attack Mitigation
5.2.1 Default Mitigation
5.2.2 Adaptive Mitigation
5.2.3 Dynamic Mitigation
5.3 Mitigation Evaluation
5.3.1 Simulation Setup
5.3.2 Mitigation Performance
5.3.3 Conguration Parameters Impact
5.3.4 Resource Consumption
5.4 Conclusions
6 Security-oriented Distributed Monitoring Architecture
6.1 Introduction
6.2 Proposed Architecture
6.2.1 Overview and Components
6.2.2 RPL-based Mechanisms
6.3 Monitoring Node Placement Formalization
6.4 Detection Modules
6.4.1 DAG Inconsistency Attack
6.4.2 Version Number Attack
6.5 Conclusions
7 Architecture Evaluation
7.1 Introduction
7.2 Overhearing Evaluation
7.2.1 Simulation Setup
7.2.2 Performance Analysis
7.2.3 Cost Analysis
7.3 Detection Modules Evaluation
7.3.1 DAG Inconsistency Attack
7.3.2 Version Number Attack
7.4 Scalability Evaluation
7.5 Conclusions
8 General Conclusions
8.1 Achievements
8.2 Perspectives
Publications
Résumé de la thèse en français
1 Introduction
2 Protocole de routage RPL
3 Taxonomie des attaques contre le protocole RPL
4 Analyse d’attaques visant le protocole RPL
4.1 Attaque d’incohérence DAG
4.2 Attaque sur le numéro de version
5 Détection locale d’attaques d’incohérence DAG
6 Architecture de supervision distribuée pour la sécurité
7 Évaluation de l’architecture
8 Conclusions
Bibliography
