可信任AODV（TRUSTAODV）

转载地址：http://www.dcs.warwick.ac.uk/~adhoc1/trustaodv.html

3.  TRUSTAODV

3.1.  Evaluating Trust

3.1.1  Acknowledgements

3.1.2  Packet Precision

3.1.3  Gratuitous Route Replies

3.1.4  Blacklists

3.1.5  Hello Packets

3.1.6  Destination Unreachable Messages

3.2.  Implementing Trust Evaluation

3.2.1  Storing Trust

3.2.2  Promiscuous Mode

3.2.3  Detecting packet Forwards and Drops

3.2.4  Baring Unwanted Neighbours

3.3.  TRUSTAODV Original

3.3.1  Trust Model

3.4.  TRUSTAODV Version 2

3.4.1  Trust Model

3.5.  Modifying and Improving

3.5.1  Influencing Routing

3.5.2  AODV bodge to note

3.5.3  To Do List

---

3. TRUSTAODV

---

3.1. Evaluating Trust

There are many possible means of identifying if a node can be trusted. This trust can be based on a variety of the nodes activities, with the different behaviors of the node being weighted accordingly to produce a trust level.

A lot of the means described below are difficult to detect or are not fully implemented within ns2's version of AODV. This has led to using acknowledgment solely to indicate benevolence. We believe that this form of detection is the most worthwhile and best indicates a benevolent and functioning node.

3.1.1 Acknowledgement

Acknowledgment is a means of ensuring that packets sent for forwarding have been forwarded. There is a couple of ways that this is possible but Passive Acknowledgment is by far the easiest to implement. Passive Acknowledgment uses promiscuous mode to monitor the channel, this allows the node to detect any transmitted packets, irrelevant of the actual destination that they are intended for. With this the node can ensure that packets it has sent to a neighbouring node for forwarding are indeed forwarded.

This has been implemented within TRUSTAODV using promiscuous mode to monitor the channel.

3.1.2 Packet Precision

As defined by Pirzada “Packet Precision ensures the integrity of the data and control packets that are either received of forwarded by other nodes in the network.”, this type of detection aims to spot packets that have either been corrupted due to a faulty node or have been generated maliciously. This could be done by monitoring the control packets that lead to suitable successful routes. Another possible means is to check the packet information is within certain tolerances. For example one possible addition to TRUSTAODV would be to ensure that the sequence number within a reply is note inconceivably higher that the sequence number within the request, as this suggests that the replying node is trying to ensure it is part of the final route.

This is possible to implement and would be a good addition to the TRUSTAODV protocol.

3.1.3 Gratuitous Route Replies

Gratuitous replies are generated when an intermediate node replies to a route request because it has a fresh enough route, allowing AODV to respond faster to route requests. When this happens the node sends out a normal reply to the source of the request and then sends a gratuitous reply to the destination to update and ensure that the route still exists. Gratuitous replies are only required to be sent when the 'G' flag is set within the route request (No such G flag exists within ns2, it is either on or off all of the time) and even then gratuitous replies are not required for the network to function but they improve route maintenance. This means that a nodes benevolence can be detected from their willingness to transmit gratuitous replies. We currently have gratuitous replies turned off and they can be turned on by defining RREQ_GRAT_RREP within trustaodv.h. The line to insert is:

#define RREQ_GRAT_RREP

The problem with detecting gratuitous replies is they are the same as any other reply and would need to be detected by monitoring the requests going into a node and the replies it produces.

3.1.4 Blacklists

According to to Pirzada “AODV maintain[s] blacklists for nodes displaying uni-directional behaviour”. I do not believe blacklisting is currently implemented within ns2's version of AODV, or atleast no reference to any blacklist can be found. This means that if such blacklisting was to be used it would have to be implemented. Currently a form of blacklisting has been added to the TRUSTAODV itself and is separate from the blacklist component that would be implemented within AODV.

3.1.5 Hello Packets

Hello packets can be used to maintain a view of the local neighbourhood, although ns2's implementation currently uses a more advanced link-layer notification todo do this. Although, the code for Hello Packets is still in place but never called. This means if the correct setting could be found it should be possible to activate the Hello Packets. As of yet the correct setting has not been found and Hello Packets are not used as a means of calculating benevolence.

