LDES: detector design for version number attack detection using linear temporal logic based on discrete event system

The Internet Engineering Task Force (IETF) has defined routing protocols for low power and lossy networks (RPL) for constrained devices. RPL constructs DODAGs (destination oriented directed acyclic graphs), to optimize routing. RPL ensures acyclic topology with the DODAG version number. However, the control message’s DODAG version number is not authenticated. So, RPL is vulnerable to network resource attack known as DODAG Version Number (DVN) attack. DVN attack creates a packet delay, packet loss, cyclic topology, etc., in the network. This paper proposes a method for detecting DODAG version number attacks. Several existing schemes to defend against the DVN, such as cryptographic techniques, trust-based, threshold-based and mitigation are computationally intensive or require protocol modification. DVN does not change the packet format or sequence of packets, but can still perform attacks and hence fall under the category of stealthy attacks, which are difficult to detect using traditional intrusion detection system’s (IDS). Discrete-event system (DES) based IDS have been applied in the literature for stealthy attacks that achieve low overhead, low false alarm rate, etc. However, the construction of DES-based IDS for network protocol may lead to errors, as modelling is manual. The resulting IDS, therefore, is unable to guarantee its correctness. This paper proposes linear temporal logic (LTL) based DES paradigm to detect DVN. LTL-based paradigm facilitates formal verification of the DES-based IDS, and hence the correctness of the scheme is ascertained. The proposed technique is simulated using the Contiki cooja simulator. When the percentage of spiteful nodes in the network increases, the true positive rate, and packet delivery rate drops, while the false positive rate and control message overhead increase. The memory requirement for sending the packets and verifying the nodes is minimal. The LTL-based IDS has been formally verified using NuSMV to ensure the correctness of the framework.


Introduction
The Internet of Things (IoT) has been overgrowing. It connects a vast network of machines or objects over the Internet. These interconnected machines or objects such as sensors, actuators may consist of resource-constrained devices [17,36] Various applications like smart hospitals, smart industrial monitoring, smart agriculture, smart irrigation, smart fighting, use IoT devices. In the IoT framework, a wide range of constrained devices with minimal memory, power, and processing capacities construct a low power and lossy networks (LLNs) [24]. LLNs have lossy links and low throughput. Therefore, LLN requires a routing protocol that can fulfill the need of LLN devices. However, there are already many existing routing protocols like OSPF (Open Shortest Path First) Version 2, RIP (Routing Information First) Version 2, DYMO (Dynamic Mobile ad hoc network On-demand routing), that are designed for other networks like wireless, ad-hoc, MANET. Many researchers have applied these routing protocols for LLN devices, but such protocols lack the routing criteria (such as routing state, lossy response, control cost, link cost, node cost) required for LLN devices.
Thus, Routing Protocol for LLNs (RPL) [6,11,13] has been designed that passes all criteria associated with LLNs. RPL based network is open to various security attacks because of their limited potential and open and unguarded distribution. Major security attacks against RPL include internal attacks, e.g., Rank attack, DIS (DODAG Information Solicitation) flooding attack, topological inconsistency attack, and external attacks like DoS (Denial-of-Service), hijacking of IoT device, password-based attacks. A variety of security mechanisms have been taken into consideration for RPL [7]. All these mechanisms can secure or guard the network against external attacks [9,10,12], but it is also vital to secure the network from internal attacks [14,25,26,33,35].
This paper focuses on a resource attack is referred to as DODAG Version Number attack. This attack falls into the category of stealthy attacks that are difficult to be detected by standard IDS. A spiteful node alters the version number by illegally incrementing the version number value in the respective field of the DIO control message format. Once the new increased version number of the DIO message format is received, this modification forces the rebuild of the new DODAG tree. The parent node sends DIO messages to their child nodes. In this way, the DIO messages are exchanged to build the new DODAG. The new DODAG formation can cause loss of reserved energy, unavailability of channels, and even form loops in the routing topology. There is no technique available that can assure the integrity of the DIO field, i.e., version number. Various trust-based [18], cryptographybased approaches (such as key exchange, signature-based approaches, hashing) have been proposed to ensure the security of version numbers in RPL networks. However, these approaches deliver the protocol as heavy-weight for LLN devices. Only a few strategies target to detect version number attacks but require protocol modification and hardware upgradation. [5,8]. Traditional signature and anomaly IDS [12,31,34] show high false alarms as stealthy attacks like DODAG version number attacks do not change the syntax of a network packet or result in a large statistical change of the network parameters. Therefore, in this paper, we apply the Discrete Event System (DES) based IDS technique to detect DODAG Version Number attack, which does not require a change in hardware or protocol and is low weight, yet able to handle stealthy attacks.
DES is a discrete automata model with event-driven dynamics [4,27,33] that has been used to develop the IDS [10,23,33] to resolve the issues of change in protocol, augmentation in hardware, etc. The DES model is built for both normal and attack (referred to as failure) conditions on the network. The state estimator, also known as the DES detector, is designed as the IDS. The detector evaluates whether the system traverses through the normal or failure conditionbased DES model based on events created (triggered) by the system.
The Discrete Event System framework is automata-based because the specification is modeled for the network protocol as an automaton. The DES-based IDS has shown impressive results like low overheads, low false alarm rate, no protocol change, and also at the same time are effective against stealthy attacks. In DES-based IDS, the behavior of the network protocol under normal and failure conditions are described in terms of ordinary language, i.e., specification. The manual translation of common (natural) language into an automata-based DES for the network protocol is tiresome, so that it may lead to errors. As a result, proving the IDS's correctness becomes a difficult task. Therefore, the Linear Temporal Logic (LTL) based DES (LDES) is used to resolve the problems related to the correctness of the model in automata-based DES.
The LDES framework [22,27] is a user-friendly environment as it can capture the standard language specifications. This paper focuses on the LDES to construct an IDS that detects DODAG Version Number attacks.
The LDES IDS has the following features: • Transformation of common language specification of DIO protocol to models. LDES renders modeling less vulnerable to errors. • At any stage of IDS development, model checking [16,19,32] is performed to verify the correctness, i.e., from modeling to detector design.
The remaining paper is organized as follows. Section 2 presents the operation of the RPL protocol along with the version number attack. Section 3 consists of related work for the detection of version number attacks. The overview of detector design using LTL-based scheme is discussed in Section 4. The proposed scheme is discussed in Section 5. It gives a detailed working principle of the proposed IDS. It consists of an LTL-based DES framework and concerns constructing a DES detector for a version number attack. Section 6 contains the performance evaluation of various simulation scenarios and verifies the DES-based IDS using the NuSMV tool. In Section 7, counterexample for showing the importance of LTL is shown. The concluding remarks are given in Section 8.

