Subramanian Kumaran Matrikelnummer:

Transcription

1 Rheinisch-Westfälische Technische Hochschule Aachen Lehrstuhl für Informatik IV Prof. Dr. rer. nat. Otto Spaniol Enforcing Service Availability in Mobile Ad-hoc Networks Seminar: Data Communication and Distributed Systems Winter Semester Subramanian Kumaran Matrikelnummer: Betreuung: Ralf Wienzek Lehrstuhl für Informatik IV, RWTH Aachen

2 Table of contents Abstract 2 1. Introduction Mobile Ad-hoc network Service availability problem Approaches to solve the service availability problem 3 2. Charging the packet forwarding service Packet Purse Model Packet Trade Model Problems to be solved Implementation of the models Implementing the Packet Purse Model Implementing the Packet Trade Model Analysis of Packet Purse and Packet Trade Models Reputation based technique Main Idea and Routing Protocol (DSR) Problems to be solved The CONFIDANT Protocol CONFIDANT Components CONFIDANT Protocol Description Analysis of CONFIDANT protocol Conclusion 20 References 21 1

3 Abstract Devices in mobile ad-hoc networks work as network nodes and relay packets originated by other nodes. Mobile ad-hoc networks can work properly only if the participating nodes cooperate in routing and forwarding. However, it may be advantageous for individual nodes not to cooperate, for example to save power, so a mechanism to stimulate the cooperation of the participating nodes for enforcing service availability is needed. This paper addresses the problem of service availability in mobile ad-hoc networks and it discusses two different solutions to enforce service availability. 1. Introduction 1.1 Mobile Ad-hoc Networks A mobile ad-hoc network is a wireless multi-hop network which is formed by a set of mobile nodes. An important property of this network is that it is formed in a self organizing way without relying on any established infrastructure. Due to the absence of infrastructure, all networking functions must be performed by the nodes themselves. For instance, packets sent between two distant nodes are expected to be forwarded by intermediate nodes. This principle makes the cooperation of nodes as an essential requirement in mobile ad-hoc networks. The term cooperation means that the nodes perform networking functions for the benefit of other nodes. Lack of cooperation may have fatal effects on network performance. 1.2 Service availability problem This paper addresses the service availability problem in mobile ad-hoc networks. In mobile ad-hoc networks, network management is totally distributed and all networking functions (e.g., packet forwarding) must be performed by the nodes themselves. If the nodes in the mobile ad-hoc network belong to the same authority, the threat of denial-ofservice attack is low and the packet forwarding is normally ensured. But in civil applications, each node is most likely to be its own authority, so cooperation is not ensured. Intentional non-cooperation is mainly caused by two types of nodes: selfish ones that, e.g., want to save power and malicious nodes that are not primarily concerned with power saving but that are interested in attacking the network. Selfish behaviour Service provision is not in the direct interest of users, because it consumes energy and thus, reduces battery lifetime. A systematic denial of the packet forwarding service restrains the communications to a packet exchange only between directly connected nodes (nodes that are within the transmission range of each other). In order to increase the network's throughput and to enable communication between nodes that are not directly connected, an incentive mechanism to encourage the nodes to cooperate is desirable. 2

4 Malicious behaviour A malicious denial-of-service attack can be done by sending too much traffic with the goal to overload the network. Due to this overloading of the network service unavailability occurs. Therefore, a mechanism to make denial-of-service attacks expensive and to discourage users from flooding the network with useless traffic is needed. 1.3 Approaches to solve the service availability problem Number of solutions have been proposed and implemented for enforcing service availability in mobile ad-hoc networks. This paper discusses two different approaches and their implementations. The first approach introduces the concept of money and service charges to stimulate a cooperative behaviour and to prevent congestion. The natural idea is that nodes that use a service should be charged and nodes that provide a service should be remunerated. Since nodes earn by providing packet forwarding service, they are motivated to offer the service. Furthermore, nodes are no longer interested in sending useless messages and overloading the network because they have to pay to get service. The second approach is a reputation based technique. The idea is to find the selfish and/or malicious nodes and to isolate them, so that misbehaviour will not pay off but result in isolation and thus cannot continue. Malicious nodes are detected by means of observation or reports about several types of attacks, thus allowing nodes to route around misbehaving nodes and to isolate them. 2. Charging the packet forwarding service This solution is developed by Levente Buttya n and Jean-Pierre Hubaux [1] for so called terminode networks and it is based on tamper resistant Security Modules. The Terminodes Project [2], [3] is a research program with the aim to investigate wide area, large, totally wireless, mobile networks i.e., mobile ad-hoc wide area networks. In this, all networking functions are embedded in the terminals themselves. These devices are called terminodes, because they act as network nodes and terminals at the same time. An important characteristic of terminode networks is that there are no routing tables stored in the devices. Instead, a simple packet forwarding mechanism lets each of the terminodes located on the route of a given packet compute the best next hop toward the final destination. To stimulate a cooperative behaviour and prevent congestion, this approach introduces the concept of money and service charges. The basic idea is that terminodes that use a service should be charged and terminodes that provide a service should be remunerated. Virtual currency called nuggets is introduced and it is assumed that the terminode hardware comes with an initial stock of nuggets. Nuggets have no monetary value, and they can only be used within terminode networks. Now, terminodes have to pay in terms of nuggets to intermediate nodes, if they want to use a service (e.g., wants to send a message). Each forwarding intermediate terminode earns nuggets by offering the packet forwarding service. This motivates each terminode to increase its number of nuggets, because nuggets are indispensable for using the network. Since the terminode 3