3.1.6 Destination Unreachable Messages

Although Pirzada mentions that it is possible to use Destination Unreachable Messages, no such messages are returned by ns2.

---

3.2. Implementing Trust Evaluation

3.2.1 Storing Trust

There are 3 additional classes within TRUSTAODV used for storing trust

TrustNode: 
Stores all the trust information about an individual node

CircularBuffer: 
Stores a set number of packets in a cyclic buffer

LinkList: 
basic 2 headed linked list

The main class for storing trust values is TrustNode and contains all of the trust information for monitoring a single other node. All of thses TrustNodes are access by a map called trustMap. The trustMap maps nodeID numbers to a TrustNode pointer, which is used to access the TrustNode object. Within this trustMap a node can store a TrustNode for each node in the network, thus associating the nodeID number to a nodes trust information.

3.2.2 Promiscuous Mode

Promiscuous mode is implemented by following the instructions in this guide:

NS2 Notebook: How to Use Promiscuous Mode in AODV  , From the useful link:  http://www.cse.msu.edu/~wangbo1/ns2/

This causes the tap() function:

void TRUSTAODV::tap(const Packet *p)

within trustaodv.cc to be called every time a packet is promiscuously seen. Thus, within the tap function is where all code related to monitoring other nodes is located.

3.2.3 Detecting packet Forwards and Drops

To detect if a packet has been forwarded successfully a buffer of packets that have been recently sent for forwarding is stored. This is stored in a cyclic buffer, defined in the class CircularBuffer and instantiated within that nodes TrustNode. Using a circular buffer means that if packets are not removed frequently enough it will cause the buffer to cycle erasing the last element. This means that if a node is dropping packets or if it is being unacceptably slow at forwarding packets then the buffer will start to cycle. Otherwise, if the node is performing acceptably then when the promiscuous mode detects a packet that has been forwarded, the packet can be found and removed from the buffer, increasing the trust in that node.

3.2.4 Baring Unwanted Neighbours

Unwanted neighbours are bared using by using a call to nb_delete(), within the forward() function in trustaodv.cc.

// If the trust value for the next_hop_ has become too low,
// delete the node from the neighbours
if(!tmpTrustNode->isNodeTrusted(CURRENT_TIME) || droppedPacket)
{
	nb_delete(ch->next_hop_);
}

This call removes the neighbour form the local neighbourhood and causes all routes using that node to be removed and a new route request sent out.

This works in conjunction with another piece of code inserted into recvReply(), within trustaodv.cc.

// Check to see if the node can be trusted
else if(!(trustMap[firstHopInRoute])->isNodeTrusted(CURRENT_TIME))
{
	trust = false;
}	

This case is used to drop route replies received from untrusted sources. This stops the node being part of the network as long as isNodeTrusted() returns false.

---

3.3. TRUSTAODV Original

The aim of the original TRUSTAODV was to prove that in principle promiscuous mode functioned and that nodes could be monitored successful.

3.3.1 Trust Model

The original TRUSTAODV uses a very simple model, with each node associated to an integer trust value initialised to 0. That value is simply incremented for nodes that are detected to forward packets and decremented for nodes that do not appear to forward the packet.

void TrustNode::increaseTrust()
{
	trustValue++;
}

void TrustNode::decreaseTrust()
{
	trustValue--;
}

Malicious and faulty nodes are then bared from the network once they obtain a score of -10.

bool TrustNode::isNodeTrusted()
{
	if(trustValue <= -10)
	{
		return false;
	}
	else
	{
		return true;
	}
}

---

3.4. TRUSTAODV Version 2

3.4.1 Trust Model

TRUSTAODV-V2 uses a significantly more advance trust model, although it still requires a significant amount of work and research.

The main changes are:

1. Increased Monitoring
2. Weighting Scheme
3. Introduction of a Trust Level
4. Temporary Blacklisting

Increased Monitoring

The TrustNodes now store packets that have been sent out for forwarding as well as general packets that have been promiscuously seen that are expected to be forwarded. The two sets of packets are stored separately in cyclic buffers packetBuffer and generalPacketBuffer.

