## 10 Attack Detection Perspective  
Based on the overhead estimation of our protocol, we are able to allow nodes to detect certain types of attack attempts. Indeed, when a node is attempting an attack, it will induce additional overhead due to the execution time of cryptographic operations that the attacker needs. Moreover, even in the man-in-the-middle attack, the wormhole attack or the replay attack, the attacker needs to listen, forward or generate some encrypted messages. All these operations will cause an additional delay to the estimated overall request/reply procedure of the authenticated join protocol or key establishment protocol. We assume that the attacker has the same processing capacities of the nodes; in other words, we assume that an intruder was able to control one or more nodes of the network and is trying to launch the attack using the compromised nodes. The attacks that this technique is able to detect are the ones that will introduce additional delay to the process. For example, the node that is requesting to join the network will be waiting for an authenticated response. This response should be received before a certain timeout expires. This timeout can be estimated according to the number of hops that separate the new node from the sink and the type of protocol that is used to join the network. For example, if the new node is 5 hops away from the sink, with a 160-bit key, it will take \(6834.20\) plus the end-to-end communication delay for a node to establish a key with another node in the network by passing through the sink (\(MKE_{S}\)). Indeed, the results shown in Table 3 represent the execution time without taking into consideration the end-to-end communication delay that is induced by the intermediate nodes. This delay can be estimated by the routing protocol and taken into account when calculating the estimated overall time of the process. In order for the attack detection to be efficient, the end-to-end communication delay should remain considerably lower than the delay induced by additional cryptographic operations. Hence, according to the protocol that is being used, the new node is able to estimate when it is expected to receive its response. Therefore, if a node does not receive an answer on time, it can deduce that this delay might have been caused by an intruder and then decide to abort the current join process or key establishment process and try to restart it. This means that a reply will be discarded if received later than expected. This \begin{table}
\begin{tabular}{c c c} \hline \hline
**Protocol Name** & **Execution Time on the Testbed (ms)** & **Standard Deviation (ms)** \\ \hline \(DJS\) & 10,186.49 & 5.94 \\ \(IJS\) & 10,291.24 & 5.71 \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Total execution time for protocols \(DJS\) and \(IJS\) using the same random number in ECIES encryption. attack detection will help prevent a node from accepting late replies, and restart the process to ensure that the response is received within a certain timeout interval. Delay estimations should be done for each network configuration and deployment because they are affected by the traffic state and the congestion that might be present in the network. In this paper these estimations are out of scope and will be the subject of future work. Also, in order for the detection to work, the new node should know how many hops it is away from the sink. This information can be obtained from the routing protocol. One way to obtain this information could be the following. When the new node decides to join the network, it will listen for signalling messages from neighbouring nodes. These signalling messages should contain how many hops the signalling node is away from the sink. This way, the new node is able to estimate the delay in receiving the response. In this simple approach, we do not consider the case where certain nodes will deliberately announce that they are farther away from the sink in order to delay the process or try to launch attacks.