Overview of RPL
RPL is a routing protocol for Low Power and Lossy Network, developed as a distance-vector routing protocol. The RPL protocol is primarily for IoT devices with limited capabilities and wireless sensors. The devices (nodes) use RPL to construct a Destination Oriented Acyclic Graph (DODAG) [28] for communication. The DODAG consists of three different kinds of nodes: parent (in-between nodes), child (leaf nodes), and root (default gateway), as illustrated in Fig. 1. Each device in a DODAG tree has a rank that helps to reduce upward traffic flow while increasing downward traffic flow. In DODAG, the root node has rank zero, and the parent node s rank is always lesser than its child to avoid loop creation. The RPL supports three kinds of traffic schemes. In P2P, the communication between two LLN devices occurs, whereas, in P2M, the traffic flows from a root node to LLN devices. In M2P, communication from LLN device(s) to root occurs. The RPL consists of multiple DODAG networks, where the number of distinct wireless sensor nodes are linked to a DODAG s gateway node, i.e., root [5]. Each DODAG in the network can be distinguished by some fields -DODAG version number, rank values, DODAG ID, and instance ID. To maintain and establish the DODAG routing, RPL uses ICMPv6 control messages: DODAG information object (DIO), DODAG Advertisement Object (DAO), DODAG Advertisement Object Acknowledgement (DAO-ACK), and DODAG Information Solicitation (DIS). DIO advertises the information to maintain and build the DODAG. The DODAG root begins the construction of DODAG towards the upward route by broadcasting DIO frames. The nodes select the sender as a parent on receiving the DIO frame, and the receiving node notifies the updated data to neighboring nodes in the next DIO. All nodes has an upward route towards the root on completing the DODAG construction process. A rank value is assigned to each node in DODAG with respect to the root node, which denotes the location of a node. A node selects the preferred parent from the parent list, which acts as a default gateway. A node selects the preferred parent to forward a packet towards the root. Upon unsuccessful transmission, the node selects any non-preferred parent to forward the packet, one after the other. Figure 1 depicts the DODAG construction using RPL. The root node (node A) delivers the DIO frame consisting of the DODAG s data. Node C, B joins DODAG upon receipt of the DIO frame and responds to node A with the DAO frame. Then, node B forwards a DIO frame containing the latest DODAG data. On receipt of the DIO frame from node B, node D joins the DODAG. After joining DODAG, node D responds to node B with a DAO packet. Node B receives a DIS request response from node E, as no node has joined the DODAG. After node B joined the DODAG, node B sends the DIO frame to node E to join the DODAG. Now, after joining DODAG, node E responds with a DAO frame to node B. After receiving the frames, node B will sum up all the data and forward the DAO frame to its selected parent node A. Finally, node A attains all data about the nodes from their DAO frames to construct a downward route. Similarly, the remaining nodes will join the DODAG. In RPL, the trickle algorithm transmits the DIO periodically. A rank rule is used to avoid loop creation where a parent node always has a rank lesser than its child node. DODAG loops may occur when DODAG is cyclic. When inconsistencies arise in the DODAG (e.g., due to less power or lossy communication condition, nodes vanish from the network), RPL activates repair mechanisms. Two different repair mechanisms are available: (i) Global repair and (ii) Local repair. Whenever the preferred parent is unavailable, a local repair is triggered. RPL uses a local repair mechanism to find an alternate path to route the packets. This mechanism fails if multiple inconsistencies occur and activate the global repair mechanism. A global repair mechanism increments the DODAG version number to rebuild the whole DODAG tree. The DIO control message consists of the version number. A node checks its current version number with the new version number of the received DIO from its parent nodes. If the latest version number value is large, a node ignores its current rank value, resets the clock, and rebuilds a new DODAG. A global repair procedure in a new DODAG assures an acyclic topology.

Threat model
The RPL protocol is exposed to a large variety of attacks. The characteristics of LLN networks such as resource constraints, lack of infrastructure, dynamic topology, unreliable links etc. make them particularly vulnerable against attacks. The RPL integrates local and global repair mechanism as well as loop avoidance and detection techniques. Even though an attacker is able to bypass security at link layer by exploiting a vulnerability as well as can configure faulty node to disturb the network functioning. Therefore, RPL based attacks targeting the exhaustion of network resources like Flood-ing attack, Routing It may also result in memory overflow. • Increased rank attack: In this attack, the rank value of a RPL node is increased intentionally in order to generate loops in the network. The rank value is associated to each node and corresponds to its position in the DODAG structure according to the root node. As previously mentioned, the node rank always increase in the downward direction to preserve the acyclic DODAG. The rank of child node must be greater than rank value of its parents node. If a node wants to change its rank value, it has to update its parent list by removing the nodes having a higher rank than its new rank value. An adversary node advertises higher rank value than the one it is supposed to have. Loops are formed when its new preferred parent was in its prior sub-DODAG and only if the attacker does not use loop avoidance mechanisms. It drains the node batteries power and creates congestion in the RPL network. • Version number modification attack: The version number acts as an indicator for global repair mechanism and carried in DIO message. The root node in the network uses a version number to manage the global repair process. The version number assures that all nodes in the DODAG are present with the routing state. In this attack, spiteful node illegally increments the version number field value in the DIO frame format [3]. A spiteful node forwards the DIO frame to all of its neighbors. When the neighboring nodes receive the DIO frame from the spiteful node with an incremented version number value, they form the latest DODAG tree. The latest DODAG tree for- mation creates a loop in the topology, resulting in a waste of node energy, increased overhead, and many more.
In this paper, version number modification attack has been considered. The version number modification attack is explained through an example. The network topology in RPL comprises of one root node, several normal nodes and spiteful node facilitate for version number attack. Figure 2a shows the impact of DODAG Version Number Attack. The network consists of 8 nodes where there is one DODAG root (node A), one spiteful node (node F), and the remaining are legitimate nodes. In DODAG, only node A is allowed to update the Version number parameter in DIO message format. Node F joins DODAG as a legitimate node like other nodes, but it becomes spiteful after the DODAG becomes stable. Now, node F sends DIO (dotted arrows) messages to its neighboring nodes, i.e., Node C, E, H, and G (assuming in the transmission range). This DIO message consists of the modified version number. Node C rejects the received DIO message, as it is from the child node. Nodes E, H, and G also receive the DIO message with the updated version number. Upon receiving DIO, Nodes E, H and G update their existing version number and propagate it in the DODAG. It will result in new DODAG tree formation and breaks the single tree into two DODAG's as shown in Fig. 2b. The new DODAG formation is one of the implications of DODAG version number attack, where Node F becomes root node (as shown in Fig. 2b) from the spiteful node (as seen in Fig. 2a).

Related work
Section 3.1 describes the study of the detection strategies for the DODAG version number attack. As already discussed, for stealthy attacks, e.g., the DODAG Version Number attack, DES-based techniques are implemented. Section 3.2 comprises the background of DES-based IDS techniques and their drawbacks.