Monitoring of packets sent out for forwarding works as before, except with modified weightings. The difference and increased work comes from monitoring packets that have been promiscuously seen and are expected to be forwarded. This allows nodes to obtain trust information about nodes without transmitting packets, by monitoring of other nodes packets. Although, this can only be used to increase trust as it is possible to promiscuously see a packet that requires forwarding but the forward may not also be promiscuously detected.

Weighting Scheme

With TRUSTAODV now monitoring multiple inputs a better weighting scheme was required, for this reason the trustValue within TrustNode has became a double. This allows the trustValue to be incremented more subtly and the trustValue is altered by different fractions depending on the action seen.

// Increases the trustValue the amount associated with seeing a general forward
void TrustNode::increaseForwardGeneralPacketsTrust()
{
	if( trustValue < MAX_TRUSTVALUE )
	{
		trustValue += 0.1;
	}
}

// Increase the trustValue the amount associated with seeing one of the nodes own packets forwarded
void TrustNode::increaseTrust()
{
	if( trustValue < MAX_TRUSTVALUE )
	{
		trustValue++;
	}
}

// Decrease the trustValue the amount associated with one of the nodes packets not being forwarded timely enough
void TrustNode::decreaseTrust()
{
	if( trustValue > -MAX_TRUSTVALUE )
	{
		trustValue -= 2;
	}
}

Introduction of a Trust Level

The new trustValue is now computed into a trustLevel before comparisons, the idea behind this is to move away from the linear trust value towards a function that caps trust levels. The function used is a atan(), which is then modified to generate values between 0 and 1, from values ranging between -29 to 29.

As can be seen the shape of the function nodes that are neutral and around the 0.5 area the rate at which their trust alters is high as we are not sure how benevolent these nodes are, but as node become either more trusted or distrusted they tend towards 1 and 0 respectively.

This trust level is not currently used to influence routing choices but how to do this is described within the 'Modifying and Improving' section

Temporary Blacklisting

TRUSTEDAODV-V2 also implements a means of temperately baring nodes, the purpose of this is to give other nodes a chance to reply to route requests. The length of the baring is dependent on the number of packets that have been dropped in a row and exponentially increases. This also substantially reduces the packet overhead of the Original TRUSTAODV.

double TrustNode::banTime()
{
	return double (timeSinceLastDrop + (numDroppedSinceLastForward * numDroppedSinceLastForward * 0.5));
}

---

3.5. Modifying and Improving

3.5.1 Influencing Routing

to start influencing route choices using the trustLevel of nodes we suggest editing the following if statment:

		 if ( (rt->rt_seqno < rp->rp_dst_seqno) ||   // newer route 
			  ((rt->rt_seqno == rp->rp_dst_seqno) && (rt->rt_hops > rp->rp_hop_count) )// ||
			
			  //More trusted route within reasonable tolerance
			  //((newNode > oldNode + 0.1) &&	
			  //(rt->rt_hops >= rp->rp_hop_count + 2) && (rt->rt_seqno == rp->rp_dst_seqno))
		 	) { // shorter or better route

within trustaodv.cc at a proximately line 945, within the recvReply() function.

The reason for this is the if statement is responsible for specifying the restriction on what routes are allowed to update the routing table. As can be seen there is a commented out line where we were trying this out.

It is important to note the request radius of transmission when experimenting with this condition, because on the first request the distance the route request propagates is limited, and increases for subsequent attempts to reduce initial flooding. Thus, only routes within the request radius of transmission will reply. This causes issues when a black hole is close to the source of the route request and the actual destination is out of range of the first request, as the blackhole will establish a route as no other route can be found.

3.5.2 AODV bodge to note

There is a bodge within AODV to allow it know who the sender of a routeRequest or routeReply was, this has been extended to allow promiscuous mode to work out who the sender of any packet was. This could have also been performed within the mac layer but problems were encountered when this was attempted, hence the bodge was used.

The bodge only requires the following line:

// Set the previsous hop to be the current node, before packet continues
ch->prev_hop_ = index;

and is in the forward() functions of all *adov.cc files for all of the protocols we have created.

3.5.3 To Do List

• Uses the new TRUSTAODV-V2 and get some results for this protocol on Condor.
• Finish MODIFICATIONAODV
• Look into calcualting Path Optimalitiy there is a means of doing this inbuilt into NS-2, expect would require a few days search to implement.
• Edit the TraceAnalyser to function stand alone, currently configured for Condor.