RPLAD3: anomaly detection of blackhole, grayhole, and selective forwarding attacks in wireless sensor network-based Internet of Things

Upward route

The directed acyclic graph (DAG) information object (DIO) message that the DODAG route sends to indicate the graph ID and its rank is used to construct DODAG. It allows other nodes to recognize their position within the network. DIO message will be sent to other nodes if new nodes want to join the network. By receiving the DIO’s message, it adds the address of the DIO message sender to its parent list and calculates their rank with the help of the objective function (OF). The rank of each node should be higher than the rank of all its parents. Furthermore, it updates the DIO packet with its ran and redistributes it all again. This procedure is recapped until all the nodes in the network receive their ranking. Each node should select a node from its parents as its preferred parent to direct data packets to the sink. When a node joins the DODAG graph, if it senses a DIO message, it can process it in three ways:

• Drop the DIO packet under some RPL terms.

• Route the message to preserve its location in the network.

• Expands its location by getting a lessened rating inside DODAG.

Whenever a node reduces its rank, it must remove all the parental members who rank less than their ranking from their parent list to stop the loop created in the network. After the end of this phase, each node has a default path to the root and can send its data packets to the root (Oliveira & Vazão, 2016).

Downward route

If the flag type is a non-zero performance in the DIO message, the downward route should be supported and kept from root to nodes. Each node must send a destination advertisement object (DAO) message to its parent to determine the downward route information. The DAO packets transmit node addresses that cross paths along the upward route when they move from the nodes to the root, and the entire path between the root and the nodes is created. This message can be acknowledged by the destination using DAO’s acknowledgment message. RPL has two functional models for maintaining a downward route:

• Storage mode, in which the parent receiving the DAO packet can save the content of the DAO message before sending the packet to its members. In this case, each parent node stores the address of all its child nodes.

• Nonstorage mode, in which a direct DAO message is sent to the root of DODAG. Thus, the source nodes reject the DAO’s message storage, only store their addresses in the route, and direct it to their chosen parent. As a result, no parent maintains the address of its child’s nodes, and the only root that receives all of the DAO’s packets can store the entire downward route (Kim et al., 2017b).

Since traditional Internet routing protocols are insufficient for resource-constrained IoT devices and routing techniques perform poorly in the IoT, several solutions have been proposed to manage routing. One of these standards, the RPL, was developed from scratch to address the routing requirements of IoT networks and minimize resource consumption along the route (Hui & Vasseur, 2012). RPL has its security methods primarily via the following three security modes:

• Unsecured mode: RPL’s default setting when link-layer security is needed. The RPL control messages are not subject to security controls in this mode.

• Preinstalled mode: Symmetric preinstalled keys are manually preconfigured on the nodes. These keys are used to manage and produce secure copies of RPL control messages when a node joins the DODAG and for keeping them. This possibility is recommended when secure routing is necessary with many limited devices.

• Authenticated mode: Nodes with routing capabilities must use the preinstalled keys to get another key from the authentication authority. In this mode, nodes that wish to join the DODAG as leaf nodes use the preinstalled keys to join. The implementation will decide how the authority verifies the nodes and how the keys are shared.

Furthermore, RPL employs AES/CCM (the Advanced Encryption Standard in the “Counter with Cipher-block chaining Message authentication code” mode) with a 128-bit key to create 32-bit and 64-bit Message Authentication Codes to keep the confidentiality, integrity, and authenticity of these communications (MAC). These MACs are used to guarantee the communications’ integrity. To ensure the privacy and validity of the communications, RPL also employs RSA with SHA-256 for the optional 2,048- and 3,072-bit digital signatures (Raoof, Matrawy & Lung, 2018).

However, RPL cryptographic algorithm and authentication key generation cannot detect internal attacks. Selective forwarding, grayhole, and blackhole attacks are typical internal routing attacks. A blackhole attack creates a “black hole” in the network by having malicious nodes delete all packets they receive rather than forwarding them, leading to a Denial of Service (DoS) (Pawar & Jagadeesan, 2021). A more advanced attack is the selective forwarding attack which sends packets from a few protocols while dropping the rest, for example, only sending ICMPv6 and RPL control packets while deleting all other packets (Lal & Prathap, 2021). Grayhole attack changes in the packet before forwarding them (Sidhu & Sachdeva, 2020). These three attacks differ primarily in their goals: selective forwarding and grayhole attacks aim to significantly disrupt routing, while the blackhole attack desires to impose a DoS on the network. RPL’s self-healing capabilities cannot prevent or reduce these attacks since malicious nodes often transfer control messages from RPL and participate in forming and maintaining DODAGs like any other valid node.

