## 8 Security Considerations  
Traditional security techniques are characterized by their important overhead in terms of computation and communication costs. Hence, these mechanisms are infeasible in the WSN based-IoT that contains sensor nodes with low processing and memory capabilities. Table 16 recapitulates the possible threats that can occur during the LC-DEX handshake and the security requirements that should be considered. _Collision attack_: The channel frequency is not fixed arbitrarily by the nodes. We propose to implement a dynamic selection of the Frequency Hopping Techniques after defining the quality metrics [41]. Besides, the interference probability of the exchanged packets between the communicating HIP peers decreases considerably. The combination of this technique in addition to the minimization of the communication overhead, improved by our proposed solution LC-DEX, may decrease the collision attack. _DoS attack_: The countermeasures against DoS attacks must be defined regarding the different networking layers. Since our work focuses on the link layer (exactly on the MAC layer), we discuss only the DoS attacks on the link layer. HIP DEX is designed to protect communications against DoS attacks that are due to the puzzle mechanism. More the puzzle is difficult, more the communications are protected against DoS attacks. Besides, the minimization of the processing overhead in LC-DEX decreases the probability of such attacks. _Flooding attack_: The compression and decompression are performed on the 6 BR the most near of the HIP peers except the edge router. An adversary tries to flood the 6 BR on the edge of the IoT domain. In our implementation, we propose that compressed HIP packets are only forwarded by the edge 6 BR if the target is in the external network with the use of the firewalls and Intrusion Detection System (IDS). For this reason, we firstly propose that all the sensor nodes in the internal WSN are running a robust IDS like SVELTE [42] and especially the IDS proposed in [43] designed for securing WSN 6 LoWPAN networks \begin{table}
\begin{tabular}{l c c} \hline \hline
**Extension** & **RAM (KiB)** & **Memory Percentage Use** \\ \hline Linux OS & 7864 & - \\ Initiator (I1 + I2) & 8140 (+276) & 3\% \\ Responder (R1 + R2) & 8136 (+272) & 3\% \\ \hline \hline \end{tabular}
\end{table} 
Table 15: Memory consumption of LC-DEX software. based on RPL as it is the adopted routing-protocol on our work. The internal 6 BR is charged with the compression/decompression of HIP packets. Hence, with this strategy with the performed computation overheads of LC-DEX, flooding attacks will be minimized in advantage. _Data freshness_: We study this attack on two sides : (1) Null old message is being replied by an adversary using an old shared key; (2) The attacker stored old HIP packets and then replay them with the communicating peers as it is a legitimate node. In (1), an attacker used an old key to initiate the connection with the HIP peers at the same time as the distribution of a new key for all nodes in WSN. In our solution, HIP DEX shared key is not distributed to the nodes in the IoT domain. The shared secret key is shared only between the nodes that initiate communication using HIP DEX in the handshake. In (2), the HIP DEX used a two-factor authentication mechanism [5]. The Initiator stores a shared group key that will be used to encrypt credentials in the I2 packet. After reception of the I2 packet, the responder verifies that its puzzle challenge was encrypted with the shared and correct key. If it is the case, the handshake is continuing the process, else the connection is discarded. The attacker does not know the group key shared between the HIP peers and especially the private key. We could also propose to add a time counter, as a sequence number of packets, to ensure data freshness by implementing an algorithm for that in the correspondent HIP peers.