5 has to pay in nuggets if it wants to use the service, it is no longer interested in sending useless messages and overloading the network because this would decrease its number of nuggets, and it is better off providing services to other terminodes because this is the only way to earn nuggets. General Assumptions Two different models based on charging the packet forwarding service concept are going to be discussed in this paper. This section lists general assumptions, which the models described in the next section depend on. Tamper resistant Security Module. It is assumed that each terminode has a tamper resistant Security Module, such as, for instance, a special chip or a smart card, that is used for the management of cryptographic parameters (e.g., keys) and nuggets. It is assumed that this Security Module functions correctly and its behaviour cannot be modified by the user of the terminode or other attackers. Contrary to the Security Module, other parts of the terminode hardware and software are not tamper resistant and their behaviour can be modified by anybody who has physical access to the device. Public key infrastructure. Public key infrastructure contains functions which are necessary for the Security Module to use to authenticate each other and to establish secure communication links. Security Modules use public and private keys to protect the message to be sent. Due to the public key infrastructure two neighbouring Security Modules are able to share secret keys and to ensure the association of the right public key (i.e., the public key of other terminode) with the unique identifier of the Security Module of that terminode (see section 2.4). Omni directional antennae. It is assumed that the terminodes use omni directional antennae, which means that a message sent by a terminode can be heard and understood by all the terminodes within the communication range of the sender. It means that all the neighbours receive the message and can determine who the sender and the intended receiver are and what the content of the message is. Section 2.1 and 2.2 presents two different models based on charging the packet forwarding service concept The Packet Purse Model (PPM) In this model, the terminode that wants to send packets to other nodes (originator) pays for the packet forwarding service. The originator loads the packet with a number of nuggets sufficient to reach the destination. The forwarding terminodes get service charge. Each forwarding terminode earns one or several nuggets from the packet by forwarding the packet and thus, increases the stock of its nuggets. The number of nuggets to be loaded in the packet depends on the direct connection on which the packet is forwarded (long distance requires more nuggets). If a packet does not have enough nuggets to be forwarded, then it is discarded. 4

6 A (1) (2) (3) (4) C C C 10 C D 3 D 3 D 3 A A A 2 D B 5 B 9 B 4 9 B Stock of nuggets at the terminode 5 Number of nuggets in the packet Fig. 1. The Packet Purse Model Fig. 1 illustrates the packet forwarding mechanism in Packet Purse Model. For example, if terminode A wants to send a packet to terminode D (It is assumed that originally each terminode has nuggets (1)), then A loads, 5 nuggets in the packet and sends it to the next hop B (2). Terminode A, who is the originator of the packet, decreased its stock of nuggets. B takes out 1 nugget as a service charge from the packet, and forwards it with the remaining 4 nuggets to C (3). C takes out 2 nuggets from the packet and forwards it with the remaining 2 nuggets to the final destination D (4). Terminodes B and C, which forwarded the packet, increased their stock of nuggets. The problem with this approach is that it might be difficult to estimate the number of nuggets that are required to reach a given destination. If the originator underestimates this number, then the packet will be discarded, and the originator loses its investment in this packet. If the originator overestimates the number (like in the example above), then the packet will arrive, but the originator still loses the remaining nuggets in the packet. This model assumes that there exists a mechanism to estimate the number of nuggets that the originator must load in the packet purse in order for the packet to be delivered to the final destination. The model described in the next subsection overcomes this problem The Packet Trade Model (PTM) In this approach, the packet does not carry nuggets, but it is traded for nuggets by intermediate terminodes. Each intermediate terminode buys it from the previous one for some nuggets, and sells it to the next one (or to the destination) for more nuggets. In this way, each intermediary that provided a service by forwarding the packet increases its number of nuggets, and the total cost of forwarding the packet is covered by the destination of the packet. An example is given in Fig. 2. Originally each terminode has nuggets (1). If terminode A wants to send a packet to terminode D, then A sends the packet to the first hop B for free (2). B then sells it to the next hop C for 1 nugget (3), because it offers packet forwarding service. Finally, C sells it to the final destination D for 2 nuggets (4), C gets one nugget as service charge and it takes one more nugget from the same packet because it already spent one nugget for this packet while buying this from the previous 5