DODAG version number RPL attack detection techniques
The technique presented in SVELTE [30] consists of three modules for detecting routing attacks in a 6LoWPAN network. The first module collects the data of the IPv6 at the edge router, and the second module determines the invasion in the traffic. The third module prevents unwanted traffic from entering the 6LoWPAN network. The main issue of the scheme is that it shows high false positive rates. Authors in [15] present a solution for attacks on VeRAversion number and rank authentication in RPL. This cryptography-based solution secures rank and version number fields using a hash chain in the DIO control message. However, the authors have neither evaluated network performance parameters nor discussed the paper's implementation.
Ahmet Arõsü et al. [8] have proposed mitigation techniques for the Version Number Attack. The technique eliminates the Version Number coming from the child nodes and allows the node to change its Version Number only when most neighbors with better ranks claim a Version Number update. However, the multiple Version Number attack condition has not been considered in this work.
Firoz Ahmed et al. [5] have proposed a technique for the detection of the version number attack using a cooperative verification technique. In this scheme, the node exchanges verification messages among the two-hop neighbors and collects the version number information from the two-hop neighbors to identify the attacker. The issue with this scheme is that every node should know the address of every two-hop neighboring node. Also, this scheme itself can become the source of the DoS attack by repeatedly sending the verification request messages to misuse the neighbors' resources.
The detection, as mentioned above, techniques are either the cryptographic schemes (involving resource overheads) or need protocol modification, software updation, etc.
Some attacks will require no change in protocol or header format and neither lead to any significant statistical deviation in the network parameters but can still exploit the vulnerabilities. These attacks are known as stealthy attacks, and DODAG Version Number attack falls in this category. For stealthy attacks, the DES-based IDS technique has been proposed in the literature that has shown impressive results in non-requirement of protocol modification, low resource overheads, low false alarm rate, etc.
In the following subsection, we discuss the DES-based IDS schemes and issues therein.

DES based IDS techniques
N. Hubballi et al. [20] proposed a LAN attack detection technique using Discrete Event Systems. ARP spoofing is a stealthy attack where signature and anomaly-based IDS have a high false alarm rate. In this work, the IDS detector is designed to detect ARP request and response spoofing using the probing scheme. The scheme has salient features like no protocol change, low false alarm rate, etc. This technique only detects ARP attacks based on the IP-MAC pair conflicts.
In [33], the authors have designed the DES-based IDS detector for the de-authentication attack. The victim's access point gets disconnected from the network due to the deauthentication frame in the network. As for the IDS of ARP, in this case, also the DES-based IDS for de-authentication requires neither protocol change nor firmware upgradation.
Authors in [21] proposed an event-based detection approach to recognize impersonated IP packets. This approach uses proactive authenticity testing of the obtained packets. The active probing scheme uses discrepancies in the Time-to-Live (TTL) values of the received packets to verify whether the earlier packet was impersonating or not. This method helps to identify impersonated IP packets with the help of the DES-based detector.
The critical problem with the DES-based system is that it begins with designing the model from the English language specification of the protocol under normal and attack conditions [27]. The state-transition model is built manually, which may lead to an inaccurate design. It is observed that inaccurate design can have a significant impact on the entire IDS.
In [22], Jiang and Kumar discussed the failure diagnosis problem for DES with LTL specifications. In the temporal logic setting, the diagnosability of DES is established. The issue of diagnostic testing is reduced to that of verification of the model.
The LDES framework has the facility of verification that is missing in the automata-based DES scheme. So, the LDES scheme is adopted for the detection of the Version Number attack in this paper.
The benefits of the LDES framework over automata-based DES are as follows.
• LTL scheme offers a representation of the user-friendly common language specifications as compared to the automata-based DES [29]. • The proof for the correctness of the IDS can be done easily because the automated method, i.e., model checking, can be used for the verification of the LTL specification as compared to the detector of the state-based DES.
The main contribution of the proposed technique for version number attack detection is described below: • To detect DODAG Version Number Attack, LTL-based DES framework IDS is proposed.
• The IDS designed for detecting DODAG Version Number attack does not require protocol modification can work with low resource overhead etc. • The LTL-based DES IDS can be verified to ensure the correctness.

Overview of detector design using LTL-based scheme
This section presents the steps to construct the detector with model variables using the LTL-based scheme.
The tuples of the system model M d for fault diagnosis (or attack detection)are defined as: where, is the set of events. Events can be observable or unobservable.
• τ is the set of transitions.
• AP is the finite set of atomic propositions.
• L is a marking function S i → 2 AP that marks each state with the set of atomic propositions which are valid at each state.

Steps for diagnosability test and detector design
The steps for the design of detector for M d are as follows.
1. The first step consist of construction of FSA known as Buchi Automta, which shows the normal behaviour of the system obtained automatically through the LTL specification. The Buchi Automata accepts the input pattern if there exists a self-loop to atleast one of the final states. Buchi Automata consists of 5 tuples are defined as: where, • C f is the set of states.
• AP is the set of events 2. This step tests the pre-diagnosability of the system model M d . The pre-diagnosability test is performed to verify whether the fault occurrence can be observed within a finite time after its occurrence. The pre-diagnosability property will automatically hold if the LTL formula satisfies a safety property; it means either failure events are never triggered, or failure states are never visited. With this property, the infinite failure trace can be detected through the observations of the state traces. As a result, no detector can be constructed if a system cannot pass the pre-diagnosability test. The proposition synchronization of B f and M d constructs the automata T 1 . T 1 is defined as follows: • L 1 is the marking function.
When every failure state has its own indicator, then the system model is called pre-diagnosable to a specification. So, if the states are visited infinitely often for every infinite proposition generated in T 1 , then the system model is considered pre-diagnosable. The model T 1 1 should assure the LTL specification GF f 1 1 where f 1 1 ∈ F i .
3. The diagnosability of M d is tested in this step. The failure diagnosis approach captures both safety and liveness failures. The system model tests the diagnosability to the specification formula after completing the pre-diagnosability test. The fault diagnosis shows the detection and identification of the faulty states in the model. The diagnosis means either the fault has already occurred or predicts it will occur (liveness property). A detector can be constructed only after the system M d is diagnosable. The construction of model for T 2 consist of 5-tuples as follows: where, is the set of observable events.
• m denotes the set of observable equivalent transitions of .
0 is the set of initial states. Now design, Therefore, language generated through T 2 is all unobservable events are added with observable events equivalent to the language generated by T 1 . Now from T 2 , design T 3 as the event synchronization of T 2 and M d .
The language accepted by T 3 = lang(T 2 )∩ lang(M d ). The diagnosibility can be checked using LTL model checking. 4. The construction of the detector D = (T 2 , M 2 ) is the last step. If any transition is not generated in the language of model T 2 then the detector gives output as "fault".

