# A Specification-Based IDS for Detecting Attacks on RPL-Based Network Topology
## 5 Further Considerations on Expanding the IDS Capability to Detect More Internal Threats  
Topology attack is only one type of internal threats that can happen with the RPL-based network. The nature of the specification-based IDS makes it suitable to detect this type of attack because all the collected monitoring data and set of rules can be used straight forward for detect the illegitimate protocol behaviors with small amount of overhead and little requirement on storage and computing. As aforementioned, this work is only part of our on-going research on detecting the internal threats. In detail, besides topology attacks, there are still other internal threats that aim at performance directly, as discussed comprehensively in our previous work [2]. Apart from the protocol side, node behaviors also depend on other conditions such as applications, environments and so on. The set of protocol rules obtained from the specification-based IDS cannot reflect node behaviors regarding such aspects, therefore, it may not be effective in dealing with the performance-type internal threats. For example, internal adverse can follow the protocol operation yet still manipulating other performance behaviors such as sending, forwarding or controlling activities at the lower layer. To deal with this type of internal threats, a more proper anomaly-based IDS technique needs to be applied. As the accuracy of any anomaly-based IDS will correlate to the robustness of the detection algorithm and the amount of monitoring data that the system collected, the storage and computation capability need to be extended more. Note that the specification-based IDS in this paper collects only a small amount of monitoring data, while using simple comparing and checking algorithms, therefore, the cluster head can still adapt with the storage and computation workload. However, if we want to employ anomaly-based IDS with larger monitoring data and more robust detection algorithm such as Bayesian network or other data mining techniques, the cluster monitoring architecture will not be able to deliver. To enable the use of a more robust anomaly-based IDS working on a larger amount of monitoring data, we envisage an architecture that can extend the computation and storage capability of the IDS massively, yet still keep the network overhead low and acceptable for operating. In detail, we extend the cluster monitoring architecture by first making benefit from the multiple-interface design that allows the sensor devices to communicate in different channels. One real life example is the Libelium Waspmote devices that allow many wireless communication standards such as Wifi, 3G, GSM, GPRS, LoRa, and so on apart from sensor data transmission [16]. We can use the multi-interface sensor devices as the cluster heads to communicate both in RPL-based network and another overlay network, which supports high speed, long distance, and low power consumption transmission. There are many options for such overlay network, for example, the IEEE 802.11, LTE, 3G, _etc_. By doing so, we aim at transferring the IDS monitoring data directly to an IDS server through the overlay network by the extra interface. To compare with the network-based architecture, sending IDS data to the server through the overlay channel will eliminate many communicational issues such as overhead, delay, packet loss, _etc_. Moreover, we propose to implement the Cloud Computing [17] application at the IDS server. The IDS work deal by the server only before now can be delegated to many other computers in the Cloud, which helps to enable the IDS computation and storage capability massively. The additional cost for implementing this architecture is only a little, given the reasonable price of multi-interface cluster heads, IDS data collection, and Cloud Computing service.