# A Specification-Based IDS for Detecting Attacks on RPL-Based Network Topology
## 3 A specification-Based IDS for RPL to Detect the Topology Attacks
### Design and Implementation of the Specification-Based IDS for RPL-Based Network
#### 3.2.2 IDS Data Collection  
Similar to [6], we do not make the cluster head to change to promiscuous mode to eavesdrop all the radio communication around because it will drain its battery out quickly, while the obtained information in this case also has only limited use. Instead, we make the cluster head to request its members to report its topology information periodically. The period is set up depends on the particular scenario. Once the members receive such request, they need to send their neighbor lists with corresponding ranks, the preferred parent, and its own rank. Such information are already stored in the routing table of each node for the purpose of selecting its preferred parent, therefore, there will be no additional cost on storing and computation. By doing so, we save the resource for the cluster head while expanding the view to even nodes which are outside the cluster. As nodes report information of its neighbors, a cross-check of the collected data is required. However, the cross-check process suffers from the synchronization issue when the IDS agent cannot check whether the data from the neighbor is collected later or sooner than data from the node itself. This issue was first pointed out by [PERSON] _et al._[15], through the example illustrated in Figure 4 as follows. Let A is a normal node in the network and N is its neighbor. At time \(t_{1}\) when A broadcasting its DIO, its rank is 3 and N record rank of A as 3 in its memory. At time \(t_{2}\), A updates its rank to 4 but because it is not the time to send the new DIO yet, so A does not send any new DIO, and N still store the rank of A as 3. Soon after \(t_{2}\), at \(t_{3}\), the root requests nodes to send IDS information. In this case, node A will send its rank as 4 (its current rank) while node N informs the root that the actual rank of A is 3. The rank information of node A that it and node N reported is not the same because the recording time was not synchronized. This synchronization issue makes the root consider that the rank of A is not consistent, hence detect A as malicious node, which create a false detection. [PERSON] _et al._[15] proposes an improvement by letting the nodes send only the rank information in its latest broadcast DIO, rather than the latest rank it has. Moreover, they separate the rank inconsistent threshold when detecting the consistency, in which if there is time difference when receiving the report rank (information from the node itself) and the monitor rank (information from the node's neighbors), the threshold will be higher than it in the case there is no time difference. However, this solution still cannot overcome the synchronization issue in some of the cases. For instance, based on Figure 4, in Figure 5, we added node P as node A's parent and N is the neighbor of both A and P. At time \(t_{1}\), P has rank 2, A has rank 3. In time \(t^{\prime}_{1}\), P update its rank to 3, hence it broadcasts this new information to the neighbors. At time \(t_{2}\), node A receives this information and increase its new rank to 4 without updating its rank for the neighbor yet. At time \(t_{3}\), the root request every node to send IDS information. According to [PERSON], P will report its rank as 3 because it already sends the new DIO before the root request. On the other hand, node A will also report its rank as 3 because its next DIO is scheduled after the root asking for report. Both of these reports are considered consistent under the view of node N. Now, A and P has the same rank as 3, both are considered consistent, but according to the rank rule, P is the parent of A so it should have a lower rank than A. As a result, both A and P may be considered as malicious source. In order to solve the synchronization issue as raised above, we propose to add the sequence number information in the DIO and DIS messages in order to make the cross-check more reliable.