* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Extending AODV to enforce participation in a Mobile Ad
Survey
Document related concepts
Wake-on-LAN wikipedia , lookup
Deep packet inspection wikipedia , lookup
Computer network wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Backpressure routing wikipedia , lookup
Distributed operating system wikipedia , lookup
Airborne Networking wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
List of wireless community networks by region wikipedia , lookup
IEEE 802.1aq wikipedia , lookup
Transcript
Extending AODV to enforce participation in a Mobile Ad-Hoc Network Project Report Team Members Imran Patel ([email protected]) Wasim Mohiuddin ([email protected]) Abstract In the not-so-distant future, ad-hoc mobile networks will get widely deployed for commercial and civilian uses. Problems related to security, fault-tolerance and robustness are of special concern in these scenarios. For maintaining the peer-to-peer and co-operative nature of ad-hoc mobile networks in such untrusted environments, some challenging problems need to be solved. In this project, we tried to address one such important problem of guaranteeing participation in an adhoc mobile network. Our goal was to design and implement a system which guarantees that participating nodes in a network forward other nodes’ packets irrespective of their own selfish motives of conserving resources like battery power, CPU and memory usage, etc. In this project, we designed and implemented a technique that “forces” the nodes to cooperatively forward packets in the network. Our system achieves this by detecting selfish behavior and punishing misbehaving nodes appropriately. We discuss the rationale, design and operation of our protocol in the sections that follow. We also discuss the validity and performance of our approach, which was evaluated using a simulation model. Motivation Use of ad-hoc networks in our daily lives is expected to increase in the coming years. Adhoc networks are characterized by constraints such as nodes with low processing-power, low battery power and unreliable and bandwidth-constrained wireless links. Most of the current research in this area is focussed on applying ad-hoc networks in military and other specialized scenarios. However, ad-hoc networks when applied to “open” networks can face unique problems. Mobile Ad-Hoc networks consist of mobile nodes which act as routers. All the current ad-hoc routing protocols assume that mobile nodes co-operatively participate in forwarding packets. However, it might be the case that some nodes might not co-operate in forwarding the packets and thus disrupt the routing fabric of the network. A node may do this for several reasons: The node is selfish and it wants to conserve valuable resources like battery power, processing, memory or other resources by avoiding routing packets that are of no direct interest to it. The node is malicious and it wants to disrupt the ad-hoc network by launching attacks like Denial of Service, Illegal Intrusion, etc. A malicious node normally operates by spreading false routing information in an ad-hoc network. To explain the scenario, we consider an “open” multi-hop ad-hoc mobile network, which is a collection of community wireless networks providing “hot spots” for Internet connectivity. Now, consider a person with a laptop sitting in a street-side cafeteria next to a local “hot spot”. His node is one of the nodes that forwards the Internet-bound or Internet-originated packets to/from the “hot spot”. The person might decide to turn off the forwarding of non-local packets to decrease his power usage and may thus violate the co-operation property of ad-hoc network. We believe that these kind of selfish behaviors might pose serious threat to the fair usage of ad-hoc networks in day-to-day scenarios. To achieve the goal of enforcing participation in routing, our system follows the concept of “punishment-if-found-guilty” model. The operation of the system can be described generally as: Each node keeps a close watch on its neighbors looking for any selfish behavior. In other words: a node does not trust anybody. If a node detects selfish behavior from its neighbor, it assumes the link with the neighbor to be broken and “remembers” the selfish node. Thus all the routes using this now broken link are invalidated and the selfish node is thereby removed from the routing infrastructure of the affected nodes. Also, since the neighbor node remembers the selfish node, any further communication from the selfish node will be ignored. A node, which acts as selfish, is eventually exposed by its neighbors and is cut off from the rest of the network. After some period of cut-off from the affected nodes as punishment, the selfish node might be re-admitted into the network. In the above approach, fear of punishment forces nodes to be selfless and fair in forwarding packets. Scope of the Project and Assumptions To achieve the goal of enforcing participation in routing, our system works on top of an existing routing protocol. We have chosen AODV [1] as our underlying ad-hoc routing algorithm since it provides almost all the required message-passing functionality and necessary states in the nodes to support our extension. This leads to a less overhead for enforcing participation in routing. However, we rely on some extra state information to correctly enforce participation. Although this makes our mechanism tightly coupled with AODV, we think that it might be easier to make this mechanism work in conjunction with other routing protocols. We also make an important decision about the types of misbehaviors that our protocol can address. Specifically, we only handle the selfishly behaving nodes (as defined above) in our protocol. The reason for this is that the participation guarantee problem is closely related to Byzantine failure model. It has been proved in [2] that Byzantine failures are impossible to handle in an asynchronous system even in the presence of a single “faulty” node. For example, a mobile node trying to tactfully avoid forwarding packets is similar to a malicious node foiling a consensus algorithm. This means it is impossible to create algorithms that might handle all kind of faulty behavior. Thus, by deciding to tackle selfish nodes, we can concentrate on a specific type of fault model and define a well-tuned solution for it. We believe tackling malicious nodes can be made easy by utilizing in-built routing security mechanisms like authentication. We also make assumptions about the kind of selfish behavior a node can exhibit. One of the ways in which a selfish node can drop non-local data packets is by using a packet filtering personal firewall. Moreover, the selfish node can still send and receive its own data while exhibiting this selfish behavior. We assume that the users are not sophisticated enough to intelligently drop routing control packets since that would require a deep knowledge of the underlying routing protocol. The proposed protocol is not designed to be immune against “node collusion”. So, if two or more nodes agree beforehand to mislead and bypass it, they can do so with relative ease. But forming such kind of a priori relationship in a dynamic mobile ad-hoc network seems to be a less likely event. Keeping in mind these assumptions, we now define selfish behavior as: A selfish node agrees to route the data flow (i.e. participates in route discovery) but indiscriminately drops data packets later. Finally, for the correct operation of the proposed protocol, we assume that the underlying link is bi-directional and link layer acknowledgements are provided in the case of unicast transmissions (as in IEEE 802.11b). Related Work Though enforcing participation is one of the major issues a routing protocol must consider, relatively less work has been done on it. Currently, it seems that the trend is to develop a routing protocol and then formulating some system on top of it. Upon surveying related research projects, we found the following methods currently employed to solve this problem: Incentive Based Approach This approach is being used by the Terminodes Project [3]. Under this scheme, each node is given some incentives for forwarding other nodes’ packets. The node then spends these incentives for forwarding its own packets. Thus this model simulates a virtual economy where virtual currency (called “nuglets”) is transferred between nodes. The implementation of this payment method is done using simple counters which are implemented under a tamper-proof secure layer. In general, this method has following disadvantages: Computationally expensive It utilizes private/public key cryptography to provide enhanced security – this is a frequently done computationally expensive task, which is not desirable for low-powered mobile nodes. Requires Tamper-Resistant Layer This solution assumes that there is a layer in the protocol stack in each node, which is tamperproof and secure. This property can only be achieved by a hardware solution and this will mean that each mobile node has to be modified which is infeasible in most cases. Weak Model This model does not guarantee a stable network/economy. Nodes can earn unequal amounts of virtual currency because of their topological location. Consider, a node on the periphery of the network. This node might not be selfish, but because of its topologically inferior position, it can forward only few packets compared to the packets it has to send. This node might go bankrupt very soon. Compare this to a node in the center of the network, which might earn lots of money because it can forward lots of traffic based on its superior location. Weak Participation Guarantee It does not properly enforce participation since a node with enough money can stop participating for a while and start forwarding again when the need arises. A group at Stanford also works along the same lines [4]. They build upon the above approach but instead of relying on a tamper-proof hardware solution, they propose a software solution. They introduce the concept of a trusted third-party called the “Banker Node”. This solves most of the problems related to payment consolidation, non-repudiation and authenticity. But it has the following shortcoming in addition to those mentioned above (except the tamperresistance requirement): Centralized approach The reliance on a trusted third-party for providing “banking services” severely reduces the faulttolerance and mobility of the system. In an ad-hoc mobile network, it is very difficult to provide fault-tolerance and continuos connectivity guarantees. Mitigating Routing Misbehavior This method is described in [5] and it solves the problem by routing packets around the selfish nodes. Thus, it also requires discovering selfish nodes and then avoids routing traffic across them. However, a selfish node may transmit its own packets if it wishes. So, this method does not enforce participation and tries to get around the problem. Handling Malicious Nodes Malicious nodes can be tackled by providing integrating authentication with AODV. On such approach is described in [6]. An inherently secure routing protocol limits the damage caused by a malicious node. Thus, it can aid participation guarantee protocol like ours to provide a more robust and secure solution. Design and Operation of the Protocol In this section we try to explain the working of our protocol. We assume the reader is familiar with the working of AODV since our protocol runs as an extension on top of it. The proposed protocol comprises of 4 basic operations: Selfish Node Discovery Adjusting Routing to isolate and punish Selfish Node Re-inducting the selfish node into the network. Avoiding “False Accusations” Selfish Node Discovery For finding a selfish node, we use a “Passive Acknowledgement (Ack)” scheme which can be described as follows: When any node sends a packet to the next hop, it stores some information about the packet with itself. It then listens on the channel in promiscuous mode to check whether the next hop forwarded the packet or not. If it overhears a packet which matches with the packet info that it has, it decides that the next hop has forwarded the packet. If it does not overhear a matching packet on the channel for sometime, it doubts the next hop as selfish. However, the node is not deemed selfish right away upon the failure of a single Passive Ack. Instead, we give the next hop a few chances. So given our example “café” scenario, the node next to the hot spot is detected to be selfish by one of its neighbors. Selfish Node Punishment Once the node determines the neighbor is selfish, it broadcasts a RERR packet suggesting that the link through the selfish node is broken. This invalidates all the routes going through that link. It also marks the misbehaving node as selfish in its neighbor table. Any further correspondence from the selfish node would be ignored by it in the future for sometime. Again, in our scenario, this means that the nodes start accessing the Internet through some other node closer to the hot spot instead of routing through the selfish nodes. Also, the selfish node is now gradually isolated from the network by its neighbors. Re-induction of Selfish Node into the network The node is cut-off from the rest of the network only for a specific time as a form of punishment. After a specified time, the node can start accessing the network again. Avoiding False Accusations Sometimes the Passive Ack scheme might fail i.e. a node may fail to overhear the next hop’s transmission even if the next hop forwarded the packet. In this case, it might wrongfully accuse the next hop to be selfish. We try to avoid this by using a compensation scheme. This means that whenever the next hop successfully forwards a packet, the precursor node lessens its “doubt” of the node being selfish. Implementation We prototype implementation was carried out under a simulator. In this section, we provide a high-level overview of the various components of our implementation. Passive Ack Scheme We implemented the passive ACK scheme by writing a promiscuous mode packet handler. This callback function is called for each promiscuous receive. Also, when we send a data packet, we keep some information about it in a table called “Data Sent Table (DST)”. As an optimization, instead of storing a copy of the packet, we only store the fields of IP header that uniquely identify the packet. The promiscuous handler upon receiving each packet compares its info with the sent packets info in the DST. If it finds a matching packet, it means that a packet that we sent was overheard (meaning forwarded by the next hop) and thus its entry is deleted from the table. However, if the entry is not removed after sometime (meaning that the promiscuous handler did not overhear the packet), the next hop is doubted to be selfish. The Passive Ack operation is shown in the Fig 1. Source IP = A Id = 100 Fragment Offset = 0 TTL = 62 Matches! A B C Source IP = A Id = 100 Fragment Offset = 0 TTL = 63 Fig 1 State Maintenance Once we discover that our next hop is selfish, we remember this information. We do this by defining a neighbor table. A node is entered into our neighbor table if we receive a RREP from it and we remove it from our table if there is a link breakage. We keep a counter with each neighbor table entry that quantifies our “doubts” of the neighbor being greedy. Route Invalidation and Re-discovery We do this when we confirm that the next node is selfish. In that case, we send a RERR packet to all the precursor nodes that might be using the selfish node for their routing. In turn, they initiate a new route discovery cycle in which RREPs from the selfish node are ignored and thus an alternate route is established. Selfish node punishment This is achieved by dropping all routing related transmissions (RREQ, RREP) from a selfish node at the neighbors. This guarantees that the selfish node is unable to initiate new connections through the neighbors who know the fact that it is selfish. Testing and Characterization This section describes our prototype simulation, validation and performance characteristics, associated measurements and their analysis. We implemented the prototype for our AODV extension under Glomosim - a wireless network simulator developed at UCLA. Our simulation code is clearly segregated from the standard AODV implementation and can be enabled/disabled as a compile-time option. The implementation was done in C on Solaris 8 workstations. We also developed bash and awk scripts for extracting the relevant statistics from the simulation runs. The simulations were carried out on PCs (Intel) running Solaris 8. Configuration Parameters The following parameters can be configured at compile-time in our simulation: Selfish Behavior Start Time: This value specifies after what time should the designated selfish nodes start behaving selfishly. We set it to 0 min i.e. start acting selfish right from the start. Selfish Node Fraction: This specifies what fraction of the nodes should act selfish. We varied this value during our simulation. Selfish drop threshold: This value specifies that how many “benefit of doubts” should the next node be given before declaring it selfish. This value should be selected such that false accusations as well as packet losses are minimized. We set its value to 8 for our simulation. Re-induction timeout: This value specifies the time duration for which a selfish node should be punished/isolated. It was set to 5 min in our simulations. Validity Testing To check whether our implementation was valid and working correctly, we created a base case scenario. We analyzed simulation runs based on it and verified the functionality of our protocol extension. Our scenario consisted of 8 nodes, which were placed in a custom grid-like position initially. We designated one node to be selfish. We created three Constant Bit Rate (CBR) connections. Two of them originated from the selfish node and the other had a route through it. The various stages of the scenario are depicted in the Fig 2 – 5. As shown, we selected node 1 to be selfish. Two CBR connections – node 1 to node 3 and node 2 to node 0 are established throughout the simulation. The third connection from 1 to 7 gets established at a later time. This is shown in Fig 2. We describe the validation tests as follows: 0 4 0 4 0 4 0 4 1 5 1 5 1 5 1 5 2 6 2 6 2 6 2 6 t=0s t=60s 7 3 Fig 2 7 3 Fig 3 7 3 Fig 4 7 3 Fig 5 Discover selfish nodes: Initially, the routes for the two connections are as shown in Fig 3. However, node 1 being selfish drops packets for the packets from node 2 destined for node 0. Our Passive Ack scheme was able to identify selfish behavior of node 1 (Fig 4). Route around the selfish nodes: Once node 2 discovered that node 1 was selfish it invalidated the route for the connection to node 0 since it passed through node 1. It then established a route around the selfish node (Fig 4). Punish the selfish node: In addition to routing around node 1, node 2 must also punish it for being selfish. Our protocol does this by making the non-selfish node avoid all new connections from selfish nodes. However, the existing connections from selfish node remain unaffected. In this case, node 2 does not allow the new connection from node 1 to node 7, thus punishing node 1 (Fig 5). Re-induct the selfish node if necessary: Eventually, after node 1 is isolated for a sufficient time, node 2 re-inducts it back into the network. It does this by allowing the till-now unsuccessful connection from 1 to 7. Performance Tests For these tests, our simulation scenario included 50 nodes positioned in a 1000 x 1000 m flat space. The link layer protocol used was IEEE 802.11 since our protocol requires link-layer Acks to function properly. Our simulations run for 300 seconds – we discuss the effects of this parameter later . Node Placement For the initial node placement, we used a random placement model. The random placement (and all other random behavior in Glomosim) is influenced by a single seed, which is specified in a configuration file. We used 5 different seeds for each simulation run. Mobility Model We carried out our tests using a Random Waypoint Mobility Model. Under this model, a node randomly chooses a destination and moves straight in that direction with speed uniformly bounded within a range. After reaching the destination, the node waits for a period of time known as the Pause Time. We carried out our simulations with the following parameters: Minimum speed: 0 m/s Maximum speed: 20 m/s Pause Time: 100 seconds We chose the above model and parameters because they represent a moderate mobility environment and closely model real world mobility scenarios. Communication Model In our tests, we used 8 Constant Bit Rate (CBR) data flows among nodes. All the 16 end-nodes involved in the flows are different. In three of the data connections, the selfish nodes act either as source or destination. The other five connections were to and from the fair nodes. All CBR connections have a data rate of 512 bytes/sec (one packet of 512 bytes is sent every second) and they run from the start of the simulation till the end. Selfish Node Behavior In our simulations, a fraction of the nodes act as selfish. As described above, a selfish node will allow routes to pass through it (by routing packets to pass through) but will refuse to forward data packets later. Selfish nodes can start behaving selfishly after a variable amount of time. One of the most challenging parts of the simulation was to figure out an appropriate randomized scheme for selecting random nodes. We wanted to measure different performance characteristics by varying the fraction of selfish nodes in the network. In our simulation, the fraction of selfish nodes varies from 0 – 50% in 10% increments. We thought that 50% bound was very realistic and represented the worse case. Finally, the mathematical model that we used for selecting random nodes is expressed as: R = Node Id % 100/Fraction_interval Selfish if 0 <= R < Fraction * 10 In our simulations, Fraction_interval = 10% and Fraction varies from 0 –50% in 10% increments. The above formula can select selfish nodes in a predictable manner. So, for example in our 50 node network: Fraction = 10 %: Selfish Nodes = {0, 10, 20, 30, 40} Fraction = 20%: Selfish Nodes = {0, 1, 10, 11, 20, 21, 30, 31, 40, 41} The above figures reflect an important property: The nodes, which are deemed selfish in the 10% case, are also deemed selfish in the 20% case. Thus, the simulation run with 20% nodes as selfish has the same (and more) difficulties as that of a 10% run, when they are run with the same seed (thus guaranteeing the same mobility pattern and initial placement). This property can also be achieved by generating random numbers to select selfish nodes with the same seed across 10% and 20% cases. But then connections might include selfish nodes in one run and might not include selfish nodes in another run. This is required because when we collect the performance metrics, we separate out the metrics of selfish connections from that of non-selfish connections. We discuss the rationale for this below. Performance Metrics We measured the following metrics to evaluate the performance of our protocol extension: Throughput Network Throughput We measure the network throughput, which is defined as ratio of number of packets received to the number of sent. We record the throughput of connections involving non-selfish nodes and the throughput of connections involving selfish nodes. We do this because our protocol may increase or decrease throughput depending on whether the connection involves a selfish node or not. Thus, this test reflects the desired effects that our protocol is trying to achieve. False Accusation Avoidance One special case is when there are no selfish nodes in the network i.e. fraction of selfish nodes = 0%. We want to show that in this case, our extensions achieve the same throughput as that of a standard AODV protocol. We want to show that our scheme also mitigates the effects of false accusations that might occur due to ambiguous promiscuous listening. Normally, a false alarm will unnecessarily result in a new route discovery, which in turn leads to decrease in packet throughput. But with the compensation scheme in our protocol, these false alarms can be minimized. This test measures the effectiveness of our technique. Overhead We measure the overhead of our protocol in terms of two metrics: Routing Overhead It is defined as the ratio of number of routing control packets received to the number of data packets transmitted. This transmission count includes the end-nodes of the connection as well as the forwarding nodes. In the case of AODV, this means Route Request (RREQ), Route Reply (RREP) and Route Error (RERR) packets. Passive Ack Overhead We calculate the overhead associated with Passive Ack scheme in terms of state maintenance and processing of packets received in the promiscuous mode. We carry out this test by running simulations under a fair network and compute the overhearing overhead by measuring the number of packets additionally processed in promiscuous mode. We measure the state maintenance using the same runs and by calculating the maximum amount of memory used for storing sent packet info during the runs. Results We conducted the simulation runs using 5 different seeds and 6 different selfish fractions. We ran this simulations using our protocol extensions and also using the standard AODV simulation. Thus, we analyzed data from a total of 60 simulation runs. Our findings are detailed below: Throughput throughput 1 0.8 0.6 0.4 0.2 0 0 10 20 30 40 50 % of selfish nodes Extended AODV Standard AODV Graph 1 Network Throughput Graph 1 represents the throughput observations recorded during the simulation runs. As can be seen, our extensions provided a higher throughput rate compared to the standard AODV implementation. We achieve a maximum of 31% throughput increase and a minimum of 14% throughput increase. One more important thing to notice is that as the fraction of selfish nodes increases, our extensions perform much better than the standard implementation. This is because when the number of selfish nodes is less, the non-selfish node can be unintentionally aided by its mobility to get away from a selfish node. Thus, mobility might lead to the creation of a new route, which avoids the selfish node. But as the number of selfish nodes increases, even mobility doesn’t help much since the possibility that alternate routes also have selfish nodes increases. Our extensions perform much better since they intelligently route around selfish nodes instead of relying on this (sometimes beneficial) side effect of mobility. False Accusation Avoidance Graph 1 also shows an important desirable characteristic. When both the AODV implementations are run in a fair network (% of selfish nodes = 0), they achieve the same throughput. This shows that our Passive Ack mechanism coupled with compensation scheme performs reliably and generates lesser false alarms. Overhead Graph 2 Routing Overhead Graph 2 compares the routing overhead incurred by our extensions versus that by standard implementation. As can be seen from the graph, our extensions incur significant overhead compared to the standard implementation. This is because the standard AODV implementation fails to identify selfish nodes and thereby utilizes the same route, which includes the selfish node. This leads to a lesser routing overhead since alternate fair routes are not explored. In contrast, our protocol leads to new route discovery cycles upon finding a selfish node. This has an advantage of increased throughput but also has the side effect of increasing routing overhead. Also note that as the fraction of selfish nodes increase, the routing overhead increases in our case. This is because more and more routes include selfish nodes and alternate routes have to be discovered frequently. State Maintenance Overhead The figures related to state maintenance overhead are summarized in Table 1. As can be seen, the number of packets processed increases tremendously in promiscuous mode. However, we think that it might not affect the speed of our implementation since we make simple comparisons on packets received in promiscuous mode. Extra Packets Processed (promiscuously) 11 times (compared to Std AODV) Maximum Size of Data Sent Table (Avg) 40 (720 Bytes) Table 1 However, it might have considerable implications on the power usage of the mobile node. Also noted in the table is the average storage associated with Passive Ack mechanism. It turns out to be very less, thus showing that the memory requirements of our extensions are less. Other observations We also conducted the above mentioned performance tests in an ad-hoc network with no mobility. We discovered that standard AODV performed very poorly. The tests that we conducted showed that the standard AODV implementation achieved 90-100% throughput and 0% throughput in another run. This was because once a route through a selfish node is established, it remains established forever (since there is no mobility) and thus all the data packets get dropped. Thus standard AODV gives all-or-no throughput. Our extension outperforms the standard implementation in terms of throughput but also incurs heavy routing overhead compared to it. One more important thing to note was that our simulations failed to show the decrease in throughput of selfish nodes with our protocol. Instead, the throughput of selfish nodes increased compared to the standard AODV case. We believe this was due to the selfish nodes dropping the other selfish nodes packets. Thus, the selfish nodes routed around the other selfish nodes and maintained the connection. They could find alternate route through nodes, which did not know that they were selfish. This is because our protocol limits the knowledge of a node being selfish at most to its neighbors and does not propagate the information throughout the network. We talk more about this in the next section. Lessons Learned We learned very quickly during our implementation of Extended AODV that there were many subtle issues that needed to be tackled. Our initial implementation of Extended AODV involved non-selfish nodes dropping any packets originating from selfish nodes. This approach has some flaws that can be seen more clearly using an example (see Fig 6). Suppose we initially have two existing data connections as in the figure below (From Node A to Node B, and vice-versa). Using our original approach, when Node A became selfish and stopped forwarding Node B’s data packets, Node B would accuse Node A of being selfish (using Passive ACK on the data packets) and Node B would immediately drop any data packets originating from Node A. Finally, Node B would proceed to route around Node A if possible. Then Node A would figure out that Node B stopped forwarding its packets. That had the undesired side-effect of Node A (the true selfish node) accusing Node B (an innocent node) of being selfish. This poses a serious problem if Node B tries to re-induct Node A into the network even if Node A stops behaving selfishly. Node B would try to re-induct Node A into the network after some timeout. At this point, Node A’s timeout for Node B would not yet have expired and Node A would still be accusing Node B of being selfish (Node A would refuse to forward any packets originating from Node B). By the time Node A’s timeout for re-inducting Node B would have expired, Node B would be accusing Node A of being selfish. This “see-saw” problem of nodes accusing each other of being guilty was preventing us from re-inducting greedy nodes. Furthermore, this problem prevents us from trying to inform other nodes in the network about existing selfish nodes because not all nodes that are being accused of being selfish are indeed selfish. To solve this problem, we had to allow existing data connections involving selfish nodes to continue. But, any future connections from this selfish node would not be allowed (since we do not use Passive ACK for the control packets used to setup a connection, this approach works). A B Fig 6 Since the true selfish node is no longer accusing innocent nodes of being selfish, we could have introduced a new control packet into AODV informing other nodes about selfish nodes. This would serve an effective tool for isolating selfish nodes more quickly and could be addressed in future work. References [1] C. Perkins, E. Royer, and S. Das, Ad hoc on-demand distance vector (aodv) routing, Internet Draft draft-ietf-manet-aodv-04.txt, work in progress, October 1999. [2] Fisher, M., Lynch, N., and Patterson, M. Impossibility of distributed consensus with one faulty process, Journal of the ACM 32, 2 (Apr. 1985), 274-382. [3] L. Buttyan, J. P. Hubaux. Stimulating Cooperation in Self-Organizing Mobile Ad Hoc Networks, Technical Report No. DSC/2001/046, Swiss Federal Institute of Technology, Lausanne, August 2001. [4] Ad Hoc Participation Guarantee Group, Stanford University. Participation Incentives for Ad Hoc Networks (http://www.stanford.edu/~chekist/paper.ps) [5] S. Marti, T. Giuli, K. Lai, and M. Baker. Mitigating routing misbehavior in mobile ad hoc networks. In Proceedings of the Sixth annual ACM/IEEE International Conference on Mobile Computing and Networking, pages 255--265, 2000. [6] Manel Guerrero Zapata. Secure Ad hoc On-Demand Distance Vector (SAODV) Routing, Internet Draft draft-guerrero-manet-saodv-00.txt, work in progress, August 2001.