Proposed technique: LTL based DES IDS for version number attack
This section provides an outline of the proposed technique to detect version number attacks as discussed in Sect. 2. The network under consideration comprises devices with limited power, energy, and processing. The network is assumed to be dense, and the root node is never compromised. After the formation of the DODAG tree, the spiteful nodes show unexpected (malicious) behavior, that is the attack. The assumptions made for hosts connected to the DODAG network that is being monitored for version number modification attack are as follows: 1. Each host connected to the DODAG network is allocated a Node ID. 2. A Spiteful node will never be able to stop a genuine node.

System component and its goal
The block diagram for the IDS used for the detection of the version number modification attack is shown in Fig. 3. The different components are described as follows: 1. Tables and probe: This section discusses how an IDS utilises probe and tables to detect version number attack. It implies that the technique requires extra probe messages,i.e., RQP and RSP packets to verify the genuineness of the DIO message. Additionally, tables are used to maintain the data pertaining to the DIO packet information verified from the host for verification. These tables are helpful for separating the spiteful node from the DODAG to save the probes in future.
- Tables  -Monitoring table: This table is

Working principle of the IDS
Initially, during new DODAG formation, information of all nodes joining the DODAG will be stored in the monitoring table. In the proposed technique, whenever a node accepts the DIO frame from adjoining nodes, a comparison of the DODAG version number (VNN) in the DIO message with the existing version number (VNO) of the accepting node is performed, as illustrated in Fig. 4. The node also checks whether the VNN is greater than VNO or not. If the VNN is greater than VNO, the receiving node(RN) sends the VNN and DIO Sender Node Address (DIO message sender abbreviates as DSNA) to the IDS node (located near root node); otherwise, RN ignores the received DIO message. Now the IDS is invoked to detect and verify the identity of neighboring node DSNA to determine whether the node is spiteful or not. For verification, the IDS node obtains the current DODAG version number with the help of Request (REQ) and Response (RSP) packets. After joining the network, even if a spiteful node transmits DIO's without modifying the version number or other spiteful activity, the network functions cautiously. All nodes can observe the transmission behavior of the neighboring nodes, which ensures the neighboring node's honesty. Each node notices the neighboring node's transmission behavior by examining the DODAG version number sent by its neighbors in the DIO control message. The honesty of a node depends on whether a node has sent the correct version number in DIO or not to its neighboring nodes.
After receiving DIO messages from its neighbors, a node starts examining the DODAG version number field of the DIO control frame. If DIO has high Version Number (VNN) value than receiving node's existing Version Number (VNO), the receiving node (RN) sends VNN and DSNA to the IDS. The IDS is located near the root node. Upon receipt of this information, the IDS searches for the DSNA and RN node IDs in the monitoring table to confirm the presence of nodes in the internal network of the DODAG. If the search is successful, the identification procedure in IDS will be initiated to identify whether the neighboring node (DSNA) is malicious or not. For the confirmation of the neighboring node, whether it is malicious or not, the IDS sends REQ = (destination node address, IDS address, AskVersionNumber) message to know the version number. The REQ message is sent to the root node and DSNA asking for the current version number. Both nodes send responses to the IDS on receipt of the REQ message. The RSP = (IDS address, Target address, Node's latest Version Number) contains version number. Now, the IDS may receive version number from both the node's response messages, i.e., Root Node's version number(RVNI) and DSNA version number (PRVN). The IDS verifies whether the RSP message is received from DSNA or not. If the RSP from DSNA is received, IDS checks whether VNN is equivalent to PRVN or not. If the result is false, node (DSNA) is considered as a Spiteful node; otherwise, it compares VNN with RVNI. Even if the RSP message is not received at the IDS, it compares VNN with RVNI. If RVNI is equivalent to VNN, the node is considered as Normal node, otherwise as a Spiteful node. When DSNA is found as a legitimate node, the IDS adds the entry of DSNA node in the Whitelist table. The confirmation node is validated by verifying the temporarily stored version number on the IDS with the version number received from the response messages. If the IDS receives two or more distinct version number values, it then considers the version number sent by the root node. We assumed that the root node is never compromised and always responds. After DSNA is found as a Spiteful node, the IDS adds the entry of DSNA to the Blacklist table. Now, the IDS alerts all the nodes of the DODAG network about the DSNA. For Intrusion Prevention (IP), a spiteful node will be detach from the DODAG network and will not be allowed to communicate with any node in that particular DODAG. Now, we demonstrate the working of the verification procedure through an example. Initially when the DODAG is constructed current version number of the DODAG is "2" and the details of nodes present in the DODAG network are stored in monitoring table, depicted in Table 1. Considering Fig. 5, node 7 receives the DIO control message with an increased version number, i.e., "3" from node 6. Now, node 7, instead of changing its existing version number with the new DIO version number (VNN), compares them to check if the new version is large than the old version number. Node 7 will send the new version number and node's 6 address to the IDS. After receiving the information sent by node 7, IDS searches for the Node IDs of node 7 and node 6 in the monitoring table to ensure that both nodes are present in the internal DODAG network. If the node ID 7 is found in the monitoring table but node ID 6 is not found, IDS searches for node 6 ID in the blacklist table. If the node 6 ID is found in the blacklist table then IDS alerts node 7 in the DODAG that node 6 is spiteful node, so, another parent node is adjoined and detection process exits; else IDS sends the REQ1 packet to the root node and REQ2 to node 6, asking for the version number. After a while, IDS receives RSP1 and RSP2 from  (2) 3 Address (3) 4 Address (4) 5 Address (5) 6 Address (6) 7 Address (7) the root node and node 6, respectively. Finally, IDS compares the received version number in RSP1 and RSP2 with the VNN and decides whether node 6 is spiteful or normal. If the node is found as spiteful, the IDS adds the information of node 6 to the blacklist table, shown in Table 3 and alerts all nodes of the DODAG about node 6 to disconnect themselves from node 6 and adjoin another parent node. Consider the scenario that the legitimate node, after registering itself in the whitelist table, sends modified version number value (VNN) to launch the threat. In that scenario the node id can be found but the version number value will not match. For example, consider the scenario where the node 6 is legitimate node and has an entry in whitelist table as shown in Table 2. Now the node 6 sends the modified version number as 3 to neighboring node ,i.e., node 7. Now, the IDS searches for the node 6 and 7 ID in the monitoring  Table 3.
Even if any spiteful node drops the REQ message or declines to forward the message due to communication breakdown, the scheme will work. It is so because other intermediate nodes would have received the response messages other than the spiteful node. If any node does not send any response message, that node can be called spiteful. The response message may not be transmitted due to link failure;    (2) 3 Address (3) 4 Address (4) 5 Address (5) 7 Address(7)  (7) in this condition, the node needs to send an error message to IDS.

