## 9 Results and Discussion  
HIP DEX is the most encouraging candidate of the authentication or bootstrapping processes in IoT. Since it is more legitimate to optimize an IoT-designed protocol than working on existing Internet standards, our effort focuses on the quick authentication process to access a WSN integrated into IoT based on HIP DEX protocol. Authentication in IoT, which is composed of hundreds of devices, must have a lower cost overhead in terms of the computation and communication of exchanged packets. Indeed, we worked on minimizing the energetic costs of the authentication based on the HIP DEX protocol as a keying material. Our contribution is around three axes: the first one is the compression of the HIP DEX packets' header with adaptation to the 6 LowPAN packet header. The second one is about the optimization of the number of exchanged messages during the handshake. The last one consists of a novel solution that implements HIP DEX's handshake in opportunistic mode. The proposed compression model, presented in Section 3.4, contributes with an efficient minimization of the energetic communication and computational costs comparing with existing works. The optimization of the handshake process concerns the avoidance of two signaling packets (NOTIFY and CLOSE_ACK). We are not the first to propose the compression technique of the HIP protocol, but we are the first to propose such a minimal compression header. In this section, we discuss and compare previous HIP solutions with LC-DEX. Slimfit [17] cannot be suitable for lossy IoT networks because it does not deal with the minimization of the communication overhead that we consider an obstacle on the real-time application on the IoT. In contrast, LC-DEX is considering  
\begin{table}
\begin{tabular}{p{113.8 pt} p{113.8 pt} p{113.8 pt} p{113.8 pt}} \hline \hline
**Attack** & **Layer** & **Scenario** & **Defense** \\ \hline Collision attack & Link & A collision is triggered by the usage of the same channel frequency by the HIP peers. & HIP communicating peers should implement a solution to avoid collision attacks. \\ \hline \multirow{4}{*}{Denial of Service (DoS) attack} & \multirow{4}{*}{Link} & An attacker may produce a collision when transmitting the signaling CLOSE_ACK packet. A bombardment in transmitting repeatedly such resulting collision has a costly resource consuming on the victim node. & \multirow{4}{*}{HIP peers must be protected against DoS attack.} \\ \cline{3-3}  & & An adversary try to flood the edge 6 BR to interrupt the communication between the peers. & Compressed HIP packets should be protected against the flooding attack on the 6 LoWPAN edge router. \\ \hline \multirow{4}{*}{Data freshness} & \multirow{4}{*}{Link} & An adversary lunch a replay attack using an old shared key at the same time when a new key is being distributed to the nodes. The adversary stores exchanged HIP messages and then initiates the communication with the peers. & HIP peers do not receive new keys from an external appliance. \\ \cline{3-3}  & & & An attacker can store the HIP packets (I1, R1, I2, R2) and then replay a packet with the HIP peer as it is the legitimate target. & \multirow{4}{*}{The exchanged HIP packets must be protected against MITM attacks.} \\ \cline{3-3}  & & & An attacker may lunch node capture attacks on the gateways and get cryptographic keys and add other malicious nodes in the network as legitimate ones. & \multirow{4}{*}{A defending strategy must take place.} \\ \cline{3-3}  & & & & Athis issue and shows better results in communication energy cost compared with previous works. D-HIP [19] and HIP-TEX [44] are not optimal solutions that can be implemented on IoT solutions because they increase the communication overhead due to the increase of the exchanged messages caused by the integration of the proxies selection on the distribution model during the authentication process. Security features in LHIP [16] are maintained and communicated over the exchanged messages but ignored by the pairs.