Secure Forwarding in Personal Ad Hoc Networks

Secure Forwarding in Personal Ad Hoc Networks

Master Thesis

Author: Qi Xu

Supervisors: Dr.ir. Sonia Heemstra de Groot (INF-DACS/WMC) Dr.ir. Pieter-Tjerk de Boer (INF/DACS) Assed Jehangir M.Sc. (INF/DACS) ir. Simon Oosthoek (WMC)

Design and Analysis of Communication Systems Faculty of Electrical Engineering, Mathematics and Computer Science University of Twente May 2005, Enschede

Secure Forwarding in Personal Ad Hoc Network

I

Abstract

This thesis focuses on secure packet forwarding in ad hoc networks and proposes a new reputation-based solution to mitigate the effects of adverse situations caused by misbehaving nodes. The new solution consists of three necessary parts: detection, prevention and reaction. An objective and effective dynamic detection mechanism is introduced. It could be used to detect misbehaving nodes through performing neighbor monitoring and local reputation exchange in a fully distributed way. A new prevention approach based on reputation information of intermediate nodes is also described. This prevention mechanism exploits all well-behaving nodes’ local knowledge to bypass misbehaving nodes, evaluate path quality and choose the most reliable path for data forwarding. In addition, some reaction approaches have been mentioned which could be used to enforce cooperation in ad hoc networks. Furthermore, the packet delivery ratio is primary evaluated in different scenarios.


II


III

Acknowledgement

This thesis is the result of my work in WMC for the master final project. Many people contributed to the completion of this thesis. I would like to express my gratitude to all these people who gave me help and support during this period of time. The first person I would like to express my acknowledgement is my direct supervisor Sonia Heemstra de Groot who helped me whenever I had problems during the research. Her valuable guidance and technical advices enabled me to complete this project. I want to express my gratitude to Assed Jehangir who kept close to the process of my work and always was available when I needed his help, and provided me with much information and support. I am very grateful to my committee members Pieter-Tjerk de Boer and Simon Oosthoek for their valuable comments and recommendations. Thanks to Bram van Zeist and Malohat Kamilova with whom we had pleasant and fruitful discussions while working on the project. I am grateful to people in WMC for the fine working atmosphere and for their supports. My absolute acknowledgement is dedicated to my parents, who gave me great encouragement and inspiration throughout my study. Their support enabled me to complete this thesis and finish my education in UT.


IV


V

Table of Contents Abstract ............................................................................................................................................I Acknowledgement.........................................................................................................................III 1 Introduction ............................................................................................................................ 1

1.1 Background....................................................................................................................... 1 1.1.1 WLAN ..................................................................................................................... 2 1.1.2 WPAN...................................................................................................................... 2 1.1.3 PN............................................................................................................................ 2 1.1.4 Mobile Ad Hoc Network ......................................................................................... 7

1.2 Research Objective ........................................................................................................... 11 1.3 Other Relevant Technologies............................................................................................ 12 1.4 Thesis Structure ................................................................................................................ 12

2 Secure Data Forwarding in Mobile Ad Hoc Networks...................................................... 13 2.1 Secure Routing Challenges and Solutions........................................................................ 13

2.1.1 Challenges ............................................................................................................. 13 2.1.2 Secure Routing Protocols ...................................................................................... 14

2.2 Secure Data Forwarding Challenges and Solutions.......................................................... 15 2.2.1 Challenges ............................................................................................................. 16 2.2.2 Secure Data Forwarding Solutions ........................................................................ 16

3 A New Reputation-based Secure Forwarding Solution..................................................... 22 3.1 Motivations....................................................................................................................... 22

3.1.1 Reputation Requirements....................................................................................... 23 3.1.2 Solution Features ................................................................................................... 23

3.2 Assumptions ..................................................................................................................... 24 3.3 Solution Overview............................................................................................................ 25

3.3.1 Detection................................................................................................................ 25 3.3.2 Prevention.............................................................................................................. 26 3.3.3 Reaction................................................................................................................. 26

4 Dynamic Misbehaving Node Detection............................................................................... 29 4.1 Neighbor Sensing ............................................................................................................. 29 4.2 Neighbor Monitoring Rules.............................................................................................. 30

4.2.1 Packet Forwarding Monitoring.............................................................................. 30 4.2.2 Data Packet Forwarding Rules .............................................................................. 31 4.2.3 Route Packet Forwarding Rules ............................................................................ 32

4.3 Detection Mechanism Description ................................................................................... 35 4.3.1 Neighbor Sensing Implementation ........................................................................ 35 4.3.2 Neighbor Table ...................................................................................................... 36 4.3.3 Neighbor Monitoring and Local Reputation Calculation ...................................... 37 4.3.4 Weaknesses of Neighbor Monitoring..................................................................... 42 4.3.5 Possible Optimizations .......................................................................................... 44 4.3.6 Local Reputation Propagation and Global Reputation Calculation ....................... 44


VI

5 Prevention Technique and Optimal Route Discovery........................................................ 51 5.1 Motivation ........................................................................................................................ 51

5.1.1 Bypassing Misbehaving Nodes.............................................................................. 51 5.1.2 Optimal Route Discovery ...................................................................................... 52 5.1.3 Local Reputation.................................................................................................... 52

5.2 Overview .......................................................................................................................... 53 5.3 Detailed Operations .......................................................................................................... 55

5.3.1 Originating a Route Request Packet ...................................................................... 55 5.3.2 Processing a Received Route Request Packet ....................................................... 56 5.3.3 Originating a Route Reply Packet ......................................................................... 59 5.3.4 Processing a Received Route Reply Packet........................................................... 61 5.3.5 Optimal Route Selection........................................................................................ 63

5.4 Analysis ............................................................................................................................ 65 5.4.1 Performance for Various Misbehaving Nodes ....................................................... 65 5.4.2 Limitations............................................................................................................. 66

6 Performance Evaluation ...................................................................................................... 69 6.1 Network Simulator Introduction....................................................................................... 69 6.2 DSR in NS-2..................................................................................................................... 70

6.2.1 Mobile Node Architecture ..................................................................................... 70 6.2.2 DSR Mobile Node Architecture ............................................................................ 71 6.2.3 DSR Implementation in NS-2................................................................................ 72

6.3 Simulation Setup .............................................................................................................. 73 6.3.1 Simulation Configuration ...................................................................................... 73 6.3.2 Movement Model .................................................................................................. 74 6.3.3 Communication Model .......................................................................................... 74 6.3.4 Misbehaving Nodes ............................................................................................... 75

6.4 Simulation Result Analysis............................................................................................... 75 6.4.1 Mobility Influence ................................................................................................. 76 6.4.2 Misbehaving Nodes ............................................................................................... 77 6.4.3 Bypassing Misbehaving Nodes.............................................................................. 80 6.4.4 Optimal Route Discovery ...................................................................................... 81

7 Future Work.......................................................................................................................... 84 8 Conclusion............................................................................................................................. 85 Reference ....................................................................................................................................... 86 Appendix A: Simulation Script ................................................................................................... 91


1

1 Introduction

In recent years, rapid growth in wireless communications has stimulated numerous researches in this field. Many new wireless technologies have been developed, such as WiFi, HiperLAN, Bluetooth, ZigBee, UWB and WiMax. This chapter gives the corresponding background introduction and the objective of this assignment. Section 1.1 presents the background information in which Personal Network and mobile ad hoc network are primarily introduced. Section1.2 describes the objective of this assignment. Section1.3 briefly introduces the other relevant technologies investigated and discussed during this period of time. And section 1.4 gives the structure of this thesis.

1.1 Background

Wireless technologies have many advantages compared with their wired competitors, such as flexibility, robustness, mobility and scalability. Therefore, many wireless technologies have been developed recently for various purposes. The following table shows some well-known wireless technologies.

Table 1. Wireless technologies [8]


2

1.1.1 WLAN

A wireless local area network (WLAN) is one in which a mobile device can connect to a local area network through a wireless connection. WLAN technologies have created a fast-growing market currently. It also introduces the flexibility of wireless access into office, home, and other various environments. In addition, many infrastructure providers have been building Wireless LAN hot spots in public areas such as airports, railroads, and hotels, to enable people to perform data communication in a more convenient way. The IEEE 802.11 [4] standards specify the technologies for wireless LANs. Currently standard-based wireless LANs can operate at high speeds. For example, the majority of WLAN products (802.11b) today are able to communicate at speeds up to 11 megabits per second, new WLAN standards (802.11a and 802.11g) are able to provide up to 54 Mbps transmission, and 802.11n [9] is expected to support transmission rate at least 100 Mbps. Some other standards within 802.11x family are recently proposed for different requirements. For example, 802.11e is intended to enhance the 802.11 MAC to improve and manage Quality of Service (QoS), 802.11i defines strong authentication and access control mechanisms to provide improved security, and 802.11k defines radio resource measurement mechanism.

1.1.2 WPAN

Personal Area Networks (PANs) [3] also have received much interest in the research community recently. The trend is due to the rapid development of personalized devices and the growing user-centric communication and computing applications. A wireless personal area network (WPAN) is a short-range wireless ad hoc communication system built in the vicinity of a person. WPANs can be used for data communications among the personal devices, or for connecting these devices to a higher level network or the Internet. IEEE 802.15 standards specify the wireless technologies for WPANs, such as low layers of Bluetooth [5] and Zigbee [7]. Power consumption, complexity, size and cost constrains are considered carefully in these technologies in order to design short-range, low-cost wireless devices. These wireless technologies have different purposes: 802.15.3 (WiMedia) [6] is intended to support fast transmission rates, and is suitable for home networks. 802.15.4 (Zigbee) is designed for sensor networks and targets low power consumption and low cost.

1.1.3 PN

1.1.3.1 Introduction More and more small but powerful mobile devices are produced and becoming popular in recent years, person-centric applications and services are getting more attractive. As a consequence, many researchers are working in this field to develop new networks to meet the increasing requirements. A personal network (PN) [1,2] is a new concept related to pervasive computing with a strong user-focused view, which extends a person’s Personal Area Network


3

(PAN) with remote devices and services. The extension could be made via infrastructure-based networks or multi-hop ad hoc networks. PN is now being developed within the IST MAGNET project [10]. A PN connects a person's Personal Nodes together by using direct local wired or wireless connections as well as infrastructure-based connections and multi-hop ad hoc networks (connecting geographically dispersed Personal Nodes). By integrating all of a person’s devices and resources into a person’s PN, not only the devices within the person’s vicinity could be used, but also those far away are available at any moment. Communication with other persons’ Personal Networks as well as independent Foreign Nodes are also considered. For example, in figure 1, the PN includes the nodes in the core PAN (Private-PAN) around the user, and nodes in remote networks (clusters), such as the home network, and the corporate network. The geographically dispersed clusters could be interconnected through a variety of available networks, such as the Internet, UMTS, and ad hoc networks. Therefore, a person can make use of all his/her devices and relevant services regardless of the current location. Besides, communications among different persons’ nodes could also be performed at the same time.

Figure 1. An example of a PN [1]

A PN must be self-configuring and self-organizing to adapt to the changes in surroundings, user’s context, location and other conditions, so that ordinal users can operate their Personal Networks in an efficient and simple way. And due to the fact that a PN could incorporate all possible devices of a person, not only the portable devices are included, but also the devices at home, in the car and in the office should also be considered. Therefore, on the network layer, all these devices and networks should be integrated into one PN.


4

1.1.3.2 Abstraction levels

Figure 2. Three-level PN architecture [38]

As shown in figure 2, a proposed PN architecture has been given in the IST MAGNET project [37, 38]. The first level is called the service abstraction level, which addresses the problems related to discovering services inside or outside a PN. The second level is the network abstraction level addressing the problems related to the network and transport layers. The third level is called the connectivity abstraction lever, which specifies and implements PAN radio interfaces. 1.1.3.3 Communication in PNs Secure routing and forwarding is the research objective of this assignment, so some routing issues in PNs are introduced in this section. The network layer is the place where the whole PN for a particular person is constructed and maintained. It is concerned with issues such as addressing, routing and self-organization. Communications in PNs could be classified into several domains. 1.1.3.3.1 Communication in P-PAN The advantage of secure data communication in a P-PAN is that all nodes within this network belong to the same user. Therefore, trust relationship could be easy to be established among these nodes. Mobile ad hoc networks are suitable for P-PAN. Either proactive or reactive routing protocols could be used in a P-PAN depending on the concrete scenarios. Routing protocols designed for mobile ad hoc networks are introduced in the section 1.1.4.4.


5

Figure 3. Communication in P-PAN

1.1.3.3.2 Intra-cluster Communication Intra-cluster communication has the similar characteristics with P-PAN communication. However, it is likely that less communication happened in a cluster than that in a P-PAN, a reactive routing protocol may be more suitable.

Figure 4. Intra-cluster communication

1.1.3.3.3 Inter-cluster Communication In each cluster, one (or multiple) node is selected as gateway that is responsible for handling all traffic to or from the nodes in this cluster. If a node wants to communicate with another node in a different cluster, it first needs to send data to the gateway. Inter-cluster communication depends on the interconnection structure to connect different clusters. If an infrastructure network is applied as the interconnection structure, IPsec could be used to provide security using tunnel, authentication and encryption mechanisms. If the interconnection structure is an ad hoc network, more security problems will appear, for example, intermediate nodes could drop packets or modify routing information to launch a variety of attacks.


6

Figure 5. Inter-cluster communication 1.1.3.3.4 Communication with foreign nodes The lack of trust relationship gives big challenges for secure communication in this scenario. In infrastructure networks, central agents (Certification Authority) could be used to support establishment of trust relationship. However, it is possible that no such CA is available in some situations. Several solutions are mentioned in [80] to address this problem, such as SUCV [81] and pre-authentication.

Figure 6. Communication with foreign nodes

A mobile ad hoc network could be a quite suitable network to be applied in PNs, not only for communications among Personal Nodes in a P-PAN, but also for interconnecting geographically dispersed nodes that belong to multiple clusters (Figure 5, 6). In order to route packets among Personal Nodes as well as to and from Foreign Nodes, routing schemes [38, 39] must be investigated in PNs. In order to make the research more general, in this project, we investigate routing and data forwarding security in a mobile ad hoc network in which trust relationships only exist between sender nodes and destination nodes.


7

1.1.4 Mobile Ad Hoc Network

Mobile ad hoc networks could be important network architectures in PNs due to their unique characteristics, such as infrastructure-independence, self-organization. Within a P-PAN or cluster, a mobile ad hoc network is quite suitable for data exchange among devices due to its simplicity and dynamic topology. When inter-cluster communication is considered, each cluster is regarded as a small mobile network. All these networks could be interconnected through mobile ad hoc networks. In other words, all cluster gateway nodes can communicate with each other to form a mobile ad hoc network. This is useful especially for communication with other persons’ PNs. 1.1.4.1 Introduction During the past decade, mobile computing and wireless communication technologies have been developing extremely fast due to the proliferation of inexpensive, widely available wireless devices. Current cellular systems have reached a high penetration rate, enabling worldwide mobile communication and Internet access. In addition, more and more wireless LAN hot spots are emerging, allowing people to surf the Internet in airports, railways, hotels and other public areas with their portable devices, such as laptops. All these networks are conventional networks which depend on fixed network infrastructure and central administration. These networks require a large investment before they are operational and useful. Furthermore, updating these networks to meet continuously growing requirements, such as bandwidth, has proven to be quite expensive and slow. And at the same time, more and more digital devices are produced which could be equipped with relatively short-range wireless transmission interfaces. These devices are becoming smaller, cheaper, and more popular and powerful. In order to enable multiple small portable devices to interconnect with each other without any fixed infrastructure, a new alternative network architecture has been designed, in which all devices form a self-organizing and self-administering wireless network, called a mobile ad hoc network [8, 27]. The emergence of mobile ad hoc networks enables network accessing and data communication in an area where no fixed infrastructure exists or existing infrastructure is not available. Because ad hoc networks do not rely on any existing infrastructure and are self-organizing, this kind of networks is quite suitable for communication in very diverse environments. For example, mobile ad hoc networks can be used in battlefield as well as in remote areas where infrastructure is not available and building infrastructure in such area is too expensive or time consuming. They also can be used in an area suffering from natural disaster. 1.1.4.2 Common Network Architectures There are two common architectures of a mobile ad hoc network:

Hierarchical network architecture: Each sub-network dynamically interconnects with


8

other sub-networks through its gateways. All traffic to and from a sub-network must pass through its gateways. It could be a feasible network model for PNs, in which multiple clusters belonged to same or different persons could form big mobile ad hoc networks dynamically. An example of such mobile ad hoc networks is shown in figure 7.

Figure 7. A two-tier mobile ad hoc network

Flat network Architecture: In this architecture, all nodes are treated equally, and there is

no gateway in a cluster. An example of flat mobile ad hoc networks is shown in figure 8.

Figure 8. A flat mobile ad hoc network

1.1.4.3 Characteristics of Mobile Ad Hoc Networks Mobile ad hoc networks have some specific characteristics mentioned in table 2 briefly:


9

Characteristics Infrastructure-independence Multi-hop Dynamic network topology Energy constrained operation Bandwidth constrained Limited physical security Network scalability Decentralized control and management self-organization and self-configuration

Table 2. Characteristics of mobile ad hoc networks

1.1.4.4 Routing Protocols Within a mobile ad hoc network, a node's radio transmission range typically can not cover the whole network. In order to enable a node to communicate with other nodes out of its radio coverage, a route generally contains several intermediate nodes, and this is why ad hoc networks are also referred to as multi-hop networks. For data communication in a network, a node must depend on routing protocols to discover routes to the specific destinations. A mobile device is generally limited by its available resources, such as computation capability and memory capacity. Moreover these devices are likely to be battery powered, so energy constraint is another important issue that must be considered. Because of these resource limitations, routing protocols designed for mobile ad hoc networks must take special requirements into account. Therefore, the existing routing protocols designed for wired networks are not suitable for mobile ad hoc networks, and new routing protocols have been designed recently. Some routing protocols are introduced here.

1. Proactive routing protocols For proactive routing protocols, the routing control information is exchanged in the network periodically to enable each node to get a good knowledge of network topology. The advantage of this kind of routing protocols is that the routes are available immediately when a node wants to communicate with other nodes.

DSDV Destination-Sequenced Distance-Vector (DSDV) [28] was developed 1994 by C. Perkins and it is a proactive distance-vector routing protocol. Its difference from traditional distance vector routing protocols is that each entry in routing table or a routing update message is tagged with a sequence number, which is generated by the destination. The sequence number is used to guarantee loop free and to prevent stale routing information being used. Only routing information with higher destination sequence numbers or same destination sequence but better metric will be used to update


10

routing table. This technique promises that only newest routing information will be used.

OLSR