Challenges
The main challenge for IDS is to detect attacks masked by Blacklist technique. The ability of the IDS would be determined through Blacklisting spiteful node performing the version number attack. The main challenge in the design of the IDS framework is to have an approach that can assure the integrity of DIO message field using low weight approach. There are various ways to secure version number DIO field using trust-based approach, cryptography-based approaches, hardware upgradation etc. These traditional approaches either require change in syntax of a network packet or generates high amount of traffic in the DODAG network. In the proposed technique, the IDS uses extra messages, i.e., RQP and RSP to detect a spiteful node in a DODAG. So, the low weight IDS framework is proposed which does not require change in hardware or syntax of the network packet except two extra messages to detect version number modification attack. It may be noted that the extra probes are as per the RPL protocol and hence do not require change in protocol. The proposed approach also generates limited traffic in the DODAG Another challenge is to verify the correctness of an IDS. This paper mainly focuses on the LTL based DES (LDES) to construct the IDS that detects DODAG version number attack. The LDES is used to render the IDS framework less vulnerable to errors. LDES also performs model checking at every stage of IDS development to verify the correctness, i.e., from modeling to detector design.
The basic idea used in the active IDS for version number attack involves sending RSP and REQ packets to nodes in the DODAG for observations (like changes in version number). It may be noted that development of IDS require a number of manual procedures namely, modeling the attacks from English language specifications of the protocols and vulnerabilities, IDS design etc. Although the protocols and vulnerabilities for IDSs are complex but existing IDSs in the literature lack in formal modeling and verification paradigm. Similarly, the proposed scheme has not been formally verified. So, from the above issue it may be stated that an efficient IDS for detecting version number attack should be verifiable for correctness, dynamic, scalable etc. Therefore, we use formal verification techniques to ensure there are no design flaws in the IDS before its implementation. Most of these parameters are achievable through LTL-based DES framework. The LTL specification describes safe property and use model checking for system verification.
In the next subsection, the DES-based system model is designed for version number attack. Further, this system model helps in designing the detector for version number attack. The LTL-based DES framework helps in modeling verification to ensure the correctness of the IDS. -Transition A transition is a tuple with three values i.e., σ , check(v), assign(v).

DES modelling for version number attack and its detector
For example, DIO, VNN > VNO, VNN ← DIOVN && VNO ← DIOPVN is a transition, where, DIO event is triggered, with the assignment of DIOVN to VNN, and DIOPVN to VNO. There is a checking condition also that checks whether VNN is greater than VNO. RSP1, VNN==RVNI,is another transition where event RSP1 triggers after checking whether VNN is the same as RVNI or not. No assignment operation is performed in the third field of the transition.
-Proposition set The set of propositions are listed as follows.
-P1 → Source state for the detector.
-P2 → DIO frame is received. After any transition of DIO event occurs, proposition P2 is true. -P3 → QRP has been sent. After any transition of QRP event occurs, proposition P3 is true. -P4 → RSP2 frame is received having VNN == PRVN.
After any transition of RSP2 event occurs, proposition P5 is true. The network model for version number attack under normal and faulty conditions are shown in Fig. 6. The model is represented as M d and its description as follows: For the both 'normal and failure (attack)' scenarios, the DES model is described, as depicted in Fig. 6 is given below.
Normal scenario: Initially, the system is normal and is in state S1. When there is a DIO frame, a transition from S1 to S2 occurs. In this transition, the model variables VNN and VNO are initialized by DIOVN and DIOPVN, respectively. Along with the initialization, it checks whether the VNN is greater than VNO or not. If the comparison is true, transition (t1) moves to the S2 state; otherwise, it remains in the initial state. The transition (t2) moves from S2 to S3 when the request RQP frame is received, asking for the version number. This QRP frame is received by the root node and Parent node (node sent the DIO frame). After receiving RQP, the root node and Parent node send the RSP1 and RSP2, respectively. The root node is assumed never to be compromised and reliable. When the response frame RSP2 is received from the parent node, it verifies the received version number PRVN with the VNN. In the checking, if PRVN is equal to VNN, the transition moves from state S3 to S4. This transition is taken only when the frame is received within the required frame response time. Afterward, in this transition, the version number RVNI received from the response frame RSP1 is compared with the VNN. If the comparison is true, then this condition is considered normal. The change of state from S4 to S5 occurs due to transition t4. RSP2 cannot be received due to link failure or any other reason. In that case, the only RVNI version number is verified with VNN. If RVNI is same as VNN, the situation is considered as normal. So, transition(t4) moves from S3 to S6 state. Transition (t7) occurs from S6 to state S10 after the T req time has passed and event FIN is fired. In the normal situation, the VNN should be same as PRVN and RVNI. The RSP2 may not be received; in that case, if RVNI is the same as VNN the situation is considered as 'normal'.
Attack scenario: When there is a DIO frame, transition (t1) from the initial state S1 to S2 occurs. This transition initializes VNN and VNO model variables, respectively, with DIOVN and DIOPVN. The transition also checks the equality of VNN with VNO. If the check is found true, transition moves to S2 state, otherwise remains at initial state S1. When the RQP event occurs, transition (t2) moves to S3. A RQP frame is sent to root node and Parent node asking for version number. The RSP1 and RSP2 events are triggered by root node and parent node, respectively. The RSP1 and RSP2 frames contain the version number RVNI and PRVN, respectively. Further, these responses are to arrive within T req time after RQP is sent. A model moves from S3 to S4 on observation of the event RSP2 by transition t3. After transition t2, responses from the attacker arrives (i) transition (t3) having PRVN the same as VNN (ii) transition (t6) not having PRVN same as VNN, where system moves to state S8. It may be noted that RSP2 event for transition (t6) is considered malicious. But RSP2 event for transition (t3) proceeds with response RSP1. Enabling of transition (t5) is only dependent on RSP1. The model variable equality is ensured by checking RVNI with VNN. In case RSP1 arrives from attacker, the RVNI is not equal to VNN in transition (t5). The transition (t5) fires on receipt of single response RSP1 within T req . It checks RVNI with the VNN and t5 moves to state S9. The transitions (t7) is enabled when event FIN occurs and system moves to state S10.

LTL specification
The LTL specification for the version number attack in the normal scenario is formulated. In terms of events, the spec-ification of the system's non-failure scenario (no version number attack) is described as: Either any response with unmatched VNN-PRVN and VNN-RVNI should not be encountered, or any response (RSP1 and RSP2) frame should not be detected after the RQP request frame is sent before the system terminates.
Therefore, according to the transition set, the specification is considered as: Either t5 and t6 (caused by RSP1 and RSP2) should not be detected, or t7 (caused by FIN) does not occur just after transition t2 before the system terminates.
It can be observed from the proposition set that P5 and P7 are the propositions that are true when transition t6 and t5 occur; respectively, P3 corresponds to transition t2 and P8 is true when t7 exists, and the system terminates.
The specification is described in the form of LTL formula f 1 as: Using LTL, the system s non-failure scenario is stated logically and unambiguously. The conversion of the LTL formula into a Buchi Automata is done automatically. Due to this, the LTL-based framework provides a proper and suitable way to state specifications compared to the state-based scheme.

