Processing a Received Route Request Packet

When a node receives the route request packet, it first should check whether it is the target of the route discovery. If it is not the target, the node should process the packet according to the following sequence of steps:

the case, this packet will be dropped directly to prevent false information flooding in the network as soon as possible.

2. The node checks whether it has processed the packet from the same initiator with the same request identification and target address before. (For DSR, initiator address, request identification and target address are used to identify a route request packet.) If this is the case, the packet should be dropped silently.

3. The node checks whether it is allowed to process this packet by examining the neighbor record of the packet. If the node finds itself in the neighbor record, this means that it is regarded as well-behaving node by that neighbor who transmitted this packet, and is authorized to process and forward the packet. If it is not the case, it means it is a misbehaving node from that neighbor’s point of view, and dropping the packet is its only choice.

4. If the node has never seen this request packet before and is allowed to forward the packet, it appends its own address to the route record of the packet, which is the requirement of DSR. Therefore, all intermediate nodes on the path can be accumulated in the request packet.

5. The node should search the neighbor record of the packet to get its own local reputation and appends this value to the reputation record of the packet. So all intermediate nodes’ local reputation values can be accumulated in the packet.

6. The node removes information in the neighbor record of the packet, and searches its neighbor table to get all its well-behaving neighbors and their local reputations, and put them into the neighbor record of the packet. In order to address some security problems, the threshold used to identify misbehaving nodes should be uniform in the whole network.

According to the neighbor monitoring technique, a node's route packet forwarding behavior is also monitored, and if a node drops route request packets, this behavior is regarded as misbehavior, and that node's reputation will be decreased. So each neighbor in the neighbor record of a request packet must relay the route request packets. But there is an exception. The node sending this packet should not be included in the packet no matter its reputation. For example, node C receives a request packet from node B, it should not include B into the neighbor record of the packet, because B will not forward this request packet again when it receives the packet broadcasted by C.

7. The node broadcasts this packet to its neighboring nodes. The detection mechanism is used to monitor all its neighbors’ behaviors. For a well-behaving node, if it does not relay the packet in a predefined period of time, its behavior is regarded as

misbehavior. For a misbehaving neighbor, if it relays the packet, its local reputation will become even worse. The detailed monitoring and detection mechanism is described in the last chapter.

8. The request packet is kept in the node’s cache for some time and identified by initiator address, target address, and request identification. When the corresponding route reply packet passes through this node, the reputation information in that reply packet should be checked. But for DSR, a route reply packet does not contain request identification, so some modifications are necessary to prevent replay attack.

Figure 23. Route request packet forwarding

For the same example in figure 23, we can see that node B is a well-behaving neighbor of node A. When B receives this route request packet for the first time, it will put its own address (here just the node’s identification B) into the route record of the packet, and gets its local reputation LRA(B) from the neighbor record and puts it into the reputation record. Then it

replaces information in the neighbor record with its own well-behaving neighbors and their local reputations LRB(D), LRB(F), LRB(G). Because B received this request packet from node

A, it should not include node A and A’s local reputation in the neighbor record, because it is impossible for A to be the next hop of B.

This mechanism is based on DSR, but due to some additional operations and requirements, there are some differences from DSR. Intermediate nodes are not allowed to return route reply packets. In DSR, if an intermediate node has a route to the target, it can return a route reply

packet to the initiator in order to reduce overhead. But it is based on the assumption that all nodes in the network are well-behaving nodes. This assumption does not hold here, so the only thing an intermediate node can do is to relay route request packets or drop them. In this solution, only the destination nodes are authorized to return route reply packets because routing and reputation information is protected by MAC which is based on secure associations between the sender nodes and the destination nodes.

Collision is a serious problem that makes the detection result incorrect. In some proposed solutions, such as DCF of 802.11, some measures are taken to prevent this problem. For example, to prevent multiple neighbors broadcast request packets at the same time, broadcast with a short jitter delay could be used to reduce collision. The jitter period should be chosen as a random period, uniformly distributed between 0 and BroadcastJitter.