The literature on routing attack detection is currently more constrained and needs to consider new protocols like RPL and their parameters to detect and prevent attacks. Internal attack detections in RPL networks have received little attention, but a limited detection system may be found using a mobility framework. The limited node’s capacity further complicates finding the right node to support the resource constraint detection approach. Patel & Jinwala (2022) developed an internal routing attack detection system for RPL protocol which on reputation calculation of node behaviour. Their behavior can detect selective forwarding attacks by checking actual packet loss to estimate the average loss. However, this system is ineffective in large-scale routing and does not support mobility frameworks.

Farooq et al. (2022) proposed MMTM-RPL system to detect three types of internal attacks based on RPL protocol. They integrated the trust model into RPL and developed a multi-mobile agent framework that supports mobility. Thus, their system consumes high energy and end-to-end delay due to the layer-based architecture. Similarly, Hashemi & Shams Aliee (2019) developed a mobility RPL based trust model to detect blackhole, sybil, and rank attacks. The significance of their system is the improvement in terms of an average number of parent changes; however, it consumes high energy and memory overhead. Another mobility system based on RPL was proposed by Medjek et al. (2021) to mitigate DIS attacks by modification of some RPL standard codes in the cooja simulator. It supports both static and dynamic RPL networks; however, it has high computational costs due to the use of added hardware omnidirectional. Table 1 is a comparison table to discuss each method and their strength and evaluation metrics.

Thus, a resource-constrained internal attack detection system that supports a mobility framework and effectively detects attacks is required to resolve the identified issues.

RPLAD3 architecture

The proposed system architecture is made up of four interconnected layers. Since these layers are connected, each can call the next layer whenever required. Different sublayers are incorporated in each layer which is discussed in detail in the following sections. The four layers of RPLAD3 are as follows:

• Layer one: information gathering.

• Layer two: trust calculation.

• Layer three: decision making

• Layer four: backup and restore.

Attacks are detected in a distributed network without the intervention of a central network entity during the deployment of the proposed trust model, which is applied to each network node separately. Figure 5 illustrates the proposed method architecture.

All the required information for the trust calculation layer is collected in the information gathering layer. Additionally, in the trust calculation layer, the trust values about the preferred parent node are calculated using the data obtained from the previous layer. Furthermore, decisions regarding the trust in the preferred parent node are made in the decision-making layer using values obtained from layer two. The root will store the node’s crucial data during the backup and restore layer to access it in case of an error. One of the proposed system’s novelties is that it considers the backup and storage layer, which is uncommon in RPL-based systems.

The proposed method starts functioning immediately after the initial state of the network. At the start of the method, the information gathering layer monitors and collects information about the neighboring nodes. The trust calculation layer is called by layer one if required, and the other layers may also be called by the previous layer if essential. In the following sections, each layer will be discussed separately.

Layer one: information gathering

Layer one collects three types of information from all immediate neighbours through three sublayers. Algorithm 1 displays step by step how layer one functions.

• CT: information related to control packets.

• DT: information related to data packets.

• AT: information related to all packets (Control and Data Packets).

Layer two: trust calculation

In this section, we describe the process used to calculate trust. The three sublayers of this layer are the calculations of the trust that each node obtains about its parent node.

The trust threshold is measured as a decimal value between zero and one. The initial value is 0.5-PLR (packet loss rate), which expresses a neutral point of view toward the nodes at the initial state of the network. According to the information obtained from the parent node in the information gathering layer, trust can increase or decrease over time.

Trust is calculated for the successful forwarding of packets using the obtained information from layer one about a parent node’s positive and negative behaviour. For this purpose, first the trust for all the successful forwarded packets will be calculated as TF-All. Then the trust for the successful forwarding of control packets TF-Control is calculated and then the trust for the successful forwarding of data packets TF-Data is calculated. Finally, it obtains the minimum of these three values as the final value for trust_.

Layer three: decision making

After each trust calculation, the decision-making layer is performed. This layer makes decisions about the parent node using the final trust value. Two procedures are defined in the decision-making layer for each node: a punishment procedure and a forgiveness procedure.

Layer four: backup and restore