LTL-based DES detector for version number attack
The construction steps for the detector are as follows: 1. Construction of buchi automata The Buchi Automata B f is obtained from the given LTL specification as follows. Fig. 7 where, .
} are the final states that satisfies the specification expressed through F 1 .
As shown in Fig. 7, B f shows five transitions emerging from the source state B0. All the transitions satisfy (¬P5 ∧ Fig. 8 Model T 1 for f 1 ¬P7). Furthermore, the states that can be reached via proposition P3,i.e., B3 & B6 and B4 & B8, do not have any outgoing paths of P8. This suffices (P3 → X(¬P8)) sub-part of f 1 . After reaching state B5, f 1 is satisfied, and as a result, any subsequent proposition leads to final state B10. B f is a nondeterministic automaton which means, various transitions for the same set of propositions exist. It can be verified manually that "B f accepts all proposition traces over AP satisfying f 1 ". As a result, the specification is represented through an automaton.

Test of Pre-diagnosability using Proposition Synchronization of Buchi Automata and the model
The model is considered to be pre-diagnosable, whenever every infinite proposition trace encounters final states of the automaton infinitely often. A Proposition Synchronization of the M d and B f is used for the testing of Pre-Diagnosibility. Figure 8 depicts the synchronization where Y i_ j denotes (B i , s j ), B i ∈ C f 1 and s j ∈ S i . The proposition synchronization is represented as model T 1 for f 1 . The T 1 consists of 7-tuples is shown as: -R 1 is the transition relation as shown in Fig. 8.
-L 1 represents marking function, which is shown in Fig. 8.
As mentioned in Sect. 4.2, the system model is prediagnosable only if T 1 visits the F i states infinitely for every proposition trace generated by T 1 . In terms of model checking, T 1 must satisfy the LTL specification GFF i . This model checking is performed by NuSMV tool for pre-diagnosibility (is shown in Sect. 6).
3. After completing the pre-diagnosability test, the system model proceeds to test the diagnosability to specification formula. Synthesis of Masked T 1 : With the use of mask function M, T 2 is constructed as shown in Fig. 9.
-R 2 is the transition relation, as shown in Fig. 9.
The set Q 2 contains all those states of T 1 where the transition leading into that state is triggered having an observable event.
Hence, Y 10_10 state (in T 1 ) gets eliminated as t8 is the only transition that leads to Y 10_10 state whose observed event is .
Unmasking T 1 : Now from T 2 , the construction of T 2 is done. T 2 accepts M −1 (lang(T 2 )). The T 2 is represented using 5-tuples shown in Fig. 10 as follows: -R 2 is the transition relation, as shown in Fig. 10.
In a comparison of T 2 with T 2 , self-cycle transitions are an addon to all states of T 2 . For example, (Y 1_1 , t8, Y 1_1 ) ∈ R 2 as Y 1_1 = Y 1_1 and t8 transition triggers the event .
-R 3 is the transition relation as shown in Fig. 11. -AP is the set of proposition, like M d .
-L 3 = Q 3 → 2 AP is the marking function, which is shown in Fig. 11.
All the traces of M d , which has similarly observed traces in T 1 , are produced through T 3 . Therefore, all unobservable event u has self-loop transitions on states Y 1_1 , Y 1_2 , Y 3_3 , Y 6_4 , Y 7_5 , Y 7_6 , Y 5_10 are eliminated although any of the state does not associate to R(i.e., not present in M d ) and remaining transitions from T 2 are present. This way, T 3 is constructed. If M d is diagnosable then all infinite traces generated through T 3 satisfy the f 1 . LTL model checking of the model T 3 with specification f 1 through NuSMV model checker is presented in Sect. 6.
1. Final detector The system model M d is diagnosable, so its detector can be designed. It can be seen in Fig. 9 that T 2 accompany M τ 2 to construct the final detector where, M τ 2 : * → {failure} is a partial function where ∀ s ∈ * , M τ 2 (s) = failure if s is not produced by T 2 .
Using mask M, the detector notices the traces of transitions that are generated by M d . If same trace is not generated by T 2 , the detector shows that attack has occurred as output. For example, consider t1, t2, t3, t5, t11 as the transition trace generated through M d , then its equivalent transition trace t M1 , t M2 , t M3 , t M5 , t M11 is not generated through T 2 . The transition trace t M1 , t M2 , t M3 , t M5 , t M7 corresponds to P1, P2, P3, P4, P7 that violates ((¬P5 ∧ ¬P7)∧(P3 → X¬P8))∪ P8. Thus the detector shows the attack for a trace as a output. On the other side, for transitions t1, t2, t3, t4, t7 the equivalent transition trace is t M1 , t M2 , t M3 , t M4 , t M7 that is generated by T 2 . The trace t M1 , t M2 , t M3 , t M4 , t M7 corresponds to P1, P2, P3, P4, P6 which coheres to ((¬P5 ∧ ¬P7)∧(P3 → X¬P8))∪ P8. Thus, the detector shows normal for this case as output. Any transition that does not satisfy the property i.e., any transition is not generated in the language of the model T 2 then detector shows output as attack.

Performance evaluation
The performance of the Version Number detection technique has been evaluated through simulation and the NuSMV model checker.
In this work, we considered the random topology with the increased percentage of the spiteful node to analyze the performance changes in the metrics. The simulation topology consists of 20 nodes, i.e., root, IDS, and remaining sensor nodes, as shown in Fig. 12. All nodes are placed in a 100x100m area. In random topology, all nodes are placed randomly except the IDS node. The IDS node lies near the root node. Here, node 1 and node 2 are considered as the root node and IDS node, respectively, as shown in Fig. 12a. In other scenarios, the simulation setup has nodes 19 and 20 as spiteful nodes, depicted in yellow. Figure 12b has only node 20 as a spiteful node, and the scenario shown in Fig. 12c has nodes 19 and 20 as spiteful nodes. In such a way, we have considered there scenarios wherein the number of spiteful nodes increases by 5%.