Optimized Link State Routing Protocol (OLSR) [29, 30] is an optimization over a pure link state routing protocol, and utilizes a multicast-like mechanism to reduce control traffic overhead. Each node declares a subset of its symmetric 1-hop neighbors as its multipoint relays (MPRs), through which all its symmetric 2-hop neighbors can be reached. OLSR minimizes the flooding of control traffic in the network by using only these MPRs to retransmit control messages. This technique significantly reduces the number of retransmissions required to flood a message to all nodes in the network. Furthermore, OLSR requires a node to broadcast only a part of its link state information about its neighbors.

TBRPF

Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) routing protocol [74] is another proactive, link state routing protocol designed for mobile ad hoc networks. Each node reports part of its source tree to its neighbors to minimize overhead. A modification of Dijkstra’s algorithm is used to calculate a source tree and only partial topology information in the topology table is used. Both periodic and differential updates are used to enable all neighbors to obtain full or additional topology information.

2. Reactive routing protocols For reactive routing protocols, they work in an on-demand way. Routing information is only transmitted in the network when a node has something to send but no suitable route is available. This kind of routing protocol is suitable for large networks, and necessary route control traffic is smaller than that of reactive routing protocols.

AODV

Ad hoc On-Demand Distance Vector (AODV) [31] routing protocol is a reactive routing protocol specially designed for mobile ad hoc networks. It enables mobile nodes to obtain routes quickly for new destinations, and do not require nodes to maintain routes to those destinations that are not in active communication. AODV builds routes using a route request / route reply query cycle. Each node keeps a next-hop routing table containing the destinations to which it currently has a route. AODV makes use of a destination sequence number for each route entry to guarantee loop free.

DSR

Dynamic Source Routing (DSR) [32] protocol is another well-know reactive routing protocol designed for mobile ad hoc networks with various efficiency improvements. DSR is one of the most preferred protocols due to its simplicity and efficiency. It enables the network to be completely self-organizing and self-configuring. DSR also employs


11

route request / route reply packets in the route discovery phase to discover routes on-demand. And each node keeps a routing table that contains full paths to some specific destinations. In the data packet forwarding phase, a complete path is included in each data packet.

3. Hybrid routing protocols For hybrid routing protocols, both proactive and reactive mechanisms are applied.

ZRP Zone routing protocol (ZRP) [33] is a hybrid routing protocol that combines both the proactive and the reactive routing mechanisms. The route discovery phase can be divided into an intra-zone discovery and an inter-zone discovery. Intra-zone discovery involves all the nodes whose distance from the sender is in a certain number of hops, and it is executed in a proactive way. And inter-zone discovery operates using a reactive approach. The tradeoff between proactive and reactive routing protocols defines the optimal zone radius in a specific network.

Besides the routing protocols mentioned above, many other routing protocols have been proposed, such as Temporally-Ordered Routing Algorithm (TORA) [34], Dynamic MANET On-demand Routing Protocol (DYMO) [35], and Ariadne [36].

1.2 Research Objective

The ad hoc nature of PNs brings serious security challenges. Research in the field of secure routing could be divided into two complementary parts: secure route discovery and secure data forwarding. This thesis addresses the problems on secure data forwarding. In ad hoc networks each node functions as a router and forwards packets for other nodes. Here, we study the impact of misbehaving nodes on packet forwarding. Most existing routing protocols designed for ad hoc networks typically assume a trusted and non-adversarial environment where each node is assumed to be cooperative and well-behaving. This assumption is not true in a hostile environment. The existence of misbehaving nodes may significantly disrupt the network operation and degrade the network performance. For example, if a misbehaving node on an active route drops data packets, then a large number of packets will be lost. Simulation results show that the average packet delivery ratio of DSR [11] degrades by 30%, when 20% nodes are misbehaving nodes [12]. The main objective of this research is to investigate security issues in the context of PNs based on mobile ad hoc networks, analyze the benefits and weaknesses of currently existing solutions, and find new and effective solutions for the purpose of secure data forwarding in mobile ad hoc networks.


12

1.3 Other Relevant Technologies

During the process of doing this assignment, in additional to the investigation of security challenges, corresponding secure routing and forwarding techniques, other relevant technologies have also been studied to evaluate their applicability and adaptability in PNs. Security in Bluetooth [13, 14, 15] and 802.11i [16] was analyzed to see whether these security mechanisms could be used in PNs to provide link-level security for data communication. Link-level authentication and encryption, initial key establishment, and security weaknesses were primarily studied. IPsec [17, 18] was analyzed to see how to employ it to support secure packet exchange on the network layer in PNs, especially for communication between different clusters. Some related protocols and techniques are studied, such as AH [22], ESP [23], IKE [18], and HMAC [21]. Mobile IP [24, 25] and Network Mobility (NEMO) [26] have also been studied for the purpose of defining possible network layer architecture of PNs. Address auto-configuration, mobility management and relevant protocols have been investigated.

1.4 Thesis Structure

The remainder of this report is organized as follows: chapter 2 discusses the security problems related to routing and forwarding in mobile ad hoc networks, and some proposed solutions are classified and analyzed. Chapter 3 introduces a new reputation-based solution for secure data forwarding containing three components: prevention, detection and reaction. Chapter 4 specifically describes the detection mechanism of this solution, which is used to detect misbehaving nodes in the network. Chapter 5 introduces the prevention mechanism of the solution, which is used to bypass misbehaving nodes and discover the optimal routes. Chapter 6 presents and analyzes the simulation results to show the effect caused by various misbehaving nodes, and the network performance improvement if the prevention techniques is applied. Chapter 7 gives the future research in this area and chapter 8 gives the conclusion of the thesis.


13

2 Secure Data Forwarding in Mobile Ad Hoc

Networks

Characteristics of mobile ad hoc networks such as infrastructure-independence and self-organization make this kind of networks very flexible. However, at the same time some new security challenges specific to this new technology appear. In this chapter, the challenges related to routing and data forwarding in mobile ad hoc networks are discussed. Some proposed solutions are introduced and analyzed. Section 2.1 is related to secure routing, and section 2.2 is related to secure data forwarding.

2.1 Secure Routing Challenges and Solutions

In this section, the security challenges related routing in mobile ad hoc networks are discussed, and some corresponding solutions are described briefly, which are primarily used to guarantee the acquisition of correct routing information.

2.1.1 Challenges

The provision of security in mobile ad hoc networks faces a set of challenges. Unique characteristics of mobile ad hoc networks, such as open network architecture, shared medium, highly dynamic network topology, lack of infrastructure and authorization facilities and decentralized control [40, 41, 59, 60], introduce many new security challenges. The infrastructure-independence feature of mobile ad hoc networks extends the application scope of this kind of networks, but it makes network control and management more difficult compared to traditional networks. Many efficient and effective network management schemes such as central network control and authentication mechanisms can not be directly implemented in mobile ad hoc networks. Absence of infrastructure also impedes the popular operation of establishing a line of defense. As a consequence, it increases the difficulty of detecting attacks. Dynamic network topology is another important characteristic of mobile ad hoc networks. All nodes in such networks are allowed to move arbitrarily at any time. And each node could join and leave the network independently. The network topology of a mobile ad hoc network is likely to change dynamically. Therefore, it is difficult to have a clear global view of an ad hoc network.


14

Trust relationships among nodes may also change dynamically in some scenarios due to the flexibility of ad hoc networks. Furthermore, in large-sized mobile ad hoc networks, it is possible that there is no trust relationship among the majority of nodes. For example, when an ad hoc network is used as the interconnection structure for communication among a large number of users, it is possible that no trust relationship is available. As a consequence, security solutions with static configuration are not suitable for mobile ad hoc networks. Routing in wired networks is usually performed on dedicated devices such as switches, routers and gateways. But in mobile ad hoc networks, each node works as router and is responsible for forwarding packets for other nodes. This feature significantly complicates the network management and makes the network very vulnerable to attacks. If a misbehaving node on an active route begins to drop data packets, it is obvious that a large number of packets will be lost. Therefore, all nodes in a mobile ad hoc network are required to behave cooperatively to support the network operation. Mobile devices generally have limited resources, such as computational capability and memory capacity. They are also constrained by energy since they are more likely to be battery powered. Therefore, complicated and expensive solutions, such as advanced authentication or encryption/decryption operations performed on each packet, are not very suitable for this kind of networks. When these factors mentioned above are considered, it is difficult to promise that no misbehaving nodes exist in mobile ad hoc networks. Moreover, compared to traditional infrastructure-based networks, it is much easier for misbehaving nodes to perform some harmful activities in mobile ad hoc networks, especially for operations related to routing and forwarding. For example, a malicious node could claim that it is one hop away from a specific destination to cause all routes to that destination to pass through it. Fabricating false routing information or modifying transmitted routing messages could cause data to be lost. A small number of misbehaving nodes could degrade the network performance significantly. Furthermore, mobile ad hoc networks require not only the correct execution of network operations such as routing and data forwarding by each node, but also fair distribution of these operations among all network nodes. The latter requirement is a big challenge and difficult to realize, but it is quite important and has received much attention recently.

2.1.2 Secure Routing Protocols

Most of the routing protocols designed for mobile ad hoc networks generally assume all nodes in the network are cooperative and well-behaving. But this assumption does not hold in many scenarios, in which routing information is vulnerable and misbehaving nodes could easily change the routing information to disrupt the network. Therefore, a number of secure routing protocols have been proposed to prevent a set of attacks that attempt to compromise the route discovery. These protocols could be used to guarantee the acquisition of correct network


15

topological information. Some proposed protocols are introduced briefly below.

ARIADNE Ariadne [51] is a new secure on-demand routing protocol and is based on DSR. Authentication of routing messages in Ariadne could be performed through three modes: shared secrets between each pair of nodes, shared secrets between communicating nodes together with broadcast authentication, or digital signatures. TESLA [53] is a widely accepted broadcast authentication protocol which relies on synchronized clocks. It is a very suitable authentication mechanism for Ariadne.

SEAD

Secure Efficient Ad hoc Distance vector (SEAD) routing protocol [54] is based on destination-sequence distance vector (DSDV) routing protocol. It makes use of one-way hash functions rather than expensive asymmetric cryptographic operations to protect routing information. It is quite efficient and can be employed by mobile nodes that constrained with resources. In SEAD, hop counts and sequence numbers are protected by hash chains.

SRP

Secure Routing Protocol (SRP) [50, 52] is based on DSR. SRP could guarantee the acquisition of correct routing information. No assumption is made to intermediate nodes in SRP. Its only requirement is that a security association (SA) exists between endpoints of a path, which is used for Message Authentication Code (MAC) calculation. MAC is used to support data integrity and message originator authenticity of route request/reply packets.

SAODV

Secure AODV (SAODV) [55] is a security extension to the AODV routing protocol. It can be used to protect routing information and provide security features like data integrity, originator authenticity and non-reputation. The protocol employs two schemes, digital signatures and hash chains. Digital signatures are used to protect non-mutable fields of messages, and hash chains are used to protect hop count information.

2.2 Secure Data Forwarding Challenges and Solutions

Data forwarding is the next phase of route discovery. Obtaining correct routing information does not guarantee that packets could reach their destinations. In this section, the security problems related to data forwarding in mobile ad hoc networks are discussed. Some proposed solutions for secure data forwarding are presented and analyzed.


16

2.2.1 Challenges

The secure routing protocols mentioned in 2.1.2 are primarily designed for routing information protection. They depend on various authentication mechanisms to provide routing data integrity and originator authenticity. However, even in case all obtained routing information is correct, misbehaving nodes can still launch various attacks in the data forwarding phase. For example, a misbehaving node could behave cooperatively during the route discovery phase, but drop data packets later (Denial of Service attack). Moreover, if misbehaving nodes simply drop all packets including routing related packets, all these solutions can not detect and prevent such attacks, as they focus only on the detection of modification of routing control traffic or fabricating false routing information. Generally, attacks in mobile ad hoc networks can be divided into two kinds: passive attacks and active attacks. Passive attacks such as eavesdropping give an adversary access to secret information, since the promiscuous mode is usually required by many protocols. Active attacks, such as replay attacks and DoS attacks, are launched by an adversary to propagate false information, impersonate other nodes, or disrupt the network operation. Besides these traditional attacks, in mobile ad hoc networks, a new type of attack is emerging which is less dramatic but more subtle. In mobile ad hoc networks, nodes are generally battery powered, so they have limited power available. As a consequence, a new type of misbehaving nodes called selfish nodes appeared in research papers [41, 42, 44, 61]. A selfish node does not intend to attack or jeopardize other nodes, but it refuses to spend its own resources such as energy on forwarding packets for other nodes. Its intension is to save energy to prolong its own life time. However, if there are a larger number of selfish nodes in a mobile ad hoc network, the network performance will degrade and well-behaving nodes’ burdens will increase significantly. In order to deal with these security challenges related to data forwarding, especially for malicious packet dropping and selfishness, some solutions have been proposed recently. In the following section, these solutions are introduced and analyzed.

2.2.2 Secure Data Forwarding Solutions

2.2.2.1 SMT In [47], the secure message transmission (SMT) protocol is proposed, which could be used to protect the data transmission against arbitrary malicious behavior of misbehaving nodes. Different from some detection mechanisms, this protocol takes advantage of topology and transmission redundancies to achieve secure data transmission. SMT consists of four elements: end-to-end secure and robust feedback mechanism, dispersion of the transmitted data, simultaneous usage of multiple paths, and adaptation to the network changing conditions. It requires a security association between endpoints of a communication.


17

A sender node disperses each message into a number of pieces according to a certain algorithm. This operation introduces redundancy to each message. And then each piece is transmitted over different path to the destination. At the destination node, a message could be reconstructed even if some message pieces are lost or corrupted. Each dispersed message piece carries a message authentication code (MAC) to provide integrity and authenticity of its origin. A security association between sender and destination is necessary. The destination node acknowledges the successfully received messages through feedback messages which are also protected. The main problem of this solution is that it is difficult to guarantee the required number of available routes for message pieces delivery. This is due to many factors, such as node mobility, congestion and transmission impairments. And another problem is that it needs much computation for MAC calculation and message division/reconstruction. 2.2.2.2 Watchdog and Pathrater This solution [41] is used to address packet lost problem caused by misbehaving nodes in mobile ad hoc networks. Two extensions are introduced to DSR to mitigate the effects of misbehaving nodes. The watchdog is in charge of monitoring neighbors to identify misbehaving nodes, and the pathrater try to prevent packets being delivered through these nodes. After a node forwards a packet, its watchdog checks whether the next node on the path forwards the packet cooperatively. The watchdog performs this operation by listening promiscuously to the next node's transmissions. If the number of packets a neighboring node drops exceeds a threshold, that neighbor will be regarded as a misbehaving node. The watchdog needs to know the next two hops in order to monitor the next node's data forwarding behaviors. Therefore, watchdog is implemented based on DSR. The pathrater in each node selects the most likely reliable route according to knowledge of misbehaving nodes and link reliability information. It calculates the route metric by averaging the rating of all nodes on a path and chooses the path with the highest metric. In this solution, the node rating is calculated in terms of link reliability rather than neighbor monitoring results. The pathrater only assigns and updates rating of nodes which are currently in use. In each interval, it increases a node's rating if the link is normal by 0.01 and decreases a node's rating by 0.05 if the link is broken during the data forwarding phase. The detected misbehaving node is reported to all nodes that are transmitting data through this node. And those sender nodes assign an extreme negative rating value to this reported misbehaving node. As a consequence, the routes containing this misbehaving node will have a negative value and will not be chosen.


18

Misbehaving nodes can be detected by watchdog and prevented by pathrater. However, there are some weaknesses of this solution. First, the transmission of reports about misbehaving nodes is vulnerable. In a network without trust relationship in most of the nodes, it is easy for a malicious node to give a report to claim that the next node is misbehaving. Secondly, the watchdog scheme is based on the assumption that misbehaving nodes behave cooperatively during the route discovery phase. But if these nodes drop all packets, they will not be detected. 2.2.2.3 BMR In [42], Xue and Nahrstedt propose a solution named BMR (Bypassing Misbehaving nodes Routing), which is able to bypass misbehaving nodes and select a good path to route packets. BMR algorithm is based on DSR, and includes two phases: the testing phase and the delivery phase. In the testing phase, packets are transmitted to the intended destination node on each available route, and end-to-end performance is measured on each path. Routes with low packet loss rate and small delivery delay are regarded as good path. Routes are evaluated according to the ascending order of their length until a good path is found or all paths have been tested. In the delivery phase, the sender node chooses a good path or the path with the highest metric for data delivery. By making routing decision according to end-to-end performance, BMR provides an efficient solution to address the problems caused by misbehaving nodes. However, BMR can only work under the assumption that misbehaving nodes behave consistently during the test phase and the delivery phase, because no end-to-end performance will be measured during the delivery phase. Another problem is that BMR only works well under lightly-loaded networks. Otherwise, good path and bad path may not be distinguished due to network congestion. Node mobility also gives a challenge to BMR. Furthermore, the test phase is time-consuming and a certain number of data packets are required for this purpose. 2.2.2.4 CONFIDANT In CONFIDANT [43, 44], several components (figure 9) are combined together in each node. They interact with each other to detect and isolate misbehaving nodes, and to discipline each node to work cooperatively. In this protocol, a node only concerns with the abnormal behaviors of its neighbors, which means that only the negative reputation values will be considered and propagated. This reputation system is based on negative experience rather than positive impressions.


19

Figure 9. Trust architecture and finite state machine within each node [44]

The monitor in each node is responsible for monitoring behavior of neighbors. If a suspicious event is detected, relevant information will be reported to the reputation system. Incoming alarm messages from other nodes are first delivered to the trust manager. In that component they are checked for trustworthiness according to their originators' credibility, and are processed accordingly. If there is sufficient evidence to show that the node reported in alarm messages is misbehaving, relevant information will be sent to the reputation system. The reputation system is responsible for analyzing and calculating a node's reputation. The reported suspicious events from alarm messages and direct observation are weighted and processed to calculate reputation. The reputation will only be changed if there is sufficient evidence of abnormal behavior (evidence exceeds the predefined threshold that is high enough to distinguish malicious behavior from simple coincidences such as collisions). When the rating becomes intolerable, the report is sent to the path manager, which deletes all routes containing discovered misbehaving nodes from the routing table. At the same time, an alarm message will be sent to all nodes in its friend list. This protocol has a good performance for malicious and selfish node detection because it only concerns with negative experience. However, due to this nature, it is less tolerant to failing nodes. These nodes may be regarded as misbehaving nodes for some inevitable reasons, such as network congestion or shortage of energy. Therefore, the preset threshold is quite important and needs to be considered carefully to prevent such situations. Another problem is that this protocol is vulnerable to low reputation attack. Such attack could be launched by malicious nodes through propagating false low reputation values. Because a well-behaving node’s good performance is not rewarded or maintained, it is easier for a malicious node to launch this attack, especially for a malicious node with high reputation (behaving cooperatively first). And friend relationships used in this solution are also difficult to measure.


20

