## 5 Implementation Steps
### Communication between SRF-IDS and Monitored Devices  
Communication and routing among devices is handled by the RPL-lite protocol. The SRF-IDS and monitored networks operate as usual in two different RPL instances. Nodes accept packets destined only for their RPL instance. Therefore, a solution was needed to allow SRF-IDS to alert monitored devices about attackers. As discussed in Section 4.4, the SRF-IoT scheme works with the help of an external SRF-IDS. A first prototype of SRF-IDS was presented and evaluated for detecting DIS attacks in our previous work [12]. However, as already discussed in Section 4.1, more features are added. The new implementation includes the possibility of monitoring devices operating in a different RPL instance, detecting packet forwarding behaviour of a monitored node, and communicating with neighbouring devices. Apart from that, the detection mechanism for DIS attacks is not affected. Allowing SRF-IDS to communicate with monitored nodes is essential to enable SRF-OF to calculate trust correctly. Trust is calculated by each node using the metrics received from SRF-IDS detectors. To achieve this, we implemented a new ICMPv6 control message in Contiki-NG. The implementation was done for SRF-IDS detectors and the nodes that could be monitored. SRF-IDS detectors are able to send special packets to nodes in RPL InstanceID zero, and include metrics noted in Section 4.3. Algorithm 3 presents the actual implementation that is used by SRF-IDS detectors to send packets to neighbouring devices. As it is shown, SRF-IDS detectors iterate over their neighbours and create a buffer that contains the metrics. For each neighbour, SRF-IDS detectors send the IP address of the node, the _verifiedIP_ flag, and the number of forwarded packets. After adding the metrics into the buffer, the SRF-IDS detector sends the ICMPv6 message using a custom RPL code to the neighbouring device. Moreover, the detector sends the same information to SRF-IDS root for detecting potential blackhole attackers. If no information is available for a device, the SRF-IDS detector does not send any packets to neighbours. Custom ICMPv6 packets are parsed by benign/malicious nodes to extract metrics and calculate trust using the appropriate formulas. We assume that these ICMPv6 packets are encrypted and only nodes participating in the monitored network can read its contents. Although malicious nodes can receive and read packet contents, the metrics will be related to their parents. Therefore, it will be useful even for them to select a benign parent based on metrics. In cases where a monitored node receives metrics from multiple SRF-IDS detectors, an appropriate mechanism is in place to handle these cases. For example, let M\({}_{\text{a}}\) be the monitored node, IDS\({}_{\text{a}}\) and IDS\({}_{\text{b}}\) the SRF-IDS detectors, and D\({}_{\text{a}}\) a candidate parent. If IDS\({}_{\text{a}}\) sends a packet with metrics to M\({}_{\text{a}}\) for device D\({}_{\text{a}}\) that contains _verified\({}_{\text{a}}=1\)_ and _packets\({}_{\text{a}}\)_\({}_{\text{a}}=5\)_, the M\({}_{\text{a}}\) will store it normally. In a later moment, if IDS\({}_{\text{b}}\) sends another packet that contains _verified\({}_{\text{a}}=0\)_ and _packets\({}_{\text{a}}=0\)_, node M\({}_{\text{a}}\) will aggregate the knowledge and calculate trust with the proper weight factor. Node M\({}_{\text{a}}\) will consider its actual transmitted packets to check if _packets\({}_{\text{a}}\)_\({}_{\text{a}}=0\)_ is correct or not. A candidate parent is verified after consecutive notifications arrive by multiple SRF-IDS detectors.