Simulation environment
The detection technique uses the Contiki 2.7 operating system and its Cooja simulator for performance evaluation.
Contiki is an open-source and multi-tasking operating system for wireless sensor networks. The Contiki 2.7 update  contains the Contiki RPL protocol [5]. Cooja is a simulator for the simulation of the networks of sensors running over the Contiki operating system. On a plane square, the Tmote Sky motes are introduced. All motes, i.e., motionless motes, are called static motes. For all motes, the communication and interference range is 50 and 100 meters, respectively. The simulation is verified 20 times for each scenario, and the average values for all parameters are determined. In Table 6, the simulation parameters and their values are given.
By increasing the number of spiteful nodes in random topology, the performance of the detection scheme has been assessed. For an attack or normal case, each simulation runs for 50 minutes. It is assumed that 50 minutes are sufficient to determine the network's performance and the network's DODAG becomes stable within three minutes.
Performance parameters: The following performance parameters are considered: False Positive Rate (FPR) is computed as per Eq. 3. In Eq. 3, FP is the number of false positives while N refers to the total number of negative cases. FP is a case in which our proposed mechanism detects legitimate node incorrectly as spiteful node.

Analysis on simulation results:
The performance of the simulation parameters in terms of accuracy metrics, i.e., True Positive Rate (TPR) and False Positive Rate (FPR) with the distinct percentage of spiteful nodes are shown in Table 7, and resource requirements like average power consumption and memory utilization are shown in Fig. 13 and Table 8, respectively.
As seen from Table 7, the true positive rate drops when the percentage of spiteful nodes rises. It happens because an increased percentage of spiteful nodes may collide, and therefore, IDS can not detect all spiteful nodes. It is showed that the proposed scheme functions well with near about 99.7 and 95.5 true positive rate when the percentage of the spiteful node is 5 and 25, respectively. Table 7, it is also shown that false-positive rates rise with the increased percentage of the spiteful nodes. It happens when there is no path to send the version number value to the IDS node to verify the version number.
The simulation uses the emulated sky motes [1] which utilizes the MSP430 controller to determine the memory usage. The controller consists of 10 KB RAM and 48 KB ROM. The verification technique requires the extra overhead of sending the probing packets and verifying the node, which requires extra RAM and ROM usage. In this case, an additional 327 bytes and 743 bytes of RAM and ROM are required, as shown in Table 8. It may be noted that this memory requirement is reasonable. The IDS stores the DIO message VNN and DIO  Fig. 13, which correspond to the RPL+Spiteful node and RPL+IDS+Spiteful node environments. It can be seen that the power consumption increases with the increase in the percentage of spiteful nodes. It happens since packets are dropped due to a global repair mechanism. This causes the nodes to waste energy due to the repeated transmissions of the packets. Therefore, it leads to high power consumption. When the efficiency of the IDS is checked, we can see that power consumption has been reduced compared to the RPL+Spiteful node environment.
The performance of the network parameters, i.e., Packet Delivery Rate and Control Message Overhead against the distinct percentage of spiteful nodes, are shown in Figs. 14 and 15, respectively. The PDR performs better when there is no spiteful node in the network, i.e., higher than 99. Nevertheless, when 5% of the total nodes are spiteful in the network, the PDR value drops drastically to nearly 40 percent from 99 percent. The PDR value depreciates more with the increase of spiteful nodes. However, our proposed detection technique works efficiently, as it reduces the effect of the Version Number Attack. Figure 14 shows that the PDR of the proposed technique is better in the RPL+IDS+Spiteful scenario than the RPL+Spiteful scenario. It happens because our proposed technique detects the spiteful node more accurately after the verification of the suspect node. The verification node does not update the new Version Number sent from the suspect node until the verification procedure gets complete and the suspect node gets verified as normal. The packet is sent to the The performance of the Control Message Overhead (CMO) can be seen in Fig. 15. The CMO of the RPL+Spiteful environment increases drastically even when 5% spiteful nodes of total nodes are present. The CMO increases with the increase of the spiteful nodes in the RPL+Spiteful environment. It happens because of the version number attack behavior. However, the proposed solution s control overhead is not proportional to the percentage of spiteful nodes, as the proposed scheme prevents DIO s from the broadcasting process, which broadcasts for the reconstruction of the DODAG. As a result, the CMO is much lower in the RPL+IDS+Spiteful environment than the RPL+Spiteful environment, as shown in Fig. 15.

Presence of tables:
The performance of the parameters, i.e., power consumption, control message overhead and memory usage in the presence and absence of the blacklist and whitelist tables in the IDS, are measured. is present in the IDS, only the history of genuine nodes is maintained. So, REQ messages will be sent from the IDS to verify even for those DIO messages that were previously determined as spiteful. In the presence of only a whitelist table, more REQ messages will be sent from the IDS compared to the presence of both tables. Figure 16 represents the effect over average power consumption in the presence of only blacklist or whitelist or both tables. The power consumption of the IDS is proportional to the number of REQ messages sent from the IDS. It can be seen in Fig. 16 that the power consumption is lowest when both tables are present and increases as the table are reduced.
The performance of the control message overhead in the presence of only blacklist or whitelist, or both tables can be seen in Fig. 17. As in the case of power consumption, the control message overhead is proportional to the number of REQ messages sent from the IDS. The graph of Fig. 17 shows similar trends as power consumption.   Table 9 shows the memory requirement of either only blacklist or whitelist table. The memory requirement of the individual whitelist and blacklist table is 104 and 53 bytes, respectively. It can be seen from Table 9 that the memory requirement is minimal for both tables individually, but togetherly both tables are advantageous in improving the efficiency of the IDS. Table 10 represents the comparison of studies in the related work with the proposed approach. It is shown in the table that the proposed approach provides better network performance, i.e., in terms of PDR and CMO. The proposed solution supports random topology and performs better than the studies in the related work. The PDR and CMO obtain the best result, i.e., 98.7% and 1100 pkts/sec, respectively.
Model checking: NuSMV [2] is a platform for describing the models and validates LTL formula(s) for these models. It accepts the program (describing a model) in the form of text as input. It shows the output as 'true' over the given LTL specification; if the specification holds, it otherwise generates a trace where the specification is not satisfied. As discussed in section 4.3, the LTL specification used for the normal condition is as follows.

Pre-diagnosibility Model Checking:
The pre-diagnosability testing of the system model M d (as depicted in Fig. 6) is done through NuSMV model checking. Figure 18a depicts the code snap for the pre-diagnosability of M d . The variables status and ev are of enumeration type. Both variables status and ev are initialized with proposition value (pone) and event (DIO) that can be seen in Fig. 18a. The variable ev is assigned the value among DIO, RQP, RONE, RTWO, EXP, UNOBV of different events. Proposition values like pone, ptwo, three, pfour, psix, peight are referred through the variable status as depicted in Fig. 18a. The definition of a transition in NuSMV is not supported, so the code snap consists of the triggering events of transitions (for example, DIO denotes t1). Furthermore, the propositions are presented in words (e.g., P1 is represented through Pone; similarly, other propositions are represented). The cases are evaluated where P8 is true for the pre-diagnosability test. The result is true for the specification (GF(P8)) that can be seen in Fig. 18b. So, it can be said that the system is pre-diagnosable, as model T 1 satisfies the specification.
Model checking Test for Diagnosability: For testing the diagnosibility, the event synchronization of the system model and T 2 model together constructs the model T 3 as depicted in Fig. 11. The code snap for diagnosibility testing and output corresponding to T 3 are shown in Fig. 19 with the help of NuSMV model checker.The system model is said to be diagnosable with respect to T 3 , as, model satisfy the specification ((¬P5 ∧ ¬P7) ∧ (P3 → X¬P8)) ∪ P8.
As T 3 is formally verified, the diagnoser can be constructed (as per Section 4.5), and the resulting IDS can be considered free of errors.