2.2.2.5 CORE CORE [45] is another reputation-based solution. The authors regard a mobile ad hoc network as a community, in which only ones contributing own resources are entitled to use shared resources. In CORE, three types of reputations are employed. Subjective reputation values are obtained directly from a node's own observation of behavior of its neighbors. Contrary to CONFIDANT, more weight is assigned to past observations to prevent false detection caused by link breaks or collisions. Indirect reputation values are obtained from other nodes, and only positive values are considered to avoid denial of service attack (broadcasting negative ratings for legitimate nodes). Function reputation values are related to certain functions like routing and data forwarding. And global reputations are calculated in terms of subjective reputation and indirect reputation on different functions. In CORE, there are two types of protocol entities, requestors and providers. It works as follows: a requestor asks for service to a provider, if the provider refuses to cooperate or provide service, the CORE scheme of the requestor will react by decreasing the reputation of that provider. And the requestor will be excluded from the network if its non-cooperative behavior persists. Reputation can be updated in two different situations, the request phase and the reply phase. During the request phase, only the subjective reputation value is updated. It means if the provider did not behave cooperatively, a negative rating factor will be assigned to the observation and that node’s reputation value will decrease. If the provider is well-behaving, its reputation does not change. During the second phase, only indirect reputation value is updated. In CORE, the reply message from the destination node contains a list of entities that correctly behaved. As a consequence, these entities' indirect reputation values are positive and their reputation values of course will increase. CORE is tolerant of sporadically bad behavior because it puts more weight on past behavior and good behavior is rewarded by increasing reputation. But CORE is less sensitive to misbehavior than CONFIDANT due to its natures. Reputation increase in the reply phase depends on other nodes’ feedback. However, these reply messages are vulnerable. 2.2.2.6 Pricing-based Solutions Pricing-based solutions [56, 57, 58] are another kind of solutions. These solutions do not try to detect misbehaving nodes to take corresponding measures such as punishment or isolation, but treat packet forwarding as a service that can be priced. Virtual currency is introduced in these mechanisms to stimulate each node to behave cooperatively. In [56], tamper resistant hardware is used to process nuglet (virtual currency). And in [57], a central agent called Credit Clearance Service (CCS) is introduced to process credit (virtual currency) issues. However, these solutions have some problems. First, traffic in mobile ad hoc networks is likely to be unevenly distributed. So it may be difficult for some nodes to earn enough credits to transmit their own packets even if they always behave cooperatively, and there may be the


21

case where some nodes could get sufficient credits easily, even if they do not behave cooperatively sometimes (dropping some packets). Secondly, some solutions require the existence of a central control agent, which is not applicable in a pure ad hoc network. Thirdly, they are relatively difficult to implement due to some security problems, such as nuglet initialization, transition and maintenance. 2.2.2.7 Other Solutions In [46], Dewan and Dasgupta propose a solution also based on reputation, which is similar to BMR. End-to-end performance is measured to evaluate path quality. In [48], the Secure and Objective Reputation-based Incentive (SORI) scheme is proposed to encourage packet forwarding and discipline selfish behavior. In this solution, a node’s reputation is quantified by objective measurements, and reputation values are propagated in a secure way. A punishment scheme is used to penalize selfish nodes. In [75], the REliable and efficient forwarding (REEF) is described. In this solution, each intermediate node decides the next hop to a certain destination according to the available routes and next node’s reputation. ACK packets from the destination are used to update the next node’s reputation.


22

3 A New Reputation-based Secure Forwarding

Solution

In this chapter, a new reputation-based secure forwarding solution is introduced which consists of three components: detection, prevention and reaction. The detection component is responsible for misbehaving node detection, the prevention component is used to bypass misbehaving nodes and discover optimal routes, and the reaction component provides different service qualities based on reputations. Section 3.1 describes the solution motivations and features. Section 3.2 presents some assumptions of this solution. And section 3.3 introduces different parts of the solution briefly.

3.1 Motivations

From the analysis of some proposed solutions for secure data forwarding in chapter 2, we can find that reputation-based solutions are quite suitable for mobile ad hoc networks and have good performances if they are well designed. Due to lack of a clear line of defense, a complete security solution for mobile ad hoc networks should encompass three components: prevention, detection, and reaction [40] (figure 10). The prevention component could deter misbehaving nodes’ attacks by preventing them participating in the network operations, such as routing and packet forwarding. The detection component is responsible for monitoring and detecting misbehaving nodes in the network. And the reaction component takes corresponding actions to punish misbehaving nodes or even exclude them from the network. The prevention component as well as the reaction component is based on reputation information derived from the detection result, therefore, reputation value is the basis of this solution and needs to be considered comprehensively.


23

Figure 10. Solution components

3.1.1 Reputation Requirements

In order to make this kind of schemes more effective and effective, the reputation value should precisely reflect the current state of each node. For example, if a well-behaving node is compromised and begins to behave abnormally, this node should be detected as soon as possible. There are several requirements for reputation-based solutions.

Reputations should be obtained in an efficient way, which means the detection mechanism could be implemented easily.

Reputations can be used to evaluate a node's behavior objectively and correctly.

Sporadically bad behavior or inevitable problems such as collision should be tolerable, but misbehaving nodes should be detected effectively.

Reputation processing and transmission overheads should be limited in an

acceptable scope due to mobile device’s resource constraint.

In an environment without trust relationships in the majority of the nodes, some mechanisms must be performed to guarantee that reputation is propagated in a secure way.

3.1.2 Solution Features

In order to make full advantage of reputation information to handle the problems caused by misbehaving nodes, this reputation-based secure forwarding solution has the following features. First, a node’s reputation is measured and evaluated in a quantitive and objective way. In this solution, both data packets and route control traffic are monitored respectively according to different but specific requirements. Therefore, misbehaving nodes can be detected more


24

effectively. Secondly, fully selfish nodes could also be detected. In this thesis, a fully selfish node means a node that never relays any packets for other nodes, but requires other nodes to transmit its own packets. Malicious nodes refer to those nodes that promise to forward packets but later drop packets. Due to the requirement of the reaction mechanism that a well-behaving node never forwards packets from a node which does not claim its existence, each node must first claim its presence to its neighbors if it wants to communicate with other nodes. Thirdly, the prevention mechanism is completely performed in the route discovery phase. In many proposed solutions, route test or bad route exclusion is operated in the data delivery phase, consequently, some data packets are still transmitted on bad routes. In this solution, before data packets are going to be transmitted, all discovered misbehaving nodes have already been excluded from the available routes. Finally, reputation information is not only used to detect misbehaving nodes, but also could be used to measure path quality. For well-behaving nodes, some other factors influence the network performance. Mobility has a great impact on data forwarding. For a node moving rapidly and continuously in the network, it is more likely that the link between this node and other nodes will be broken. A node's resources such as CPU capability, energy, and memory size also influence its forwarding behavior. Generally nodes with larger buffer size and more energy are more reliable for data forwarding. In this solution, this aspect is also considered. Routes are evaluated according to hop counts as well as their qualities.

3.2 Assumptions

In order to make this solution feasible, there are some assumptions for this solution. Not all nodes in mobile ad hoc networks are well-behaving. In this thesis, the

primary concern of secure data forwarding is to guarantee that a packet could reach its destination correctly. We only consider packet dropping problem, because other security problems such as confidentiality could be implemented by upper layers. Here, misbehaving nodes are divided into two types: malicious nodes and selfish nodes. Malicious nodes refer to nodes that forward route request/reply packets, but later drop data packets. Selfish nodes want to save power and prolong battery lifetime for their own communications. Therefore, they refuse to provide forwarding services to other nodes. It means it may drop route control packets to exclude itself from discovered routes.

Different mobile devices may use different wireless technologies. In order to enable

communication and monitoring in mobile ad hoc networks, we suppose that all nodes have the same physical layer.


25

Bidirectional communication on each link is required in this solution. Bidirectional communication means if node A is able to receive a message from node B, node B is also able to receive a message from node A at the same time. This assumption is possible since many wireless MAC layer protocols, including MACA [62], MACAW [63], IEEE802.11 [4], Bluetooth [5] and Zigbee [6], require bidirectional communication for reliable transmission, for example, RTS / CTS packets exchange needs bidirectional communication, and link layer acknowledgement also needs it. Bidirectional links are also assumed in many routing algorithms designed for mobile ad hoc networks. However, many algorithms are incapable of functioning properly over unidirectional links, such as AODV and SRP.

Each node in mobile ad hoc networks supports promiscuous mode, which is

necessary for the detection part in this solution. Promiscuous mode means that if node A is in the radio transmission coverage of node B, A can overhear packets from B even if the packets are not directly related to A. So a node can listen to every packet sent by its neighbors to realize monitoring operation. This assumption also could be possible, because most current network hardware has the ability to operate the network interface in “promiscuous” mode. This mode enables hardware to deliver every received packet to the network driver software without filtering based on link-layer destination address.

A security association (SA) exists between each pair of endpoints of a path. How to

initialize or distribute keys and how to create specific purpose keys such as session keys, authentication keys or encryption keys is beyond the scope of this report. A security association is primarily used to protect routing and reputation information by including a Message Authentication Code (MAC) in each route control packet.

3.3 Solution Overview

This section provides an overview of this reputation-based solution which consists of three parts: detection, prevention and reaction.

3.3.1 Detection

The objective of the detection mechanism is to discover misbehaving nodes in mobile ad hoc networks. This is realized by neighbor monitoring and reputation propagation. The detailed description and analysis can be found in chapter 4. Dynamic network topology and lack of central management agent cause that the monitoring operation can only be performed in a local scope by each available node in mobile ad hoc networks. Each node is responsible for monitoring its neighbors’ behaviors in order to detect misbehaving nodes. Routing control traffic and data packets are monitored according to


26

different requirements. Obtained reputations based on a node’s own observation are called local reputations. In order to share its experience with other nodes to make reputation evaluation more objective and precise, each node broadcasts its local reputation reports. But due to the fact that no trust relationships exist among the majority of nodes, the reputation propagation is also limited to a local scope. This means reputation reports are only broadcasted to immediate neighbors. Global reputations are calculated based on one’s own observation and reputation reports from other nodes. The credibility of a report is evaluated in terms of the performance of its originator.

3.3.2 Prevention

The prevention mechanism could realize two functions: bypassing misbehaving nodes and choosing optimal routes. The first one is used to exclude misbehaving nodes from discovered routes, and the second one is used to select routes according to hop counts as well as path qualities. This scheme is based on the detection result at each node in the network, and is performed in the route discovery phase. In chapter 5, the prevention mechanism will be introduced in detail. DSR is employed to perform the basic routing operations, but some extensions are performed on DSR. Misbehaving nodes are bypassed in such a way that each node guarantees that the next node on the route is not a misbehaving node based on its reputation information. Some techniques are used to make this operation be executed in a secure way. Reputation values of all intermediate nodes of any discovered routes are available at sender nodes. So a sender node is able to evaluate all discovered routes according to both hop counts and path qualities.

3.3.3 Reaction

The reaction mechanism is relatively simple in this solution and is not the primary part of the report. But in order to make the solution complete and operational, this part is also necessary. It is responsible for punishing misbehaving nodes by providing different forwarding service qualities according to reputations. In this section, this component is described briefly. 3.3.3.1 Reasons for Reaction Mechanism This mechanism is a necessary part of a complete solution due to several reasons. First, if only the prevention technique is employed, it does increase each well-behaving node’s throughput and reduce packet delivery delay. However, all misbehaving nodes also enjoy these benefits as well, and all these benefits are achieved at the cost of more workloads on well-behaving nodes. From the simulation results in chapter 6, it is obvious that well-behaving nodes’ forwarding burdens increase significantly with the increase of misbehaving nodes in the network.


27

Secondly, the prevention mechanism can not handle fully selfish nodes, because this kind of nodes has already excluded from the discovered routes by themselves. The only useful mechanism for selfish nodes is to force them to behave cooperatively. In price-based mechanisms mentioned in the previous chapter, virtual money is used to stimulate selfish nodes to behave cooperatively. In this solution, necessary punishment and disciplinary measures are taken for the same purpose. 3.3.3.2 Reaction Requirements of this Solution In order to discipline misbehaving nodes and stimulate their cooperation, there are some indispensable reaction operations in this solution.

A node only provides forwarding service to its neighbors that claim their existences. As a consequence, a node must claim its existence in order to ask other nodes to forward its own packets. If a node declares its presence, its behavior will be monitored by its neighbors. Without this requirement, a selfish node can always keep silence for all route request packets to prevent itself being included in any routes.

Each well-behaving node should refuse to provide forwarding service to

misbehaving neighbors. But this requirement is difficult to realize. For example, if node A detects that its neighbor B is a misbehaving node, and begins to drop packets originated from B. But it is quite possible that in a mobile ad hoc network B will move outside of the radio transmission coverage of node A later. If A still drops packets from B, other nodes may think that A is a misbehaving node. If A forwards B’s packets, the misbehaving nodes can not be punished effectively. It is one of the difficulties of the solution. If B returns to A’s radio coverage after some interval, A’s action to B depends on whether B’s record is still in A’s neighbor table. If B’s record is still valid, A will keep on dropping B’s packets. Otherwise, A will assign an initial reputation value to B and begin to monitor B’s behavior.

3.3.3.3 Other Possible Implementations Several proposed reaction operations could be employed.

If a misbehaving node is detected, the relevant report will be sent to those sender nodes that transmit packets over the routes containing this misbehaving node. The sender nodes can delete these routes from their routing tables. This is one of the general reaction operations used in many solutions. But security is a big problem for this operation. A sender node has no idea about whether to trust this kind of reports if there are no trust relationships between them.

A node punishes misbehaving nodes according to their behaviors [48]. More severe

a node behaves uncooperatively, more percentage of its packets are dropped.


28

Priority-based mechanism for packet forwarding [75] (figure 11). The key idea of this solution is to differentiate the quality of service to other nodes according to the way they behave with others. Packets from reliable neighbors (high reputation) are forwarded with higher priority than packets from neighbors with lower reliability (low reputation).

Figure 11. Priority-based mechanism for packet forwarding [75]


29

4 Dynamic Misbehaving Node Detection

In this chapter, the detection component of this reputation-based solution is introduced in detail. Section 4.1 describes neighbor sensing, which is the precondition of local monitoring. Section 4.2 gives the rules for packet forwarding monitoring based on packet type. And section 4.3 introduces the detailed description of detection mechanism that consists of neighbor sensing, local monitoring, local reputation calculation, local reputation propagation and global reputation calculation.

4.1 Neighbor Sensing

Neighbor sensing is used to detect immediate neighbors of a node, and is the precondition of neighbor behavior monitoring and reputation calculation. There are several reasons for neighbor sensing.

1. Due to lack of a central management agent, only fully distributed monitoring and management techniques can be employed in mobile ad hoc networks. Therefore each node should be responsible for monitoring its neighboring nodes in order to detect any abnormal behaviors. To perform this kind of operations, a node must know exactly which nodes are its immediate neighbors to be able to monitor their behaviors. For example, in this solution, when a node broadcasts a route request packet, it needs to monitor all its well-behaving neighbors to check whether or not these nodes relay the packet.

2. In the reaction part of this solution, a node is only permitted to punish its immediate

misbehaving neighbors. As a consequence, the node must keep track of its neighboring nodes to know which nodes it has right to punish if they do not behave cooperatively. The reason why a node can only punish its neighboring nodes is because we want to limit the punishment measures to a local scope to avoid the situation in which malicious nodes broadcast false information to disrupt the network, and to prevent the problem mentioned in 3.3.3.2.

3. In order to prevent selfish nodes keeping silent (dropping all packets) to save energy,

in the reaction mechanism, a node only provides packet forwarding service to its current neighbors that claim their existences. It means that if a node wants its neighbors to forward its own packets, it has to first claim its existence to its neighbors. As a consequence, each node in the network can be detected and monitored by other


30

nodes. Otherwise, a selfish node could always require other nodes to relay its packets, but never forwards any route request packets (for DSR), so it will never be included in any discovered routes. This node does not need to relay any data packets and will never be detected by its neighboring nodes. We should avoid such situations.

4.2 Neighbor Monitoring Rules

The characteristics of mobile ad hoc networks, such as infrastructure-independence, dynamic network topology, lack of central management agent and trust relationship, determine that monitoring can only be performed in a fully distributed way. Each node should be responsible for monitoring its neighbors’ behaviors in order to detect misbehaving nodes. This kind of monitoring mechanisms has been employed in many research projects [40, 43] and is quite suitable for mobile ad hoc networks due to its specific and unique characteristics. But most of them do not give very detailed description on how to perform monitoring operations and how to process detected data. In this solution, we give the detailed description about these issues. In this section, neighbor monitoring rules are first introduced which are directly related to packet type.

4.2.1 Packet Forwarding Monitoring

Each node independently performs the monitoring operation within its ratio transmission range. In theory, a variety of neighbors’ behaviors can be monitored and corresponding detected data can be maintained and processed to discover misbehaving nodes. However, to make the neighbor monitoring mechanism effective and suitable for mobile ad hoc networks, the monitoring mechanism should be based on the frequent and primary behaviors of mobile nodes. For mobile ad hoc networks, its unique characteristic is that each node is responsible for forwarding packets for other nodes. And for secure data forwarding in mobile ad hoc networks, the most important requirement is to ensure that every data packet can reach its destination, which means that each intermediate node must behave cooperatively to forward packets to the next correct node. Only when the requirement that packets can reach destinations is realized, other secure requirements such as data integrity and confidentiality will be useful and make sense. Therefore, the packet forwarding behavior is the most important behavior in mobile ad hoc network, and should be monitored primarily. And it is also the only thing that can be used to detect selfish nodes in mobile ad hoc networks. And also due to limited available resources of each mobile device, such as memory, energy, in order to decrease the corresponding computation and transmission overhead caused by monitoring operation, other behaviors are not considered in this solution currently. There are two basic types of packets transmitted in mobile ad hoc networks. The first one is


31

route control packet which is used to deliver routing information and enable nodes to discover routes to other nodes. The second one is ordinary data packet which is exchanged in the network for data communication purpose. To effectively monitor neighbors to detect if they behave cooperatively, each node should monitor these two kinds of packets respectively based on different rules.

4.2.2 Data Packet Forwarding Rules

It is doubtless that the majority of packets transmitted in the network are data packets, so data packet forwarding behavior should be primarily monitored. To detect whether a neighbor behaves cooperatively to forward data packets, a node should perform the monitoring operation according to the following rules (table 3).

The next intermediate node on the path should forward the packet. Rule 1 If node A transmits a packet to node B (B is not the destination node) for forwarding, B should forward this packet within the predefined interval. Otherwise, its behavior should be regarded as misbehavior. Each intermediate node’s cooperative forwarding operation is the guarantee that the packet can reach the final destination. Node A can take advantage of promiscuous mode to overhear B’s transmissions to detect if B forwards the packet. The next intermediate node should transmit the packet to the correct further next hop.

Rule 2