7 node. Terminodes B and C, which forwarded the packet, increased their number of nuggets, whereas the destination D decreased its number of nuggets. (1) (2) (3) (4) A C B D A C 7 B D Stock of nuggets at the terminode A 5 Number of transferred nuggets 1 9 C B D A 9 C 9 2 B 6 D Fig. 2. The Packet Trade Model This model assumes that there exists a mechanism to determine the number of nuggets, for which a forwarding terminode can sell a packet to the next hop. An advantage of this approach is that the originator does not have to know in advance the number of nuggets required to deliver a packet. A disadvantage is that this approach for charging does not directly deter users from flooding the network. However, allowing each terminode to decide if it buys a packet or not can provide a sort of back pressure mechanism, which may deter a user from generating too much traffic, by ensuring that eventually nobody will buy packets from users who try to overload the network. In the above example, if A sends too much traffic to D, at some point in time D will not buy the packet from A. After that C will become aware of the malicious behaviour of A and it will not buy packets from A anymore. In the same way B, the neighbour of A, will realize that it already lost some nuggets due to the unwanted traffic from A. So the neighbours of A will not accept packets from A, once they realize the malicious behaviour of A thus, eventually nobody will buy packets from the maliciously behaving nodes. This mechanism is called back pressure mechanism Problems to be solved Terminodes (or, more precisely, their users) may misbehave in several ways if no enforcement and no protection are applied. One important general problem is to prevent nugget forgery. In addition, the problems to be solved by the Packet Purse Model include the following: The originator of a packet should be denied the re-use of the nuggets that it loaded in the packet purse. An intermediate terminode, which offers the packet forwarding service, should not take more nuggets out of the packet than the actual number of nuggets for its service charge. This is called packet robbery and it should be prevented. Each intermediary should be forced to indeed forward the packet after having taken the nuggets out of it. 6

8 The integrity of the packet purse should be protected from forgery or illegitimate modification during transit. The replay of a packet purse i.e., receiving the packet which is already processed by a terminode should be detected to avoid earning more nuggets from the packet by forwarding the packet once again. Detachment of a packet purse from its original packet and re-use of it with another packet should be impossible. Problems to be solved in the Packet Trade Model include the following: Nuggets spent for buying packets cannot be re-used by terminodes. Re-use of already spent nuggets by terminodes should be denied. A forwarding terminode should receive the nuggets from the next hop if, and only if, the next hop receives the packet from the forwarding terminode (fairness of the exchange). A packet can be sold only once. It should not be possible for an intermediate terminode to sell the same packet more than once to different neighbours. 2.4 Implementation of the models The tamper resistant Security Module (SM) is used to enforce the behaviour described by the models. This section presents the description of this module and the protocols that it runs with its environment. Long and medium term data in the Security Module For the correct behaviour of the system, the Security Module stores and manipulates some long term and short term data. The SM has three long term data: a system-wide unique identifier (id SM ) of its own, the number of nuggets (n SM ) which expresses the wealth of the terminode as a counter known as nugget counter and a private key of an asymmetric key pair. Each Security Module has a public key and a corresponding private key. The private key is stored in the Security Module as a long term data because this key is exclusively known to the SM. Since the public key is intended to be made publicly available, it can be stored elsewhere. In addition, the Security Module keeps a list of its current neighbours and maintains data associated to each of these. The following table shows the medium term data for each neighbouring Security Module SM which is to be stored by SM. id SM Shared secret key k SM,SM Sending Counter SM c SM Receiving Counter SM c SM Fine Counter f SM,SM Fig. 3. Medium term data in the Security Module 7