In this research, the backup and recovery layer is introduced for the first time aiming to control a scenario wherein nodes lose their essential information due to an error. After the t_backup timeout, the node transmits IP address and the amount of forgiveness for nodes that have been blocked since the previous backup. The root stores this information per node i. Node i reconnects to the network whenever an error occurs, or it is restarted by losing its parent. After choosing a new parent, it will then send a DAO message asking for DIO packets. To distinguish it from DAOs that are typically sent in response to a parent change, we kept a bit flag (B) in that DAO message. Root determines if it is necessary to send the stored data to node i upon receiving this DAO message and inspecting its flag. As a result, it embeds this information in DAO-ACK packets and sends it to node i. Moreover, root stores the attacker IDs by receiving backup message and will alert the network’s nodes about node j if it has received more than k backup messages from different clients identifying the node j as an attacker. All network nodes decrease the priority of node j to be selected as their preferred parent by receiving this information from the root.

Energy and power consumption

RPLAD3 estimates the node’s battery energy level to decide whether it can perform a specific task, like forwarding a packet. If a node’s battery level is low or its buffer size is almost complete, it may behave differently in a routing decision. Unless they are critical requests for urgent packets, declining emphasizes the significance of the limited resources available to these nodes. Additionally, a node with a high lossy link, limited bandwidth, or a slow processing speed may cause a significant delay in packet delivery. A node with insufficient resources is isolated, given enough time to refill its drained resources, especially battery power, and then given another chance to rejoin the network. Equation (11) (Chu, Horng & Chang, 2019) displays the formula for calculating energy consumption used in the Cooja simulation, and Eq. (12) (Radosavljević & Babić, 2021) displays the formula for calculating power consumption.

(11) $EnergyConsumption\left(mJ\right)=Energerst\mathrm{\_}Value\times Current\times Voltage$

(12) $$PowerConsumption\left(mW\right)={\displaystyle \frac{EnergyConsumption\left(mJ\right)}{RTIMER\mathrm{\_}Second\times Runtime}}$$

The PDR of RPLAD3 in cooja is calculated by subtracting totalReceived (DATA receive) from totalSent (DATA sent) using the script provided in the Contiki directory’s powertrace.c file. The same script is also used to calculate the end-to-end delay, energy, and power consumption values.

Experiment 1: RPLAD3 adaptivity evaluation

Using the trust window (TW), a guilty node can be forgiven TW times. Unless the number of attacker flags exceeds TW, a node is not considered an attacker. The false positive rate (FPR) for RPLAD3 attack detection is decreased using this technique. Keep in mind that TW can slightly extend the time it takes to detect an attack. TW value is adaptive to get around this limitation, enabling network administrators to identify the TW value in accordance with network security guidelines. Therefore, trust threshold and TW values could be increased if FPR needs to be reduced, while they could be decreased if detection delay needs to be shortened. The right amount for trust threshold and TW will depend on the network administrator’s security policy, demands, and preferences.

Experiment 1 was conducted in six different scenarios. In scenarios 1 and 2, the value of TW is set to 1, and trust threshold values vary between 0.4 and 0.5. In scenarios 3 and 4, the value of TW is set to 2, and trust threshold values vary between 0.4 and 0.5. Simultaneously, in scenarios 5 and 6, the value of TW is set to 3, and trust threshold values vary between 0.4 and 0.5. TW values vary from 1 to 3 in all scenarios to evaluate the changes in TW values. Besides, trust threshold values are set once as 0.5, based on trust calculation layer 2, and 0.4 other times when the error probability value is subtracted from trust threshold. Figure 7 displays the simulation results of Experiment 1 for different values of TPR and FPR. The evaluation results from experiment 1 undoubtedly reveal extremely high values of TPR, which are almost close to 1, and exceptionally low values of FPR, which are almost close to zero. It is evident that the trust threshold and TW values have no adverse effects on the RPLAD3 trust model. Nevertheless, it significantly improves the network’s performance effectively.

Experiment 2: RPLAD3 scalability evaluation

Large-scale sensor networks with many sensor nodes require scalable routing attack detection systems to operate effectively. It would be ideal for network performance to remain stable as it grows. The conception and application of such security systems are promised future-generation sensor networks. Experiment 2 is conducted to evaluate the scalability of RPLAD3 and its impact on network size and density while detecting routing attacks. Table 3 displays the results of four distinct Cooja simulator scenarios. RPLAD3 isolated the malicious nodes with low end-to-end delay, FPR, energy, and power consumption after attacks were launched in Cooja. TPR and PDR also experienced rapid growth. We started with ten nodes and increased the nodes in the scenarios stepwise until they reached eighty.