Rule 1 is not enough to promise that the packet can reach its destination, because it is possible for a potential malicious node to launch a DoS attack by forwarding the data packet to a wrong node. Consequently, the packet may be dropped due to the next node does not have a route to that destination (more likely for reactive routing protocols), or the packet may reach the destination but with a large delay due to not the optimal route is used (proactive routing protocols) for packet delivery, and both consequences are not acceptable. Therefore, node A should also make sure that node B has forwarded the packet to the correct next hop. The content of the packet is not modified. Rule 3 Node A could check the packet relayed by node B to identify whether it is modified for the purpose of data integrity. But this requirement is not obligatory due to data integrity is not the primary goal of this solution. Furthermore, it can be realized using other security techniques at IP or higher layers, such as IPsec. Additionally, this operation will result in much heavy overhead at each intermediate node due to a large number of data packets are required to be processed. Therefore, in this solution, this requirement is not considered currently.

Table 3. Data packet forwarding rules


32

To meet the second requirement, node A must know exactly the next two hops of the route on which this packet should be delivered, and then it is able to detect whether its neighbor B relays the packet cooperatively to the correct next node. Most of the routing protocols designed for mobile ad hoc networks do not meet this requirement, because each intermediate node only keeps the next hop of the route to a certain destination. Therefore, it is impossible to monitor data packet forwarding behavior effectively if the monitoring mechanism is based on such routing protocols. Fortunately, DSR protocol meets this specific requirement. Because DSR enables a sender node to put the whole route in each data packet and then all intermediate nodes are able to know the path on which this packet should be delivered. So based on DSR, each node is able to monitor its neighbors according to the first two requirements mentioned above.

4.2.3 Route Packet Forwarding Rules

4.2.3.1 Introduction When DSR is chosen as the routing protocol in this solution, node’s route packet forwarding behavior in the route discovery phase should also be monitored. The route packets (route request packets and route reply packets) are much less compared with data packets, but they are more important for secure data forwarding in mobile ad hoc networks. First route packets provide routing information to enable a sender node to discover the expected routes to other nodes. If an intermediate node is misbehaving, the packets delivered on this route are more likely to be lost or damaged. Secondly, it can be used to detect fully selfish nodes in the network. There are two basic types of route packets in DSR routing protocol: route request packet and route reply packet. Route request packets are sent by sender nodes and then broadcasted in the whole network to reach specified destination nodes. And route reply packets are sent by corresponding destination nodes in order to deliver routing information about discovered routes to sender nodes. Because a route request packet is broadcasted in the whole network, there is no need for a node to know the next two hops in order to make sure that the packet is delivered correctly. The only thing a node needs to monitor for route request packets is whether its neighbors rebroadcast the packet. A route reply packet generally is transmitted to the sender node along a predefined route. Therefore, both requirements for data packet forwarding should be considered. The analysis above is for standard DSR routing protocol, where no security requirements are considered. But in this solution, the prevention technique (route discovery) is also based on DSR and has its own requirements. It could be used to bypass misbehaving nodes and enable a sender node to discover the optimal route to a specific destination according to both hop


33

count and path quality, and some security measures are also included. Therefore, DSR protocol is modified. More information is included in route request/reply packets, and more operations are required at each node. The detailed description about the prevention mechanism can be found in the next chapter. The following two sections describe the rules for evaluation of forwarding behavior related to route request/reply packets. 4.2.3.2 Route Request Packet Forwarding Rules During the route discovery phase, after broadcasting a route request packet, the node is responsible for monitoring its neighbors’ packet forwarding behaviors to check whether they behave cooperatively according to the following rules (table 4).

Each well-behaving neighbor should forward route request packets if it is not the destination node.

Rule 1

Because the route request packet is broadcasted in the whole network, the node does not need to know the next two hops to check whether its neighbors relay the packet cooperatively. Each well-behaving neighbor (except the destination node) is required to rebroadcast the request packet. It is possible that a potential misbehaving neighbor modifies the original content in the route request packet. This can be detected by checking the request packet relayed by each neighbor or the corresponding reply packet when it comes back. In this solution, the content check is performed on route reply packets, because route reply packets must be checked to guarantee the correctness of contained information, and reply packets are much less than request packets. All discovered misbehaving neighbors are not allowed to forward route request packets.

Rule 2

It seems unpractical to require misbehaving nodes to behave cooperatively. However, it could be possible in this solution. First, the request packet from a misbehaving node will be dropped (rule 3). Secondly, all route reply packets from misbehaving neighbors will be dropped. Therefore, a misbehaving node will get nothing even if it uses its resource to forward request packets illegally. Route request packets from misbehaving neighbors are dropped. Rule 3 A misbehaving node may relay a route request illegally, so it is necessary for a node to perform operation in terms of this rule to exclude it as soon as possible. It also could be regarded as a punishment in reaction mechanism. Because it is possible that a misbehaving node initiates a route request packet to find routes to another node, if it is detected by its neighbors, all these neighbors should not forward this packet to exclude this node from the network.

Table 4. Route request packet forwarding rules

4.2.3.3 Route Reply Packet Forwarding Rules


34

Route reply packets are used to deliver discovered routes to sender nodes. In this solution, a route reply packet must be transmitted to the sender node along the reverse route contained in the corresponding route request packet, which is as same as the requirement of SRP. The reason for this requirement is due to some security considerations.

1. To guarantee that misbehaving nodes are really excluded form the route. 2. To guarantee that no false routing or reputation information is in the route reply

packet.

Each node on the route should monitor behaviors of its neighbors according to the following rules (table 5).

Packet forwarding monitoring The next intermediate node on the path should forward the packet. Rule 1 The next intermediate node should transmit the packet to the correct next hop.

Rule 2

The content of the packet is not modified by the next node. Rule 3 It is necessary and feasible for route reply packets. First, reply packets are more important than data packets. Secondly, reply packets are much less than data packets, so this operation will not cause much overhead.

Other security related monitoring Route reply packets from misbehaving neighbors are dropped. Rule 4 Normally a route reply packet should not be from a misbehaving neighbor, because all misbehaving neighbors are not allowed to forward route request packets. But it may happen because 1. A misbehaving node relays that request packet illegally and the next

node does not drop the packet due to some reasons (it is also a misbehaving node or it has not detected this misbehaving node).

2. A malicious neighbor sends the manipulated reply packet. This rule is necessary to promise that any routes containing misbehaving nodes are discarded. Routing and reputation information in the packet are correct. Rule 5 When a node receives a route reply packet, it should check whether the routing and reputation information in this packet are correct by comparing with the information in the corresponding route request packet maintained in its cache. If it is not the case, it means the next node towards the reply packet sender does not behave cooperatively. The detailed description will be given in the next chapter.

Table 5. Route reply packet forwarding rules


35

4.3 Detection Mechanism Description

This section describes the detection mechanism in detail, which contains neighbor sensing, local monitoring, local reputation calculation, local reputation propagation and global reputation calculation.

4.3.1 Neighbor Sensing Implementation

To discover its neighbors, each node needs to broadcast periodically control messages, which contain the information about its neighbors and their links states in order to detect bidirectional links. These control messages are transmitted to all of its immediate neighbors. For example, there is a control message named "hello" message in AODV, which can be employed to advertise a node's existence and offer connectivity information. This message is broadcasted by each node at short intervals, so all nodes in the network can take advantage of this message to discover neighboring nodes. This technique can also be used in this solution to enable a node to find its neighboring nodes. But in order to simplify the operation, one of the assumptions mentioned before is that all links in the network are bidirectional. Therefore, a node does not need to put all its neighboring nodes and corresponding link information in the control messages, instead, a simple message for the only purpose of presenting its own existence is enough This can decrease the overhead caused by this kind of message broadcast. Hello messages are broadcasted with TTL = 1, which means they are only broadcasted to one’s one-hop neighbors, and must never be forwarded. Soft states can be used to detect whether a neighbor still exists. If a neighbor moves outside a node's radio transmission range, this node will not receive Hello messages from that neighbor anymore, and then it can update its neighbor table. Concretely, a node determines connectivity by listening for packets from its neighbors (figure 12). If within the past interval (DELETE_PERIOD), it has received a Hello message from a neighbor, and then it has not received any packets from that neighbor (Hello message or other packets) for more than ALLOWED_HELLO_LOSS * HELLO_INTERVAL, the node should assume that the link to that neighbor has been lost, but the record about that neighbor is still kept. If the node receives a Hello message from that neighbor within DELETE_PERIOD, which is larger than ALLOWED_HELLO_LOSS * HELLO_INTERVAL, the node should assume that the link to that neighbor becomes available again. Otherwise, the node will not regard that node as its neighbor, and all information related to that node will be removed from its neighbor table.


36

Figure 12. Neighbor sensing implementation The description above is for well-behaving neighbors, and is not suitable for misbehaving nodes. Otherwise, a misbehaving node can always move away for more than DELETE_PERIOD, and it will not be regarded as misbehaving node when it comes back. Therefore, a misbehaving node’s record should be kept in the neighbor table for much longer time than DELETE_PERIOD.

4.3.2 Neighbor Table

Each node has a neighbor table (table 6), which is used to keep detected data and reputation information about all its neighbors. Because in this solution, packet forwarding behaviors are primarily monitored and used for reputation calculation, relevant information should be kept in this table. The prevention and reaction techniques are also operated based on the reputation information in this table.

Field Description Neighbor ID It represents a neighbor’s identity. Each node in the network has a

specific identity and this identity must not be changed. This is a basic requirement for this solution.

Request to

Forward

The number of packets this node has sent to a specific neighbor (node N) for forwarding in a period of time. The packets include data packets and


37

(RtF) route request/reply packets. Relayed by

Neighbor

(RbN)

It represents the number of packets that have been relayed cooperatively by node N in a period of time. The rules for cooperative packet forwarding behavior evaluation are based on packet type.

Total request to

Forward

(TRtF)

The number of all packets the node has sent to node N for forwarding.

Local Reputation

(Packet Forward

Ratio)

Neighbor N’s local reputation. Local reputation is calculated based on this node’s own observation of packet forwarding behaviors of node N.

Global

Reputation Neighbor N’s global reputation. Global reputation is calculated based on this node’s own observation together with reputation reports from its neighbors.

Creation Time It shows the time when node N became its neighbor. Every time when this node receives the Hello message from node N, this field should be updated.

Status It shows the current status of node N. If the link to node N becomes broken, the value of Status in the corresponding entry will be set to false, which means this entry is invalid currently and node N is not regarded as neighbor temporarily. But this entry will still be kept in the table for some time in order to make use of reputation information more efficiently. If before DELETE_PERIOD, the link becomes available again, the Status value will be set to true. Otherwise, after DELETE_PERIOD, the entry will be removed from the table, and node N is not regarded as its neighbor any more.

Table 6. Neighbor table When a new neighbor is detected by means of Hello message propagation, a new entry will be appended to neighbor table. The value of Creation Time in this entry is set to the current time, and the value of Status is set to true. This new neighbor will be monitored and relevant detected data will be recorded and processed.

4.3.3 Neighbor Monitoring and Local Reputation Calculation

The goal of neighboring monitoring and local reputation calculation is to detect misbehaving nodes. Therefore, well-behaving nodes (including potential misbehaving nodes) are primarily monitored and their behaviors are recorded and analyzed according to the predefined rules. And discovered misbehaving nodes are also monitored, and their behaviors determine when they will be included in the network again. But well-behaving nodes and misbehaving nodes are monitored and treated in different ways. 4.3.3.1 Well-behaving Nodes Monitoring and Processing


38

4.3.3.1.1 Evaluation Criteria for Well-behaving Nodes Local reputations are calculated based on a node’s packet forwarding ratio, which means if node A sends a packet to node B (B is an intermediate neighbor of A), what is the probability that the packet will be forwarded cooperatively by B and reach the next node. Packet forwarding ratio (PFR) is the criterion in this solution to evaluate a node’s local reputation and is quite suitable for secure data forwarding evaluation. Because the most important requirement of secure data forwarding is to make sure that each intermediate node behaves cooperatively to forward the packet and then the packet can reach the destination along the correct route. 4.3.3.1.2 Monitoring Implementation The promiscuous mode enables each node to monitor its neighbors’ behaviors by overhearing their transmissions. Promiscuous mode means if node A is in the transmit coverage of node B, A can overhear packets from B even if those packets are not directly related to A. So a node can listen to every packet sent by its neighboring nodes, and through which its neighbors’ behaviors can be monitored. Each node in the network has a neighbor table mentioned in 4.1.3 which contains relevant information about its entire neighbors. And each node calculates its neighbors’ local reputations according to its own observation. In order to keep track of the data packet forwarding behaviors of its neighboring nodes, two basic numbers are maintained and updated for each neighbor.

RtF (request to forward) The number of packets this node has sent to a neighbor (node N) for forwarding in a period of time.

RbN (relayed by neighbor) This number is used to show how many packets have relayed cooperatively by Node N in a period of time.