9 As it is shown in Fig. 3 the Security Module stores the unique identifiers of its neighbours. For each of them an associated shared secret key value used to protect the communication with this specific neighbour is stored. This shared secret key protection is mainly introduced for efficiency reason. Furthermore two counters are stored, the sending counter (c SM ( SM and the receiving counter (c SM ( SM associated with. SM The values in these counters are the identity of the last packet sent to and received from the terminode whose Security Module is SM and they are ever increasing. Message replay is detected using these values thus, the terminode cannot process the same packet twice. Finally the Security Module stores a fine counter (f SM,SM ( as a medium term data. Misbehaviour of the terminode that hosts SM is accounted in this counter. The underlying protocol, which is used by the Security Module, works as follows: SM increases its nugget counter for the service it provided only after the reception of an acknowledgement from the next hop. If it does not receive an acknowledgement it accounts the misbehaviour of the next hop by increasing the fine counter associated with that neighbour. When SM sends packet next time to that neighbour it also sends the value of its fine counter associated with that terminode which hosts. SM If this packet is processed by that next hop the fine counter value will also be taken into account and that Security Module will decrease its nugget counter by the fine value. SM resets the fine counter associated with that neighbour. If the value of the fine counter exceeds a limit, the hosting terminode of SM may stop forwarding packets towards the misbehaving next hop. This mechanism stimulates to send acknowledgments Implementing the Packet Purse Model The Packet Purse Header In the Packet Purse Model, each packet has to carry some nuggets in order to be forwarded by the intermediate terminodes to reach the destination. A new header, which is called Packet Purse Header (PPH) is used to store these nuggets. This header is an additional header, which is introduced between the network layer header and the MAC layer header. Since each terminode has omni directional antennae it piggy backs the acknowledgement for the previous node with the packet while forwarding the packet, so that the previous node, which also receives the packet, can extract the acknowledgement part from the packet. The acknowledgement is part of the Packet Purse Header so that it has to be recomputed by the Security Module of each forwarding terminode. The Packet Purse Header consists of three parts. The common part contains the unique identifier of the originator of the packet. The second part is the purse part which is meant for the forwarding next hop. It consists of the unique identifier of the next hop, the number of nuggets currently stored in the purse part of the packet, and the current value of the fine counter. This part is protected by Purse Authentication Code (PAC) which is computed from the purse part of the PPH and the cryptographic hash value h(networkpdu) of the content of the packet using a keyed cryptographic hash function g. This function computes the PAC using the shared secret value between this Security Module and the Security Module of the next hop as a key value.

10 The third part contains an acknowledgement, which is meant for the previous hop. This part contains the identifier of the Security Module of the previous hop and the sending counter value from the received purse which is used to identify the packet for which this acknowledgement has been created by the Security Module of the previous hop. This part is also protected by an authentication code, which is known as Acknowledgement Authentication Code (AAC). This is computed from the previous PPH using a keyed cryptographic function g with the shared secret value between this Security Module and the previous hop as a key. Fig. 4 shows the Packet Purse Header. Network PDU MAC Packet Network Additional Headers and Layer Purse Layer payload Header Header(PPH) Header id SM id SM next Sending Nuggets fine PAC id SM prev Sending counter from AAC counter the received purse Common Purse for the SM of the next hop Acknowledgement for the SM of the previous hop PAC Purse Authentication Code PAC = g k SM,SM next (id SM, id SM next, sending counter, nuggets fine, h(network PDU)) AAC Acknowledgement Authentication code AAC = g k SM,SM prev (received PPH) The packet forwarding protocol Fig. 4. The Packet Purse Header (PPH) The packet forwarding protocol is illustrated in Fig. 5. When a terminode T q receives a packet which is to be forwarded to some other terminode T p (1), it supplies the identifier of the Security Module of the next hop, the Packet Purse Header PPH received from the previous hop, and the cryptographic hash value h(networkpdu) of the content (3). PPH of the packet to its Security Module (2), to get a new 9

11 Fig. 5. The packet forwarding protocol The Security Module creates a new Packet Purse Header in the following way: Verification 1. It checks whether the Packet Purse Header has indeed been created by the sender and not modified by anyone else, by re-computing the Purse Authentication Code and comparing the computed value to the received one. 2. It checks whether the packet is a replay or not, by checking that the sending counter value in the received PPH is greater than the receiving counter value associated with SM p. 3. It checks whether it has to pay fine or not, by checking the fine part of the received PPH. Re-Computation of the Packet Purse Header 1. The common part is replaced by its own identifier, id SM. 2. The id SM of the purse part is set to the id of the identifier of the next Security Module SM r, the sending counter is set to the current value of the sending counter associated with SM r, number of nuggets is set to the previous value decreased by one, the fine part is set to the fine counter value associated with the SM r and PAC is replaced by the new PAC calculated from the purse and hash value of the content of the packet using g k SM,SM r. 3. In the acknowledgement part, the id of is set to the id of SM p, the sending counter value is set to the value of the sending counter value taken from the purse part of PPH and the AAC is replaced by the new AAC calculated from PPH using g k SM,SM p. The Security Module of T q stores the Packet Purse Header PPH internally and outputs a copy for T q. Terminode T q attaches this new PPH to the packet and sends it to the next hop (4). The previous hop T p also receives this packet and checks the acknowledgment part by supplying the PPH to its Security Module (5). If this acknowledgment is meant for this terminode T p, then it uploads PPH to its Security Module SM p. SM p tries to find out the matching PPH in its internal memory. To do this SM p uses the identifier of SM q and the identifier of the packet (sending counter value in.( PPH By matching these values to the values of the PPH stored in its internal memory it 10

12 tries to find out the PPH. If SM p finds PPH, then it verifies the authenticity of the acknowledgment using the Acknowledgment Authentication Code AAC part. After successful verification, it gets the charge for the service it provided by increasing its nugget counter by one. Packet creation and final delivery The PPH sent by the originator is a special one, because it does not have any acknowledgement part, since there is no previous hop that would need it. If the destination receives the packet, it creates a special PPH that has only an acknowledgement part so that the last intermediate node gets paid Implementing the Packet Trade Model In the Packet Trade Model, each packet has to carry the current price of the packet. The Packet Trade Header (PTH) which has the same structure as PPH is used to store the price of the packet. In PPH the purse part contains nuggets here the purse part contains the price of the packet. This model can be implemented in the same way as the Packet Purse Model because there is only one difference between PPH and PTH, which is explained above. The same packet forwarding protocol described before can be used here with the following modification. Since the packet carries its price not nuggets, each forwarding terminode buys the packet by decreasing its nugget counter by the price in the PTH from the previous hop, and sells the packet to the next hop with a new price, by increasing its nugget counter by the new price when the acknowledgement arrives. 2.5 Analysis of Packet Purse and Packet Trade Models This section presents the analysis of the implementation of the Packet Purse Model and it shows how the implementation solves the original problems of stimulation for cooperation and prevention of overloading. Analysis about the robustness of the Packet Purse Model is also presented in this section. Essentially, this analysis applies for the implementation of the Packet Trade Model as well, since it is almost identical to the implementation of the Packet Purse Model. It will be pointed out those cases in which the analysis does not apply for the Packet Trade Model. Stimulation for co-operation and prevention of overloading Nuggets are indispensable for using the network and the only way to increase the stock of nuggets is to provide the packet forwarding service. So terminodes (i.e., users) are motivated to forward packets of other nodes. A terminode cannot deny packet forwarding for a long time because thereafter no packets will be sent to it. If a terminode does not forward a packet, then it will receive a fine later, and its number of nuggets will be decreased. Overloading the traffic by sending too much information or useless information is discouraged in Packet Purse Model because this would decrease the number of nuggets. It 11

13 is ensured in this solution that a user cannot get more benefit than what he has contributed to the network. But the implementation of the Packet Trade Model fails to protect the network from overloading because a terminode can generate useless traffic and overload the network without any consequences. This drawback can be solved by modifying the implementation such that a terminodes is allowed to decide whether to buy a packet or not. This provides a back pressure mechanism, which may ensure that eventually nobody will buy packets from misbehaving senders. Robustness The implementation of packet purse and packet trade models is robust and resists against various attacks. Nugget forgery is prevented, because it would require either an illegitimate increase of the nugget counter, or the generation of fake packet purses or acknowledgements. The former is impossible, because the nugget counter is manipulated by the Security Module, which functions correctly and its behaviour cannot be altered. The latter is prevented by the use of cryptographic checksums (i.e., the Purse Authentication Code and the Acknowledgement Authentication Code), which can be computed correctly only by the Security Module. These checksums also protect the integrity of the PPH during transit. Furthermore, the packet purse cannot be detached from the packet and re-used with another one, because the calculation of the Purse Authentication Code involves the cryptographic hash value of the content of the packet. Replay of the packet purse is prevented by the use of an ever increasing counter that is placed in the purse. The originator of a packet cannot re-use the nuggets that it has already loaded in the packet, because the Security Module decreases the nugget counter when creating a PPH for a new packet. An intermediary cannot take out more nuggets from the packet than it deserves for the packet forwarding, because its nugget counter can be manipulated exclusively by its Security Module, which behaves correctly. Moreover, the intermediary is stimulated to forward the packet, because its nugget counter will be increased only if an acknowledgment arrives from the next hop, and this is possible only if the packet has been forwarded. 3. Reputation based mechanism This solution is developed by Sonja Buchegger and Jean-Yves Le Boudec [4], as an extension to routing protocols for mobile ad-hoc networks. This approach finds the selfish and/or malicious nodes and isolates them, so that misbehaviour will not pay off but result in isolation and thus cannot continue. This idea has been implemented as a protocol called CONFIDANT (Cooperation Of Nodes, Fairness In Dynamic Ad-hoc NeTworks). The CONFIDANT protocol works as an extension to routing protocols such as Dynamic Source Routing (DSR) protocol. The next section gives a brief introduction to the Dynamic Source Routing (DSR) protocol. 12

14 3.1. The Dynamic Source Routing Protocol Dynamic Source Routing (DSR) is a protocol developed for routing in mobile ad-hoc networks [5], [6]. The working principle of this protocol is as follows: A Route Request (E[A]) B Route Request (E[A,B]) Route Request (E[A,B]) Route Request (E[A,B]) E Route Request (E[A]) C Route Request(E[A,C]) D Cache E Fig. 6. ROUTE-REQUEST: A wants to send to E It is an on-demanding routing protocol, i.e., each time a node wants to communicate with another node a route has to be determined. A node that needs a route to another node broadcasts a ROUTER-REQUEST message. All nodes that receive this message forward it to their neighbours and put themselves into the route. A request is only processed once by each node, i.e., if a node receives a request for the second time it is ignored. A Route Reply (A,[E,B,A]) B Route Reply (A,[E,B,A]) E Route Reply (A,[E,D,C,A]) C Route Reply (A,[E,D,C,A]) D Fig. 7. ROUTE-REPLY: both D and E know a path If a receiving node is the destination, or is aware of a route to the destination, it does not forward the request, but sends a ROUTE-REPLY message back to the originator of the request containing the full route. After receiving one or several routes, the source selects the best (e.g., the shortest), stores it, and sends messages along that path. An example for route discovery process is given in Fig. 6 and Fig. 7. For example, if node A wants to find a route to E, it sends a ROUTE-REQUEST message to its neighbours B and C. Node B adds itself into the route and forwards the request to its neighbours C, D and E. Node C also adds itself into the route and then forwards the request from node A to its neighbour D. Since node C already received the same request from node A, it drops the second request message which is forwarded by B. Since node D 13

15 has a path to the destination, it does not forward the request to its neighbours. Instead it sends a ROUTE-REPLY message to the previous node C. Node E receives the request message from B and E sends a ROUTE-REPLY message to B, because node E itself is the destination. Nodes B and C forwards the ROUTE-REPLY to node A. Now, node A has discovered two different routes to E. In case of a link failure, the node that can not forward the packet to the next node sends an error message towards the source. Routes that contain a failed link can be recovered by bypassing the bad link Problems to be solved The problem described in section 1.2 which is known as service availability problem may happen in several ways. This section lists the problems to be solved by the CONFIDANT protocol: If a node receives a data packet or control message such as ROUTE-REQUEST, it has to forward it. If a node does not forward the received message, this malicious behaviour has to be detected in order to enforce the service availability. Traffic deviation: unusual traffic attention (advertises many excellent routes or advertises routes very rapidly, so they are considered good routes) or the opposite (claims to have only bad routes). A node may misbehave by performing rerouting which is normally used to avoid a broken link, although no error has been observed. Unusual frequent route updates aimed to overload the network with traffic. Silent route change (tampering with the message header of either control or data packets) is a kind of network attack, which has to be found out The CONFIDANT Protocol Nodes monitor their neighbours and change the reputation accordingly. If they have enough reason to believe that a node misbehaves, they can take action in terms of their own routing and forwarding and they can decide to inform other nodes by sending an ALARM message. When a node receives such an ALARM, it evaluates how trustworthy the ALARM is, based on the source of the ALARM and the accumulated ALARM messages about the node in question. It can then decide whether to take action against the misbehaving node CONFIDANT Components The CONFIDANT protocol has been split into four functional components: a Monitor, a Trust Manager, a Reputation System and a Path Manager. This section describes these functional components. The functional diagram of the CONFIDANT protocol is shown in Fig. and it also shows the relationship between the components of the CONFIDANT protocol. 14

16 The Monitor This component monitors neighbours for unusual behaviour. It can detect misbehaviour by either listening to the transmission of the next node or by observing route protocol behaviour. The monitor registers deviations of normal behaviour if it detects. As soon as a given bad behaviour occurs, the reputation system is called. Reputation System ALARM Trusted Node re-ranked Trust Manager ALARM Node re-ranked Event Detected ALARM Receivd Path Manager Monitor ALARM Route information Routing Protocol (DSR) Control messages Fig.. CONFIDANT Components in a node The Trust Manager This component deals with incoming and outgoing ALARM messages. The trust manager of a node sends ALARM messages to a group of neighbours (friends) if it wants to warn others of malicious nodes i.e., it generates outgoing ALARMs after having experienced, observed, or received a report of malicious behaviour. ALARM messages received from friends or other nodes has to be checked for trustworthiness before taking action. Therefore the trust manager filters the incoming ALARMs according to the trust level of the originator of the ALARM. The trust manager consists of the following components. An alarm table containing information about received alarms. Trust table managing trust levels for nodes to determine the trustworthiness of an ALARM. Friends list containing all friends a node sends alarms to. 15

17 Trust is important when making a decision about the following issues: Routing information from other nodes has to be evaluated how trustworthy the information is. The trust value of the originator of the routing information will be used. While accepting a node as part of a route the trust value of that node will be useful to decide whether to accept that node or not, and before taking part in a route originated by some other node, the originator has to be evaluated using the trust value so that the node will be avoided from servicing a malicious node. The Reputation System The reputation system in this protocol manages a table consisting of entries for nodes and their rating. The rating is changed only when there is enough evidence for malicious behaviour that is significant for a node and that has occurred a number of times exceeding a threshold to rule out coincidences. The rating is then changed according to a rate function that assigns different weights to the type of behaviour detection: Own experience: greatest weight, Observations: smaller weight, Reported experience: smallest weight. Once the weight has been determined, the entry of the node that misbehaved is changed accordingly. If the rating of a node in the table has deteriorated so much as to fall out of a tolerable range, the path manager is called for action. The Path Manager If the reputations of the nodes in a path change, the path manager performs path reranking. It detects paths containing malicious nodes and deletes these paths from its list. Upon receiving a request for a route form a malicious node it performs an action like ignore or do not send reply. Likewise, if it receives a request for a route containing a malicious node it performs an action like ignore or alert the source CONFIDANT Protocol Description Each node monitors the behaviour of its neighbours. If a suspicious event (i.e., any one of the problems described in section 3.2) is detected, the information is given to the reputation system. If the event is considerable for the node then it has to be checked to find out whether this event is deliberate malicious behaviour or simple coincidence by considering the number of occurrences of the same event. If the event has been detected more often than a specified limit, which is enough to distinguish malicious behaviour from simple coincidences, then the rating of that node will be updated by the reputation system. If the rating continuously goes down, leading to intolerable state, the path manager will be informed about this. The path manager removes all the paths containing the malicious node from the cache. The node continues to monitor the neighbourhood and an ALARM message is sent to warn other nodes about the misbehaviour of the intolerable node. 16

18 3.4 Analysis of CONFIDANT protocol The analysis of the performance of the CONFIDANT routing protocol extension in a mobile ad-hoc network where part of the population in that network acts maliciously, is described in [4]. For this performance analysis the regular DSR network which is called defenceless network and a version of DSR extended with CONFIDANT extensions which is called fortified network are used for comparison. These two networks are simulated such that part of the network behaves maliciously i.e., a certain number of nodes in the network behave maliciously. GloMoSim, which is a simulator for mobile ad-hoc networks, was used to carry out all the simulations for the performance analysis and each experiment was repeated 10 times. In this the area of the network is fixed to 1000m 1000m and the simulation time is set to 900s. Out of various routing and forwarding attacks forwarding defection (i.e., no forwarding of any packets by malicious nodes) is concentrated in this analysis. The Random Waypoint Model, which is a mobility model, was used in the simulations. In that model nodes move to a random destination at a speed uniformly distributed between 0 m/s and a specified maximum speed of 20 m/s. Once they reach the destination, they stay there for certain amount of time, which is called pause time. To reflect realistic user behaviour this movement model is used. The nodes run applications that generate Constant Bit Rate (CBR) data streams. The application is defined as follows: A client constantly sends to a server, which in turn responds to the client. The client-server pairs have been randomly generated for the simulations. This section shows some of the results of the simulation. In the graphs shown below the regular DSR protocol is denoted as defenceless and network with CONFIDANT protocol extension is denoted as fortified. Fig. 9 and Fig. 10 are the results of an experiment with the following parameters: The percentage of malicious node is fixed to one third of the network size, the size of the network (i.e., the number of nodes in the network) is varied to three different values 10, 20, 50, but for better understanding only the result for network size 20 is shown here. 10 applications are used in the network and the number of packets sent is Initially the pause time is varied and the mean number of packets dropped is measured. Fig. 9 shows this measurement as a graph between mean no of packets and pause time. The graph shows that in the defenceless network, the number of packets dropped intentionally is higher than in the network fortified with CONFIDANT. The curve shows that the results are almost constant with respect to mobility in defenceless network. But the fortified network is a little bit more sensitive to mobility. And then with the pause time 0 m/s, the mean no of packets dropped is measured for various network sizes (10, 20 and 50). Fig. 10 shows the result of this experiment. From a network size perspective, as shown in the graph the number of packets dropped increases with the no of nodes in the defenceless network, whereas the fortified network keeps the number of packets dropped as constant irrespective of the network size. In heavily loaded network, loss of packets due to malicious nodes in DSR fortified with CONFIDANT extensions is only a small fraction (always less than 3%) but loss in defenceless DSR network is around 70%. The analysed network consists of 50 nodes and 30 applications are used in order to make the network as heavily loaded network. 17

19 10000 mean no of packets dropped fortified defenceless 0, pause time(s) Fig. 9. Mean number of packets dropped versus pause time, one third is malicious. mean no of packets droped fortified defenceless number of nodes Fig. 10. Number of packets dropped versus number of nodes, one third is malicious, 0 pause time. 1

20 Fig. 11 and Fig. 12 are results of another experiment with the following parameters: network size is fixed to 50 nodes, the number of applications used is 30 and the pause time is set to 0 m/s. Initially the mean no of packets dropped intentionally by malicious nodes is measured for various percentages of malicious nodes in the network (from 0 to 100%). The result is shown in the Fig. 11. In defenceless network even a small percentage of malicious nodes can affect the network. But the fortified network keeps the number of packets dropped low even in an environment where more than 50 percentages of the nodes in the network act maliciously mean number of packets dropped fortified defencelsee 0, percentage of malicious nodes Fig. 11. Number of packets dropped, 50 nodes, 30 applications, 0 pause time, varying percentage of malicious nodes. Further more mean goodput is measured for various percentage of malicious nodes in the network (from 0 to 100%) where goodput is defined as a metric which expresses the data forwarded to the correct destination for each node i in a network with n nodes ( goodput= n i=1 Packets Received / n i=1 Packets Originated ). Goodput is directly influenced by packet loss. The fortified network keeps performance up in the presence of up to 40% of the malicious nodes and deteriorates only slightly in the presence of up to 60% of malicious nodes. Finally, with 90% or more malicious nodes the fortified network can no longer improve the performance. This is shown in the Fig. 12. As shown in the graph even in a population of only malicious nodes there is still a goodput of about 20%. This happens due to a portion of the communication happening between nodes that are within the radio range of each other. Only 0% of goodput is measured even for a network containing no malicious nodes because here the packet loss due to the link errors is also taken into account in addition to the packet loss due to the malicious nodes. 19

21 100 0 mean goodput(%) fortified defenceless percentage of malicious nodes Fig. 12. Goodput, 50 nodes, 30 applications, 0 pause time, varying percentage of malicious nodes. 4. Conclusion This paper addresses the problem of service availability in mobile ad-hoc networks. It discusses two different concepts and their implementations to solve this problem. The first approach introduced is charging the packet forwarding service. It describes two different implementations of the charging the packet forwarding service idea (Packet Purse Model and Packet Trade Model). Both of these implementations have their own advantages and disadvantages. Packet Purse Model indeed solves the problem of service availability by stimulating the user to provide the packet forwarding service and preventing overloading the network. But it has a disadvantage in its implementation because an estimation of the exact number of nuggets to be loaded in a packet is difficult. This problem is solved in the Packet Trade Model but it fails to prevent the problem of maliciously overloading the network. The second approach introduced is a reputation based method. CONFIDANT as an extension of the underlying routing protocol is discussed as a solution for enforcing service availability. Malicious behaviour such as a denial of the packet forwarding service is discouraged because CONFIDANT isolates the malicious nodes so no packets will be forwarded to the maliciously behaving nodes. Network performance i.e., the packet forwarding service by the participating nodes in the network is well even in a network with more than 50% of malicious nodes if the network is fortified with the CONFIDANT protocol extensions. But the performance of the network without CONFIDANT protocol collapses even in a small percentage of malicious nodes. 20

22 References [1] L. Buttya n and J.-P. Hubaux, Enforcing Service Availability in Mobile Ad-Hoc WANs, in Proceedings of the IEEE/ACM Workshop on Mobile Ad Hoc Networking and Computing (MobiHOC), Boston, August [2] J.-P. Hubaux, J.-Y. Le Boudec, S. Giordono, and M. Hamdi, The Terminode Project: toward mobile ad-hoc WANs, in Proceedings of the Mobile multimedia Conference, MOMUC, San Diego, [3] Terminodes web site. [4] S. Buchegger and J.-Y. Le Boudec, Performance Analysis of the CONFIDANT Protocol (Cooperation of Nodes: Fairness In Dynamic Ad-hoc NeTworks), in Proceedings of the ACM Symposium on Mobile Ad Hoc Networking and Computing (MobiHOC), Lausanne, Switzerland, June [5] L. Blazevi c, S. Giordano and J.-Y. Le Boudec, Nodes Bearing Grudges: Towards Routing Security, Fairness, and Robustness in Mobile Ad-Hoc Networks, in 10th Euromicro Workshop on Parallel, Distributed and Network-based Processing, Jan [6] D. B. Johnson and D. A. Maltz, The dynamic source routing protocol for mobile ad hoc networks, Internet Draft, Mobile Ad Hoc Network (MANET) Working Group, IETF, October