## 3 A Proposed Robust Scheme Based on Hop-Count Analysis (MHA)
### RREP number limit and Graylist Broadcast  
The RREP packets are finally sent back to the source node. In our MHA protocol, we set a _RREP number limit_ (\(\mathrm{RREP_{lim}}\)) to consider the reasonable amount of routes that are found in a route discovery procedure. This is designed for a special circumstance in attacking RFC 3561. In Figure 5, there is a wormhole between a communication pair. Due to the better metric of the wormhole, the RREQ packet rebroadcast by the wormhole is accepted by the nodes around the destination node at first. Consequently, the RREQ packets which are flooded from the normal nodes later will be dropped. As a result, only the route through the wormhole can be established.  
The \(\mathrm{RREP_{lim}}\) can prevent this situation. This value can be adjusted according to the network circumstances. For example, in a highly trusted environment, where most nodes consist of familiar people, we can safely decrease the \(\mathrm{RREP_{lim}}\) value in the route discovery procedure. First, we set the default \(\mathrm{RREP_{lim}}\), such as \(\mathrm{RREP_{lim}}=2\). After the source node receives all RREP packets, it compares the number of received RREP packets \(\gamma\) with \(\mathrm{RREP_{lim}}\). If \(\gamma<\mathrm{RREP_{lim}}\), it probably means that there is a wormhole, or too few nodes in the network. The source node then launches the graylist broadcast in this situation.  
The graylist broadcast contains the following steps:  
1) \(\mathrm{CF}+1\) in the RREQ packet;
2) \(\mathrm{Adds}\) all intermediate nodes which are found in the last route discovery procedure into the graylist;
3) \(\mathrm{Broadcasts}\) the RREQ packet with the graylist.  
Figure 5: Route establishment under the wormhole attack.  
In the graylist broadcast illustrated by Figure 6, the nodes handle the received RREQ packet in following steps:  
1. Check CF to confirm the broadcast type. When CF \(\
eq\) 0, check IP\({}_{\text{S}}\), IP\({}_{\text{D}}\) and RREQ ID to determine the communication pair;
2. Compare CF with the cached value;  
Figure 6: Graylist broadcast in MHA protocol.  
* If it is the same as the cached one, check the received graylist with the cached one;
* If they are the same, drop the packet;
* If some values in the graylist are suspected to be modified by the malicious nodes, alert the source node of the modified value. The source node then marks the suspect IP address in the blacklist The blacklisted nodes will not be used for a period;
* If CF is larger than the cached one, update the CF and graylist in the memory and check if the last hop in the RREQ packet is in the graylist;
* If the last hop has been recorded in the graylist, drop the packet; if not, add its own IP address into the intermediate list;
* Construct a route back to the RREQ packet came from;
* Rebroadcast the RREQ packet and enter the waiting mode of this route.  
The destination node receives the RREQ packet and replies RREP packets as usual. Finally, the source node receives the new RREP packets with a larger CF. The source node compares \(\gamma\) with \(\text{RREP}_{\text{lim}}\) again and triggers another graylist broadcast until at least one of the following conditions is true:  
* \(\gamma\geq\text{RREP}_{\text{lim}}\);
* CF = 7. Considering efficiency, CF value in MHA reserves 3 bits, i.e., \(\text{CF}_{\text{max}}\) = 7;
* No RREP packet reply, perhaps due to a too small quantity of nodes in the network.  
After the source node completes the route discovery and graylist broadcast, it continues to the hop-count analysis and route path selection mechanism.