The packet forwarding ratio (PFR) can be expressed based on these two numbers. The packet forwarding ratio is calculated and updated in the following way. In a new period of time, the two numbers are initialized to 0. And when node A sends a packet to node B and requires B to forward this packet, it increases the value of RtFA(B) by one. And A keeps this packet in its cache, and starts to listen to the wireless channel and check whether node B forwards the packet as expected. After A detects that B relays this packet cooperatively, it increases RbNA(B) by one. Given these two numbers, node A can create a packet forwarding ratio for its neighbor B in this period of time.

)()()(

BRtFBRbNBPFR

A

AA = (1)


39

Due to different packet forwarding requirements for data packets and route packets, the criteria for judging whether a neighbor behaves cooperatively are different. The detailed operation is shown in table 7.

Data packets Node B’s forwarding behavior complies with both two rules (relay, correct next hop) for data packet forwarding.

Increases RbNA(B) by one

Route request packets Node B’s forwarding behavior complies with the first rule (relay) for route request packet forwarding.


Route reply packets If node B is the next node towards the route discovery originator, B’s behavior complies with the first three rules (relay, correct next hop, data integrity) for route reply packet forwarding.


Information is correct

No change If B is the next node towards the route discovery target, node A needs to check whether the local reputation information accumulated in the route reply packet is correct. However, this is not directly related to packet forwarding ratio. Therefore, B’s global reputation value rather than local reputation will be decreased.

Information is modified

Decreased global reputation RA(B) by ε

Table 7. Neighbor monitoring There are some issues need to be considered for local reputation calculation. First, the number of packets monitored should be considered in the calculation, because more packets delivered and monitored, more precise the calculation result will be. Next, not only the newest detected data is used for local reputation calculation, the historical record is also needed to be considered. But in order to make the calculated reputation present a node’s current status more precisely, more weight should be assigned to the newest data. Therefore, each new local reputation value consists of two parts: the packet forwarding ratio in this period and the old local reputation value. Node A calculates a neighbor’s local reputation in terms of its own observation, and uses the following formulary

M

BPFRBTRtFBRtFMBLR

BTRtFBRtFBTRtF

BLRA

A

AA

A

AA

A +

+−

=1

)()()()('

)()()(

)( (2)


40

PFRA(B) is the new calculated packer forwarding ratio in the latest period, TRtFA(B) represents the total number of packets sent to B for forwarding which also can be obtained from its neighbor table. Whenever A sends a packet to B for forwarding, A will increase TRtFA(B) as well as RtFA(B) by one. Packet number is used as weight, but in order to increase the newest PFR’s weight, M’s value should be larger than 1.

Figure 13. Local reputation and packet forwarding ratio

Figure 13 shows the relationship between packet forwarding ratio and local reputation. In each period of time, every neighbor’s packet forwarding ratio is calculated, and new local reputation is calculated based on old local reputation and current packet forwarding ratio. 4.3.3.1.3 Other Issues The method mentioned above can be used to monitor a node’s behavior effectively. But there are some issues need to be considered to make the approach work well. First, if in a period of time the value of RtFA(B) is quite small, it is possible that the obtained packet forwarding ratio is not correct. For example, in a certain period, node A only sends two packets to node B for forwarding, but one of the packets is lost or B’s cooperative behavior has not

been detected by A due to collision. If )()()(

BRtFBRbNBPFR

A

AA = is simply used to calculate node

B’s new packer forwarding ratio, it is obvious that the obtained value does not reflect B’s actual behavior. Therefore, a threshold must be set for minimum value of RtFA(B). When RtFA(B) is larger than this threshold, node A uses the formula to calculate the current packet forwarding ratio of node B. Otherwise, the old local reputation is still in use, and the information obtained in this period of time is accumulated until this requirement is met in a future period. But it is not a good choice if we consider the following situation, in which node A has two neighbors B and C. B and C have the same local reputation from A’s point of view. But B’s reputation is a quite old date obtained long time ago due to in recent periods there are not enough packets could be monitored, and C’s reputation is a flesh one. Of course, C’s reputation is more likely to truly reflect its current status. And also because misbehaving nodes exist in the network, the old reputations are more likely to be out of date.


41

Therefore, in this solution, when in a certain period of time, there are not enough packets available for monitoring a neighbor’s packet forwarding behavior, the current packet forwarding ratio is set to the threshold which is used to distinguish misbehaving nodes. Because for a well-behaving node, this threshold is always lower than its current local reputation value. If this situation lasts for a long period of time, its local reputation will decrease gradually to reach the threshold. Figure 14 shows the change of the local reputation in such situation.

Figure 14. Gradual decrease of local reputation

If a new neighbor is discovered, because no data is available to calculate its local reputation, its current local reputation is also set to the threshold value. 4.3.3.2 Misbehaving Nodes Monitoring and Processing Misbehaving nodes are monitored and handled in a different way. Because when the prevention technique is in use, all discovered misbehaving nodes should be bypassed during the route discovery phase. Therefore, no data packet will pass through these misbehaving nodes. The monitoring mechanism is only based on their route packet forwarding behaviors. 4.3.3.2.1 Misbehaving Nodes Monitoring During the route discovery phase, misbehaving nodes should not be included in the discovered routes. Several rules are defined to meet this requirement, which have been mentioned before.

1. All discovered misbehaving neighbors are not allowed to relay route request packets. If a misbehaving neighbor does not confirm with this rule, its global reputation will be decreased by ε.

2. All request packets from misbehaving neighbors should be dropped. But due to nature of ad hoc network, it is possible that different nodes have different views to a certain node. For example, node A may regard node B as a well-behaving node, while node C regards node B as misbehaving node. So if C receives a route request


42

packet from B, it only drops the packet, but should not decrease B’s reputation. 3. All route reply packets from misbehaving neighbors should be dropped. If a node

receives a route reply packet from a misbehaving neighbor, that neighbor’s global reputation will be decreased by ε.

4.3.3.2.2 Misbehaving Nodes Recovery Due to the fact that the discovered misbehaving nodes will be excluded from the network by their neighbors, data packets will not pass through these misbehaving nodes. Therefore, these nodes are not able to increase their reputation even if they want to behave cooperatively. Another possible situation is a well-behaving node may be regarded as misbehaving node due to some other problems such as collision. We need some methods to recover their reputations. In order to give misbehaving nodes opportunities to be included in the network again, their local reputations should be increased gradually to reach the threshold if they behave cooperatively in this period of time.

))(1()(')( βαα +−+= ThresholdBLRBLR AA (3)

The formula can be used to recover a misbehaving node’s local reputation gradually. The time required for a misbehaving node being accepted by its neighbors depends on the following factors. 1. Its current local reputation. 2. Its behavior in the route discovery phase. 3. The value of α and β. These two values could be changed according to the concrete

situation. Therefore, if a detected misbehaving node still behaves uncooperatively, it will never be accepted by other nodes.

4.3.4 Weaknesses of Neighbor Monitoring

This monitoring mechanism is based on packet forwarding behavior. And it can be used to detect misbehaving nodes effectively according to the rules and operations mentioned above, but there are some weaknesses due to its characteristics. In the watchdog and pathrater solution [41], the authors describe the following weaknesses.

Ambiguous collisions Receiver collisions Limited transmission power False misbehavior Collusion Partial dropping


43

Figure 15. Ambiguous collision

The ambiguous collision problem could happen if collision occurs at node B when it is listening for C to forward a packet. And B can not distinguish whether this collision is due to C’s relay behavior.

Figure 16. Receiver collision

The Receiver collisions problem is that node A can only promise that node B forwards the packet to node C, but it can not promise that C receives this packet due to possible collision at C.

Figure 17. Limited transmission power

A misbehaving node C can control its transmission power such that the next node D may be outside of its radio transmission range, but the packet still can be overheard by node B. False misbehavior means that a node transmits false reputation information. In this solution, the global reputation will be influenced by this problem. It is difficult to handle false misbehavior especially for that from a node with perfect credibility. Some mechanisms are proposed in 4.3.6 for addressing this problem. Partial dropping means a misbehaving node drops packets at a lower rate than the predefined threshold. A node is able to save some resource if it does partial dropping, but at least this node can provide an acceptable forwarding service quality which is directly related to threshold. The optimal route selection mentioned in the next chapter is designed for this purpose. The first two problems can be addressed if data link layer can provide some mechanisms to mitigate collision, such as CSMA/CA, RTS/CTS. And only malicious nodes can cause the third problem, but this is beyond the scope of this report. Collusion means multiple nodes in collusion launch a sophisticated attack. For example, B forwards a packet to C, but does not record C’s misbehavior when C drops this packet. This kind of problems can not be detected by this monitoring mechanism.


44

4.3.5 Possible Optimizations

In this solution, all packets are treated in the same way. The advantage of this method is simplicity. But due to some other reasons, processing data packets and route packets independently may make the scheme more effective. First, route packets are more important than ordinary data packets. For example, a selfish node can drop all route request packets, and then it will not be included in any route and no data packet will pass though it. Next, route packets are much less than data packets, so it is possible that route packets is overwhelmed by data packets if they are processed together. Generally, in mobile ad hoc networks, nodes are more likely to be battery powered. Therefore, energy is quite important for each mobile node and all kinds of solutions designed for mobile ad hoc networks should not neglect this issue. Monitoring all packet forwarding behaviors of neighboring nodes could give a heavy burden to a mobile node. Therefore, some additional modifications could be employed to reduce such workload. Node in a mobile ad hoc network can adjust its monitoring operations according to the quality of the network. If the condition of the network is ideal, which means very few misbehaving nodes are detected in the network, a node can monitor its neighbors at a low frequency. For example, if ten packets are sent to a neighbor for forwarding, the node can only monitor one of these packets to check whether its neighbor behaves cooperatively. The percentage of the monitored packets can be changed dynamically in terms of the node’s own observation. A node can also monitor its neighbors according to their current reputation values. More attention should be paid to well-behaving neighbors with relatively low reputations, because these nodes are more likely to be potential misbehaving nodes. For example, for the neighbor with a reputation value that is just above the threshold, each packet transmitted to that node needs to be monitored. While less efforts may be required for those ones with high and stable reputation values.

4.3.6 Local Reputation Propagation and Global Reputation

Calculation

In this section, the concept of global reputation is introduced. The global reputation is calculated based on a node’s own observation (local reputations in its neighbor table) and reputation reports from its neighbors in order to make the detection mechanism more effective. 4.3.6.1 Local Reputation Propagation Using neighbor monitoring mechanism, a node can evaluate its neighbors’ local reputations directly according to its own observation. But sometimes only base on its own detection, a node may not give its neighbor a correct estimation, especially when a misbehaving node behaves inconsistently.


45

Figure 18. A network topology For example (figure 18), when we consider the partial dropping problem mentioned before, a malicious node M could behave cooperatively to relay the packets from some neighbors such as B, but drops the packets from other neighbors A and C. In such a situation, from B’s point of view, M is a well-behaving node if it makes a judgment only according to its own observation. But node A and C of course regard M as misbehaving node. Therefore, in order to detect misbehaving nodes more effectively, neighboring nodes could exchange their local reputation information with each other. Using reputation reports from other nodes also can prevent a node making wrong evaluation. The reason why a neighbor’s local reputation is lower than the threshold could be because of some other problems such as collision. If a node can make use of reputation reports from other nodes, it may get a more correct reputation evaluation for its neighbors. Therefore, in order to make reputation calculation more accurate and misbehaving node detection more effectively, reputation reports are exchanged among nodes in the network. But in mobile ad hoc networks, it is likely that no security associations exist among the majority of the nodes, so it is difficult for a node to evaluate the credibility of a received reputation report. And misbehaving nodes can modify information in reputation reports or create false reports to disrupt the network. This is the primary problem of reputation propagation in mobile ad hoc networks. In order to make use of reputation reports from other nodes and at the same time avoid new problems, in this solution, reputation propagation is limited to a local scope, which means a node only broadcasts its local reputation information to its intermediate neighboring nodes. And when a node receives the reputation report from a neighbor, it uses this neighbor’s local reputation in its own neighbor table to evaluate the credibility of the report. If the reputation report is from a well-behaving node with high reputation, the node is willing to trust this reputation report. On the contrary, if the report is from a misbehaving node, the report will be dropped.


46

Local reputation reports are broadcasted to neighbors just like Hello message, but the frequency of this message broadcast is much lower. In the neighbor table at each node, only information related to neighbor identity and local reputations is put into reputation reports, and then nodes broadcast such packets to intermediate neighbors. 4.3.6.2 Global Reputation Calculation When a node receives reputation reports from its neighboring nodes, it is able to perform global reputation calculation according to its own local reputations in its neighbor table and reputation information from its neighbors. 4.3.6.2.1 Credibility Evaluation Lack of central management agents and trust relationships among nodes increases the difficulty of evaluating the credibility of a received reputation report. In order to make use of reputation reports from other nodes, two methods can be employed for this purpose. First, local reputation can be used to measure a neighbor’s credibility. The neighbor with high local reputation generally is worthy to be trusted; contrarily, a neighbor with low local reputation is more likely to be a misbehaving node. This rule is applicable in most of the scenarios. But if malicious nodes are considered, situation will become more complicated. For example, a malicious node can behave cooperatively to obtain a high reputation first, and then broadcasts false reputation reports to make other nodes produce incorrect reputation information.

To address such problems caused by misbehaving nodes, another method must be used, which is based on the reputation information in all received reputation reports. It works in the following way. A node first uses all received reputation reports from its neighbors to calculate its own reputation. Because each neighbor’s reputation reports contain this node’s local reputation, if this node is a well-behaving node, the calculated value should reflect the actual situation. And then the node can use this value to evaluate the credibility of each reputation report. For a well-behaving node, it does its best to forward packets for other nodes, but due to some other inevitable reasons, such as congestion and mobility, its local reputation at other nodes may be distinct significantly in different environments. Therefore, all neighbors’ reputation reports should be combined together to calculate its own reputation, because such calculated value is more objective.


47

Figure 19. Credibility evaluation based on all available reputation reports from neighbors

From figure 19, we can see that node A has four neighbors: B, C, D and E. Each neighbor broadcasts its reputation report, so A can receive four reports from B, C, D and E respectively. And in each report, A can find its own local reputation information. For example, LRB(A) means A’s local reputation at node B. Therefore, A can make use of all these local reputation values to calculate its own reputation with the following formula.

∑

∑

=

== n

iiA

n

iNiiA

A

NLR

ALRNLRAR

1

1

)(

)(*)()( (4)

In the formula, Ni represents a neighbor of node A. LRNi(A) represents A’s local reputation at node Ni, and it has a weight of LRA(Ni), which is this neighbor’s local reputation at node A. The weight LRA(Ni) is used to measure the credibility of the reputation report from node Ni. Therefore, the reputation report from a node with higher local reputation will get more weight in the calculation. For the previous example, A’s own reputation is calculated based on reputation reports from all its neighbors B, C, D and E.


48

)()()()()(*)()(*)()(*)()(*)(

)(ELRDLRCLRBLR

ALRELRALRDLRALRCLRALRBLRAR

AAAA

EADACABAA +++

+++=

After node A gets its own reputation, it can make use of this value to evaluate the received reputation reports. It can compare RA(A) with its local reputation value contained in each independent reputation report. For a well-behaving node, its reputation value at all its neighboring nodes should be similar. For example, in this scenario, if all nodes in the picture are well-behaving nodes, then the difference among LRB(A), LRC(A), LRD(A) and LRE(A) should be small. As a consequence, the difference between RA(A) and LRB(A), LRC(A), LRD(A) or LRE(A) should also be small. If the difference for example between RA(A) and LRB(A) is large and pass the acceptable level, B is likely to be a misbehaving node. Therefore, using this method, if a misbehaving node broadcasts false reputation information, it will be detected by its neighbors. More false reputation information in its reputation reports, more neighbors are able to detect it. It makes sense when most of one’s neighbors are well-behaving nodes. In real situation, it should be the case; otherwise, the network is not able to work. But if it is not the case, node A should evaluate its environment according to RA(A). For example, if A is a well-behaving node, but the value of RA(A) is quite low. It means that A’s local environment is hostile, or it becomes a bottleneck so that a large number of packets are dropped due to buffer overflow. Both situations are disadvantageous for node A. In order to prevent misbehaving nodes broadcasting false reputation reports, a node should check the reputation reports using the method mentioned above. And some corresponding reactions are also necessary. To simplify the presentation, the network topology in the picture is still in use. Suppose node A has already calculated and obtained RA(A). Node A sets a margin γ, and takes measures according to the following rules. If the difference between RA(A) and LRNi(A) is larger then γ (Ni is A’s neighbor), node A reduces node Ni’s global reputation by (RA(A) – LRNi(A)) – γ directly. Otherwise, node A does not change node Ni’s global reputation. 4.3.6.2.2 Global Reputation Calculation The primary object of the detection scheme is to enable nodes in mobile ad hoc networks to detect misbehaving nodes. Therefore, an objective and effective global reputation calculation approach is important for the availability of this mechanism. The global reputation can be calculated in a way similar to the one used to calculate a node’s own reputation introduced in 5.2.2.1. But different from that method, now, a node’s own observation (local reputation information in its neighbor table) should be taken into account.


49

And another requirement is that all reputation reports from discovered misbehaving nodes must be dropped.

∑

∑

=

=

+

+= n

iiA

Ni

n

iiAA

A

NLRM

XLRNLRXLRMXR

1

1

)(

)(*)()(*)( (5)

In this formula, node A calculates the global reputation of its neighbor X. LRA(X) is based on its own observation (X’s local reputation in A’s neighbor table), and LRNi(X) is obtained from the reputation report from its neighbor Ni (X’s local reputation in Ni ’s neighbor table). M is the weight of its own observation, and LRA(Ni) is the weight of Ni’s report, which means the credibility of the report. The global reputation consists of two parts: own observation and reputation information from neighbors. M is the weight of the local reputation based on its own observation, and it makes the solution more resistant to malicious node’s false reputation propagation attack. Each node can use some approaches such as those mentioned in 5.3.2.1 to estimate the local environment. In a hostile environment (a large number of misbehaving nodes exist in the network), a node should make M larger to increase the weight of its own observation and then to decrease bad influence caused by false information from misbehaving nodes. In a good environment, a node should decrease M’s value to make the global reputation values more objectively and precisely. The minimum value of M is one, which means the weight of its own data is equal to that of the best neighbor’s data. The reputation reports from neighboring nodes are weighted. Therefore, higher the local reputation value a neighbor has, more weight is assigned to that neighbor’s reports. This is the most important reason why reputation propagation is limited to a local scope. A node can evaluate the credibility of a received report according to its own observation on the report originator’s behavior. In addition, the problems caused by false reputation information from discovered misbehaving neighbors can be avoided. And potentially misbehaving neighbors are also disciplined. If those undetected misbehaving nodes broadcast false reports, they will be in the risk of being discovered due to some of the methods mentioned above. But if we allow the reputation reports to be broadcasted in the whole network, it will increase the overhead significantly. Furthermore, security is a big challenge. A node has no idea about whether a received report is from a misbehaving node due to the fact that there is no trust relationship among the majority of the nodes in mobile ad hoc networks.


50

Figure 20. An example for global reputation calculation As an example, consider the network topology described in figure 20. Node A wants to evaluate node B’s global reputation. A should perform the operation in the following way. 1. Search its own neighbor table to get B’s local reputation LRA(B). 2. Search neighbor C’s reputation report to get B’s local reputation LRC(B). 3. Search neighbor E’s reputation report to get B’s local reputation LRE(B). 4. Use adjustable value M as the weight of LRA(B). 5. Search its neighbor table to get C’s local reputation LRA(C), and use it as the weight of

LRC(B). 6. Search its neighbor table to get E’s local reputation LRA(E), and use it as the weight of

LRE(B). 7. Calculate B’s global reputation.


51

5 Prevention Technique and Optimal Route

Discovery

In this chapter, the prevention technique is specifically described. It could be used to exclude misbehaving nodes from discovered routes and find the most reliable route among all available routes. Section 6.1 introduces the motivation of this technique. Section 6.2 gives the overview of this technique. And section 6.3 gives the detailed description of this scheme.

5.1 Motivation

The prevention mechanism is one of the most useful mechanisms to address problems caused by misbehaving nodes in mobile ad hoc networks. The prevention mechanism in this solution is performed in the route discovery phase, so it must be integrated with a certain routing protocol to perform its operation. Currently, many routing protocols are available for mobile ad hoc networks, such as AODV, DSR, OLSR, and DSDV. Form the analysis before, it is obvious that DSR is the most suitable routing protocol for this prevention mechanism. In the route discovery phase, two objects that bypassing detected misbehaving nodes and choosing the optimal route are realized. Local reputation information is included in DSR route packets for these purposes.

5.1.1 Bypassing Misbehaving Nodes

Its basic idea is that a sender node tries to discover a route to the specific destination, on which no misbehaving node exists. Therefore, the delivered packets can reach destination node at a much higher probability, and this is the main purpose of secure data forwarding considered in this thesis. We first need to promise that data can reach destination and then other security requirements such as data integrity and confidentiality can be taken into account. Bypass misbehaving nodes means that all routes containing misbehaving nodes should not be in one’s routing table. In the chapter 4, some techniques have been introduced to meet this requirement:

1. Misbehaving neighbors are not allowed to forward route request packets. This rule is directed related to one’s global reputation. If a misbehaving node wants to be accepted by other nodes and included in the network again, it must comply with this


52

rule. 2. All route request packets from misbehaving neighbors must be dropped. This rule

can decrease the impact of misbehaving node’s uncooperative operation, which means the false information should be discarded as soon as possible.

3. All route reply packets from misbehaving neighbors must be dropped. This rule is crucial to guarantee that misbehaving nodes are not included in the discovered routes.

5.1.2 Optimal Route Discovery

Local reputations are used to evaluate the quality of each discovered path at the route evaluation stage. There are some reasons for optimal route discovery. Above all, it is impossible to detect all misbehaving nodes in the network. For example, a selfish node may drop packets at a certain probability which is a litter higher than the predefined threshold, so it will be very difficult to detect such selfish node. If we increase the threshold, some well-behaving nodes may be regarded as misbehaving node due to some other reasons such as collision. Furthermore, data loss may happen because of other reasons. For example, if a rapidly moving node is included as an intermediate node, the packets delivered on this route are more likely to be lost because this node frequently moves outside of its neighbor’s radio transmission range. On the contrary, a fixed or rarely moving node is much more reliable for data forwarding. And if a node becomes a bottleneck, the packets passing through this node are more likely to be dropped due to buffer overflow. Additionally, mobile devices with more resources including CPU capability, battery power and memory are more suitable for data forwarding. Therefore, even without regarding misbehaving nodes, different routes could have various performances. How to measure the quality of a discovered path is a big challenge in ad hoc networks. In some of the projects mentioned in chapter 2, end-to-end performance is measured to evaluate path quality. But this kind of methods is time consuming and generally performed at data delivery stage, so some data packets must be used for testing purpose and they are more likely to be lost. In this solution, path quality is measured according to each intermediate node’s local reputation (packet forwarding ratio).

5.1.3 Local Reputation

According to the detection mechanism, one node could obtain local reputation and global reputation information about its neighbors. This prevention mechanism is base on local reputation for several reasons. First, local reputation represents packet forwarding ratio, which means the probability that the


53

packet passes through this node and reach the correct next node successfully. Therefore, each intermediate node’s local reputation can be combined together to calculate the packet delivery ratio of one path. The higher the packet delivery ratio a path has, the more reliable the path is, and better packet forwarding performance can be obtained on this path. Secondly, there is much less overhead caused by local reputation compared with global reputation. Because global reputation calculation also depends on reputation reports from other nodes, exchanging and processing reputation information will result in much transmission and computation overhead. Last, there are some potential security problems for global reputation. Lack of trust relationship is the main reason for these problems, and the corresponding methods mentioned before can not address all problems well. Therefore, in the current prevention mechanism, only local reputation is used. Another problem is that if one

5.2 Overview

This section provides an overview of this DSR-based prevention mechanism, which consists of two stages: route request/reply packet transmission stage and route evaluation stage. Bypassing misbehaving nodes is realized at the first stage. At the second stage, all discovered routes are evaluated and the optimal route is selected in terms of hop count as well as path quality. Route discovery is a scheme by which a sender node S tries to discover a path to a destination node D when S has packets addressed to that destination node but no available route exists in its routing table. Because this prevention mechanism is based on DSR, all basic operations follow the standard of DSR protocol. Bypassing misbehaving nodes is realized in the following way. In the route discovery phase, the sender node broadcasts a route request packet and then the packet floods in the whole network. Each node puts its well-behaving neighbors and their local reputations into the packet, and only the neighbors contained in the packet are authorized to forward this route request packet, which means misbehaving nodes are not allowed to forward the packet. And each node only accepts the route request/reply packets from its well-behaving neighbors. All route request/reply packets from its misbehaving neighbors must be dropped to guarantee that only well-behaving nodes are included in the discovered routes.

Figure 21. Bypassing misbehaving nodes

Given the example in figure 21, for a path between the sender node S and the destination node


54

D, S can promise that the next node A is not a misbehaving node according to its own observation, and A can promise the next node B is not a misbehaving node, because each node on the route is able to promise that the next node is not a misbehaving node. Therefore, all discovered misbehaving nodes can be excluded from the discovered routes. Furthermore, the route reply packets are protected by Message Authentication Code (MAC) calculated with keyed one-way hash function to prevent misbehaving nodes modifying the reply packets. Route evaluation is performed by sender nodes according to the local reputation (packet forwarding ratio) information contained in the route reply packets. Because DSR is able to discover multiple routes to a certain destination, the sender node can make use of local reputations of all intermediate nodes on a path to calculate the quality of this path. In this solution, path quality is measured by packet delivery ratio, which means if the sender node transmits a packet to another node, what is the probability that the packet can reach the destination along the expected route (here, retransmission is not considered). Packet delivery ratio is used to choose the most reliable path and then good performance such as low delay, high throughput can be achieved. To initiate route discovery, the sender node first needs to create a route request packet. Besides the necessary information required by DSR, the sender node checks its neighbor table and puts all its well-behaving neighboring nodes and their local reputation values into the request packet, and broadcasts this packet. The route request packet is received by all nodes currently within its transmission radio range. Here, the sender node is called route discovery initiator, and the destination node is called route discovery target. When a node receives this request packet, if it is not the target, it processes the packet in this way: if this packet is from a well-behaving neighbor, it has never processed the same request packet before, and it is a well-behaving node from that neighbor’s point of view (the node from which it receives this request packet), this node appends its own address to the route record of the packet, obtains its own local reputation from the neighbor record of the packet and appends this value to the reputation record of the packet, removes all information in the neighbor record, puts its own well-behaving neighbors and their local reputations into the neighbor record, and last broadcasts the packet. Otherwise, the packet should be dropped silently. If the node is the target of the route discovery, it returns a route reply packet to the initiator. A copy of the accumulated route record and the reputation record is put into the route reply packet, which is protected by MAC calculated using keyed one-way hash function. The route to the discovery originator must be the reverse path according to the accumulated hops in the route request packet. This is necessary to enable each node on the path to guarantee that the next node towards the target is not a misbehaving node and the important information in the packet is correct. When an intermediate node receives the route reply packet, it first checks whether this packet


55

is from one of the neighbors that it puts into the corresponding route request packet. If it is not the cast, this reply packet should be dropped. And then it checks whether the local reputation information in the reply packet is consistent with that in the corresponding route request packet kept in its cache. If it is not the case, the node should drop the packet silently. Otherwise, it forwards the packet to the next hop according to the route in the packet. When the sender node receives the route reply packet, it first performs the similar check, and then calculates the MAC to identify whether the packet is modified. If the MAC is correct, it can make use of intermediate nodes’ local reputations to evaluate this path’s quality. And finally, the optimal route among all discovered routes can be discovered.

5.3 Detailed Operations

In this section, the prevention mechanism is described based on the implementation of a route discovery, which consists of propagation and processing of route request/reply packets. During the route discovery phase, all discovered misbehaving nodes will be bypassed, and a sender node can evaluated quality of each available path to select the optimal route.

5.3.1 Originating a Route Request Packet

When a node originates some data and wants to send it to another node. It will take the following actions as same as what DSR defines. Normally, it will obtain a suitable source route by searching its routing table. But for reactive routing protocols, because route discovery operates entirely on demand, and it does not rely on any periodic or background exchange of routing information, it is possible that there is no available route to that destination in its routing table. If no route is available, the node will initiate the route discovery protocol to dynamically discover a new route to that destination node. According to the formal description of DSR, this route request packet could be a separate IP packet, used only to carry this route request option, or the sender can include the route request option in an existing packet that needs to send to the destination. In order to fulfill the two objectives of this prevention mechanism, some additional information must be included in the route request packet. The sender node should put all its well-behaving neighbors and their local reputations in the request packet.


56

Figure 22. Route request packet generation Figure 22 shows the content of the route request packet created by the route discovery originator node A. In order to simplify the presentation, only the most important parts of the packet that related to this prevention technique are displayed. Besides the route record required by DSR, the reputation record and the neighbor record are added into the packet. The reputation record is used to accumulate intermediate nodes’ local reputation values for optimal route discovery, and the neighbor record is used to keep all well-behaving neighbors and their local reputations. In this example, the route discovery initiator A creates a route request packet. Besides all information required by DSR, A also puts all its well-behaving neighbors and their local reputations into the packet. To do it, A must get relevant information from its neighbor table. From the picture we can see that A has three neighbors B, C and D, but node C is a misbehaving node and has already been detected by A. Therefore, A puts B and D and their local reputations into the neighbor record. This route request packet is broadcasted to its neighboring nodes.

5.3.2 Processing a Received Route Request Packet

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

1. The node checks whether this packet is from a well-behaving neighbor. If it is not


57

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

2. The node checks whether it has processed the packet from the same initiator with

the same request identification and target address before. (For DSR, initiator address, request identification and target address are used to identify a route request packet.) If this is the case, the packet should be dropped silently.

3. The node checks whether it is allowed to process this packet by examining the

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

4. If the node has never seen this request packet before and is allowed to forward the

packet, it appends its own address to the route record of the packet, which is the requirement of DSR. Therefore, all intermediate nodes on the path can be accumulated in the request packet.

5. The node should search the neighbor record of the packet to get its own local

reputation and appends this value to the reputation record of the packet. So all intermediate nodes’ local reputation values can be accumulated in the packet.

6. The node removes information in the neighbor record of the packet, and searches its

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

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

7. The node broadcasts this packet to its neighboring nodes. The detection mechanism

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


58

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

8. The request packet is kept in the node’s cache for some time and identified by

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

Figure 23. Route request packet forwarding

For the same example in figure 23, we can see that node B is a well-behaving neighbor of node A. When B receives this route request packet for the first time, it will put its own address (here just the node’s identification B) into the route record of the packet, and gets its local reputation LRA(B) from the neighbor record and puts it into the reputation record. Then it replaces information in the neighbor record with its own well-behaving neighbors and their local reputations LRB(D), LRB(F), LRB(G). Because B received this request packet from node A, it should not include node A and A’s local reputation in the neighbor record, because it is impossible for A to be the next hop of B. This mechanism is based on DSR, but due to some additional operations and requirements, there are some differences from DSR. Intermediate nodes are not allowed to return route reply packets. In DSR, if an intermediate node has a route to the target, it can return a route reply


59

packet to the initiator in order to reduce overhead. But it is based on the assumption that all nodes in the network are well-behaving nodes. This assumption does not hold here, so the only thing an intermediate node can do is to relay route request packets or drop them. In this solution, only the destination nodes are authorized to return route reply packets because routing and reputation information is protected by MAC which is based on secure associations between the sender nodes and the destination nodes. Collision is a serious problem that makes the detection result incorrect. In some proposed solutions, such as DCF of 802.11, some measures are taken to prevent this problem. For example, to prevent multiple neighbors broadcast request packets at the same time, broadcast with a short jitter delay could be used to reduce collision. The jitter period should be chosen as a random period, uniformly distributed between 0 and BroadcastJitter.

5.3.3 Originating a Route Reply Packet

If the target address field in the route request packet matches this node's own IP address, then the node should return a route reply to the initiator of this request packet. The node processes the packet according to the following sequence of steps:

1. First, the node checks if the number of intermediate nodes is consistent with accumulated reputation information. If there are n intermediate nodes, n local reputation values should be included in the request packet.

2. The sequence of hop addresses initiator, Address[1], Address[2], Address[n],

target accumulated in the route record is put into the route reply packet. Initiator is the address of the initiator of this route request packet, each Address[i] represents each intermediate node on the path.

3. Local reputation information accumulated in the reputation record of the request

packet is put into the route reply packet. And its order should correspond with the order of intermediate nodes. The first one means the reputation of the first intermediate node.

4. The reply packet is protected by MAC. MAC can be generated by a keyed hash

algorithm in order to be suitable for mobile device which has low calculation capability and limited power. SHA-1 and MD5 could be proper choices. The one-way hash function input could be the whole route reply packet, or only routing and reputation information. In this way, the sender node is provided with the evidence that the route request packet had reached the destination. And all important routing and reputation information in the packet can be guaranteed.


60

Figure 24. Route reply packet generation We can see from figure 24, when the destination node H receives the route request packet, it creates a route reply packet including the path from the sender node A to itself (A, B, G, H). And all intermediate nodes’ local reputations LRA(B) and LRB(G) are also included in the packet. MAC is calculated to prevent this packet being modified by any misbehaving nodes. The destination node generates multiple route reply packets for each query, so multiple routes will be available at the initiator. This is a feature of DSR, and makes the optimal route selection possible. And the reverse of the route accumulated in the request packet is used as the source route of the route reply packet, and the reply packet must be transmitted on this route. It is different from DSR, because for DSR, the route reply packet can be delivered on a path which could be an existing route to the initiator, the reverse of this path, or the target initiators route discovery to find a new route to the initiator. The reason why the route reply packet must be delivered along the reverse path is because of security problems. The MAC can be used to detect any modification on route reply packet, but the target can not promise that the reputation information in the packet is correct, because a misbehaving node can change reputation information in the route request packet when it is transmitted to the destination. To guarantee that the information in received route reply packets is correct, each intermediate node must check reputation information in reply packets.


61

Figure 25. Routing and reputation information verification

Using the same example to express this problem, but in order to make the picture clearer, the nodes that are not on the route are neglected (figure 25). Suppose node G is a misbehaving node (has not been detected), and it changes its reputation value from LRB(G) to LR’B(G). The target H is not able to detect this modification and puts the wrong reputation value LR’B(G) in the reply packet. The reply packet is delivered to the initiator along the reverse path. When node B receives this reply packet, it should compare this packet with the corresponding route request packet in its cache to check whether reputation values are consistent. It means B should check LRA(B) and LRB(G) to see if these values are consistent with those ones in the reply packet. Consequently, B is able to detect the value of G’s local reputation LRB(G) is modified, and then B should drop this packet and low the next node G’s reputation. It means if a misbehaving node modifies the reputation information in a route request packet, it will be detected by the next hop towards the initiator when the corresponding route reply packet is transmitted to the initiator. Therefore, the false reputation information will not exist in the initiator’s routing table.

5.3.4 Processing a Received Route Reply Packet

Because the destination node can use MAC to protect the reply packet, no intermediate node is able to modify the information in the reply packet without being detected. But it is possible that an undetected misbehaving node modifies the information in the route request packet, which is mentioned before. Therefore, when the route reply packet is transmitted along the


62

reverse path, each intermediate node must check the packet based on the corresponding route request packet maintained in its cache.

Figure 26. Route reply packet transmission

A node first needs to check whether the reply packet is from a well-behaving neighbor which is in the neighbor record of the corresponding route request packet kept in its cache. For example, in figure 26, node F is a misbehaving node, then only D and G will be included in the neighbor record of the request packet and are authorized to forward the packet, and as a consequence, B only accepts reply packets from D and G. Secondly, the node needs to check whether the source address of the route reply packet is a misbehaving node according to its local reputation. If the packet is from a misbehaving neighbor, the node must drop the packet. In this example (Figure 26), node B must drop the reply packet from node F because F is a misbehaving node. In most cases, the first requirement is enough to exclude any routes containing misbehaving nodes. The second requirement is used to prevent the situation that a misbehaving neighbor is discovered after the request packet is sent and before the corresponding reply packet arrives, which actually rarely happens. Thirdly, the node needs to check whether the local reputation information in the route request packet is modified in the corresponding route reply packet. It has been explained in the previous section. If node B receives the reply packet from G, it needs to check if the values of LRA(B) and LRB(G) in the reply packet are as same as their values in the corresponding request packet maintained in its cache. If any values are changed, node B should discard the


63

packet and reduce the global reputation of node G. Because if a node between G and the target changes the information, for example LRA(B), G is able to detect it and should drop the packet directly. Therefore, each node on the path is able to promise that the next node towards the destination is a well-behaving node. Furthermore, each node on the route performs reputation information check, and they work together to promise that all reputation information contained in the reply packet is correct. When the originator receives this route reply packet, it also executes all checks that an intermediate node needs to perform. Furthermore, the originator calculates the MAC to check whether the routing and reputation information in the packet is not modified. If the calculated MAC as same as that contained in the packet, the sender can trust this packet and keeps this route in its routing table.

5.3.5 Optimal Route Selection

In the route discovery phase, each node on the route promises that the next node is not a misbehaving node based on its observation. Therefore, all detected misbehaving nodes can be excluded from the route. However, it is impossible to detect all misbehaving nodes in the network due to various reasons. Furthermore, some nodes such as low power nodes, or rapidly moving nodes are more likely to make the route unstable. In order to find the most reliable route in all discovered multiple routes, a sender node can take advantage of local reputation to evaluate all available routes and find the optimal route to the destination. In this solution, packet forwarding ratio is used to evaluate node's local reputation, so all intermediate nodes' local reputation information can be used to calculate the path's packet delivery ratio. Here, it means if a sender node transmits a packet, what is the probability that this packet can reach the destination node along the expected route (retransmission is not considered). And this is the most important requirement of secure data forwarding in mobile ad hoc networks. If a path has higher packet delivery ratio, it means this path is more reliable.

Figure 27. Path quality evaluation

In figure 27, if a sender node A wants to send a packet to the destination node E, and A has an available route including three intermediate nodes B, C and D. Due to misbehaving nodes have been excluded from the route, we can suppose that all these three nodes are normal nodes. Local reputation LRA(B) means when A sends the packet to B, what is the probability that the packet is relayed cooperatively by B. If we neglect collision at node C, this value


64

could be regarded as the probability that the packet reaches C through B. Therefore, if all intermediate nodes’ local reputations are considered together, it presents the probability that the packet reaches the destination node E. All intermediate nodes’ local reputations should be used to calculate the path quality. It is calculated with the formula

QoP = LRS(N1) * LRN1 (N2) * … * LRNi(Ni+1) * … * LRNn-1 (Nn) (6) in which S represents the sender node, and Ni, represents an intermediate node on this path. According to QoP (quality of path) of each available path, the sender node can discover the optimal route. If QoP of a path is 0.95, it means if the sender node sends a packet along this path, the packet will reach the destination at the probability of 95 percent without retransmission. Of course, higher a path’s QoP is, better performance this path can provide, such as lower packet delivery delay and higher throughput due to fewer packets are lost and less retransmission occurs. In [65], it showed that the minimum acceptable value for T (same as QoP here) should not fall below about 0.6 including misbehaving nodes as well as loss due to uncontrollable events, such as congestion or jammed links. This value is for connection-less UDP, and T must be much higher for TCP connection. In [64], a quantitative estimation is performed to evaluate the performance of mobile ad hoc networks. And one observation is that if “p” (same as local reputation or packet forwarding ratio in this report) is high, even small increase of “p” can cause significant benefit on the network’s reachability. And in one example, it increases the network’s absolute reachability by about 400%. In this solution, all intermediate nodes on available routes are well-behaving nodes and their p values are at least higher than the threshold which should be high enough to identify misbehaving nodes. So there are big differences among the values of QoP of all available paths. For example, we suppose node S has two discovered routes to node D, and each of them contains 4 intermediate nodes. If packet forwarding ratio of each intermediate node on one path is 90%, then the QoP of this path will be only 0.66. And if packet forwarding ratio of each intermediate node on another path is 98%, the QoP of that path will be 0.92. We can find that there is large performance difference between these two paths. And the optimal path could be the most reliable route for data forwarding and increase the network performance greatly. The optimal route selection also needs to take hop count into account. Several rules could be used for selection of the optimal route.


65

1. Hop count is the first criterion followed by path quality. 2. Path quality is the first criterion followed by hop count.

It is obvious that if only path quality is considered, the path with highest path quality will be chosen which means this path will have the best performance. However, it is unrealistic to neglect hop count which is the only metric used by almost all routing protocols. And the energy constrain is also directly related to hop count. More intermediate nodes one path has, more energy is required to deliver a packet on this path. If we suppose that the hop count of a path from A and B is n, and its path quality (packet delivery ratio) is p. If A sends a packet to B, the packet will be forwarded n times on this path. And the probability of the packet loss on this path is 1-p. If the packet is lost on the way, node A will have to retransmit this packet (TCP) or does not perform any reaction (UDP). For TCP traffic, a retransmitted packet will still need n times forwarding on this path and with the loss

probability of 1-p. It can be calculated that in theory after pn

times, the packet can be

guaranteed to reach its destination. Therefore, there is another rule for optimal route selection.

3. The path with the highest value of pn

Which rule to choose depends on concrete scenario. For example, for UDP, the second rule may be a good choice. However, the third rule may be a nice one for TCP.

5.4 Analysis

This prevention technique is based on DSR, so its performance on bypassing misbehaving nodes and optimal route discovery is also tightly related to DSR route discovery performance. DSR routing protocol enables a sender node to discover multiple routes to a certain destination. If this technique is employed, the number of available routes at sender nodes depends on two factors: How many routes DSR can find and how many misbehaving nodes are in the network.

5.4.1 Performance for Various Misbehaving Nodes

This prevention technique is based on packet forwarding ratio, which is obtained by the detection scheme for reputation calculation and misbehaving node detection. To evaluate whether this solution can handle the problems brought by different misbehaving nodes, the misbehaving nodes are classified based on their forwarding behaviors. 1. Misbehaving nodes dropping all packets.


66

For a node in this type, it drops all packets going through it (including route request packets). Therefore, it will not be included in any discovered routes. And there is no data packet will pass through it. This kind of nodes can be regarded as classical selfish node. Such nodes can be detected by their neighbors by route request packet monitoring. Due to the requirement of the reaction mechanism that a node has to claim its existence to its neighbors (otherwise, its neighbors will not provide relay service to it), if this node drops all request packets, it is easy for its neighbors to detect its abnormal behavior. And the detection result will be quite correct.

2. Misbehaving nodes dropping all data packets.

This kind of misbehaving nodes can also be detected easily by its neighbors using data packet monitoring. Because those nodes drop all data packets, they can be obviously distinguished from well-behaving nodes.

If there are only these two types of misbehaving nodes in mobile ad hoc networks, the prevention technique will be very effective to address problems caused by these misbehaving nodes, because this technique can guarantee that packets delivered in the network do not pass through these misbehaving nodes, which are very easy to be detected.

3. Misbehaving nodes dropping partial packets.

Packets dropping could be caused by misbehaving nodes, as well as by congested nodes or unreliable links. Therefore, this kind of misbehaving nodes is relatively difficult to detect. If the threshold is set to T, a misbehaving node should make its packet forwarding ratio multiple than T to avoid being detected. So at least an acceptable level can be promised if a misbehaving node does not want to be detected and be excluded from the network. For example, we can suppose that the threshold to identify misbehaving nodes is 0.9. For a misbehaving node, if it does not want to be detected, it should keep its packet forwarding ratio higher than 0.9.

If there are misbehaving nodes of type 3 in the network, it could be possible that some misbehaving nodes could not be detected directly. The optimal route selection technique is designed to address this problem. No matter a node is a potential misbehaving node or a normal node temporarily with some uncontrollable troubles such as congestion or jammed links, the quality of forwarding service they provide must be lower than that provided by normal well-behaving nodes. So QoP can be used to evaluate each available path, and then the optimal route can be discovered.

5.4.2 Limitations

1. Using this prevention technique, the number of available discovered routes generally is less than that discovered by DSR, because all routes containing misbehaving nodes and found by standard DSR are discarded.


67

Figure 28. Route discovery with standard DSR

Consider the example show in figure 28, the sender node S makes a route discovery using standard DSR, four routes will be discovered. But if the prevention technique is used, the third route will not be in S’ routing table because it contains a misbehaving node.

Figure 29. Route discovery with the prevention technique

But due to the requirement that the discovered misbehaving nodes are not allowed to forward route request packets and all request packets from misbehaving neighbors must be dropped, new routes may be discovered (figure 29).


68

2. If every route discovered by DSR contains misbehaving nodes, there will be no available route at the sender node. Therefore, the threshold used to distinguish misbehaving nodes from well-behaving nodes is very important. If this value is too high, normal nodes may be regarded as misbehaving nodes due to problems like collision, and more routes will be dropped. And if this value is too low, some misbehaving nodes can not be detected and these potential misbehaving nodes could be included in the discovered routes.


69

6 Performance Evaluation

In this chapter, the simulation results are presented and analyzed. Form the results, we could find that misbehaving nodes do degrade the network performance. And the results also display the improvement of network performance when the prevention technique is employed in the route discovery phase. In section 6.1, the tool (NS-2) designed for network simulation is introduced briefly. Section 6.2 describes the implementation of DSR in NS-2. Section 6.3 shows the common simulation configuration. And Section 6.4 describes and analyzes the results of various simulations.

6.1 Network Simulator Introduction

Network simulation is a basic method to perform network technology research. During the research, it may be very difficult or even impossible to implement a network system in a real environment due to various reasons, such as high cost or difficulty of creating the expected environment. Therefore, network simulation becomes a suitable, rapid and cost-effective method to execute performance evaluation. And it enables researchers to take advantage of other existing solutions and technologies conveniently, and to focus more on their own research topics without paying unnecessary attentions to other parts of the system.

NS [68] is a simulation tool that designed for modeling real world networks. NS is a variant of the REAL network simulator and has evolved significantly. As the successor of REAL network simulator, NS-2 is an event driven packet level network simulator developed as part of the VINT project (Virtual Internet Testbed) [70] with the collaboration of many institutes [71]. NS is open source and free, so it is always growing to include new protocols. For example, the wireless code from the UCB Daedelus and CMU Monarch projects and Sun Microsystems, have added the wireless capabilities to NS-2. Currently, it contains plenty of network modules and touches a large number of network technologies. NS-2 could be used to evaluate the performance of a variety of network protocols and architectures designed for both wired and wireless networks, and it is suitable to run large scale experiments which are difficult to realize in real environments.


70

6.2 DSR in NS-2

The CMU monarch [72] extensions add the wireless capabilities to NS-2. These extensions provide new elements at the physical, link and routing layers of the simulation environment, and enable NS-2 to simulate mobile and wireless networks. For example, on the physical layer, radio propagation models, antennas, and network interfaces are defined; on the link layer, two media access control protocols: IEEE 802.11 and CSMA are defined; and multiple routing protocols are available on the network layer. Using these new elements, it is possible to perform precise and effective simulation to evaluate the network performance of mobile ad hoc networks.

6.2.1 Mobile Node Architecture

The concept of mobile node is the most important thing in these wireless extensions. Based on mobile nodes, additional components could be combined together to support mobile ad hoc networks and wireless sub-networks. In figure 30, the architecture of a mobile node is shown. Each mobile node is able to have one or multiple network interfaces, which are connected to a channel. Channels are used to exchange packets among these mobile nodes. When a node delivers a packet to a channel, the channel is responsible for distributing this packet to all mobile nodes which are connected to it. And each node estimates whether it can receive this packet correctly according to its radio propagation model. The radio propagation model is responsible for calculating the received signal power of each packet. If its signal power is lower than the threshold defined at the network interface, this packet will be dropped by the MAC. If the MAC accepts the packet, it will pass the packet to the entry point. The later process depends on whether or not this node is the destination of the packet. If it is the case, the packet will be delivered to the proper sink agent for further process. Otherwise, it will be delivered to the route agent. The route agent is responsible for routing issues, such as route discovery and maintenance. It will find a route to the packet’s destination, assign the packet a new next hop and deliver it to the link layer. Additionally, if this mobile node originates a packet, the packet will be first delivered to its entry point and then to the route agent generally.


71

Figure 30. Architecture of a mobile node in NS-2

6.2.2 DSR Mobile Node Architecture

The architecture of a DSR mobile node is shown in figure 31. From the picture, we can find that it is slightly different from that of a basic mobile node. For a DSR mobile node, the address demultiplexer and the route agent are combined together. The reason for this modification is the routing information may be piggybacked on ordinary data packets by DSR agents. Therefore, DSR agents should be capable of processing data packets as well as route packets.


72

Figure 31. Architecture of a DSR mobile node in NS-2

6.2.3 DSR Implementation in NS-2

When a DSR agent receives a packet, it performs the following actions as shown in figure 32 [73]. It first checks whether the packet contains a valid source route, if it is not the case, there will be two possibilities. The first one is this packet is originated by this node itself and the source route has not been added into the packet, so the handlePktWithoutSR function will be called. And the second one is this packet is a broadcast packet and then sendOutBCastPkt will be called. If the handlePktWithoutSR function is called, the DSR agent will first try to find a route to


73

that destination in its route cache using findRoute. If it can not find an available route to that destination in its cache, it will call getRouteForPacket to initialize a route discovery to find new routes to that intended destination. If this packet has a valid source route, there will be a complete route in its header. The agent checks whether this node is the final destination of the packet. If it is the destination, the handlePacketReceipt function will be called to handle this packet. And different functions are executed according to the packet type: route request packet, route reply packet, route error packet, or data packet. If this node is an intermediate node, the DSR agent will check whether this packet is a route request packet. If it is the case, the handleRouteRequest function will be called. Otherwise, it means this packet is an ordinary data packet or a route reply packet, the handleForwarding function will be called to forward the packet according to the route contained in the packet.

Figure 32. Packet process in a DSR Agent

6.3 Simulation Setup

6.3.1 Simulation Configuration

All simulations take place in a flat square with 1000 meters on each side, and there are 50 mobile nodes in the network. The Distributed Coordination Function (DCF) of IEEE 802.11 is used as the medium access control layer protocol, and the TwoRayGround model is chosen as the radio propagation model. The values of relevant parameters are set to their default values.


74

The radio transmission range of each node is 250 meters and the transmission data rate is set to 2 Mbits/s. DSR is employed as the routing protocol, and CMUPriQueue is used as the interface queue in which at most 50 packets could exist. Due to different concerns in different simulations, some simulation parameters are modified in each simulation. But the following parameters (table 8) are fixed in all simulations. The other flexible simulation parameters will be mentioned later.

Network size 1000 * 1000 m2 Number of nodes 50 Radio range 250 m Movement random waypoint model MAC 802.11 Transmission capacity 2 Mbps Application CBR Number of connection 10 Packet size 512 byte Routing protocol DSR

Table 8. Simulation parameters

6.3.2 Movement Model

The simulations are performed on a variety of scenarios using ns-2 [68]. In all simulations, each node in the network moves with the random waypoint mode [69]. In this mode, a node chooses a destination arbitrarily and moves in a straight line towards that destination. Its moving speed is uniformly distributed between zero and a predefined maximum speed. When the node reaches the destination, it stays there for some time (pause time) and then it chooses a new destination and begins to move to that destination. The maximum speed and the pause time are simulation parameters which could be changed in each simulation for different purposes. The scene files could be generated by a tool called setdest. By changing the maximum speed and the pause time, the network performance under different mobility patterns can be obtained and compared. In some simulations, the maximum speed is set to 20 m/s or 2 m/s respectively, and the pause time is set to 0 s, 100 s, 200 s, 300 s, 400 s or 500 s. While in other simulations, these values are fixed.

6.3.3 Communication Model

The traffic scenario files are created using cbrgen.tcl program in NS-2. The cbrgen tool is used to produce traffic overload, which could be TCP or CBR (Constant Bit Rate). In the following simulations, CBR is used to evaluate network performance. In each simulation, 10 connections are produced randomly in the network. The packet size is a fixed value 512 bytes.


75

All connections are generated at times that distributed between 0 and 180 seconds, and all connections exist until the simulation is finished. The packet sending rate is set to 1p/s or 4p/s in different simulations. An example of produced file is as follows. # 1 connecting to 2 at time 2.5568388786897245

set udp_(0) [new Agent/UDP]

$ns_ attach-agent $node_(1) $udp_(0)

set null_(0) [new Agent/Null]

$ns_ attach-agent $node_(2) $null_(0)

set cbr_(0) [new Application/Traffic/CBR]

$cbr_(0) set packetSize_ 512

$cbr_(0) set interval_ 1.0

$cbr_(0) set random_ 1

$cbr_(0) set maxpkts_ 10000

$cbr_(0) attach-agent $udp_(0)

$ns_ connect $udp_(0) $null_(0)

$ns_ at 2.5568388786897245 "$cbr_(0) start"

……

6.3.4 Misbehaving Nodes

There are two kinds of misbehaving nodes in the simulations. Malicious nodes

For malicious nodes, they behave cooperatively during the route discovery phase, and then they are included in some discovered routes. But they drop data packets in the data delivery phase if these packets are not intended for themselves. As a consequence, data packets delivered over routes containing these malicious nodes will be lost. In most simulations, malicious nodes drop all data packets passing through them. But in order to deal with potential misbehaving nodes that are difficult to detect, the situations in which those nodes drop data packets at a certain probabilities are also considered.

Selfish nodes For selfish nodes, they drop all packets during a simulation. Because route request packets are also dropped by these nodes, they will not be included in any discovered routes. Therefore, no data packets will pass through them.

6.4 Simulation Result Analysis

NS-2 could produce trace files for performance evaluation, and nam (Network Animator) files to show the network topology change and packet delivery in the network (figure 33).


76

Figure 33. Network topology shown in nam

6.4.1 Mobility Influence

In this scenario, there are no misbehaving nodes in the network. The simulations are performed to evaluate the impact of dynamic network topology. Packet delivery ratio is used to evaluate the network performance. It is the ratio of the number of data packets successfully delivered to all destinations and the number of packets generated by all senders.

0.9

0.91

0.92

0.93

0.94

0.95

0.96

0.97

0.98

0.99

1

0 100 200 300 400 500pause time (S)

packet delivery ratio

2 m/s

20 m/s


77

Figure 34. Packet delivery ratio vs. pause time

In figure 34, we can see that the moving speed of nodes has some influence to the packet delivery ratio. The packet sending rate is one packet per second for all simulations in this scenario, which gives a very slight traffic overload to avoid some other reasons for packet loss such as collision. For mobile nodes with the maximum speed at 2m/s, the packet delivery ratio is quite high. Even for the situation in which all nodes move continuously in the network, the value of packet delivery ratio is still very close to 1.When the maximum moving speed is increased to 20m/s, we can find that the value of packet delivery ratio decreases significantly. If all nodes keep moving in the network, the value of packet delivery ratio is about 93 percent. Actually, DSR can provide a quite high packet delivery ratio. In [76], we can find that DSR has the best packet delivery ratio performance in the four evaluated routing protocols. But it is doubtless that if all intermediate nodes on a path are fixed or move at a low speed such as 2m/s, the packet delivery ratio on this path will have a better performance.

6.4.2 Misbehaving Nodes

Two kinds of misbehaving nodes are considered in the following simulations. The first one is called malicious nodes. In the simulations, they behave cooperatively during the route discovery phase, but drop data packets later. The second one is called selfish nodes. In the simulations, they drop all packets passing through them. In all simulations, the packet sending rate is 4p/s. Two scenarios in which nodes move at the speed up to 20 m/s or 2 m/s are tested. Each simulation lasts for 200 second. The packet delivery ratio is evaluated in the following five situations: no misbehaving nodes, 10%, 20%, 30% and 40% nodes are misbehaving nodes. 6.4.2.1 Misbehaving Nodes First, network performance is evaluated when malicious nodes begin to appear in the network. In the simulations, malicious nodes drop all data packets. All simulations are based on standard DSR rouging protocol, the purpose of the simulations is to show that the network performance degrades significantly when malicious nodes appear in the network.


78

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 10 20 30 40percentage of misbehaving nodes


20 m/s

2 m/s

.

Figure 35. Packet delivery ratio vs. percentage of malicious nodes From figure 35, it is obvious that the packet delivery ratio decreases considerably when malicious nodes appear in the network in both scenarios. When 40% of the nodes in a network are malicious nodes, the values of packet delivery ratio in both scenarios are lower than 0.4. For a network with rapidly changing network topology (20 m/s), we can see that in the case where the network contains no misbehaving nodes, the packet delivery ratio is about 86%, which is different from the value shown in 6.4.1 (about 93%). It is because packet loss is also related to network overload. The packet sending ratio increases to 4p/s in these simulations. Because in these simulations, malicious nodes drop all data packets passing through them, it is obvious that all packets delivered over routes containing such nodes will be lost. Therefore, we can find that the network performance degrades significantly when malicious nodes appear in the network. But it is possible that in some cases a destination node is just one hop away from a sender node, all packets delivered between these two nodes will never be lost even with the appearance of malicious nodes in the network. As a consequence, the packet delivery ratio will become more close to a value when more malicious nodes are in the network, which depends on the transmission range of nodes and the network size. It means in theory this value will not decrease to 0 even all nodes are malicious nodes. 6.4.2.1 Selfish Nodes The impact of selfish nodes is also evaluated using simulation. In figure 36, we can see that the packet delivery ratio is not significantly influenced by selfish nodes no matter node mobility. Selfish nodes drop all packets including route request packets, so they will not be included in any discovered routes, and all intermediate nodes of discovered routes are


79

well-behaving nodes. Therefore, data packets will not be dropped by intermediate nodes deliberately.

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 10 20 30 40percentage of selfish nodes


20 m/s

2 m/s

Figure 36. Packet delivery ratio vs. percentage of selfish nodes But as for the whole trend, the packet delivery ratio is becoming lower and lower when more and more selfish nodes appear in the network. This is because when more nodes become selfish nodes, fewer nodes are available for relaying packets for other nodes. So for well-behaving nodes, their packet forwarding burdens become heavier. And more packets are lost due to more collisions happen around these well-behaving nodes. The packet delivery ratio does not change much even 40% nodes are selfish nodes in a network, but the packet relaying burden of each well-behaving node increases obviously. In the simulations, the forwarding behavior of each node on routing layer could be recorded. It means for all intermediate nodes, how many packets they relayed for other nodes could be obtained. So it is easy to calculate how many packets each well-behaving node has relayed for other nodes in a simulation. In figure 37, the simulation results show that if there is no selfish node in the network, each well-behaving node relays about 530 packets as intermediate node in a simulation. With the increase of selfish nodes, each well-behaving needs to relay more packets (total traffic in the network does not change). Due to all selfish nodes refuse to forward packets, well-behaving nodes need to forward those data packets which should be forwarded by those selfish nodes originally. We can see when 40% nodes in a network are selfish nodes, a well-behaving node needs to forward about 970 packets. Therefore, a well-behaving node’s transmission burden will significantly increase if there are a large number of selfish nodes in the network.


80

0

100

200

300

400

500

600

700

800

900

1000

0 10 20 30 40percentage of selfish nodes (S)

mean number of packets relayed by

well-behaivng nodes

Figure 37 Average numbers of packets relayed by well-behaving nodes vs. percentage of selfish nodes

6.4.3 Bypassing Misbehaving Nodes

Form the analysis above, we can see that the influence of misbehaving nodes are various, which are based on the concrete misbehaviors of those nodes. For malicious nodes, they degrade the network performance significantly. For selfish nodes, they do not have great impact on the network performance, but they increase well-behaving nodes’ burdens. The prevention mechanism could be used to improve the network performance. Its basic idea is to bypass misbehaving nodes according to the detection result. In the following simulations, the concrete detection mechanism is not considered, which means all these simulations are based on the assumption that the detection result could be obtained correctly. The prevention solution is only useful to handle malicious nodes, because for selfish nodes, they have already been excluded from the discovered routes by themselves. From figure 38 and 39, we can see that if the prevention mechanism is used, the packet delivery ratio could increase greatly. In figure 38, even 40% nodes are malicious nodes, the packet delivery ratio still can reach about 65%, but if DSR is used, the packet delivery ratio is about only 30%. And for a network in which no more than 20% nodes are malicious node, the prevention mechanism can provide a quite good network performance which is very close to that of a network without malicious nodes. The similar situation could also be found in figure 39.


81

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 10 20 30 40percentage of malicious nodes


DSR

Preventionmechanism

Figure 38. Packet delivery ratio vs. percentage of malicious nodes (20m/s)

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 10 20 30 40percentage of malicious nodes


DSR

Preventionmechanism

Figure 39. Packet delivery ratio vs. percentage of malicious nodes (2m/s) .

6.4.4 Optimal Route Discovery

In the previous chapter, the optimal route discovery technique is introduced which could be used to provide better performance if there are some potential misbehaving nodes in the network that can not be detected or packets are lost due to collision or congestion. It chooses routes according to hop count as well as path quality.


82

In all simulations, CBR is used as the traffic overload. Therefore, no retransmission happen if packet is lost on the way. Therefore, in the following simulations, the third rule for optimal mentioned in 5.3.5 is employed. In order to reduce the impact of other things that cause packet loss, the maximum speed of each node in the simulation is set to 2 m/s, because in such scenario, the packet delivery ratio is about 99.6%. The malicious nodes forward data packets at the probability of 70%. The packet delivery ratio is evaluated in the following situations in which 10%, 20%, 30% and 40% of nodes are malicious nodes respectively. If we suppose that 70% packet forwarding ratio is acceptable, these misbehaving nodes will not be detected. As a consequence, they will be included in some discovered routes. However, a sender node can take advantage of the optimal route discovery technique to find the most reliable route to another node.

0.65

0.7

0.75

0.8

0.85

0.9

0.95

1

0 10 20 30 40


DSR

Optimal Route Discovery

percentage of malicious nodes

Figure 39. Packet delivery ratio vs. percentage of malicious nodes packet forwarding ratio: 70%

In figure 40, we can see that this mechanism could improve the packet delivery ratio. But compare with the prevention mechanism (bypassing detected misbehaving nodes), the improvement is not so significant, because in these scenarios, the potential malicious nodes do not drop all packets, but drop packets at some probabilities. Therefore, even without this mechanism, the packet delivery ratio is still on an acceptable level. For example, when 40% such malicious nodes exist in the network, the packet delivery ratio is still above 70%.


83

However, if these 40% nodes begin to drop all packets, the packet delivery ratio will be below 30% (figure 38).


84

7 Future Work

This report presents initial work of the reputation-based solution which could be used to detect misbehaving nodes and to mitigate their performance impact on mobile ad hoc networks. In this chapter some further ideas are described. Currently data packets and route packets are treated equally for reputation evaluation, but it may be better if these kinds of packets are treated separately. For example, weight is determined by packet type, or different reputation calculation functions are used for different types of packets. And some problems exist in neighbor monitoring technique, but these problems are caused by the nature of the detection technique itself. Therefore, other possible monitoring and reputation evaluation methods should be investigated, such as end-to-end performance evaluation technique. And in the detection mechanism, the global reputation scheme can provide objective and effective reputation information. However, it results in a large quantity of computation and transmission overheads currently. Therefore, it needs to be optimized to reduce its overhead. Furthermore, some potential security problems exist in this scheme, for example a misbehaving node could first behave cooperatively to get high reputation and then begins to broadcast false reputation information to disrupt the network. Something must be done to address these security problems. The currently performed simulation is relatively simple. The prevention mechanism is simulated to see the throughput increase compared to solely communication without this technique. The next step is to simulate more scenarios in which more complicated misbehaviors exist, and to analyze the network performance using TCP flows. Moreover, the detection mechanism will be simulated to evaluate its performance. And other metrics need to be measured such as latency and overhead.


85

8 Conclusion

Personal Networks are an increasingly promising area of research with practical network technologies and architectures, in which ad hoc networks have been received much attention. But due to their specific characteristics such as multi-hop and infrastructure-independent, they are more vulnerable than traditional networks. Various attacks especially those related to routing and forwarding are much easy to be launched by misbehaving nodes in ad hoc networks. Furthermore, a new type of misbehaving nodes called selfish nodes could exist in such networks. Routing information as well as data packets are more likely to be damaged or lost. In this report, a new reputation-based solution designed for mobile ad hoc networks is presented. The detection mechanism and the prevention approach in this solution are specially introduced. The detection mechanism could be used to effectively detect misbehaving nodes by performing neighbor monitoring and information exchange in a local scope. But power constraint is a challenge for this local monitoring mechanism performed by each mobile node. The prevention scheme is fully operated in the route discovery phase without any specific test procedure. Depending on cooperation of all well-behaving nodes in the network, misbehaving nodes could be excluded from the discovered routes. And route selection is based on hop count as well as path quality to select the most reliable route to a specific destination. Simulation shows the different impacts on the network performance caused by misbehaving nodes which are divided into two types: malicious nodes and selfish nodes. The simulation shows that malicious nodes degrade the network performance considerably and selfish nodes increase other nodes’ burdens. The prevention mechanism is simulated to evaluate the network performance improvement. From the simulation results, it is obvious that the prevention mechanism can increase the network performance significantly if an effective detection technique is available.


86

Reference

[1] X`Martin Jacobsson, Jeroen Hoebeke, Sonia M. Heemstra de Groot, Anthony Lo, Ingrid Moerman, Ignas G. M. M. niemegeers, “A network layer architecture for personal networks”, In the first MAGNET workshop, Shanghai, China, October 17,2004.

[2] Ignas G. M. M. Niemegeers, Sonia M. Heemstra de Groot, “Research issues in ad hoc distributed

personal networking”, wireless personal communications: An international journal, Volume: 26, Issue:2-3, pages: 149-167, Kluwer Academic Publishers, August 2003.

[3] IEEE P802.15, IEEE 802.15 Working Group for WPAN http://grouper.ieee.org/groups/802/15/. [4] IEEE P802.11, IEEE 802.11 Working Group for WLAN, http://grouper.ieee.org/groups/802/11/. [5] Bluetooth SIG, Specification of the Bluetooth System, version 1.1 B, Http://www.bluetooth.com/,

2001. [6] IEEE Std 802.15.4™-2003, 1 October 2003， IEEE 802.15 WPAN™ Task Group 4 (TG4). [7] IEEE Std 802.15.3™-2003, 29 September 2003，IEEE 802.15 WPAN™ Task Group 3 (TG3). [8] Jeroen Hoebeke, Ingrid Moerman, Bart Dhoedt and Peit Demeester, “An overview of mobile ad

hoc networks: applications and challenges”, MAGNET project. [9] James M. Wilson, “Quadrupling Wi-Fi speeds with 802.11n”,

http://www.deviceforge.com/articles/AT5096801417.html [10] IST MAGNET project, http://www.ist-magnet.org/. [11] D. B. Johnson and D. A. Maltz, “Dynamic source routing in ad hoc wireless networks”, Mobile

Computing, PP. 153-181, 1996. [12] Y. Xue and K. Nahrstedt, "Bypassing misbehaving nodes in ad hoc routing," Tech. Rep.

UIUCDCS-R-2002-2306, UILU-ENG2002-1749, Department of Computer Science, University of Illinois at Urbana-Champaign, November 2002.

[13] Bluetooth Security White Paper, Bluetooth SIG security expert group. [14] Bluetooth SIG, Bluetooth Security Architecture White Paper, version 1.0, July 15 1999,

http://www.bluetooth.com. [15] Bluetooth SIG, Specification of the Bluetooth system, Core, Part B "Baseband specification",

Version 1.1, 22 February 2001, at http://www.bluetooth.com/. [16] Wireless LAN Enhanced Security, IEEE, 802.11i/D3.0, November 2002. [17] Security Architecture for the Internet Protocol, RFC 2401.


87

[18] The Internet Key Exchange (IKE), RFC 2409. [19] Sorin M. Schwartz, "IPSec basics“, ver.6, March 27, 2003 [20] Radia PerLMAN, Charlie Kaufman, “Key exchange in IPSec: analysis of IKE”,

1089-7801/00/s10.00, IEEE Internet Computing. [21] HMAC algorithm, “HMAC: Keyed-Hashing for Message Authentication”, RFC-2104. [22] The MD5 Message-Digest Algorithm, RFC-1321, http://www.faqs.org/rfcs/rfc1321.html. [23] SECURE HASH STANDARD, FIPS-180-1, http://www.itl.nist.gov/fipspubs/fip180-1.htm. [24] IP Version 6 Working Group (ipv6), http://www.ietf.org/html.charters/ipv6-charter.html. [25] Internet Protocol, Version 6 (IPv6) Specification, RFC 2460, http://www.ietf.org/rfc/rfc2460.txt. [26] Network mobility (nemo), IETF official NEMO Working Group web page and charter,

http://www.ietf.org/html.charters/nemo-charter.html. [27] Hridesh Rajan, “Mobile ad hoc networks”, Dept of Computer Science, University of Virginia,

Sept 2001, http://www.cs.virginia.edu/~hr2j/MANET.html. [28] Charles E. Perkins, Pravin Bhagwat, “Highly dynamic Destination-Sequenced Distance-Vector

Routing (DSDV) for mobile computers”, 1994 ACM 0-89791-682-4/94/0008. [29] Optimized Link State Routing Protocol (OLSR), RFC 3626. [30] Thomas Clausen, Philippe Jacquet, Optimized Link State Routing Protocol(OLSR), IETF Internet

Draft, July 3 2003. [31] C. Perkins, E. Belding-Royer, S. Das, Ad hoc On-Demand Distance Vector (AODV) Routing,

RFC 3561. July 2003. [32] D. B. Johnson and D. A. Maltz, “Dynamic source routing in ad hoc wireless networks”, Mobile

Computing, (Kluwer Academic, 1996) pp. 153-181. [33] M. R. Perlman, Z. Z. Haas, "Determining the optimal configuration for the zone routing protocol",

IEEE JSAC, Aug. 1999, vol. 17, no. 8, pp. 1395-1414. [34] Vincent D. Park and M. Scott Corson, Temporally-Ordered Routing Algorithm (TORA) version 1:

Functional specification. Internet Draft, draft-ietf-manet-tora-spec-00.txt, November 1997. [35] I. Chakeres, E. Belding-Royer, C. Perkins, Dynamic MANET On-demand Routing Protocol

(DYMO), Internet Draft, draft-ietf-manet-dymo-00. [36] Yih-Chun Hu, Adrian Perrig and David B. Johnson, “Ariadne: a secure on-demand routing

protocol for ad hoc networks”, in The 8th ACM International Conference on Mobile Computing and Networking, September 2002.

[37] Marina Petrova, Martin Jacobson, Simon Oosthoek, etc. Conceptual Secure PN Architecture,

MAGNET D2.1.1, 17 January 2005.


88

[38] Jeroen Hoebeke (IMEC) ed., Ingrid Moerman (IMEC), Martin Jacobsson (DUT), etc, “Architectures and protocols for ad-hoc selfconfiguration, interworking, routing and mobility”, 22 December 2004, MAGNET D2.4.1.

[39] Thafer Sulaiman, Kumarendra Sivarajah, Hamed Al-Raweshidy, ” MANET IN PERSONAL

AREA NETWORK (PAN)”, MAGNET project. [40] Hao Yang, Haiyun Luo, Fan Ye, Songwu Lu, Lixia Zhang, ”Security in mobile ad hoc networks:

challenges and solutions”, IEEE Wireless Communications, February 2004. [41] S. Marti, T. J. Giuli, K. Lai, and M. Baker, “Mitigating routing misbehavior in mobile ad hoc

networks,” Proceeding of MOBICOM, Aug 2000. [42] Y. Xue and K. Nahrstedt, "Bypassing misbehaving nodes in ad hoc routing," Tech. Rep.

UIUCDCS-R-2002-2306, UILU-ENG2002-1749, Department of Computer Science, University of Illinois at Urbana-Champaign, November 2002.

[43] S. Buchegger, "The CONFIDANT Protocol", NCCR MICS Kick-off Meeting, February 2002. [44] Po-Wah Yau and Chris J. Mitchell, “Reputation methods for routing security for mobile ad hoc

networks”, http://www.isg.rhul.ac.uk/~cjm/rmfrsf.pdf. [45] Michiardi P,Molva R. “Core: a collaborative reputation mechanism to enforce node cooperation in

Mobile Ad Hoc Networks”, In:Proc. of the sixth IFIP Conf. on Security Communications and Multimedia(CMS 2002), 2002

[46] P. Dewan, P. Dasgupta, “Trust routers and relays in ad hoc networks“,

http://www.public.asu.edu/~dewan/docs/Dewan-Wispr.pdf [47] P. Papadimitrators, Z. J. Haas, “Secure message transmission in mobile ad hoc networks”, Ad Hoc

Networks (2003) 193-209. [48] Q. He, D. Wu, P. Khosla, “SORI: A secure and objective reputation-based incentive scheme for ad

hoc networks”, IEEE Wireless Communications and Networking Conference 2004 [49] P. Michiardi, R. Molva, “Simulation-based analysis of security exposures in mobile ad hoc

networks”, European Wireless Conference, 2002. [50] P. Papadimitratos, Z. J. Haas, “Secure routing for mobile ad hoc networks”, In SCS

Communication Networks and Distributed Systems Modeling and Simulation Conference (CNDS 2002), San Antonio, TX, January 2002.

[51] Y. Hu, A. Perrig, D. B. Johnson, “Ariadne: a secure On-Demand Routing Protocol for Ad Hoc

Networks”, Technical Report TR01-383, Department of Computer Science, Rice University, December 2001.

[52] L. Zhou and Z.J. Haas, ‘Securing ad hoc networks’, IEEE Network Magazine, vol. 13, no.6,

November-December 1999. [53] A. Perrig, R. Canetti, D. Song and J.D. Tygar, “efficient and secure source authentication for

multicast”, Network and Distributed System Security Symposium, NDSS ’01, pages 35-46, February 2001.


89

[54] Y. Hu, D. B. Johnson, A. Perrig, “SEAD: secure efficient distance vector routing for mobile wireless adhoc networks”, In Proceeding s of the 4th IEEE Workshop on Mobile Computing Systems & Applications (WMCSA 2002), IEEE, calicoon, NY, to appear, June 2002.

[55] Manel Guerrero Zapata, “Secure ad hoc on-demand distance vector (SAODV) routing”,

draft-querrero-manet-saodv-03, Mobile Ad Hoc Networking Working Group, 17 March 2005. [56] L. Buttyan and J. Hubaux, “Stimulating Cooperation in Self-organizing Mobile Ad hoc Networks”,

Mobile Networks and Applications, 8(5):579-592, October 2003. [57] S. Zhong, J. Chen, and Y. Yang, “Spring: a simple, cheat-proof, credit-based system for mobile ad

hoc networks”, IEEE INFOCOM 2003, San Francisco, CA, USA, April 2003. [58] M. Jakobsson, J. Hubaux, and L. Buttyan, “A micro-payment scheme encouraging collaboration

in multi-hop cellular networks”, Proceedings of Financial Crypto 2003, Gosier, Guadeloupe, Jan. 2003.

[59] Panagiotis Papadimitratos and Zygmunt J. Haas, “Secure routing for mobile ad hoc networks”, In

Proceedings of the SCS Communication Networks and Distributed Systems Modeling and Simulation Conference (CNDS 2002), San Antonio, TX, January 27-31, 2002

[60] Lidong Zhou and Zygmunt J. Haas, “Securing ad hoc networks”, IEEE network, special issue on

network security, November/December, 1999. [61] Jean-Pierre Hubau, Levente Buttyan and Srdan Capkun, “The quest for security in mobile ad hoc

networks”, ACM Published in the Proceedings of the ACM Symposium on Mobile Ad Hoc Networking and Computing (MobiHOC 2001).

[62] F. Talucci, M. Gerla, “MACA-BI (MACA By Invitation) a wireless MAC protocol for high speed

ad hoc networking”, http://www.ics.uci.edu/~atm/adhoc/paper-collection/gerla-macabi-icupc97.pdf

[63] V. Bharghavan, A. Demers, S. Shenker, L. Zhang, “MACAM: a media access protocol for

wireless LAN”, http://nms.lcs.mit.edu/6829-papers/macaw.ps.gz. [64] B. Lamparter, M. Plaggemeier, D. Westhoff, “Estimating the value of co-operation approaches for

multi-hop ad hoc networks”, Ah Hoc Networks 3 (2005) 17-2 [65] H. Ellarg, “Improving TCP performance over mobile networks”, ACM Computing Surverys 34(3)

(2002) 357 – 374. [66] S. Sherry, G. Mey, “Protocol analysis for triggered RIP”, RFC 2092, January 1997 [67] OSPF protocol analysis, RFC 1245 [68] The Network Simulator - ns-2. http://www.isi.edu/nsnam/ns/index.html. [69] J. Broch, D. A. Maltz, D. B. Johnson, Y. C. Hu, and J. Jetcheva, “A performance comparison of

multi-hop wireless ad hoc network routing protocols”, in Proceedings of the Fourth Annual ACM/IEEE International Conference on Mobile Computing and Networking (MOBICOM ‘98), October 1998.


90

[70] http://www.isi.edu/nsnam/vint/ Virtual Internetwork Testbed collaboration (Valid 26/04/04) [71] P. Meeneghan, D. Delaney, “An introduction to NS, Nam and OTcl scripting”,

NUIM-CS-TR-2004-05. [72] CMU monarch project. http://www.monarch.cs.rice.edu/ [73] DSR in NS-2, http://www.winlab.rutgers.edu/~zhibinwu/html/DSR_ns2.html. [74] R.Ogier, F. Templine, M. Lewis, “Topology dissemination based on reverse-path forwarding

(TBTPG)”, RFC 3684, February 2004. [75] M.Conti, E. Gregori, Gaia Maselli, “Reliable and efficient forwarding in ad hoc networks”, Ad

Hoc Network. 22 October 204. Available online at www.sciencedirect.com. [76] G. Campos and G. Elias, “Performance issues of ad hoc routing protocols in a network scenario

used for videophone applications”.


91

Appendix A: Simulation Script

#Agent/UDP set packetSize_ 6000 # ====================================================================== # Define options # ====================================================================== set val(ifqlen) 50 ;# max packet in ifq set val(nn) 50 ;# number of mobilenodes set val(rp) DSR ;# routing protocol set val(chan) Channel/WirelessChannel set val(prop) Propagation/TwoRayGround set val(netif) Phy/WirelessPhy set val(mac) Mac/802_11 set val(ifq) CMUPriQueue set val(ll) LL set val(ant) Antenna/OmniAntenna set val(stop) 200 set val(x) 1000 set val(y) 1000 # ====================================================================== # Main Program # ====================================================================== #ns-random 0 # Initialize Global Variables set ns_ [new Simulator] set tracefd [open 10m-0p-20s.tr w] $ns_ trace-all $tracefd set namtrace [open 10m-0p-20s.nam w] $ns_ namtrace-all-wireless $namtrace 1000 1000 # set up topography set topo [new Topography] $topo load_flatgrid $val(x) $val(y) # Create God #create-god $val(nn) set god_ [create-god $val(nn)] # Create the specified number of mobilenodes [$val(nn)] and "attach" them # to the channel. # configure node set channel [new $val(chan)] $channel set errorProbability_ 0.0


92

$ns_ node-config -adhocRouting $val(rp) \ -llType $val(ll) \ -macType $val(mac) \ -ifqType $val(ifq) \ -ifqLen $val(ifqlen) \ -antType $val(ant) \ -propType $val(prop) \ -phyType $val(netif) \ -channel $channel \ -topoInstance $topo \ -agentTrace ON \ -routerTrace ON\ -macTrace OFF \ -movementTrace OFF for {set i 0} {$i < $val(nn) } {incr i} { set node_($i) [$ns_ node] $node_($i) random-motion 0; } # network scenario puts "Loading scenario file..." source "s-0p-20s" # Define node initial position in nam for {set i 0} {$i < $val(nn)} {incr i} { # 20 defines the node size in nam, must adjust it according to your scenario # The function must be called after mobility model is defined $ns_ initial_node_pos $node_($i) 20 } puts "Loading CBR file..." source "cbr" # Tell nodes when the simulation ends for {set i 0} {$i < $val(nn) } {incr i} { $ns_ at $val(stop).0 "$node_($i) reset"; } $ns_ at $val(stop).0 "stop" $ns_ at $val(stop).01 "puts \"NS EXITING...\" ; $ns_ halt" proc stop {} { global ns_ tracefd namtrace $ns_ flush-trace close $tracefd close $namtrace } puts "Starting Simulation..." $ns_ run

Secure Forwarding in Personal Ad Hoc Networks

Documents

Transcript of Secure Forwarding in Personal Ad Hoc Networks