Validation by LTL
In this section, we show how the LTL model checking helps in validating the model developed from the protocol of the network under normal and attack conditions. The construction of the DES model is done manually and since the protocol and attacks are complex, manual modeling is prone to errors leading to IDS having flaws. Here, we present an example where the model has a manual error and how LTL based framework detects the same.
The DES model with error is shown in Fig. 20. The DES model is designed manually based on the protocol for both normal condition and attack on the DODAG network for version number.  Fig. 18 Pre-diagnosibility testing of the model Fig. 19 Diagnosibility testing of the model

DES model with Manual Error
The DES model with manual error is depicted in Fig. 20.

Verification by LTL framework
The specification considered for the verification of the model with error is shown in Fig. 20 is same as considered in Sect. 5.4 for DES model without error. The specification is ((¬P5 ∧¬P7)∧(P3 → X¬P8))∪ P8 . The LTL specification is represented as f 1 .

Construction of buchi automata for erroneous DES model
The Buchi Automata B f _err or is obtained from the given model with error (M d_err or ) and LTL specification is shown in Fig. 21. Fig. 21 where, The buchi automata for DES model without error is shown in Fig. 7. In comparison of Fig. 21 with Fig. 7, we can see an extra transition A10 from B2 to B10 in Fig. 21.
The transition A10 takes place when no response message is received against the request message sent from the IDS. According to LTL specification, there must be no direct transition from proposition P3 to P8.

Test for pre-diagnosability for erroneous DES model
The model with error for pre-diagnosability is shown in Fig. 22 that is constructed using synchronization of buchi automata (B f _err or ) and DES model with error (M d_err or ) of Figs. 20 and 21, respectively. The proposition synchronization is represented as model T 1_err or for f 1 . T 1_err or consists of 7-tuples as: = set of events { DIO, RQP, RSP1, RSP2, FIN, u} -= { t1, t2, t3, t4, t7, t8 } is the set of transitions.
-R 1 is the transition relation as shown in Fig. 22.
-L 1 represents marking function, which is shown in Fig. 22.
The pre-diagnosability model for DES model without error is shown in Fig. 8. In Fig. 22, we can see an additional transition t7 from Y 3_3 to Y 5_10 in comparison with Fig. 8. The transition t7 occurs in pre-diagnosability model with error (T 1_err or ) when no RSP message is received at the IDS for the REQ message sent from IDS. The model checking based validation for T 1_err or performed by NuSMV tool for testing pre-diagnosibility is shown in Fig. 24. In terms of model checking, T 1_err or must satisfy the LTL specification GF F i .

Test for Diagnosability for erroneous DES model
After passing the test of pre-diagnosability, the system proceeds to test the diagnosability for LTL formula ( f 1 ). -L 3 = Q 3 → 2 AP is the marking function, which is shown in Fig. 23. Figure 23 represents the final diagnoser with error (T 3_err or ) that is constructed from the DES model with error (M d_err or ). The final diagnoser model T 3 without error is shown in Fig. 11. In Fig. 23, the extra transition t7 occurs from state Y (3_3)3 to Y (5_10)10 that is not present in Fig. 11. In error model, no response frames RSP1 and RSP2 are received from root node and parent node, respectively, after receipt of RQP frame at state Y (3_3) 3 . This shows that for REQ probe message no RSP message is received. In the error DES model, the case of non-receipt of response for REQ probe is also considered as attack. This is a false positive. The non-receipt of response for REQ also contradicts the assumption considered that for every REQ message there must be atleast one response message. The model T 3_err or shown in Fig. 23 is constructed to test the diagnosability. However, the designer of IDS constructs incorrect model M d_err or depicted in Fig. 20. The model checking test for diagnosability is shown in Fig. 25. The code snap for diagnosability testing and output corresponding to T 3_err or are shown in Fig. 25 with the help of NuSMV model checker. The output is shown as false and gives the path of error as counterexample. In the counterexample it is shown that model T 3_err or is having path from P3 to P8 that does not satisfy the formula f 1 . It contradicts the assumption, where atleast one response (RSP) message should be received for the request (REQ) message. The LTL-based scheme is important as it helps in verifying the correctness of the diagnoser.

Conclusion
The LLN devices are constrained in terms of low resources, high packet loss, etc. The RPL protocol uses DODAG version number to form DODAG (acyclic) topology. However, there is no technique to authenticate the DODAG version number. So, RPL has become vulnerable to DODAG version number attacks. DVN requires neither any change in packet format nor the sequence of packets and hence falls into the category of stealthy attacks. DES-based IDS has been applied for stealthy attacks that achieve low false alarm rates, low overhead, etc. The construction of DES-based IDS for the network protocol is done manually, which may lead to errors. So the designed IDS does not guarantee its correctness. Therefore, the LTL-based DES scheme has been used to design and formally verify the proposed DES-based DODAG version number detection scheme that deals with its correctness. The IDS detects spiteful node and alerts all nodes of the DODAG network. Now, the legitimate nodes as prevention not allow a spiteful node to communicate within the DODAG.
The proposed detection scheme has been simulated in the Contiki cooja simulator. The simulation results show the accuracy of 99.7% and 95.4% when the percentage of spiteful nodes are 5% and 25%, respectively. The true positive rate decreases with the increase of spiteful nodes, whereas the false positive rate increases with spiteful nodes. It happens since there is no path to send the version number value to the IDS node for its verification. In sending the packets and verifying them, the nodes require extra 327 bytes and 743 bytes of RAM and ROM, respectively, which are minimal when compared to the memory available in IoT nodes.
We plan to advance the proposed research work using a test-bed environment to validate the results in a real environment. Future research could be to analyze the version number attack collaborated with other attacks. Various other DES diagnoser concepts like stochastic approach, logical approach, petri net models etc. can be explored to develop IDS frameworks for different classes of attacks. As IoT networks are also getting popular, applicability of the proposed IDS framework may be explored for IoT frameworks.
Data Availibility Statement Data cannot be made available for reasons.

Declarations
Conflict of interest All author declares that they have no conflict of interest.
Ethical approval This article does not contain any studies with human participants or animals performed by any of the authors.