Since networks must scale from low to high densities to detect malicious nodes in any density, a secure routing system is necessary. RPLAD3 aims to ensure that the sensor nodes can reliably communicate in a wide range of environments while identifying malicious nodes. The correlation between density and node distance is inverse. The density decreases as the distance increases between two nodes and vice versa. We have performed three scenarios with node distances ranging from 20 to 40 to evaluate the impact of RPLAD3 on density. In RPLAD3, we evaluated how density impacted PDR, end-to-end delay, TPR, FPR, power, and energy. Table 4 displays the results of the experiment. It can be observed that the FPR is almost close to zero, and PDR and TPR are close to one. Moreover, we experienced low values for end-to-end delay, energy, and power consumption.

Experiment 3: RPLAD3 accuracy evaluation

Two different types of experiments are carried out for attacker ratio and error probabilities to evaluate the performance of RPLAD3 regarding detection accuracy. As seen in Table 5, the impact of RPLAD3 on error probabilities is evaluated in four different scenarios with different percentages of error probabilities. The results are evidence that even with a 30% of error probability still, we achieved extremely low values for FPR, end-to-end delay, power, and energy consumption while the values of PDR and TPR are close to one.

We have conducted three scenarios to evaluate the impact of RPLAD3 on a different number of attacker nodes. Table 6 reveals the same results for different attacker ratios, which concludes that RPLAD3 can perform accurately even if the number of attackers increases up to 20.

Experiment 4: RPLAD3 mobility evaluation

The most practical mobility model of the IoT, the random way point mobility, was utilized in the RPLAD3 trust model. It includes options for a mobility framework that defines a route using bond motion techniques. Mobilization is managed as follows: we set the mobile option for a 1-h simulation to travel randomly in a different direction after pausing for 5 min, with a minimum and maximum speed of 1.4 and 5 m/s based on human walking or running. We used the random route from the mobility tools for the experiments with mobile nodes as attackers or victims. The route example given is: (node number, millisecond time, position x, y), indicating the node’s position during that millisecond. Table 7 displays the simulation parameters for the RPLAD3 mobility framework in cooja.

Two different scenarios have been conducted to evaluate the performance of RPLAD3 with a static attacker vs a mobile attacker. The results displayed in Table 8 reveal the high performance of RPLAD3, whether it faces a static or mobile attacker. In both scenarios, the end-to-end delay, energy, and power consumption, and FPR are incredibly low, while PDR and TPR are close to one as can be seen from Figs. 8 to 13.

Figure 8 depicts the effect of a static vs mobile attacker on FPR in RPLAD3. A static attacker’s FPR is almost zero and only 0.0003 less than a mobile attacker. When under attack, the FPR in RPLAD3 performs better than any comparable studies and RPL protocol. Unlike other studies currently available, the proposed method automatically detects and prevents all types of routing attacks with an FPR close to zero.

Figure 9 illustrates the effect of a static vs mobile attacker on TPR in RPLAD3. While the mobile attacker only varies from the static attacker in TPR by 0.04, the evaluation results of static attackers are remarkable and almost one. The high TPR in RPLAD3 demonstrates the accuracy and efficacy of the proposed system.

Figure 10 demonstrates the impact of a static vs mobile attacker on PDR in RPLAD3. The PDR of a static attacker is almost one, while the PDR of a mobile attacker is only 0.03 higher. When compared to other studies of a similar nature, the proposed system’s PDR and TPR are the highest because they are nearly identical in all experiments and different scenarios, whether from a mobile attacker or a static attacker.

Figure 11 depicts the effect of a static vs mobile attacker on end-to-end delay in RPLAD3. The static and mobile attacker evaluation values are 0.41 and 0.42, respectively. The end-to-end delay results of RPLAD3 are satisfactory and slightly lower than previous comparable studies. The proposed system attack detection approach has a minor impact on end-to-end delay, demonstrating the capability of RPLAD3 to identify attacks immediately and with minimal end-to-end delay.

Figure 12 demonstrates the impact of a static vs mobile attacker on RPLAD3 power consumption. Both static and mobile attackers consume about the same amount of power to detect attacks, and the evaluation’s findings suggest that power consumption is lower compared to similar studies. RPLAD3 detects and prevents attacks efficiently while using less power, whether the attacker node is mobile or static.

Figure 13 depicts the effect of mobile vs static attackers on RPLAD3’s energy consumption. With just a 0.1 variation between static and mobile attackers, RPLAD3’s energy consumption is comparatively deficient. RPLAD3 outperforms other similar approaches in terms of energy consumption, whether confronted with static or mobile attackers.

Three more experiments were conducted to compare the performance of RPLAD3 with a mobile attacker, mobile victim, or both. Table 9 shows the high performance of RPLAD3 with a mobility framework under any attack. FPR is near zero, PDR and TPR are remarkably close to one, while end-to-end delay, energy, and power consumption are low.