# Analysing the Performance of a Trust-Based AODV in the Presence of a Flooding Attack
## 6 Trusted AODV (TAODV)  
Trusted AODV (TAODV) is very simple, which is one of its attractive features. No new messages are generated and the computational overhead is very low. Furthermore, as we employ direct trust management, there is no need for any additional separate authority to detect malicious nodes, which would go against the distributed ad hoc nature of MANETs.  
In TAODV, each node maintains a list of known nodes in the network with a trust value for each node. A trust value can be calculated using any reputational measure, depending on the objective of the trust management scheme and in practice a node could maintain an number of different trust values in order to achieve different goals, or to counter different attacks. In this paper, we are specifically concerned with the impact of flooding attacks and so the trust value used here is specifically tailored to identify nodes which are attempting to launch flooding attacks. As discussed above, AODV has measures to limit the impact of flooding attacks but these can be bypassed by a malicious node. Specifically, a malicious node may attempt to create many long routes with to flood packets across the network. Thus, the trust value in AODV is based on identifying nodes that generate multiple RREQ requests in quick succession, or RREQ packets with long time to live (to create long routes). If such behaviour is found, then the trust value for the offending node will be set to zero by other nodes. If sufficient other nodes set the trust value to zero for a given node then that node will be unable to initiate routes on which to launch the flooding attack.  
In particular, the proposed scheme can validate the values for the RREQ_RETRIES and TTL parameters in the intermediate node. Thus, instead of relying on the honesty of the source node, the intermediate node checks the values and if the TTL value is greater than the TTL_THRESHOLD value or the RREQ_RETRIES value is greater than 2/s, the source node will be given a trust value of zero. Thus, the intermediate node should be able to detect the malicious behaviour of the flooding attacker and isolate it.  
To implement the scheme, a table needs to be added to each node to store the following information: (i) the IP address of the source node sending the RREQ; (ii) the number of RREQs received by the intermediate node; (iii) the trust value of the node. The number of RREQs received is zero by default and increases by one each time the intermediate node receives an RREQ. The number resets each second. The scheme works as follows:  
1. The intermediate node checks the value of the TTL associated with the RREQ received. If the TTL value is greater than TTL_THRESHOLD, the RREQ will be discarded and the source node will be given a trust value of zero and isolated. The intermediate node can obtain the TTL_THRESHOLD on its own and compare it to the TTL of the RREQ received.
2. Each time the intermediate node receives an RREQ, it stores the IP address of the source node in the table and increases the number of RREQs received from this node by one. If the number of packets received from the same source node exceeds two packets within one second, the node is trying to flood the network. The source node will be given a trust value of zero and be isolated.