Routing Attacks and Countermeasures in the RPL-Based Internet of Things

Abstract

The Routing Protocol for Low-Power and Lossy Networks (RPL) is a novel routing protocol standardized for constrained environments such as 6LoWPAN networks. Providing security in IPv6/RPL connected 6LoWPANs is challenging because the devices are connected to the untrusted Internet and are resource constrained, the communication links are lossy, and the devices use a set of novel IoT technologies such as RPL, 6LoWPAN, and CoAP/CoAPs. In this paper we provide a comprehensive analysis of IoT technologies and their new security capabilities that can be exploited by attackers or IDSs. One of the major contributions in this paper is our implementation and demonstration of well-known routing attacks against 6LoWPAN networks running RPL as a routing protocol. We implement these attacks in the RPL implementation in the Contiki operating system and demonstrate these attacks in the Cooja simulator. Furthermore, we highlight novel security features in the IPv6 protocol and exemplify the use of these features for intrusion detection in the IoT by implementing a lightweight heartbeat protocol.

A Survey of Potential Security Issues in Existing Wireless Sensor Network Protocols

“…In [48], authors proposed a lightweight heartbeat protocol to detect faults within the RPL-based network. It was shown that if combined with IPsec [49], the heartbeat protocol can be used to detect selective forwarding attack.…”

“…However, if combined with some other internal attack the adequate protection will be needed [20]. Wormhole attack can be prevented by using a Merkel tree authentication [54] or separate link-layer keys for different segments of the network [48]. Additionally, in [55] the authors proposed a graph theoretic approach.…”

“…Additionally, in [55] the authors proposed a graph theoretic approach. Sybil attack and clone ID are usually prevented by keeping the track of the number of instances of each identity and by using the geographical location of nodes [48], [56].…”

“…Authentication attack Network access control framework [44] PS Provides the node identification, but only enables one border router; Not implemented yet; Man in the middle, Eavesdropping/spoofing IPsec (AH and EPS) [45] PS Provides end-to-end secure communication; Pre-shared keys mechanism is not very flexible; Botnet attack Bot analysis module [46] IDS Good detection rates for large number of nodes; Decreased network performance and large overhead; RPL Selective forwarding attack Lightweight Heartbeat [48] IDS It has to be combined with IPsec to detect attack; No defense is provided after the attack is detected; Resilient techniques [51] PS Improved delivery ratio, but an increase in energy consumption; Spoofed/altered inf., sinkhole, selective forwarding SVELTE [50] IDS SVELTEs overhead is small enough; The true positive rate is not 100% due to some false alarms; Sinkhole attack IDS solution [52] IDS IPsec and bidirectional communication are necessary. Parent fail-over & rank authentication [53] …”

“…Separate keys for network segments [48] PS The solution was not implemented/simulated yet; Merkel trees authentication [54] PS Node uses a key to encrypt its messages; High jitter and E2E delay until tree has been established; Graph theoretic approach [55] PS Cryptographic techniques based on local broadcast keys; Low overhead, no synchronization needed; Sybil attack, Clone ID Distributed hash tables (DHT) to store the graphical location of nodes [48], [56] PS Problem in how to securely verify the node location; Might not scale well with large networks; DAG/DAO inconsistency attack Limit the rate of tickle timer resets [57] PS Threshold value is fixed, no network or node characteristics are taken into account; Adaptive threshold [58] PS Takes into account the network characteristics; Dynamic approach [59] PS Improved version as node specific parameters are used; Rank attack VeRa [60] PS Authentication mechanism based on hash operations; Low time overhead, but still vulnerable to rank attacks by forgery and replay; TRAIL [61] PS Improvement of VeRa, requires almost no cryptography, but shows dependency on network sizes; choose to selectively forward data or drop all received packets. In both scenarios the network operation would be disturbed.…”