The American University in Cairo

School of Sciences and Engineering

Reputed Authenticated Routing for Ad Hoc Networks

Protocol (Reputed-ARAN)

A Thesis Submitted to

The Department of Computer Science

In partial fulfillment of the requirements for the degree of

Master of Science in Computer Science

By

Abdalla Ahmed Fekry Mahmoud

Bachelor of Science, Computer Science, AUC

Under the supervision of

Dr. Ahmed Sameh Dr. Sherif El-Kassas

May, 2005
 The American University in Cairo
Reputed Authenticated Routing for Ad Hoc Networks Protocol
(Reputed-ARAN)
A Thesis Submitted by Abdalla Ahmed Fekry Mahmoud
to Department of Computer Science
May 2005
in partial fulfillment of the requirements for
the degree of Master of Science
has been approved by

Dr. Ahmed Sameh

Thesis Committee Chair/Advisor__________________________________________
Affiliation ________________________________________________________

Dr. Sherif El-Kassas

Thesis Committee Chair/Advisor_______________________________________
Affiliation ________________________________________________________

Dr. Mohy Mahmoud

Thesis Committee Reader/Examiner_______________________________________
Affiliation ________________________________________________________

Dr. Awad Khalil

Thesis Committee Reader/Examiner_______________________________________
Affiliation ________________________________________________________

Dr. Gamal Darwish

Thesis Committee Reader/Examiner_______________________________________
Affiliation ________________________________________________________

___________________ _____________ ____________________ _______________

Department Chair/ Date Dean Date
Program Director

ii
To my Family and Friends

iii
 DEDICATIONS AND ACKNOWLEDGEMENTS

Writing this thesis work was a draining task. It has given me a new insight into how

all of those stacks of theses found at The American University in Cairo library actually got

there. Those theses represent not only the work of their authors, but also of all the

reviewers and advisors who play a role in that long trail from thesis topic selection to its

completion. Having accomplished this research work, I hope that I have succeeded in

adding to the field of Mobile Ad Hoc Networks and now I am looking forward to having

my spare time back to myself again.

First, I must thank Allah for helping me and giving me the strength and patience to

complete this work.

Also, I would like to express my deep gratitude to my parents, my sister, Rasha, and

my brother, Mohamed. Most importantly, I would like to dedicate special thanks to my

lovely and always caring mother who has supported me all the way, tolerated me during

my studies and always kept me on the right track. Without her constant pressure, this work

would not exist.

Special thanks go to my uncle, Mohamed Fawzi, who has always worked as my

counselor throughout my lifetime. He made me believe that I can ace it. Wished you were

here to see me finishing my thesis work!

In addition, I would like to pass many thanks and respect to my first supervisor, Dr.

Ahmed Sameh, for his patience and careful review of my thesis work, and his many

helpful corrections and comments.

Also, many thanks go to my second supervisor, Dr. Sherif El-Kassas, for his

inspirational thoughts, valuable guidance and assistance throughout this work.

iv
 Besides, I had the pleasure to have Dr. Awad Khalil and Dr. Mohy Mahmoud as my

thesis committee members. I would really like to thank them for all the time and effort they

have provided me with.

In the meantime, I had the honor to have Dr. Gamal Darwish as my external

examiner. I would really like to thank him for all his time and effort.

Many thanks go to Dr. Elizabeth Belding-Royer and Miss Kimaya Sanzgiri,

University of California, Santa Barbara, USA for their help and support during my work

with the AODV and ARAN routing protocols.

Furthermore, I can not forget all the encouragements shown by my friends: Ayyat,

Sherif, Jawish, Hatim, Riham, Omar and Rifai. They have always encouraged me to finish

my thesis work. I would really like to thank them a lot.

I would like also to devote special thanks and admiration to my best friend and twin

brother, Khaled, for his continuous support and mentoring throughout my academic and

personal life.

Finally, my greatest debt is to my fiancée, Lilia, for her enduring love, support and

forbearance during my thesis work and for her lengthy exposure to more than she ever

wanted to know about mobile ad hoc networks.

v
 ABSTRACT

A mobile ad hoc network (MANET) is a spontaneous network that can be

established with no fixed infrastructure. This means that all its nodes behave as routers and

take part in its discovery and maintenance of routes to other nodes in the network.

Its routing protocol has to be able to cope with the new challenges that a MANET creates

such as nodes mobility, security maintenance, quality of service, limited bandwidth and

limited power supply. These challenges set new demands on MANET routing protocols.

With the increasing interest in MANETs, there has been a greater focus on the

subject of securing such networks. Out of the many discussions and research groups

discussing the different security issues in the field of mobile ad hoc networks, many papers

have been written describing different proposed secure routing protocols that defend

against malicious nodes’ attacks that MANETs face. However, the majority of these

MANET secure routing protocols did not provide a complete solution for all the

MANETs’ attacks and assumed that any node participating in the MANET is not selfish

and that it will cooperate to support different network functionalities.

Recently, researchers started to study selfish nodes and their effects on mobile ad hoc

networks. That resulted in creating a new thread of research in the MANET field. A

number of research papers discussing different cooperation enforcement schemes for

detecting and defending against selfish nodes and their disturbance to mobile ad hoc

networks were published. Still none of these proposed cooperation enforcement schemes

were based on any existing MANET secure routing protocols. All of these proposed

schemes were based on routing protocols with no security measures at all.

My research strategy is to choose one of the secure routing protocols according to its

security-effectiveness, study it and analyze its functionality and performance. The

vi
authenticated routing for ad hoc networks (ARAN) secure routing protocol was chosen for

analysis. Then, the different existing cooperation enforcement schemes were surveyed so

that to come up with a reputation-based scheme to integrate with the ARAN protocol. The

result of that integration is called: Reputed-ARAN. Consequently, Reputed-ARAN is

capable of handling both selfish and malicious nodes’ attacks. Also, the Glomosim

simulation package was chosen to carry out the experimental part of this thesis work. The

results of the experiments showed that in the presence of 30% selfish nodes and with node

mobility of 10 m/s, the newly proposed Reputed-ARAN protocol improves network

throughput to 63.1%, from 38.8% network throughput provided by normal ARAN. This

improvement is obtained at the cost of a higher overhead percentage with minimal increase

in the average number of hops. The main contribution in this thesis: Reputed-ARAN

proves to be more efficient and more secure than normal ARAN secure routing protocol in

defending against both malicious and authenticated selfish nodes.

vii
 Table of Contents

1. CHAPTER ONE: INTRODUCTION 1

1.1 WIRELESS NETWORKING INTRODUCTION 1
1.2 OVERVIEW OF MOBILE AD HOC NETWORKS 3
1.3 MOBILE AD HOC NETWORKS’ USAGES 3
1.4 MOBILE AD HOC NETWORKS’ CHARACTERISTICS AND CHALLENGES 4
1.5 PROBLEM DEFINITION 5
1.6 THE SCOPE OF THE RESEARCH 6
1.7 ORGANIZATION OF THE THESIS 7
2. CHAPTER TWO: ROUTING PROTOCOLS’ OVERVIEW 8
2.1 TRADITIONAL ROUTING PROTOCOLS OVERVIEW 8
2.1.1 Distance vector 8
2.1.2 Flooding 8
2.1.3 Link state routing 9
2.2 ROUTING IN A MANET 9
2.2.1 Proactive and Reactive Routing Protocols 10
2.2.2 Ad Hoc Networks’ Routing Protocols list 11
2.3 SUMMARY 12
3. CHAPTER THREE: SECURITY ISSUES IN MANETS AND THE ARAN PROTOCOL 13
3.1 INTRODUCTION 13
3.2 ATTACKS TARGETING ROUTING PROTOCOLS 13
3.2.1 Active and Passive Attacks 14
3.2.2 Malicious and Selfish Nodes in MANETs 14
3.2.3 Routing Protocols’ Security Requirements 17
3.3 SECURE AD HOC ROUTING PROTOCOLS 18
3.4 AUTHENTICATED ROUTING FOR AD HOC NETWORKS PROTOCOL (ARAN) 19
3.4.1 Introduction 19
3.4.2 Authenticated Routing for Ad Hoc Networks 20
3.4.2.1 Certification Process 20
3.4.2.2 Authenticated Route Discovery 21
3.4.2.3 Authenticated Route Setup 24
3.4.2.4 Route Maintenance 27
3.4.2.5 Key Revocation 27
3.5 ARAN SECURITY ANALYSIS 28
3.5.1 Malicious attacks defended by ARAN 28
3.5.2 ARAN and Selfish node weakness 29
3.6 SUMMARY 30
4. CHAPTER FOUR: COOPERATION ENFORCEMENT SCHEMES 31
4.1 INTRODUCTION 31
4.2 COOPERATION SCHEMES 31
4.3 VIRTUAL CURRENCY-BASED SCHEMES 32
4.3.1 Nuglets 32
4.3.2 Sprite 33
4.3.3 Virtual Currency-based Schemes’ Shortcomings 34
4.4 REPUTATION-BASED SCHEMES 34
4.4.1 Confidant 34
4.4.2 Core 37
4.4.3 Ocean 38
4.4.4 Reputation Systems implementation Issues 40
4.4.4.1 The assignment of initial reputation values 40
4.4.4.2 The calculation of reputation values 40
4.4.4.3 The update of reputation values 41
4.4.4.4 The detection of misbehavior 42

viii
 4.4.4.5 The reaction to uncooperative behavior 43
4.5 THE CHOICE OF COOPERATION ENFORCEMENT SCHEME 43
4.6 SUMMARY 43
5. CHAPTER FIVE: THE PROPOSED REPUTATION-BASED SCHEME: REPUTED-ARAN
44
5.1 INTRODUCTION 44
5.2 PROBLEM DEFINITION 44
5.3 PROPOSED REPUTATION-BASED SCHEME 45
5.3.1 Introduction 45
5.3.2 Design Requirements 46
5.3.3 Main Idea of the Reputation System 47
5.3.3.1 Route Lookup Phase 48
5.3.3.2 Data Transfer Phase 49
5.3.3.3 Reputation Phase 51
5.3.3.4 Timeout Phase 51
5.4 ANALYSIS OF THE PROPOSED REPUTED-ARAN 52
5.5 SUMMARY 54
6. CHAPTER SIX: SIMULATION ENVIRONMENTS 55
6.1 INTRODUCTION 55
6.1.1 OPNET 55
6.1.2 NS2 56
6.1.3 QualNet 56
6.1.4 Glomosim 57
6.2 CHOICE OF SIMULATOR 58
6.3 SUMMARY 59
7. CHAPTER SEVEN: SIMULATION METHODOLOGY 60
7.1 INTRODUCTION 60
7.2 SIMULATION ENVIRONMENT 60
7.3 MOVEMENT AND COMMUNICATION PATTERNS 61
7.4 SELFISH NODES 61
7.5 METRICS 62
7.5.1 Network Throughput 62
7.5.2 Overhead 62
7.5.3 Average Route Acquisition Latency 63
7.5.4 Average End-to-End Delay of Data Packets 63
7.5.5 Packets Reached 63
7.6 SUMMARY 63
8. CHAPTER EIGHT: SIMULATION RESULTS 65
8.1 INTRODUCTION 65
8.2 EXPERIMENT 1: NETWORK THROUGHPUT 65
8.2.1 Objective 65
8.2.2 Results 65
8.2.3 Analysis 66
8.3 EXPERIMENT 2: OVERHEAD 68
8.3.1 Objective 68
8.3.2 Results 68
8.3.3 Analysis 69
8.4 EXPERIMENT 3: AVERAGE ROUTE ACQUISITION DELAY 69
8.4.1 Objective 69
8.4.2 Results 70
8.4.3 Analysis 70
8.5 EXPERIMENT 4: AVERAGE END-TO-END DELAY OF DATA PACKETS 71
8.5.1 Objective 71
8.5.2 Results 71
8.5.3 Analysis 72

ix
 8.6 EXPERIMENT 5: PACKETS REACHED 72
8.6.1 Objective 72
8.6.2 Results 73
8.6.3 Analysis 73
8.7 SUMMARY 75
9. CHAPTER NINE: CONCLUSION AND FUTURE WORK 76
9.1 CONCLUSION 76
9.2 FUTURE WORK 78
REFERENCES 81
APPENDIX A: LIST OF PROTOCOLS 87
PROACTIVE (TABLE DRIVEN) PROTOCOLS 87
REACTIVE (ON-DEMAND) PROTOCOLS 87
SECURITY ROUTING PROTOCOLS 88
APPENDIX B: LIST OF ARAN’S FUNCTIONS WITH DOCUMENTATION 90
APPENDIX C: PSEUDO CODE OF REPUTED-ARAN 97
ROUTE LOOKUP PHASE 97
DATA TRANSFER PHASE 98
REPUTATION PHASE 99
TIMEOUT PHASE 99
APPENDIX D: GLOMOSIM’S CONFIGURATION FILES 100
APPENDIX E: GLOMOSIM’S APPLICATION CONFIGURATION FILE 111
APPENDIX F: DIFFERENT SIMULATION AND LINUX SCRIPTS 113
ARAN-MAIN-SCRIPT.SH 113
ARAN-SCRIPT-FOR-20-NODES-20SELFISH.SH 113
20-10-ARAN-STAT#1.TXT 114
NETWORK THROUGHPUT.SH 115
NETWORK-THROUGHPUT.AWK 116
OVERHEAD-BYTES.SH 116
OVERHEAD-BYTES.AWK 116
OVERHEAD-PACKETS.SH 117
OVERHEAD-PACKETS.AWK 117
AVERAGE-END-TO-END-DELAY.SH 117
AVERAGE-END-TO-END-DELAY.AWK 118
AVERAGE-ROUTE-ACQUISITION-DELAY.SH 118
AVERAGE-ROUTE-ACQUISITION-DELAY.AWK 118
AVERAGE-PATH-LENGTH.SH 119
AVERAGE-PATH-LENGTH.AWK 119
APPENDIX G: RANDOM NUMBER GENERATOR TO DESIGNATE SELFISH NODES 120

x
 List of Figures

FIGURE 1.1: INFRASTRUCTURE NETWORK................................................................................................. 2

FIGURE 1.2: AD HOC NETWORK................................................................................................................ 2
FIGURE 2.1: AD-HOC ROUTING PROTOCOLS LIST..................................................................................... 12
FIGURE 3.1: DIFFERENT SORTS OF ATTACKS [13] .................................................................................... 14
FIGURE 3.2: IMPERSONATION TO CREATE LOOPS ..................................................................................... 15
FIGURE 3.3: WORMHOLE ATTACK .......................................................................................................... 16
FIGURE 3.4: CERTIFICATION PROCESS..................................................................................................... 21
FIGURE 3.5: ROUTE DISCOVERY 1........................................................................................................... 22
FIGURE 3.6: ROUTE DISCOVERY 2........................................................................................................... 23
FIGURE 3.7: ROUTE DISCOVERY 3........................................................................................................... 24
FIGURE 3.8: ROUTE SETUP 1 ................................................................................................................... 25
FIGURE 3.9: ROUTE SETUP 2 ................................................................................................................... 25
FIGURE 3.10: ROUTE SETUP 3 ................................................................................................................. 26
FIGURE 3.11: ROUTE SETUP 4 ................................................................................................................. 26
FIGURE 3.12: ROUTE MAINTENANCE ...................................................................................................... 27
FIGURE 4.1: THE ARCHITECTURE OF SPRITE [18].................................................................................... 33
FIGURE 4.2: THE ARCHITECTURE OF CONFIDANT [20] ............................................................................ 36
FIGURE 5.1: A MANET ENVIRONMENT .................................................................................................. 49
FIGURE 5.2: BROADCASTING RDP .......................................................................................................... 49
FIGURE 5.3: REPLYING TO EACH RDP..................................................................................................... 49
FIGURE 5.4: CHOOSING THE HIGHLY-REPUTED NEXT-HOP NODE ............................................................. 50
FIGURE 5.5: SENDING DATA ACKNOWLEDGEMENT FOR EACH RECEIVED DATA PACKET ......................... 50
FIGURE 8.1: EFFECTS OF SELFISH NODES ON NETWORK THROUGHPUT ................................................... 66
FIGURE 8.2: OVERHEAD PERCENTAGE .................................................................................................... 68
FIGURE 8.3: AVERAGE ROUTE ACQUISITION DELAY............................................................................... 70
FIGURE 8.4: AVERAGE END-TO-END DELAY OF DATA PACKETS ............................................................ 71
FIGURE 8.5: PACKETS REACHED ............................................................................................................. 73

xi
 List of Tables

TABLE 2.1: PROACTIVE VERSUS REACTIVE PROTOCOLS ......................................................................... 11

TABLE 3.1: SECURE AD HOC ROUTING PROTOCOLS COMPARISON ......................................................... 19
TABLE 3.2: ARAN SECURITY ANALYSIS [15]......................................................................................... 29
TABLE 5.1: ATTACK TREE: SAVE OWN RESOURCES................................................................................. 44
TABLE 5.2: REPUTED-ARAN DEFAULT PARAMETERS ............................................................................ 48
TABLE 7.1: GENERAL SIMULATION PARAMETERS ................................................................................... 64
TABLE 8.1: EFFECT OF DIFFERENT PERCENTAGES OF SELFISH NODES ON NETWORK THROUGHPUT ........ 66
TABLE 8.2: OVERHEAD PERCENTAGE DIFFERENCE ................................................................................. 69
TABLE 8.3: AVERAGE ROUTE ACQUISITION DELAY VALUES .................................................................. 70
TABLE 8.4: AVERAGE END-TO-END DELAY OF DATA PACKETS VALUES ............................................... 72
TABLE 8.5: PACKETS REACHED VALUES................................................................................................. 73

xii
1. Chapter One: Introduction

1.1 Wireless Networking Introduction

Wireless networking is an emerging technology that allows users to access

information and services electronically, regardless of their geographic position. The use of

wireless communication between mobile users has become increasingly popular due to

recent performance advancements in computer and wireless technologies. This has led to

lower prices and higher data rates, which are the two main reasons why mobile computing

is expected to see increasingly widespread use and applications.

There are two distinct approaches for enabling wireless communications between

mobile hosts. The first approach is to use a fixed network infrastructure that provides

wireless access points. In this network, a mobile host communicates with the network

through an access point within its communication radius. When it goes out of range of one

access point, it connects with a new access point within its range and starts communicating

through it. An example of this type of network is the cellular network infrastructure. A

major problem of this approach is handoff, which tries to handle the situation when a

connection should be smoothly handed over from one access point to another access point

without noticeable delay or packet loss. Another issue is that networks based on a fixed

infrastructure are limited to places where there exist such network infrastructures. Figure

1.1 shows a simple infrastructure network with three nodes.

1
 Figure 1.1: Infrastructure Network
The second approach which is the focus of this thesis research is to form a wireless

ad hoc network among users wanting to communicate with each other with no pre-

established infrastructure. Laptops and personal digital assistants (PDAs) that

communicate directly with each other are examples of nodes in an ad hoc network. Nodes

in the ad-hoc network are often mobile, but can also consist of stationary nodes. Each of

the nodes has a wireless interface and communicates with others over either radio or

infrared channels. Figure 1.2 shows a simple ad hoc network with three nodes.

Figure 1.2: Ad Hoc Network

2
1.2 Overview of Mobile Ad Hoc Networks

A Mobile Ad Hoc Network (MANET) consists of a set of mobile hosts that carry out

basic networking functions like packet forwarding, routing, and service discovery without

the help of an established infrastructure. Nodes of an ad hoc network rely on one another in

forwarding a packet to its destination, due to the limited range of each mobile host’s

wireless transmissions. An ad hoc network uses no centralized administration. This ensures

that the network will not cease functioning just because one of the mobile nodes moves out

of the range of the others. Nodes should be able to enter and leave the network as they

wish. Because of the limited transmitter range of the nodes, multiple hops are generally

needed to reach other nodes. Every node in an ad hoc network must be willing to forward

packets for other nodes. Thus, every node acts both as a host and as a router. The topology

of ad hoc networks varies with time as nodes move, join or leave the network. This

topological instability requires a routing protocol to run on each node to create and

maintain routes among the nodes [1].

1.3 Mobile Ad Hoc Networks’ Usages

Wireless ad-hoc networks can be deployed in areas where a wired network

infrastructure may be undesirable due to reasons such as cost or convenience. It can be

rapidly deployed to support emergency requirements, short-term needs, and coverage in

undeveloped areas. So there is a plethora of applications for wireless ad-hoc networks. As

a matter of fact, any day-to-day application such as electronic email and file transfer can be

considered to be easily deployable within an ad hoc network environment.

Also, we need not emphasize the wide range of military applications possible with ad

hoc networks. Not to mention, the technology was initially developed keeping in mind the

military applications, such as battlefield in an unknown territory where an infrastructured

3
network is almost impossible to have or maintain. In such situations, the ad hoc networks

having self-organizing capability can be effectively used where other technologies either

fail or cannot be deployed effectively. As a result, some well-known ad hoc network

applications are:

• Collaborative Work: for some business environments, the need for collaborative

computing might be more important outside office environments than inside. After

all, it is often the case where people do need to have outside meetings to cooperate

and exchange information on a given project.

• Crisis-management Applications: these arise, for example, as a result of natural

disasters where the entire communications infrastructure is in disorder. Restoring

communications quickly is essential. By using ad hoc networks, a communication

channel could be set up in hours instead of days/weeks required for wire-line

communications.

• Personal Area Networking and Bluetooth: a personal area network (PAN) is a

short- range, localized network where nodes are usually associated with a given

person. These nodes could be attached to someone’s pulse watch, belt, and so on.

In these scenarios, mobility is only a major consideration when interaction among

several PANs is necessary [2].

1.4 Mobile Ad Hoc Networks’ Characteristics and Challenges

MANETs have several significant characteristics and challenges. They are as

follows:

• Dynamic topologies: Nodes are free to move arbitrarily. Thus, the network

topology may change randomly and rapidly at unpredictable times, and may

consist of both bidirectional and unidirectional links.

4
 • Bandwidth-constrained, variable capacity links: Wireless links will continue to

have significantly lower capacity than their hardwired counterparts. In addition, the

realized throughput of wireless communications, after accounting for the effects of

multiple access, fading, noise, and interference conditions, is often much less than

a radio's maximum transmission rate.

• Energy-constrained operation: Some or all of the nodes in a MANET may rely on

batteries or other exhaustible means for their energy. For these nodes, the most

important system design optimization criteria may be energy conservation.

• Security: Mobile wireless networks are generally more prone to physical security

threats than fixed-cable nets. The increased possibility of eavesdropping, spoofing,

selfish behavior and denial-of-service attacks should be carefully considered.

These characteristics and challenges create a set of underlying assumptions and

performance concerns for protocol design which extend beyond those guiding the design

of routing within the higher-speed, semi-static topology of the fixed Internet.

1.5 Problem Definition

In the field of mobile ad hoc networks routing protocols, there are lot of problems to

be tackled such as Quality of service, power awareness, routing optimization and security

issues. In this thesis, the main interest is in the security issues related to routing protocols in

MANETs. So, I started researching by reading about the different research directions in

this huge field and analyzed the different existing routing protocols and their various types

[10] and [41]. I ended up interested in the AODV protocol [36] and studied its source code.

Then more interest in secure routing protocols and their different mechanism in defending

against the malicious, compromised and selfish nodes in the mobile ad hoc network was

developed. Existing secure routing protocols were studied such as ARAN [35], Ariadne

5
[34], SAODV [40], SRP [38] and others [37] [39]. Then, the decision to work with the

ARAN protocol was taken after having read many papers about it, getting in contact with

its author and doing some comparisons and analysis with other secure routing protocols.

The ARAN protocol was observed to defend almost against all security attacks in

MANETs. However, by doing more research in the field of MANETs, one major flaw in

any of the existing secure routing protocols was discovered. This is that all of these secure

routing protocols do not account for selfish nodes whether by detecting or isolating them

from the network. So I decided to read about the different types of cooperation

enforcement schemes in mobile ad hoc networks and then to design and integrate a

reputation-based scheme with the ARAN routing protocol to end up with Reputed-ARAN

that is capable of defending itself against both malicious and authenticated selfish nodes.

1.6 The Scope of the Research

The current existing Authenticated Routing for Ad Hoc Networks (ARAN) secure

routing protocol is capable of defending itself against most malicious nodes and their

different attacks. However, ARAN is not capable of defending itself against any

authenticated selfish node participating in the network. Therefore, the objective of my

thesis is to make the Authenticated Routing for Ad Hoc Networks secure routing protocol

capable of defending itself against authenticated selfish nodes participating in the mobile

ad hoc network. The resulting new protocol is called Reputed-ARAN. This work is done

by integrating a reputation-based scheme, to detect, punish and isolate selfish nodes, to

currently existing ARAN protocol and then measuring the effectiveness of that integration.

6
1.7 Organization of the Thesis

The thesis is organized as follows: The subsequent chapter introduces the subject of

routing, its different techniques, existing routing protocols and their categories. Chapter 3

addresses security issues in MANET routing protocols and presents the ARAN routing

protocol that will be modified. As for chapter 4, an extensive account of the existing

cooperation enforcement schemes and their different types, and a comparison of the best

design methodologies of reputation systems are given. Chapter 5 will present the newly

proposed and designed reputation-based scheme, Reputed-ARAN. Then, in chapter 6, a

discussion about the different simulation environments and choice of one of them is

presented. Chapter 7 then presents the used simulation environment, the different

simulation parameters that are set and a definition of the various metrics that are measured

in the simulations is given. Later on in chapter 8, the simulation results showing that the

network throughput of the newly proposed Reputed-ARAN is higher than normal ARAN

in the presence of different percentages of selfish nodes are presented. Last but not least, in

chapter 9, a conclusion about the proposed work is drawn and future work that can be

added to the proposed thesis work in particular and to the field of mobile ad hoc networks

in general is mentioned.

7
2. Chapter Two: Routing Protocols’ Overview

2.1 Traditional Routing Protocols Overview

To understand routing principles in a MANET, it is a good idea to take a look at

conventional routing algorithms such as distance vector, link state, flooding and source

routing. This is because many of the routing protocols for a MANET have roots in

traditional routing concept as underlying algorithm.

2.1.1 Distance vector

The distance vector technique [3], [4] is based on that every node maintains a

forwarding table with the best route to every node in a network. In a certain time interval

the information is sent to every neighboring node in the network. These nodes then

conduct a comparison between their own routing table and the received one. If the distance

between any nodes in the received table is smaller compared to the one at hand, the node

updates the routing table with the new value. If the value that is in the forwarding table is

from the node that now is sending a new value, the node updates the forwarding table

regardless of if the value is bigger than the existing one. This procedure is continuous so

that each and every node has an updated forwarding table with the shortest path to all

nodes in the network.

2.1.2 Flooding

With this technique every packet is sent to every node in the network and is

broadcasted by the receiving nodes exactly once [5]. Each node receiving the packet

broadcasts it to every neighboring node, except the one it received it from. These,

neighboring nodes, in term do the same and so on. To avoid retransmitting the same packet

twice every packet is tagged with a source address and a sequence number which serve as

8
a unique identifier. With these identifiers each node keeps track of which packets they have

transmitted.

This approach has a very high consumption of network resources since every packet

is sent to every possible node to ensure that the packet arrives to its destination. On the

other hand it results in an extremely high delivery ratio.

2.1.3 Link state routing

Link state routing [5], [6] works almost like distance vector when it comes to the

usage of a forwarding table. What differentiates them is how the table is updated. Link

state generates its table so that every node keeps a map over the nodes in the network.

From this map every node can use a shortest path algorithm to decide which way is the

shortest to each destination and hence know what the next hop should be in the forwarding

table.

When there is a change in the network, for example a node connects or disconnects,

a message is sent throughout the network to announce the change. The message is called a

link state advertisement (LSA) and is passed through the network by flooding. All nodes

receive the message and update their maps accordingly. If this method is compared with

the method used in distance vector, it makes link state routing more reliable, easier to

detect errors and consume less bandwidth. This is because link state routing uses event-

triggered updates instead of periodic updates as in distance vector.

2.2 Routing in a MANET

It has become clear that routing in a MANET is fundamentally different from

traditional routing found on infrastructured networks. Routing in a MANET depends on

many factors including topology, selection of routers, initiation of request and specific

underlying characteristic that could serve as a heuristic in finding the path quickly and

9
efficiently. The low resource availability in these networks demands efficient utilization

and hence the motivation for optimal routing in ad hoc networks. Also, the highly dynamic

nature of these networks imposes severe restrictions on routing protocols specifically

designed for them, thus motivating the study of protocols which aim at achieving routing

stability.

One of the major challenges in designing a routing protocol [7] for ad hoc networks

stems from the fact that, on one hand, a node needs to know at least the reachability

information to its neighbors for determining a packet route and, on the other hand,

the network topology can change quite often in an ad hoc network. Furthermore, as the

number of network nodes can be large, finding route to the destinations also requires large

and frequent exchange of routing control information among the nodes. Thus, the amount

of update traffic can be quite high, and it is even higher when high mobility nodes are

present. High mobility nodes can impact route maintenance overhead of routing protocols

in such a way that no bandwidth might remain leftover for the transmission of data packets

[8].

2.2.1 Proactive and Reactive Routing Protocols

Ad hoc routing protocols can be broadly classified as being Proactive (or table-

driven) or Reactive (on-demand). In a proactive routing protocol, all the routes to each

destination are kept in an up-to-date table. Changes in the network topology are continually

updated as they occur. In the reactive routing protocol, a connection between two nodes is

only created when it is asked for by a source. When a route is found, it is kept by a route

maintenance procedure until the destination no longer exists or is needed [9]. The

following tabular present a comparison between proactive and reactive routing protocols:

10
 Protocol Proactive Reactive

Points(+/-)

Advantages o A route can be selected o Lower bandwidth is

immediately without used for maintaining

delay. routing tables.

o More energy-efficient.

o Effective route

maintenance.

Disadvantages o Produces more control o Have higher latencies

traffic. when it comes to route

o Takes a lot of discovery.

bandwidth.

o Produces network

congestion.

Table 2.1: Proactive versus Reactive Protocols

In brief, a conclusion can be drawn that no protocol is suited for all possible

environments, while some proposals using a hybrid approach have been suggested.

2.2.2 Ad Hoc Networks’ Routing Protocols list

During the research, a list of every proactive, reactive and secure routing protocol

was compiled. The detailed list can be found in Appendix A. It is a fact that this list does

not cover every routing protocol that exists as there are so many new and different

variations of protocols being developed all the time. Enough time was spent for compiling

this list and reading about the various protocols to get a clear picture about their functions,

advantages, disadvantages in order to choose one for this thesis research. The list of

protocols that was collected [10] is shown in figure 2.1.

11
 Figure 2.1: Ad-hoc routing protocols List
In addition, within this period of research, a thorough look at security aspects was

accomplished. That resulted in finding several different security protocols that solve

different security threats. Some of them were stand-alone protocols and other worked

together with a routing protocol, all depending on their functionality. These protocols were

added to the presented list as well, for more see appendix A. In the next chapter, a

discussion about the different security threats to MANETs will be given and one of the

secure routing protocols will be delved into.

2.3 Summary

In this chapter, a discussion about existing routing protocols, the mobile ad hoc

networks routing protocols’ two types and their advantages and disadvantages was

presented. Then, a list of existing proactive, reactive and secure MANET routing protocols

was given.

12
3. Chapter Three: Security Issues in MANETs and the ARAN protocol

3.1 Introduction

Security in MANET is an essential component for basic network functionalities

like packet forwarding and routing. Network operation can be easily jeopardized if

security countermeasures are not embedded into basic network functions at the early

stages of their design. In mobile ad hoc networks, network basic functions like packet

forwarding, routing and network management are performed by all nodes instead of

dedicated ones. In fact, the security problems specific to a mobile ad hoc network can be

traced back to this very difference. Instead of using dedicated nodes for the execution of

critical network functions, one has to find other ways to solve this because the nodes of a

mobile ad hoc network can not be trusted in this way [11]. In the following section, the

different types of attacks in MANETs will be presented.

3.2 Attacks targeting Routing Protocols

There are basically two types of security threats to a routing protocol, external and

internal attackers [12]. An external attacker can be in the form of an adversary who injects

erroneous information into the network and cause the routing to stop functioning properly.

The internal attacker is a node that has been compromised, which might feed other nodes

with incorrect information. Figure 3.1 illustrates the different attacks that can be made

towards a network [13].

13
 Figure 3.1: Different sorts of attacks [13]
3.2.1 Active and Passive Attacks

Security exposures of ad hoc routing protocols are due to two different types

of attacks: active and passive attacks. In active attacks, the misbehaving node has to

bear some energy costs in order to perform some harmful operation. In passive attacks,

it is mainly about lack of cooperation with the purpose of energy saving. Nodes that

perform active attacks with the aim of damaging other nodes by causing network

outage are considered to be malicious while nodes that perform passive attacks with

the aim of saving battery life for their own communications are considered to be

selfish.

3.2.2 Malicious and Selfish Nodes in MANETs

Malicious nodes can disrupt the correct functioning of a routing protocol by

modifying routing information, by fabricating false routing information and by

impersonating other nodes. On the other side, selfish nodes can severely degrade

network performances and eventually partition the network by simply not participating

in the network operation [14].

14
 In existing ad hoc routing protocols, nodes are trusted in that they do not

maliciously tamper with the content of protocol messages transferred among nodes.

Malicious nodes can easily perpetrate integrity attacks by simply altering protocol fields

in order to subvert traffic, deny communication to legitimate nodes (denial of

service) and compromise the integrity of routing computations in general. As a result

the attacker can cause network traffic to be dropped, redirected to a different destination

or to take a longer route to the destination increasing communication delays.

A special case of integrity attacks is spoofing whereby a malicious node

impersonates a legitimate node due to the lack of authentication in the current ad hoc

routing protocols. The main result of spoofing attacks is the misrepresentation of the

network topology that possibly causes network loops or partitioning.

A D A D
M
M
B C E X B C E X

A D

M
B C E X

Figure 3.2: Impersonation to create loops

In the above figure, a malicious attacker, M, can form a routing loop so that none of

the four nodes can reach the destination. To start the attack, M changes its MAC address to

match A’s, moves closer to B and out of the range of A. It then sends an RREP to B that

contains a hop count to X that is less than the one sent by C, for example zero. B therefore

changes its route to the destination, X, to go through A. M then changes its MAC address

to match B’s, moves closer to C and out of range of B, and then sends to C an RREP with

a hop count to X lower than what was advertised by E. C then routes to X through B. At

this point a loop is formed and X is unreachable from the four nodes.

15
 Lack of integrity and authentication in routing protocols can further be exploited

through “fabrication” referring to the generation of bogus routing messages. Fabrication

attacks cannot be detected without strong authentication means and can cause severe

problems ranging from denial of service to route subversion.

A more subtle type of active attack is the creation of a tunnel (or wormhole) in

the network between two colluding malicious nodes linked through a private

connection bypassing the network. This exploit allows a node to short-circuit the

normal flow of routing messages creating a virtual vertex cut in the network that is

controlled by the two colluding attackers.

Falsely
tunneled path
M1 M2

Encap Decap

S A B C D

Figure 3.3: Wormhole Attack

In the above figure, M1 and M2 are malicious nodes collaborating to misrepresent

available path lengths by tunneling route request packets. Solid lines denote actual paths

between nodes, the thin line denotes the tunnel, and the dotted line denotes the path that

M1 and M2 falsely claim is between them. Let us say that node S wishes to form a route to

D and initiates route discovery. When M1 receives a RDP from S, M1 encapsulates the

RDP and tunnels it to M2 through an existing data route, in this case {M1->A->B->C-

>M2}. When M2 receives the encapsulated RDP, it forwards the RDP on to D as if it had

only traveled {S->M1->M2->D}. Neither M1 nor M2 update the packet header to reflect

that the RDP also traveled the path {A->B->C}. After route discovery, it appears to the

destination that there are two routes from S of unequal length: {S->A->B->C->D} and {S-

16
>M1->M2->D}. If M2 tunnels the RREP back to M1, S would falsely consider the path to

D via M1 a better choice (in terms of path length) than the path to D via A.

Another exposure of current ad hoc routing protocols is due to node selfishness that

results in lack of cooperation among ad hoc nodes. A selfish node that wants to save

battery life, CPU cycles and bandwidth for its own communication can endanger the

correct network operation by simply not participating in the routing protocol or by not

forwarding packets and dropping them whether control or data packets. This type of

attack is called the black-hole attack. Current Ad Hoc routing protocols do not address

the selfishness problem and assumes that all nodes in the MANET will cooperate to

provide the required network functionalities.

3.2.3 Routing Protocols’ Security Requirements

To solve the security issue in an ad hoc network and make it secure we have to

look at a number of requirements that have to be achieved. These requirements are:

availability, confidentiality, integrity, authentication and non-repudiation [12].

• Availability: the network must at all times be available to send and receive

messages despite if it is under attack. An attack can be in the form of a denial of

service or an employed jamming to interfere with the communication. Other

possible threats to the availability are if an attacker disrupts the routing protocol or

some other high-level service and disconnects the network. The node itself can also

be the problem to availability. This is if the node is selfish and will not provide its

services for the benefit of other nodes in order to save its own resources like,

battery power.

• Confidentiality: provides secrecy to sensitive material being sent over the network.

This is especially important in a military scenario where strategic and tactical

17
 information is sent. If this information would fall into enemy hands it could have

devastating ramifications.

• Integrity: ensures that messages being sent over the network are not corrupted.

Possible attacks that would compromise the integrity are malicious attacks on the

network or benign failures in the form of radio signal failures.

• Authentication: ensures the identity of the nodes in the network. If A is sending to

B, A knows that it is B who is receiving the message. Also B knows that it is A

who is sending the message. If the authentication is not working, it is possible for

an outsider to masquerade a node and then be able to send and receive messages

without anybody noticing it, thus gaining access to sensitive information.

• Non-repudiation: makes it possible for a receiving node to identify another node as

the origin of a message. The sender can not deny having sent the message and are

therefore responsible for its contents. It is particularly useful for detection of

compromised nodes.

However, because there are so many threats to protect from [49], there can not be a

general solution to them all. Also different applications will have different security

requirements to take into consideration. As a result of this diversity, many different

approaches have been made which focus on different parts of the problems. In the coming

section, a comparison of some of the existing secure mobile ad hoc routing protocols with

respect to most of the fundamental performance parameters will be given.

3.3 Secure Ad Hoc Routing Protocols

Throughout the exhaustive research and readings in the field of mobile ad hoc

networks and the many security challenges and issues related to their routing protocols,

analysis of various secure routing protocols proposed in the literature has been performed.

18
As a result, in the following table, a comparison between some of the most–established

secure routing protocols with respect to some performance and security parameters is

given so that to facilitate the choice of one of them to work on:

Protocol ARAN [35] ARIADNE [34] SAODV[40] SEAD [37] SRP [38]
Performance
Parameters
Type Reactive Reactive Reactive Proactive Reactive
Encryption Asymmetric Symmetric Asymmetric Symmetric Symmetric
Algorithm
MANET Protocol AODV/DSR DSR AODV DSDV DSR/ZRP
Synchronization No Yes No Yes No
Central Trust Certificate Key Distribution CA CA CA
Authority Authority (CA) Center (KDC) Required Required Required
Required Required
Authentication Yes Yes Yes Yes Yes
Confidentiality Yes No No No No
Integrity Yes Yes Yes No Yes
Non-Repudiation Yes No Yes No No
Anti-Spoofing Yes Yes Yes No Yes
DoS Attacks No Yes No Yes Yes
Table 3.1: Secure Ad Hoc Routing Protocols Comparison
As a result of this comparison, I ended up choosing to work with Authenticated

Routing for Ad Hoc Networks Protocol (ARAN) as the selected secure routing protocol. In

the following section, it will be shown how this ARAN protocol was built based upon the

early above mentioned security requirements in its design and implementation.

3.4 Authenticated Routing for Ad Hoc Networks Protocol (ARAN)

3.4.1 Introduction

In this section, one of the secure mobile ad hoc networks protocols, which is

Authenticated routing for ad hoc networks (ARAN) is analyzed. Such protocol is classified

as a secure reactive routing protocol, which is based on some type of query-reply dialog.

That means ARAN does not attempt to continuously maintain the up-to-date topology of

the network, but rather when there is a need, it invokes a function to find a route to the

19
destination. In the following subsections, the details of the different phases of the ARAN

secure routing protocol are presented. Furthermore, appendix B presents documentation

for all the functions of ARAN secure mobile ad hoc network routing protocol.

3.4.2 Authenticated Routing for Ad Hoc Networks

The ARAN secure routing protocol proposed by Sanzgiri, Laflamme, Dahill,

Levine, Shields and Belding-Royer [35] uses cryptographic certificates to prevent and

detect most of the security attacks that most of the ad hoc routing protocols face. This

protocol introduces authentication, message integrity and non-repudiation as part of a

minimal security policy for the ad hoc environment.

ARAN consists of a preliminary certification process followed by a route

instantiation process that guarantees end-to-end authentication. Thus, the routing messages

are authenticated end-to-end and only authorized nodes participate at each hop between

source and destination.

3.4.2.1 Certification Process

ARAN requires the uses of a trusted certificate server T, whose public key is known

to all valid nodes. Keys are pre-generated and exchanged through an existing out of band

relationship between T and each node. Before joining the ad hoc network, each node must

request a certificate from T. Each node receives exactly one certificate after securely

authenticating their identity to T. So a node A receives a certificate from T as follows:

T ->A:certA = [IPA,KA+,t,e]KT-

20
 Public Key A
IP Address A
Create Time
Expiry Time
Signature by T

Certificate A Certificate B Certificate C Certificate D

A B C D

Trusted certificate server T

Figure 3.4: Certification Process

The certificate contains the IP address of A, the public key of A (KA+), a timestamp t

of when the certificate was created (t) and a time (e) at which the certificate expires. These

variables are concatenated and signed by T (KT-). Nodes use these certificates to

authenticate themselves to other nodes during routing messages exchange [11].

3.4.2.2 Authenticated Route Discovery

The goal of end-to-end authentication is for the source to verify that the intended

destination was reached. The source trusts the destination to select the return path. The

source node, A, begins route instantiation to destination D by broadcasting to its neighbors

a route discovery packet (RDP):

A->brdcast:[RDP,IPD,NA]KA-,certA

21
 IP Address D
Certificate A Initial RDP packet
Nonce A
Create Time
Signature by A

RDP: A -> D

A B C D

Figure 3.5: Route Discovery 1

The RDP includes a packet type identifier (“RDP”), the IP address of the destination

D (IPD), a nonce (NA), A’s certificate (certA) and all signed by A’s private key (KA-). The

purpose of the nonce is to uniquely identify an RDP coming from a source. Each time A

performs route discovery, it monotonically increases the nonce. This nonce variable is

large enough so that not to need to be recycled throughout the lifetime of the network.

When a node receives an RDP message, it setups up a reverse path back to the

source by recording the neighbor from which it received the RDP. Therefore, it is ready,

upon receiving a reply message, to forward back to the source. Furthermore, the receiving

nodes uses A’s public key, which it extracts from A’s certificate, to validate the signature

and verify that A’s certificate has not expired. And it also checks the {NA, IPA} tuple to

verify that it has not already processed this RDP, since nodes do not forward messages

with already-seen tuples.

Then the receiving node signs the content of the message, appends its own certificate

and broadcasts the message to each of its neighbors. The signature prevents spoofing

attacks that may alter the route or form loops.

22
 Let B be a neighbor that has received from A the RDP broadcast, which it

subsequently rebroadcasts:

B->brdcast:[[RDP,IPD,NA]KA-],KB-,certA, certB

Intermediate RDP Packet

RDP: A -> D

Signature by B

Certificate B

RDP: A -> D
verified
A B C D

Figure 3.6: Route Discovery 2

Upon receiving the RDP, B’s neighbor C validates the signatures for both A, the

RDP initiator, and B, the neighbor it received the RDP from, using the certificates in the

RDP. C then removes B’s certificate and signature, records B as its predecessor, signs the

contents of the messages originally broadcast by A and appends its own certificate. C then

rebroadcast the RDP:

C->brdcast:[[RDP,IPX,NA]KA-]KC-,certA, certC

23
 RDP: A -> D

Signature by C
Certificate C

RDP: A -> D
verified verified
A B C D

Figure 3.7: Route Discovery 3

Each intermediate node in the path repeats the same steps as C [15].

3.4.2.3 Authenticated Route Setup

Afterwards, the message is received by the destination, D, who replies to the first

RDP that it receives for a source and a given nonce. There is no guarantee that the first

RDP received traveled along the shortest path from the source. Because RDPs do not

contain a hop count or specific recorded source route and since messages are signed at

each hop, malicious nodes have no opportunity to redirect the traffic. So by receiving the

RDP, the destination unicasts a Route Reply (RREP) packet back along the reverse path to

the source. Let the first node that receives the RREP sent by D to be node C:

D->C:[RREP,IPA,NA]KD-,certD

24
 IP Address A
Initial RREP packet
Certificate D
Nonce A
Create Time
RREP: A->D
Signature by D

verified verified verified

A B C D

*Replies to first RDP packet*

Figure 3.8: Route Setup 1

The route reply includes a packet type identifier (“RREP”), the IP address of A, the

nonce sent by A, the D’s certificate and all signed by D’s private key, KD-. Nodes that

receive the RREP forward the packet back to the predecessor from which they received the

original RDP. Each node along the reverse path back to the source signs the RREP and

appends its own certificate before forwarding the RREP to the next hop. Now let C’s next

hop to the source be node B: C->B:[[RREP,IPA,NA]KD-]KC-,certD,certC

Intermediate RREP Packet

RREP: A -> D
Signature by C
Certificate C

RREP: A->D
verified

verified verified verified

A B C D

Figure 3.9: Route Setup 2

25
 B validates C’s signature on the received message, removes the signature and

certificate, and then signs the contents of the message and appends its own certificate

before unicasting the RREP to A:

B->A:[[RREP,IPA,NA]KD-]KB-,certD,certB

RREP: A -> D
Signature by B

Certificate B

RREP: A->D
verified verified

verified verified verified

A B C D

Figure 3.10: Route Setup 3

Each node checks the nonce and signature of the previous hop as the RREP is

returned to the source. This avoids the attacks where malicious nodes instantiate routes by

impersonation and replay D’s message. Finally, when the source receives the RREP, it

verifies the destination’s signature and the nonce returned by the destination [15].

verified verified verified

verified verified verified

A B C D

Figure 3.11: Route Setup 4

26
3.4.2.4 Route Maintenance

When no traffic has occurred on an existing route for that route’s lifetime, the route is

simply deactivated in the routing table. Data received on an inactive route causes nodes to

generate a Route Error (RERR) message. Also, nodes use RERR messages to report links

in active routes that are broken due to node movement. Of course, all RERR messages are

signed.

IP Address A
IP Address D
Certificate C
Nonce C
Create Time
Signature by C
RERR: A->D

A B C D
Link broken!

Figure 3.12: Route Maintenance

On the other hand, it is extremely difficult to detect when RERR messages are

fabricated for links that are truly active and not broken. That is why having messages

signed prevents impersonation and enables non-repudiation. So a node that transmits a

large number of RERR messages, whether the RERR messages are valid or fabricated

should be avoided [11].

3.4.2.5 Key Revocation

In the event that a certificate needs to be revoked, the trusted certificate server, T,

sends a broadcast message to the ad hoc network announcing the revoked node. And any

node receiving this message rebroadcasts it to its neighbors. Moreover, revocation-notices

need to be stored until the revoked certificate expire normally [11].

27
3.5 ARAN Security Analysis

3.5.1 Malicious attacks defended by ARAN

In this section, an analysis of the robustness of the Authenticated Routing for Ad Hoc

Networks in the presence of the different attacks introduced in earlier sections is given

[15]:

• Unauthorized participation: Since all ARAN packets must be signed, a node can

not participate in routing without authorization from the trusted certificate server.

This access control therefore rests in the security of the trusted authority, the

authorization mechanisms employed by the trusted authority, the strength of the

issued certificates, and the revocation mechanism.

• Spoofed Route Signaling: Route discovery packets contain the certificate of the

source node and are signed with the source's private key. Similarly, reply packets

include the destination node's certificate and signature, ensuring that only the

destination can respond to route discovery. This prevents impersonation attacks

where either the source or destination node is spoofed.

• Fabricated Routing Messages: Since all routing messages must include the sending

node's certificate and signature, ARAN ensures non-repudiation and prevents

spoofing and unauthorized participation in routing.

• Alteration of Routing Messages: ARAN specifies that all fields of RDP and RREP

packets remain unchanged between source and destination. Since both packet

types are signed by the initiating node, any alterations in transit would be detected,

and the altered packet would be subsequently discarded. Thus, modification attacks

are prevented in ARAN.

28
 • Denial-of-Service Attacks: Denial-of-service (DoS) attacks can be conducted by

nodes with or without valid ARAN certificates. In the certificate-less case, all

possible attacks are limited to the attacker's immediate neighbors because unsigned

route requests are dropped. However, nodes with valid certificates can conduct

effective DoS attacks by sending many unnecessary route requests and they will go

undetected as the current existing ARAN protocol can not differentiate between

legitimate and malicious RREQs coming from authenticated nodes.

• The below table gives a summary of the different attacks that ARAN defends

against:

Table 3.2: ARAN Security Analysis [15]

3.5.2 ARAN and Selfish node weakness

It is clear from the above mentioned security analysis of the ARAN protocol that

ARAN is a secure MANET routing protocol providing authentication, message integrity,

confidentiality and non-repudiation by using certificates infrastructure. As a consequence,

ARAN is capable of defending itself against spoofing, fabrication, modification, DoS and

disclosure attacks. However, erratic behavior can come from a malicious node, which will

be defended against successfully by existing ARAN protocol, and can also come from an

authenticated node. The currently existing ARAN secure routing protocol does not account

for attacks that are conducted by authenticated selfish nodes as these nodes trust each other

to cooperate in providing network functionalities. This results in that ARAN fails to detect

and defend against an authenticated selfish node participating in the mobile ad hoc

network. Thus, if an authenticated selfish node does not forward or intentionally drop

29
control or data packets, the current specification of ARAN routing protocol can not detect

or defend against such authenticated selfish nodes. This weakness in ARAN specification

will result in the disturbance of the ad hoc network and the waste of the network

bandwidth. In chapter 5, a solution is proposed to account for this type of attack.

3.6 Summary

In this chapter, the different types of attacks targeting MANET routing protocols

were explored and a discussion of the difference between malicious and selfish nodes and

their associated attacks was presented. Then, the fundamental requirements for designing a

secure routing protocol to defend against security breaches were mentioned. Also, a

comparison among some of the existing secure mobile ad hoc routing protocols was given.

As one of the secure routing protocols built following the fundamental secure routing

protocols design methodology, the Authenticated Routing for Ad Hoc Networks protocol

(ARAN) was presented. Afterwards, a discussion about how ARAN defends against most

of the attacks that are conducted by malicious nodes such as spoofing, fabrication,

modification and disclosure ones was given. Last but not least, it was proven that the

currently existing specification of the ARAN secure routing MANET protocol does not

defend against attacks performed by authenticated selfish nodes.

30
4. Chapter Four: Cooperation Enforcement Schemes

4.1 Introduction

Current routing protocols and the majority of secure routing protocols for mobile ad

hoc networks are based on the assumption that all nodes will cooperate. Without node

cooperation, no route can be established, no packet can be forwarded, let alone any

network applications. However, cooperative behavior such as forwarding other node’s

messages cannot be taken for granted. In this chapter, the different methods of enforcing

cooperation between nodes in mobile ad hoc networks will be discussed.

4.2 Cooperation Schemes

Schemes [46] and [47] that stimulate cooperation and mitigate the damaging effect

of uncooperative nodes in mobile ad hoc network can be classified as:

• Virtual Currency-based schemes.

• Reputation-based schemes.

On one hand, virtual currency-based schemes use some form of incentive to enforce

nodes’ cooperation. Nodes get the incentives upon serving the network and use these to

gain service from the network. If a node does not have any incentives, it will not get any

service from the network. On the other hand, reputation schemes use the nodes’ reputation

to mitigate selfish behavior. Nodes maintain the reputation of other nodes based on direct

observation or indirect observation by the exchange of reputation messages with other

nodes. The description of both schemes’ types and some examples of each will be

presented in the following sections.

31
4.3 Virtual Currency-based Schemes

Since forwarding a message will deserve a cost of energy and other resources to a

node, an uncooperative node will need an incentive in order to forward messages of other

nodes. Virtual currency-based schemes use credit or micro payments to compensate for the

service of a node. A node receives a virtual payment for forwarding the message of another

node and this payment is deducted from the sender (or the destination node). Nuglets and

Sprite schemes are considered two examples of such a virtual currency-based scheme

which are discussed below [16].

4.3.1 Nuglets

Buttyan and Hubaux introduced a virtual currency called nuglets and presented a

mechanism of charging/rewarding service usage/provision to stimulate cooperation in

self-organized mobile ad hoc network [17].

Two models were presented for using the nuglets: packet purse model, in which the

source of the packet is charged and packet trade mode, in which the destination is charged.

In the packet purse model, when sending the packet, the source loads it with a

number of nuglets sufficient to reach the destination. Each intermediate node takes some

nuglets for the forwarding service.

In the packet trade model, packets are traded for nuglets by intermediate nodes.

Each intermediary node buys the packet from the previous node for some nuglets and sells

it to the next node for more nuglets. In this way, every intermediate node gains nuglets for

forwarding and the total cost of forwarding the packet is paid by the destination node.

To implement either the packet purse model or the packet trade model, tamper-proof

hardware security module is required at each node to prevent the node from illegitimately

32
increasing its own nuglets and to ensure that the correct amount of nuglets is deducted or

credited at each node.

4.3.2 Sprite

Sprite [18] is a simple cheat-proof, credit-based system for mobile ad hoc networks.

It uses credit to provide incentives for mobile nodes to cooperate and report actions

honestly.

The basic idea of this scheme is that a Credit Clearance Service (CCS) is introduced

to determine the charge and credit to each node involved in the transmission of a message.

When a node receives a message, the node keeps a receipt of the message and later reports

it to the CCS when the node has a fast connection with the CCS. Payments and charges are

determined from a game theory perspective.

In this scheme, the sender is charged for every packet it sends. So, this scheme helps

to prevent a denial-of-service attack to the destination by sending it a large amount of

traffic as the sender will be very conservative in its usage. A node that has tried to forward

a message is compensated, but the credit that a node receives depends on whether or not its

forwarding action is successful. Forwarding is considered successful if and only if the next

node on the path reports a valid receipt to the CCS [18]. Below is an architectural figure of

the Sprite System.

Credit Clearance System

Internet
Wide-area wireless network

Figure 4.1: The Architecture of Sprite [18]

33
4.3.3 Virtual Currency-based Schemes’ Shortcomings

The basic problem with virtual currency schemes is they either depend on the use of

tamper-proof hardware to monitor the increase or decrease of the virtual currency as

Nuglets does, or require a central server to determine the charge and credit to each node

involved in the transmission of a message, as the case with Sprite. However, these two

approaches may not be appropriate for truly mobile ad hoc network scenarios. In addition,

these approaches suffer from the location privilege problem. Nodes in different locations of

the network will have different chances to earn virtual currency, which may not be fair for

all nodes. Usually, nodes at the periphery of the network will have less chance to be

rewarded [19]. Accordingly, the next subsection presents the reputation-based schemes

upon which the proposed Reputed-ARAN design is built.

4.4 Reputation-based Schemes

Reputation systems are applied to wireless mobile ad hoc network to address threats

arising from uncooperative nodes. They rely on neighbor monitoring to mitigate

selfishness and stimulate cooperation in mobile ad hoc network. In the following

subsections, a discussion of the following reputation systems: Confidant, Core and Ocean

is given.

4.4.1 Confidant

Buchegger and Boudec presented a reputation-based protocol called Confidant for

making misbehavior unattractive [20]. Confidant stands for Cooperation of Nodes:

Fairness In Dynamic Ad-hoc Network, it works as an extension to the Dynamic Source

Routing (DSR) on demand routing protocol [33].

Confidant aims at detecting and isolating uncooperative nodes so that to make it

unattractive for nodes to deny cooperation. Nodes rely on passive observation of all

34
packets within a one-hop neighborhood. With Confidant, each node has the following four

components: a monitor, a trust manager, a reputation system and a path manager. These

components interact with each other to provide and process protocol information.

• The monitor is the equivalent of a neighbor watch, where nodes locally monitor

deviating behavior. A node can detect deviation by its neighbor on the source route

by listening to the transmission of its neighbor. The monitor reports any suspicious

events and any incoming ALARM messages to the trust manager.

• The trust manager makes decisions about providing or accepting route information,

accepting a node as part of a route, or taking part in a route originated by another

node. It consists of the following components:

• An alarm table containing information about received alarms.

• A trust table managing trust levels for nodes to determine the trustworthiness of an

alarm.

• A friends list containing all the friends that the node may sends alarms to.

ALARM messages containing the type and frequency of protocol violations are sent

by the trust manager of a node to warn others of malicious nodes. Outgoing ALARM

messages are generated by the node itself after having experienced, observed, or received a

report of malicious behavior. The recipients of these ALARM messages are so-called

friends, which are administered in a friends list. The source of any Incoming ALARM

messages, originated from either outside friends or other nodes, has to be checked for

trustworthiness before triggering a reaction.

• The reputation system in this protocol manages a table consisting of entries for

nodes and their rating. The rating is changed only when there is sufficient evidence

of malicious behavior that is significant for a node and that has occurred a number

35
 of times exceeding a threshold to rule out coincidences. To avoid a centralized

rating, local rating lists and/or black-lists are maintained at each node and

potentially exchanged with friends.

• The path manager performs the following functions: path re-ranking according to

reputation of the nodes in the path; deletion of paths containing malicious nodes,

action on receiving a request for a route from a malicious node and action on

receiving request for a route containing a malicious node in the source route.

Each node monitors the behavior of its neighbors. If a suspicious event is detected,

the information is given to the reputation system. If the event is significant for the node, it

is checked whether the event has occurred more than a predefined threshold that is high

enough to distinguish deliberate malicious behavior from simple coincidences such as

collisions. If a certain threshold is exceeded, the reputation system updates the rating of the

node that caused the event. If the rating turns out to be intolerable, the information is

relayed to the path manager, which proceeds to delete all routes containing the

misbehaving node from the path cache [21]. Below is an architectural figure of the

Confidant System.

Figure 4.2: The Architecture of Confidant [20]

36
4.4.2 Core

A mechanism called Core (COllaborative REputation mechanism), was proposed in

[22] to enforce node cooperation in mobile ad hoc network. It is a generic mechanism that

can be integrated with any network function like packet forwarding, route discovery,

network management and location management and is mainly an extension to the DSR on

demand routing protocol.

Core stimulates node cooperation by using a collaborative monitoring technique and

a reputation mechanism. In this mechanism, reputation is a measure of someone’s

contribution to network operations. Members that have a good reputation can use the

resources while members with a bad reputation, because they refused to cooperate, are

gradually excluded from the community.

This reputation system defines three types of reputation [23]:

a. Subjective reputation is a reputation value which is locally calculated based on

direct observation. For example, node X calculates the reputation of a neighbor

node Y at a given time for a particular function.

b. Indirect reputation is second hand reputation information which is established by

other nodes. For example, node X will accept the indirect reputation of node Y

from node Z. To eliminate an attack where a malicious node disseminates false

negative reputation information, only positive reputation information is distributed

in Core.

c. Functional reputation is related to a certain function, where each function is given a

weight as to its importance. For example, data packet forwarding may be deemed

to be more important than forwarding packets with route information, so data

packet forwarding will be given greater weight in the reputation calculations.

37
 Each node computes a reputation value for every neighbor using a sophisticated

reputation mechanism that differentiates between subjective reputation, indirect reputation

and functional reputation.

Core consists of two basic components:

• The watchdog mechanism is used to detect misbehavior nodes. When a node

forwards a packet, the node’s watchdog verifies that the next node in the path also

forwards the packet. The watchdog does this by listening promiscuously to the

next node’s transmissions. If the next node does not forward the packet, then it is

considered as misbehaving [24].

• The reputation table is a data structure stored in each node. Each row of the table

consists of four entries: the unique identifier of the entity, a collection of recent

subjective observations made on that entity’s behavior, a list of the recent indirect

reputation values provided by other entities and the value of the reputation

evaluated for a predefined function.

4.4.3 Ocean

S. Bansal et al. proposed an Observation-based Cooperation Enforcement in Ad hoc

Networks (Ocean) [25]. In contrast to Confidant and Core, Ocean avoids indirect (second

hand) reputation information and uses only direct first hand observations of other nodes

behavior. A node makes routing decisions based solely on direct observations of its

neighboring nodes interaction.

In Ocean, the rating of each node is initialized to Neutral (0), with every positive

action resulting in an increment (+1) of the rating, and every negative action resulting in a

decrement (-2) of the rating. Once the rating of a node falls below a certain faulty threshold

(-40), the node is added to a faulty list. The faulty list represents a list of misbehaving

nodes.

38
 Ocean has five components reside in each node to detect and mitigate misbehavior:

• NeighborWatch observes the behavior of the neighbors of a node. It works the

same way as watchdog [24]. Whenever misbehavior is detected, NeighborWatch

reports to the RouteRanker, which maintains ratings of the neighbor nodes.

• RouteRanker maintains a rating for each of its neighboring nodes. The rating is

initialized to Neutral and is incremented and decremented based on observed

events from the NeighborWatch component.

• Rank-Based Routing uses the information from NeighborWatch to make the

decision of selection of routes. An additional field, called the avoid-list, is added to

the DSR Route-Request Packet (RREQ) to avoid routes containing nodes in the

faulty list.

• Malicious Traffic Rejection rejects traffic from nodes which is considered

misbehaving. All traffic from a misbehaving node is rejected so that a node is not

able to relay its own traffic under the guise of forwarding it on.

• Second Chance Mechanism allows nodes previously considered misbehaving to

become useful again. A timeout approach is used where a misbehaving node is

removed from the faulty list after a fixed period of inactivity. Even though the node

is removed from the faulty list, its rating is not increased so that it can quickly be

added back to the faulty list if it continues the misbehavior.

Ocean focuses on the robustness of packet forwarding: maintaining the overall

packet throughput of mobile an ad hoc network with the existence of misbehaving nodes at

the routing layer. Ocean’s approach is to disallow any second hand reputation exchanges.

Routing decisions are made based solely on direct observations of neighboring nodes’

39
behavior. This eliminates most trust management complexity. Last but not least, Ocean

reputation system is mainly an extension to the DSR on demand routing protocol

4.4.4 Reputation Systems implementation Issues

Although the reputation based schemes applied to mobile ad hoc networks may be

different in implementation, they are all composed of essentially five different phases:

• The assignment of initial reputation values.

• The calculation of reputation values.

• The update of reputation values.

• The detection of misbehavior.

• The reaction to uncooperative behavior.

4.4.4.1 The assignment of initial reputation values

In this phase, when a new node enters the network or a node moves to a new

location, where nobody knows about its reputation and an initial reputation value should be

given. Each reputation system has a learning period, as the network will not know how a

new node will behave. One method is by assigning a very low reputation value to a new

node so that to force it to perform positive work to gain a good reputation. But this method

may not be feasible in an ad hoc network, where instantaneous connection is required and

nodes are more mobile. It may take too much time for a new node to establish its

reputation. A common way of assigning an initial reputation value for new nodes is to

assign them null values like what is done in Confidant, Core and Ocean systems [23].

4.4.4.2 The calculation of reputation values

In this phase, we have to give each node in the MANET a reputation value according

to its behavior. In most reputation systems, Confidant, Core and Ocean, reputation value is

a metric for trust. A node with a good reputation means it behaves well and thus is

40
trustworthy, while nodes with bad reputation are uncooperative and not trustworthy. There

are two ways for the calculation of this reputation value [21]:

• The direct reputation system is derived from first hand experience. A node gets

such information about another node, usually its one-hop neighbor, by direct

observation. Using this way, every node may have different reputation information

about other nodes since a node may behave differently when interacting with

different nodes. Thus, the reputation value for the same node may vary.

• The indirect reputation system is derived from second hand experience. A node

gets such information about another node from other nodes. That way, every node

deals with the received indirect reputation information based on its own judgment,

as this reputation information may be either incompatible with node’s experience

or the node does not trust the sender.

4.4.4.3 The update of reputation values

In this phase, we have to decide whether to update the nodes’ reputation values using

the global or the local reputation systems:

• The global reputation system is achieved by the exchange of indirect reputation

messages among the network nodes. Since indirect reputation information may be

from an untrustworthy node, most reputation systems using global reputation

information, such as Confidant and Core, suffer from false rating, either false

accusation or false praise. Also, since each node maintains reputation values of

every other node, storing such information requires more storage at each node and

of course the exchange of such reputation information throughout the network

results in greatly increasing the volume of network traffic. Moreover, every time a

node receives indirect reputation information, it has to decide whether to accept or

not. Sure this causes additional computation at each node. Last but not least,

41
 reputation information, as data packet, could be modified, replayed or accidentally

lost during transmission. All of these mentioned issues make global reputation

methods unreliable and complex reputation system [23].

• The local reputation system is based on direct first hand observations of one-hop

neighbors. Any second hand reputation exchanges are disallowed. An example of

such system is Ocean which uses only local reputation, and according to their

simulation, Ocean achieves a reasonable performance, in terms of network

throughput, while being less complex and less vulnerable to false accusations [25].

Thus, compared with global reputation, local reputation mechanism has low cost

and is more reliable and more efficient.

4.4.4.4 The detection of misbehavior

In this phase, nodes will need a reliable way of detecting good or bad behavior. For

example, reputation systems such as Confidant, Core and Ocean rely on promiscuous

observation for monitoring function operations. However, passive observation presents

several weaknesses when used within mobile ad hoc network as it might not detect a

misbehaving node in the presence of [24]:

• Limited transmission power in which the signal is strong enough to be overheard

by the previous node but too weak to be received by the true recipient.

• Collusion in which multiple nodes in conspiracy can mount a more sophisticated

attack. For example, Y forwards a packet to Z but do not report to X when Z drops

the packet.

• Partial dropping in which a node dropping packets at a lower rate than the

configured minimum misbehavior threshold.

42
4.4.4.5 The reaction to uncooperative behavior

In this phase once an uncooperative node has been identified, it is usually isolated

from the network. In addition, neighbors of the uncooperative node refuse to forward any

packets originated from the convicted node, depriving the network services. However,

since the function of a mobile ad hoc network depends on the participation of all nodes, so

the main objective is to force the nodes to cooperate and benefit each other [19]. Thus, an

uncooperative node should be punished temporally and be given chance to behave

normally again, like what happens in the Ocean reputation system by using the Second

Chance Mechanism.

4.5 The choice of cooperation enforcement Scheme

After the above presentation and discussion of the virtual currency-based and

reputation-based schemes, their shortcomings and implementation issues, the design of the

newly proposed Reputed-ARAN will follow the local direct reputation-based scheme.

4.6 Summary

In this chapter, a discussion of the different cooperation enforcement schemes used

in mobile ad hoc networks was presented. The description of the two used types of

cooperation schemes, the virtual currency-based and the reputation-based, was given.

Finally, some examples of each scheme and the different issues in each scheme’s design

were studied.

43
5. Chapter Five: The Proposed Reputation-based Scheme: Reputed-

ARAN

5.1 Introduction

Performance of Mobile Ad Hoc Networks is well known to suffer from free-riding,

selfish nodes, as there is a natural incentive for nodes to only consume, but not contribute

to the services of the system [26]. In the following sections, the definition of selfish

behavior and the newly designed reputation-based scheme, to be integrated with normal

ARAN routing protocol ending up having Reputed-ARAN, are presented.

5.2 Problem Definition

Whereas most of the attacks performed by malicious nodes can be detected and

defended against by the use of the secure routing ARAN protocol, as was explained earlier,

there remain the attacks that an authenticated selfish node can perform.

There are two attacks that an authenticated selfish node can perform that the current

ARAN protocol can not defend against. To illustrate these two possible attacks that a

selfish node can use to save its resources in a MANET communication, the attack-tree

notation proposed by Bruce Schneier [27] that allows the categorization of attacks that lead

an attacker to reach a specific goal is used. In the below table, the attack tree that can not be

detected by current ARAN protocol is shown:

Attack tree: Save own resources

OR 1. Do not participate in routing
1. Do not relay routing data
OR 1. Do not relay route requests
2. Do not relay route replies
2. Do not relay data packets
1. Drop data packets
Table 5.1: Attack Tree: Save own resources

44
 As shown in the above table, when nodes simply drop packets (case 1.1 and 2.1 in

the attack tree), all the security features of ARAN fail to detect or defend against these

attacks, as they focus only on the detection of malicious nodes’ attacks and not the

authenticated selfish nodes’ attacks. ARAN protocol assumes that authenticated nodes are

to cooperate and work together to provide the routing functionalities.

5.3 Proposed Reputation-based Scheme

5.3.1 Introduction

As nodes in mobile ad hoc networks have a limited transmission range, they expect

their neighbors to relay packets meant for far off destinations. These networks are based on

the fundamental assumption that if a node promises to relay a packet, it will relay it and

will not cheat. This assumption becomes invalid when the nodes in the network have

tangential or contradictory goals. The reputations of the nodes, based on their past history

of relaying packets, can be used by their neighbors to ensure that the packet will be relayed

by the node. In the upcoming subsections, a discussion of a simple reputation-based

scheme to detect and defend against authenticated selfish nodes’ attacks in MANETs built

upon the ARAN protocol is presented. Sometimes authenticated nodes are congested and

they can not fulfill all control packets broadcasted in the MANET so they choose not to

reply to other requests in order to do their own assigned load according to their battery,

performance and congestion status. My scheme does take into consideration the case 1.1

attack, do not forward control packets, by considering the reputation value of the node

asking others to forward its packets. If the packet has originated from a low-reputed node,

the packet is put back at the end of the queue of the current node and if the packet has

originated from a high-reputed node, the current node sends the data packet to the next hop

in the route as soon as possible. This scheme helps in encouraging the nodes to participate

45
and cooperate in the ad hoc network effectively. Moreover, my scheme will account for

the case 2.1 attack in which authenticated nodes promise to route data packets by replying

to control packets showing their interest in cooperation in forwarding these data packets

but then they become selfish and start dropping the data packets. This is done by giving

incentives to the participating nodes for their cooperation. The proposed scheme is called

Reputed-ARAN. Different from global indirect reputation-based schemes like Confidant

and Core, discussed in chapter 4, the proposed solution uses local direct reputations only

like in Ocean reputation-based scheme. Each node keeps only the reputation values of all

direct nodes it dealt with. These reputation values are based on the node’s first hand

experience with other nodes. My work is partially following the same methodology that

Prashant, Partha and Amiya used in their paper about reputation systems for AODV [42].

5.3.2 Design Requirements

The following requirements are set while designing the reputation-based scheme to

be integrated with the ARAN protocol:

a. The reputation information should be easy to use and the nodes should be able to

ascertain the best available nodes for routing without requiring human intervention.

b. The system should not have a low performance cost because low routing efficiency

can drastically affect the efficiency of the applications running on the ad hoc

network.

c. Nodes should be able to punish other selfish nodes in the MANET by providing

them with a bad reputation.

d. The system should be built so that there is an injection of motivation to encourage

cooperation among nodes.

e. The collection and storage of nodes’ reputation values are done in a decentralized

way.

46
 f. The system must succeed in increasing the average throughput of the mobile ad

hoc network or at least maintain it.

5.3.3 Main Idea of the Reputation System

In the proposed reputation scheme, all the nodes in the mobile ad hoc network will

be assigned an initial value of null (0) as in the Ocean reputation-based scheme [25]. Also,

the functionality of the normal ARAN routing protocol in the authenticated route setup

phase will be modified so that instead of the destination unicasts a RREP to the first

received RDP packet of a specific sender only, the destination will unicast a RREP for

each RDP packet it receives and forward this RREP on the reverse-path. The next-hop

node will relay this RREP. This process continues until the RREP reaches the sender. After

that, the source node sends the data packet to the node with the highest reputation. Then the

intermediate node forwards the data packet to the next hop with the highest reputation and

the process is repeated till the packet reaches its destination. The destination acknowledges

the data packet (DACK) to the source that updates its reputation table by giving a

recommendation of (+1) to the first hop of the reverse path. All the intermediate nodes in

the route give a recommendation of (+1) to their respective next hop in the route and

update their local reputation tables. If there is a selfish node in the route, the data packet

does not reach its destination. As a result, the source does not receive any DACK for the

data packet in appropriate time. So, the source gives a recommendation of (-2) to the first

hop on the route. The intermediate nodes also give a recommendation (-2) to their next hop

in the route up to the node that dropped the packet. As a consequence, all the nodes

between the selfish node and the sender, including the selfish node, get a recommendation

of (-2). The idea of giving (-2) to selfish nodes per each data packet dropping is due to the

fact that negative behavior should be given greater weight than positive behavior. In

addition, this way prevents a selfish node from dropping alternate packets in order to keep

47
its reputation constant. This makes it more difficult for a selfish node to build up a good

reputation to attack for a sustained period of time [23]. Moreover, the selfish node will be

isolated if its reputation reached a threshold of (-40) as in the Ocean reputation-based

scheme [25]. In the following table, the default Reputed-ARAN parameters are listed:

Initial Reputation 0
Positive Recommendation +1
Negative Recommendation -2
Selfish drop Threshold -40
Re-induction timeout 5 minutes
Table 5.2: Reputed-ARAN Default parameters
The proposed protocol will be structured into the following four main phases [42],

which will be explained in the subsequent subsections:

• Route Lookup Phase

• Data Transfer Phase

• Reputation Phase

• Timeout Phase

5.3.3.1 Route Lookup Phase

This phase mainly incorporates the authenticated route discovery and route setup

phases of the normal ARAN secure routing protocol. In this phase, if a source node S has

packets for the destination node D, the source node broadcasts a route discovery packet

(RDP) for a route from node S to node D. Each intermediate node interested in cooperating

to route this control packet broadcasts it throughout the mobile ad hoc network; in addition,

each intermediate node inserts a record of the source, nonce, destination and previous-hop

of this packet in its routing records. This process continues until this RDP packet reaches

the destination. Then the destination unicasts a route reply packet (RREP) for each RDP

packet it receives back using the reverse-path. Each intermediate node receiving this RREP

updates its routing table for the next-hop of the route reply packet and then unicasts this

48
RREP in the reverse-path using the earlier-stored previous-hop node information. This

process repeats until the RREP packet reaches the source node S. Finally, the source node

S inserts a record for the destination node D in its routing table for each received RREP.

In the below figures, the route lookup phase is presented in details, illustrating the

two phases of it, the authenticated route discovery phase and the authenticated route setup

phase.

A C

S D

B E

Figure 5.1: A MANET Environment

RDP
A C
RDP RDP
RDP
S D
RDP RDP
RDP

B RDP E
Figure 5.2: Broadcasting RDP
RREP
RREP A C RREP
RREP
S D
RREP
RREP
RREP
RREP
B E

Figure 5.3: Replying to each RDP

5.3.3.2 Data Transfer Phase

At this time, the source node S and the other intermediate nodes have many RREPs

for the same RDP packet sent earlier. So, the source node S chooses the highly-reputed

next-hop node for its data transfer. If two next-hop nodes have the same reputation, S will

choose one of them randomly, stores its information in the sent-table as the path for its data

transfer. Also, the source node will start a timer before it should receive a data

acknowledgement (DACK) from the destination for this data packet. Afterwards, the

49
chosen next-hop node will again choose the highly-reputed next-hop node from its routing

table and will store its information in its sent-table as the path of this data transfer. Also,

this chosen node will start a timer, before which it should receive the DACK from the

destination for this data packet. This process continues till the data packet reaches the

destination node D. And of course in this phase, if the data packet has originated from a

low-reputed node, the packet is put back at the end of the queue of the current node. If the

packet has originated from a high-reputed node, the current node sends the data packet to

the next highly-reputed hop in the route discovered in the previous phase as soon as

possible. Once the packet reaches its destination, the destination node D sends a signed

data acknowledgement packet to the source S. The DACK traverses the same route as the

data packet, but in the reverse direction.

In the following figures, the data transfer phase is illustrated:

Next Hop Reputation

C 20
E -5

Data
A C
Data Data
Next Hop Reputation
A 10 S D
B 5

B E
Figure 5.4: Choosing the highly-reputed next-hop node
DACK
DACK A C DACK

S D

B E
Figure 5.5: Sending Data Acknowledgement for each received data
packet

50
5.3.3.3 Reputation Phase

In this phase, when an intermediate node receives a data acknowledgement packet

(DACK), it retrieves the record, inserted in the data transfer phase, corresponding to this

data packet then it increments the reputation of the next hop node. In addition, it deletes

this data packet entry from its sent-table. Once the DACK packet reaches node S, it deletes

this entry from its sent-table and gives a recommendation of (+1) to the node that delivered

the acknowledgement.

5.3.3.4 Timeout Phase

In this phase, once the timer for a given data packet expires at a node, the node

retrieves the entry corresponding to this data transfer operation returned by the timer from

its sent-table. Then, the node gives a negative recommendation (-2) to the next-hop node

and deletes the entry from the sent-table. Later on, when the intermediate nodes’ timers up

to the node that dropped the packet expire, they give a negative recommendation to their

next hop node and delete the entry from their sent-table. As a consequence, all the nodes

between the selfish node and the sender, including the selfish node, get a recommendation

of (-2). Now, if the reputation of the next-hop node goes below the threshold (-40), the

current node deactivates this node in its routing table and sends an error message RERR to

the upstream nodes in the route. Then the original ARAN protocol handles it. Now, it is the

responsibility of the sender to reinitiate the route discovery again. In addition, the node

whose reputation value reached (-40) is now temporally weeded out of the MANET for

five minutes and it later joins the network with a value of (0) so that to treat it as a newly

joined node in the network.

51
5.4 Analysis of the proposed Reputed-ARAN

In this section, an analysis of the proposed reputation-based scheme is given by

discussing different authenticated selfish nodes’ forms of attacks and presenting ways of

counteracting them by the introduced reputation-based scheme.

• An authenticated selfish node might make a false claim of knowing the route to a

destination and generate a RREP for a destination for which it does not have a

route. This attack can be foiled by the proposed reputation-based scheme routing.

After receiving the data packet for the corresponding destination, this authenticated

selfish node will have to drop the data packet. The sender and the intermediate

nodes until this selfish node will give a negative recommendation to it. Thus, once

the reputation of this selfish node falls below the threshold reputation, it will be

considered as selfish and will eventually be temporary ostracized.

• An authenticated selfish node might not reveal that it knows the route to the

destination by not replying to or forwarding control packets so that to save its

resources, such as energy and processing power; by doing this selfish behavior, it

will not be able to inflict any damage to the network as it will not be able to drop

the data packets routed via other paths. To face this type of selfish attack, the

proposed scheme considers the reputation value of the node asking others to

forward its packets. If the packet has originated from a low-reputed node, the

packet is assigned lowermost priority and if the packet has originated from a high-

reputed node, the current node sends the data packet to the next hop in the route as

soon as possible. Hence, these selfish nodes will see a considerable increase in

network latency. So, the proposed scheme helps in encouraging the nodes to

participate and cooperate in the ad hoc network effectively.

52
• An authenticated selfish node might promise to route data packets, but then it

starts to drop all the data packets that it receives. The presented reputation-based

scheme foils this attack. In such a scenario, the upstream neighbor of the node will

give it a negative recommendation and the reputation of the node will be reduced.

Eventually, the node will be weeded out of the network for a period of time.

• Authenticated selfish nodes might collude by giving positive recommendations to

each other so that to increase their reputations. The proposed reputation-based

scheme prevents this attack by having the nodes rely on their own experience

rather than the experience of their peers. Although the exchange of reputation

information among the nodes will make the system more robust, it is not

incorporated in my scheme. This is due to that if the nodes exchange the

reputations of other nodes, the target (node soliciting reputation of another node)

will have to consider the credibility of the information source (node providing

reputation of another node). As a result, this will imply more work for the nodes at

the routing layer and will also increase the volume of the network traffic [20]. The

downside of my scheme is that an authenticated selfish node can move around the

network and selectively drop packets from different neighbors without getting

caught for a long time. However, eventually this selfish node will be caught.

• An authenticated selfish node might continuously drops data packets to decrease

the throughput of the mobile ad hoc network. The presented scheme can prevent

such attack. Since the nodes in an ad hoc network are semi-autonomous, the

proposed reputation-based scheme motivates them to allocate their resources to

other nodes in the network. As the sender relays the packet only to highly reputed

neighbors, it reduces the risk that its neighbors will intentionally drop the packet.

The neighbors in turn forward the packets to nodes that have a high reputation with

53
 them. As a result, the number of packets intentionally dropped is reduced and the

throughput of the system rises.

• An authenticated well-behaved node might become a bottleneck since in the

presented reputation-based scheme the node with the highest reputation is selected

as the next hop by its neighbor. As a result, the nodes with higher reputations will

become overloaded, while the other nodes become totally free [26]. This problem

is prevented in the proposed scheme as when authenticated nodes are congested

and they can not fulfill all control packets broadcasted in the MANET, they can

choose not to reply to other nodes’ requests in order to do their own assigned load

according to their battery, performance and congestion status.

5.5 Summary

The field of ad hoc mobile networks is rapidly growing and changing, and

while there are still many challenges that need to be met, it is likely that such networks will

see widespread use within the next few years. In this chapter, a new reputation-based

scheme to be integrated with one of the secure routing MANET protocols, ARAN, to

make it detect and defend against selfish nodes and their misbehavior is presented. An

explanation of the different phases of this scheme and analysis of the various forms of

selfish attacks that this scheme defends against are presented. Last but not least, a whole

appendix is dedicated for presenting the Reputed-ARAN pseudo code, appendix C.

54
6. Chapter Six: Simulation Environments

6.1 Introduction

As there are several different simulation packages that can be used for MANET

simulation, a survey of the commonly used simulators: OPNET, NS2, QualNet and

Glomosim is performed in order to determine the most suitable simulator to use [28]. In the

following subsections, each of these simulation packages will be presented.

6.1.1 OPNET

OPNET is a simulation tool that is developed by OPNET Technologies Inc [29].

They are a leading provider of management software for networks and applications.

OPNET have a number of solutions that aim to help the customer in different areas like,

application performance troubleshooting, application deployment planning, network

configuration auditing, network capacity and resiliency planning.

For simulating a MANET, OPNET provides a software platform called the

OPNET Modeler. This software also contains a large number of different models for

simulating network protocols, technologies and applications. There are a wireless model

included that provides the two routing protocols DSR and TORA.

Although OPNET is rather intended for companies to diagnose and organize their

networks, one could use it to develop and implement ones own protocol or modify existing

implementations of standard protocols.

The software tends to be well documented and there should not be any problems

either with the installation or support. On their homepage [29] there are technical resources

with a FAQ and product updates as well as a forum for OPNET users. To be able to

participate in the forum and download the documents, one has to acquire a license since

55
they are protected by passwords. On the negative part, the software is very expensive and

not easy to obtain for individuals.

6.1.2 NS2

NS2 [30] stands for the Network Simulator 2 and is developed by ISI, the

Information Sciences Institute at the USC School of engineering. The source code can be

downloaded, free of charge, and compiled on different platforms, e.g. Unix and Windows.

There is an extensive manual for the installation and use of the software in the NS2

homepage.

There are also many different extensions developed by varies researchers to this

software. Many wireless extensions have been contributed from the UCB Daedelus, the

CMU Monarch projects and Sun Microsystems. However, the documentation of these

extensions is not always as extensive as one would like it to be and even the developers of

NS do not always support them. In NS2, it is possible to alter and write ones own code to

make it more suitable for ones own scenarios.

The most recent version of NS2 supports AODV, DSDV, DSR and TORA. If one

wants to simulate other protocols, there are extensions that support ADMR, AODV+,

AODV-UU, Ariadne, MAODV, ODMRP, SEAD and ZRP [30].

6.1.3 QualNet

QualNet [31] is developed by Scalable Network Technologies (SNT) and is a

network simulation software. SNT claims that one can use QualNet when one wants to

design a network or if one wants to optimize a network device in order to save time and

money.

The QualNet software consists of five tools plus integration modules and model

libraries. QualNet Animator allows for graphically designing the network model using a

wide library of components. In addition, this animator can be used to display the

56
simulation as it runs. QualNet Designer is for streamline code development. One can

generate code for ones protocol from scratch and make special statistic reports. One can

also make adjustments to already made protocol models. QualNet Analyzer is a graphic

tool that presents statistics of different experiments in graphs.

The QualNet model library is a large library of networking options and contains the

MANET library. It includes models for providing wireless dynamic routing, shadowing,

fading, mobility, detailed physical layer effects such as steerable directional antennas and

complex modulation schemes. Routing protocols provided are DSR, Fisheye, LAR,

OLSR, STAR, ZRP and ODMRP. At their homepage, one can find much documentation

and help. There are manuals as well as a FAQ and a forum [31].

6.1.4 Glomosim

This simulator is probably the most commonly used software of the four. GloMoSim

stand for Global Mobile information systems Simulation library and supports protocols for

a purely wireless network [32]. It is developed at UCLA Parallel Computing Laboratory

(UCLA PCL) and is intended for academic institutions for research purposes. It is only

possible to download the current version, Glomosim 2.0 (December 2000), from the

Glomosim homepage if the user is within the edu domain. If commercial users want to use

Glomosim they have to obtain the commercial version called QualNet, discussed earlier.

This version is extended in some areas. One can read more about it in the previous section.

In order to get Glomosim to work one has to install Parsec, which is a C-based

simulation language developed by PCL at UCLA. There is good documentation of the

installation procedure and it is very easy to install. In any case, if one would run into

trouble while installing, one can get good help from the documentation.

57
 Glomosim support some protocols, which lies in my interest. These are AODV,

DSR, Fisheye, LAR, ODMRP and WRP. If one want to develop ones own protocols in

Glomosim, it is possible. But to do so, one should have some familiarity with Parsec.

6.2 Choice of simulator

None of the four simulation packages currently include any of the secure routing

protocols’ source code. Therefore, if I want to simulate ARAN, I have to implement it on

my own. Furthermore, when choosing a simulation package, the question of which routing

protocol to be simulated and which simulations to be conducted are of great importance.

So in this section, the reasons behind the decision of using the Glomosim simulation

package in the experimental work are given.

First, QualNet and OPNET are well-developed commercial software products and

should be easier to use than the other simulation packages. However, the problem is that

they cost a lot of money. The question also arises of what open source code that is publicly

available. This is an important factor since there is no enough time to implement the

ARAN routing protocol from the beginning.

Second, NS2 is free to download and some researchers for simulating mobile ad hoc

networks use it. However, it is quite a complex task to install it and have it work right.

Even after installing it, which was done, it is easy to lose the way in its many modules and

components and the manual is not that good. Last but not least, performing a simulation in

NS2 is very complicated and requires more effort and work.

Glomosim’s documentation is very good and it is easy to get support from the many

researchers using it. In addition, many papers related to my field of research have used and

recommended using glomosim to simulate MANET protocols. Also, the newly-developed

features can be downloaded by communicating with the MANET special interest group.

58
Most importantly, after the continuous communication with the author of the ARAN

protocol at the University of California at Santa Barbara, I got the source code of ARAN

protocol implemented under the Glomosim package. Thus, having this code implemented

under Glomosim, I did not reinvent the wheel and rewrite the protocol in NS2, as it was

my second choice for a simulation package.

Altogether the choice of the simulation package was quite clear, as Glomosim

provided the best overall solution for my purpose and I got the ARAN protocol source

code developed under it.

6.3 Summary

In this chapter, the different simulation packages that are used in mobile ad hoc

networks were surveyed. Then, justifications for the choice of the Glomosim simulation

environment to be used to conduct all the experimental parts of this thesis work were

presented.

59
7. Chapter Seven: Simulation Methodology

7.1 Introduction

This chapter will be presenting the simulation methodology that was followed. This

involves the selection of the simulation package, the simulation parameters, the selfish

nodes selection criteria and reputation default values. In addition, all the measured metrics

and their definitions are presented.

7.2 Simulation Environment

All simulation experiments are developed and simulated on an Intel 1.4 GHz

machine using Linux Red Hat 9.0 with 256 MB RAM and the network simulator

Glomosim [32], a library-based sequential and parallel simulator for wireless mobile ad-

hoc networks. The choice of this simulation package in specific is due to the various

reasons that were presented earlier in chapter 6. Also, several simulation and Linux shell

scripts are developed to help in conducting the various simulation experiments. These

scripts can be found in appendix F

Each cycle of the simulation runs for 15 minutes. Each simulation experiment is

repeated five times and then average values of their results are taken to ensure integrity.

The simulated network consists of 20 randomly allocated nodes in a space of 670*670

square-meters. The node transmission range was 250 meters and the propagation limit of

each node is set to -111dBm. As for the MAC layer communication, the IEEE 802.11 is

used.

60
7.3 Movement and Communication Patterns

In the application layer, the nodes communicate using five constant Bit Rate

generators (CBR) over UDP with random source and destination pairs. Each generator

produces 1000 data packets of 512 bytes each at the rate of 4 packets per second. All of

these parameters were set in the Glomosim’s application configuration file, as shown in

appendix E.

Besides, in all node movement scenarios, a node chooses a destination and moves in

a straight line towards the destination at a speed uniformly distributed between 0 m/s and

some maximum speed. Once the node reaches its destination, it waits for a pause time

before choosing another random destination and repeats the process. This is called the

random waypoint model [50]. The maximum speed was limited to 10 m/s and ran

simulations for constant node speeds of 0, 1, 5 and 10 m/s, with pause time fixed at 30

seconds.

7.4 Selfish Nodes

Of the 20 nodes simulated, some variable percentage of the nodes is selfish. As

mentioned earlier, a selfish node is one that agrees to participate in forwarding packets but

then haphazardly drops all data packets that are routed through it.

The percentage of the selfish nodes was varied from 0% to 30% in 10% increments.

Also, a random number generator to designate selfish nodes randomly was developed.

This is shown in appendix G. In the meantime, the same seed across the 0% to 30%

variations of the selfish nodes parameter was used. That means for example that the group

of the selfish nodes in the 20% case is a superset of the group of the selfish in the 10%

case. Thus, that ensures that the impediments present in lower percentage selfish nodes

runs are also present in higher percentage selfish nodes runs.

61
 In addition, in the proposed reputation-based scheme the default reputation-related

parameters which were presented earlier in chapter 5 were used. As a consequence, the

initial reputation value of each node in the mobile ad hoc network is (0), the positive

recommendation is (+1), the negative recommendation is (-2), the selfish drop threshold is

(-40), which is the value that specifies when a node is marked as selfish, and last but not

least the re-induction timeout is for five minutes, which is the value that specifies the time

duration for which a selfish node should be punished.

7.5 Metrics

In order to compare the performance of Reputed-ARAN and normal ARAN, both

protocols are run under identical mobility and traffic scenarios. First, an analysis of normal

well-behaved ARAN network is done. Then, some uncooperative nodes are introduced to

the normal ARAN network and analysis of the performance is done. Following that, the

newly designed reputation-based scheme is added to normal ARAN, to become Reputed-

ARAN, and performance is compared to normal ARAN. A comparison between both of

these protocols using the metrics explained is presented in the following subsections.

7.5.1 Network Throughput

This value represents the ratio of the total number of packets that reach their

destination, to the total number of packets sent by the source. It is calculated according to

this formula: Throughput = Packets Received / Packets Sent. The network throughput is

directly influenced by packet loss, which may be caused by general network faults or

uncooperative behavior.

7.5.2 Overhead

This is the ratio of routing-related transmissions (RDP, RREP, RERR and DACK in

case of Reputed-ARAN) to data transmissions in a simulation run. In the calculation of this

62
metric, the transmission of a control byte at each hop along the route was counted as one

transmission.

7.5.3 Average Route Acquisition Latency

This is the average delay between the sending of a route request/discovery packet by

a source for discovering a route to a destination and the receipt of the first corresponding

route reply.

7.5.4 Average End-to-End Delay of Data Packets

This is the average delay between the sending of the data packet by the constant bit

rate source and its receipt at the corresponding constant bit rate receiver.

7.5.5 Packets Reached

This metric indicates the fraction of data packets that reached when using each

routing protocol, in the presence of different percentages of selfish nodes. This metric is

very important as it gives us another view of the network throughput with regard of

number of data packets reached.

7.6 Summary

In this chapter, the followed simulation methodology was introduced and a

description of the used simulation environment, the different chosen simulation

parameters, the selected MAC layer, the number of nodes participating and their

distribution, and the area of the network were also given. In addition, the movement and

communication patterns were described. The selection criteria of selfish nodes and the

different percentages simulated and the default reputation values that were used for the

Reputed-ARAN proposed scheme were presented. In the meantime, a whole section was

dedicated to present the different metrics and their definitions. The below table

summarized the different configuration values that were used in all the performed

63
simulations, which will be presented and discussed in the next chapter. Also, appendix D

has the different Glomosim’s configuration files that were created and used.

Parameter Value

MANET Area 670*670 m2

Total number of nodes 20

% of Selfish Nodes Simulated 0% up to 30%

Movement Pattern Random Waypoint

Node Speed 0 up to 10 m/s

Application Five Constant Bit Rate (CBR)

Number of generated Packets 1000 packets per CBR

Size of Packet 512 bytes

Simulation Time 15 minutes

Table 7.1: General Simulation Parameters

64
8. Chapter Eight: Simulation Results

8.1 Introduction

In this chapter, the results of the various performed simulations are presented. The

main focus of the simulations is two scenarios. The first scenario is to simulate routing

performed without using the reputation scheme that is proposed in this thesis work, in other

words, to simulate normal ARAN secure routing protocol. The second scenario is to

simulate the routing performed with the proposed reputation scheme, in other words, to

simulate the newly proposed Reputed-ARAN. In the following sections, the results of the

simulation runs comparing between normal ARAN and the Reputed-ARAN and using

different simulation metrics, discussed earlier in chapter seven, are presented.

8.2 Experiment 1: Network Throughput

8.2.1 Objective

In this experiment, the network throughput is being measured for the normal ARAN

secure routing protocol and the Reputed-ARAN. The node speed and the percentage of

selfish nodes participating in the mobile ad hoc network are varied to compare the results.

8.2.2 Results

The below figure shows the results of the network throughput of both protocols:

normal ARAN and Reputed-ARAN with different node speed and different percentages of

selfish nodes.

65
 100

80

Reputed-ARAN with 0% selfish

ARAN with 0% selfish
Throughput (%)

60 Reputed-ARAN with 10% selfish

ARAN with 10% selfish
Reputed-ARAN with 20% selfish
40 ARAN with 20% selfish
Reputed-ARAN with 30% selfish
ARAN with 30% selfish

20

0
0 1 5 10
Node Speed (m/s)

Figure 8.1: Effects of Selfish nodes on Network Throughput

Also, in the below table, all the different results of the network throughput simulation

runs are listed.

Node Speed(m/s) 0 1 5 10
Used Protocol
Reputed-ARAN with 0% selfish 97 94.5 92 89.2
ARAN with 0% selfish 97 95.1 92.7 90
Throughput Improvement 0 0.630915 0.755124 0.888889

Reputed-ARAN with 10% selfish 95 92.6 90 87

ARAN with 10% selfish 88 84 79.1 74.4
Throughput Improvement 7.368421 9.287257 12.11111 14.48276

Reputed-ARAN with 20% selfish 89 86 81 74.3

ARAN with 20% selfish 72 67.7 62 55
Throughput Improvement 19.10112 21.27907 23.45679 25.97577

Reputed-ARAN with 30% selfish 82 76 69.4 63.1

ARAN with 30% selfish 56 50 44.1 38.8
Throughput Improvement 31.70732 34.21053 36.45533 38.5103
Table 8.1: Effect of different percentages of Selfish nodes on Network
Throughput
8.2.3 Analysis

From the above graph and its corresponding table, it is clear that the lack of

cooperation has fatal effect on the efficient working of the MANET. This graph shows the

66
dramatic fall in normal ARAN’s network throughput with increasing percentage of selfish

nodes. The different curves show a network of 20 nodes with different percentages of

selfish nodes, from 0% up to 30%, and moving at different speeds. Here are some points

that can be observed in this graph:

1. In the case that there are no selfish nodes in the mobile ad hoc network, both

ARAN and Reputed-ARAN have almost identical network throughput

values. This proves that the Reputed-ARAN protocol is as efficient as

ARAN in delivering the packets and discovering routes to any destination.

2. It can be noted that in both ARAN and Reputed-ARAN when the node

movement speed rises, the network throughput diminishes as the network in

general gets more fragile.

3. Also, as the percentage of selfish nodes participating in the mobile ad hoc

network increase, the throughput decreases because these selfish nodes tend

to drop packets that they beforehand promised to forward. The outcome of

dropping packets affects the normal ARAN protocol during the full life of

the MANET, but in case of Reputed-ARAN, it is just affected partially as by

time the selfish node will be identified and weeded out of the network.

4. The increase of throughput of the network in the case of using Reputed-

ARAN is attributed to that each node uses its local table of other nodes’

reputation values in the selection of the next-hop node for establishing the

data route.

5. Thus, the throughput of the network is reduced to 38.8% with normal

ARAN, when 30% of the nodes are selfish and moving at speed of 10 m/s.

However, the throughput of the network is reduced to only 63.1% with

Reputed-ARAN, in the same circumstances. This proves that the Reputed-

67
 ARAN increases the network throughput by 38.5% over normal ARAN

secure routing protocol.

8.3 Experiment 2: Overhead

8.3.1 Objective

In this experiment, the overhead for the normal ARAN secure routing protocol and

the Reputed-ARAN is measured. The speed of the nodes: from no mobility up to 10 m/s is

varied to compare the results.

8.3.2 Results

The below figure shows the results of the overhead metric of both protocols: normal

ARAN and Reputed-ARAN with different node speed.

30
Overhead % (# of control bytes per data packet

28
26
24
22
20
18
delivered )

16 Reputed-ARAN
14 ARAN
12
10
8
6
4
2
0
0 1 5 10
Node Speed (m/s)

Figure 8.2: Overhead Percentage

Also, in the below table, all the different results of the overhead percentage

simulation runs are listed.

68
 Node Speed(m/s) 0 1 5 10
Used Protocol
Reputed-ARAN 12 15.3 18.4 26.7
ARAN 8.7 11.4 12.3 18

Overhead% Difference 3.3 3.9 6.1 8.7

Table 8.2: Overhead Percentage Difference
8.3.3 Analysis

From the above graph and its corresponding table, it is clear that the newly proposed

Reputed-ARAN protocol has a higher overhead than the normal ARAN secure routing

protocol. This is due to the fact that the Reputed-ARAN uses extra data acknowledgement

(DACK) packet for each data packet sent. This DACK packet is used to give positive

recommendations after each successful data packet transfer. In addition, in the

authenticated route setup phase of normal ARAN protocol, the destination unicasts a

RREP for the first received RDP, but in the Reputed-ARAN protocol, the destination

unicasts a RREP for each received RDP. These extra RREPs are used later for the choice

of the highly-reputed next-hop node in the data transfer phase. Thus, when nodes are

moving at speed of 10 m/s, the overhead percentage rises from 18%, in case of normal

ARAN, to 26.7%, in case of Reputed-ARAN. Though the overhead percentage added by

the Reputed-ARAN is significant, this reputation-based scheme still improves

considerably the network throughput, as shown in the previous section.

8.4 Experiment 3: Average Route Acquisition Delay

8.4.1 Objective

In this experiment, the average route acquisition delay for the normal ARAN secure

routing protocol and the Reputed-ARAN is measured. The percentage of selfish nodes

participating in the mobile ad hoc network is varied to compare the results.

69
8.4.2 Results

The below figure shows the results of the average route acquisition delay metric of

both protocols: normal ARAN and Reputed-ARAN with different percentage of selfish

nodes.

80
Average Route Acquisition Delay00(ms)

60

Reputed-ARAN
40
ARAN

20

0
0 10 20 30
% of Selfish Nodes

Figure 8.3: Average Route Acquisition Delay

Also, in the below table, all the different results of the average route acquisition delay

simulation runs are listed.

% of Selfish Nodes 0 10 20 30
Used Protocol
Reputed-ARAN 54 64 69 75
ARAN 53 63 68 74
Table 8.3: Average Route Acquisition Delay Values
8.4.3 Analysis

From the above graph and its corresponding table, it is clear that the newly proposed

Reputed-ARAN protocol has an identical route acquisition delay as normal ARAN. This is

due to that both protocols have the same steps for the discovery, setup and maintenance of

the route, as no changes were done in these phases while designing the Reputed-ARAN.

Also, it can be seen from the graph that in both protocols, the average route acquisition

delay increases with the increase of the selfish nodes. This is due to the dropping of packets

70
because of link failures and also because of the selfish behavior which results in reissuing a

route discovery or taking a longer route to reach the destination.

8.5 Experiment 4: Average End-to-End Delay of Data Packets

8.5.1 Objective

In this experiment, the average end-to-end delay of data packets for the normal

ARAN secure routing protocol and the Reputed-ARAN is measured. The percentage of

selfish nodes participating in the mobile ad hoc network is varied to compare the results.

8.5.2 Results

The below figure shows the results of the average end-to-end delay of data packets

metric of both protocols: normal ARAN and Reputed-ARAN with different percentage of

selfish nodes.

35
Average End-to-End Delay of Data Packets (ms)

30

25

20
Reputed-ARAN
ARAN
15

10

0
0 10 20 30
% of Selfish Nodes

Figure 8.4: Average End-to-End Delay of Data Packets

Also, in the below table, all the different results of the average end-to-end delay of

data packets simulation runs are listed.

71
 % of Selfish Nodes 0 10 20 30
Used Protocol
Reputed-ARAN 26 28 30.5 33
ARAN 23 24 26 27

Delay Difference (ms) 3 4 4.5 6

Table 8.4: Average End-to-End Delay of Data Packets Values
8.5.3 Analysis

From the above graph and its corresponding table, it is clear that the newly proposed

Reputed-ARAN protocol has a higher average end-to-end delay of data packets than the

normal ARAN secure routing protocol. This is due to the fact that in the Reputed-ARAN,

at each hop and before sending or forwarding data packets, each node checks its reputation

table to choose the highly-reputed next-hop node that has route to the destination and data

packets received from low-reputed nodes are put back at the end of the queue. Also, as the

percentage of selfish nodes increase in the mobile ad hoc network, the Reputed-ARAN

protocol can end up choosing a longer selfish-free route to the destination with extra

number of hops, maximum two extra hops, as each extra hop costs 2 ms.

8.6 Experiment 5: Packets Reached

8.6.1 Objective

In this experiment, the packets reached metric for the normal ARAN secure routing

protocol and the Reputed-ARAN is measured. The speed of the nodes and the percentage

of selfish nodes participating in the mobile ad hoc network are varied to compare the

results.

72
8.6.2 Results

The below figure shows the results of the packets reached metric of both protocols:

normal ARAN and Reputed-ARAN with different node speed and different percentages of

selfish nodes.

Packets Reached

1000
Packets Reached (out of 1000)

900
800 Reputed-ARAN with no mobility
700 ARAN with no mobility
600 Reputed-ARAN with 1 m/s
ARAN with 1 m/s
500
Reputed-ARAN with 5 m/s
400
ARAN with 5 m/s
300 Reputed-ARAN with 10 m/s
200 ARAN with 10 m/s
100
0
0 10 20 30
% of Selfish Nodes

Figure 8.5: Packets Reached

Also, in the below table, all the different results of the packets reached simulation

runs are listed.

% of Selfish Nodes 0 10 20 30
Used Protocol
Reputed-ARAN with no mobility 970 950 890 820
ARAN with no mobility 970 880 720 560
Reputed-ARAN with 1 m/s 945 926 860 760
ARAN with 1 m/s 951 840 677 500
Reputed-ARAN with 5 m/s 920 900 810 694
ARAN with 5 m/s 927 791 620 441
Reputed-ARAN with 10 m/s 892 870 743 631
ARAN with 10 m/s 900 744 550 388
Table 8.5: Packets Reached Values
8.6.3 Analysis

From the above graph and its corresponding table, it is clear that with increasing the

percentage of selfish nodes in the MANET, there is a remarkable fall in normal ARAN’s

number of packets reached metric. The different bars show a network of 20 nodes with

73
different percentages of selfish nodes, from 0% up to 30%, and moving at different speeds.

Here are some points that can be observed in this graph:

1. In the case that there are no selfish nodes in the mobile ad hoc network, both

ARAN and Reputed-ARAN have almost identical number of packets

reaching their destinations. This proves that the Reputed-ARAN protocol is

as efficient as ARAN in delivering the packets and discovering routes to any

destination.

2. It can be noted that in both ARAN and Reputed-ARAN when the nodes’

speed rises, the number of packets reached diminishes as the network in

general gets more fragile.

3. Also, as the percentage of selfish nodes participating in the mobile ad hoc

network increase, the number of packets reached decreases because these

selfish nodes tend to drop packets that they beforehand promised to forward.

The outcome of dropping packets affects the normal ARAN protocol during

the full life of the MANET, but in case of Reputed-ARAN, it is just affected

partially as by time the selfish node will be identified and weeded out of the

network.

4. The increase in the number of packets reached in the case of using Reputed-

ARAN is attributed to that each node uses its local table of other nodes’

reputation values in the selection of the next-hop node for establishing the

data route.

5. Thus, the number of packets reached is reduced to 388 packets with normal

ARAN, when 30% of the nodes are selfish and moving at speed of 10 m/s.

However, the number of packets reached is reduced to only 631 packets with

Reputed-ARAN, in the same circumstances. This proves that the Reputed-

74
 ARAN increases the number of packets reached by 243 packets over normal

ARAN secure routing protocol.

8.7 Summary

In this chapter, the different results of the experimental work were presented.

Throughout the different sections, the experiments’ objective, result and analysis were

stated. Also, this chapter ended up by showing that the Reputed-ARAN protocol increased

the network throughput by 38.5% in a network of 20 nodes moving at speed of 10 m/s and

having 30% of them selfish. However, this throughput increase resulted in the increase of

the overhead percentage to 8.7% over the normal ARAN protocol.

75
9. Chapter Nine: Conclusion and Future Work

9.1 Conclusion

The field of MANETs is rapidly growing and changing. While there are still many

challenges that need to be met, it is likely that such networks will see widespread use

within the next few years. One of these challenges is security. Security of mobile ad hoc

networks has recently gained momentum in the research community. Due to the open

nature of ad hoc networks and their inherent lack of infrastructure, security exposures [48]

can be an impediment to basic network operation and countermeasures should be included

in network functions from the early stages of their design. Security solutions for MANET

have to cope with a challenging environment including scarce energy and computational

resources and lack of persistent structure to rely on for building trust. To my knowledge,

there is no previously published work on detecting and defending against malicious and

authenticated selfish nodes together in the field of MANETs’ routing protocols, even in the

proposed secure routing protocols [34], [35], [40] and [38].

Throughout this thesis research, a discussion of existing mobile ad hoc networks'

routing protocols’ types and their advantages and disadvantages was given and a list of

existing proactive, reactive and secure MANET routing protocols was compiled. Then, the

different types of attacks targeting MANET routing protocols’ security were explored.

Also, the difference between malicious and selfish nodes and their associated attacks were

discussed and a presentation of the fundamental requirements for the design of a secure

routing protocol to defend against these security breaches was given. Furthermore, a

comparison between some the existing secure mobile ad hoc routing protocols was

presented. Then, an in-depth talk about the Authenticated Routing for Ad Hoc Networks

76
protocol (ARAN) as one of the secure routing protocols built following the fundamental

secure routing protocols design methodology was given. Afterwards, a discussion of how

ARAN defends against most of the attacks that are conducted by malicious nodes such as

spoofing, fabrication, modification and disclosure ones was presented. That resulted in

proving that the currently existing specification of the ARAN secure routing MANET

protocol does not defend against attacks performed by authenticated selfish nodes. Thus, I

moved on discussing the different existing MANET cooperation enforcement schemes by

stating their types: the virtual currency-based and the reputation-based schemes. Examples

of each scheme and the different issues involved in the design of each were given. That

resulted in proposing a new design of a reputation-based scheme to integrate it with one of

the secure routing MANET protocols, ARAN, to make it detect and defend against selfish

nodes and their misbehavior. In this proposal, the different phases of the proposed

reputation-based scheme were explained. Then, an analysis of the various forms of selfish

attacks that the proposed reputation-based scheme defends against was presented. Also,

some time was invested in surveying the different simulation packages that are used in

mobile ad hoc networks. In addition, many justifications for the choice of the Glomosim

simulation package to conduct all the experimental part of the thesis work were given. The

solution presented in this thesis only cover a subset of all threats and is far from providing a

comprehensive answer to the many security problems in the MANETs field. Last but not

least, according to the many simulations that were performed, the newly proposed

reputation-based scheme, built on top of normal ARAN secure routing protocol, achieves a

higher throughput than the normal ARAN in the presence of selfish nodes. Thus, the

proposed design, Reputed-ARAN, proves to be more efficient and more secure than

normal ARAN secure routing protocol in defending against both malicious and

authenticated selfish nodes.

77
9.2 Future Work

MANETs are an increasingly promising area of research with practical

applications, but they are vulnerable in many settings to malicious and selfish nodes’

attacks. Also, MANETs rely on cooperation of the network nodes for routing. In the

absence of a common goal, the nodes need an external motivation to cooperate. Reputation

of the nodes and the subsequent advantages associated with having high reputation can

provide the motivation for the node to commit their own resources to others. In this thesis

work, a newly-designed local direct reputation-based scheme that is built on top of the

ARAN secure routing protocol was presented. This proposed design, Reputed-ARAN, is

capable of detecting and defending against malicious and authenticated selfish nodes’

attacks. In brief, my scheme works as follows: the sender only sends the packet to highly

reputed nodes, based on their reputation value, so that to lower the risk that its neighbors

will intentionally drop the packets. The neighbors in turn forward the packets to nodes

having high reputation. As a result, the number of intentionally dropped packets is reduced

and hence the throughput of the system is higher. Non-cooperative nodes are slowly

weeded out of the network. A node held by an individual who does not want to cooperate

with the other nodes in the MANET start accumulating negative reputation. Thus, the

nodes having low reputation do not receive any packet and hence can not inflict any

damage by dropping packets.

Some of the ideas that can be further integrated to the proposed reputation-based

scheme are presented as follows:

• An authenticated selfish node might propagate a false route error (RERR) and

advertise the route again on subsequent RDP from the source. This attack can

significantly increase the network latency. To detect and foil such a selfish attack,

78
 the node just before the authenticated selfish node in the route can maintain a

history of RREPs received from the authenticated selfish node.

• In the proposed reputation-based scheme, the destination of the packet

acknowledges receiving each packet, to the source of the packet, via the path

traversed by the packet. This acknowledgement increases the network traffic. To

account for this overhead, alternatively the sender can intercept the returned TCP

acknowledgement to ascertain that the previous packet has reached its destination.

This approach will reduce the traffic volume considerably.

• The proposed reputation-based scheme does not differentiate between nodes with

sufficient resources and others with limited resources. So in this scheme, poor

nodes with lower resources, such as PDAs, are unable to route packets for

other nodes due to the scarcity of resources. Such nodes lose reputation as

these nodes drop packets due to the shortage of resources. Eventually, their

reputation goes below the threshold, and these nodes are considered as selfish

nodes. This problem can be solved by attaching a list of the resources of a node in

its identity certificate. That way, this class of nodes is penalized for failing to route

packets, but the penalty inflicted on them is only a fraction of what is inflicted on a

node with a large volume of resources. For example, consider node P, which

possesses half the memory and half the processing power of most of the other

nodes in the network. If node P fails to route a packet sent by another node, it gets a

recommendation of (-1) instead of (-2). In this way, the system is democratized

[26].

In addition to the above specific add-ons that can be integrated to the proposed

Reputed-ARAN secure routing protocol, the research in the area of MANETs is far from

being exhaustive and much of the effort so far has been on devising routing protocols to

79
support the effective and efficient communication between nodes that are part of the

network. However, there are still many topics that deserve further investigation such as:

• Scalability: to what extent can an ad hoc network grow?

• Address configuration: the address scheme used in wired networks (e.g., DHCP),

as well as in Mobile IP, might not be adequate in a MANET. A new addressing

approach may be required for MANETs.

• Interoperation with the Internet: how can ad hoc networks seamlessly and

efficiently access the Internet in order to obtain advanced services?

• Improvement of interaction between layers: would it be better to have layers

interact in order to achieve better performance?

• Quality of service (QoS): is it feasible for bandwidth/delay-constrained

applications to run well in a MANET [44]?

• Applications for MANET: have we found a killer application?

• Power control: how can battery life be maximized [43]?

The research community is already investigating some answers to these

questions, however there is still a lot more work to be done.

80
References

1. A. Sun, The design and implementation of fisheye routing protocol for

mobile ad hoc networks. M.S. Thesis, Department of Electrical and

Computer Science, MIT, May 2002.

2. R. Duggirala. A Novel Route Maintenance Technique for Ad Hoc Routing

Protocols. M.S. Thesis, University of Cincinnati, November 2000.

3. Wikipedia, The free Encyclopedia. http://en.wikipedia.org/wiki/Distance-

vector_routing_protocol.

4. Freesoft. Distance Vector Algorithms.

http://www.freesoft.org/CIE/RFC/1058/6.htm.

5. P. Laigar. Analysis of Routing Algorithms for Mobile Ad-Hoc Networks.

Chalmers University of Technology, Department of Computer Engineering,

Gothenburg, March 2002.

6. Firewall. The Site For Networking Professionals.

http://www.firewall.cx/link_state.php.

7. J. Jubin and T. Truong. Distributed Algorithm for Efficient and Interference-

free Broadcasting in Radio Networks. Proceedings of INFOCOM, March

1988, pages 1119-1124.

8. M. Corson, J. Macker and S. Batsell. Architectural Considerations for

Mobile Mesh Networking. Proceedings of the IEEE MILCOM, October

1996, pages 225-229.

9. C. Cordeiro and D. Agrawal. Mobile Ad hoc Networking. OBR Research

Center for Distributed and Mobile Computing, ECECS, University of

Cincinnati, Cincinnati, 2003.

81
10. E. Royer and C. Toh. A Review of Current Routing Protocols for Ad

Hoc Mobile Wireless Networks. IEEE Personal Communications, April

1999, pages 46-55.

11. R. Molva and P. Michiardi. Security in Ad hoc Networks. Personal Wireless

Communication, September 2003, pages 756-775.

12. L. Zhou and Z. Haas. Securing Ad Hoc Networks. IEEE Networks Special

Issue on Network Security. November/December 1999, pages 24-30.

13. V. Gayraud and B. Tharon. Securing Wireless Ad Hoc Networks. ISS

Master, MP 71 project, March 2003.

14. P. Michiardi and R. Molva. Simulation-based Analysis of Security

Exposures in Mobile Ad Hoc Networks. Proceedings of European Wireless

Conference, February 2002.

15. K. Sanzgiri, D. Laflamme, B. Dahill, B. Levine, C. Shields and E. Royer. An

Authenticated Routing for Secure Ad Hoc Networks. Journal on Selected

Areas in Communications special issue on Wireless Ad hoc Networks,

March 2005.

16. L. Buttyan and J. Hubaux. Stimulating Cooperation in Self-Organizing

Mobile Ad Hoc Networks. ACM/Kluwer MONET, October 2003, pages

579-592.

17. L. Buttyan and J. Hubaux. Nuglets: a Virtual Currency to Stimulate

Cooperation in Self Organized Mobile Ad Hoc Networks. Technical Report

No. DSC/2001.

18. S. Zhong, J. Chen, and Y. Yang. Sprite: A simple, Cheat-proof, Credit-based

System for Mobile Ad hoc Networks. Proceedings of IEEE Infocom, April

2003, pages 1987-1997.

82
19. Y. Wang, V. Giruka and M. Singhal. A Fair Distributed Solution for Selfish

Nodes Problem in Wireless Ad Hoc Networks. Ad-Hoc, Mobile, and

Wireless Networks: Third International Conference, ADHOC-NOW, July

2004, pages 211-224.

20. S. Buchegger and J. Le Boudec. Performance Analysis of the CONFIDANT

Protocol: Cooperation of Nodes, Fairness In Dynamic Ad-hoc NeTworks.

Proceedings of IEEE/ACM Symposium on Mobile Ad Hoc Networking and

Computing, MobiHoc, June 2002.

21. S. Buchegger and J. Le Boudec. A Robust Reputation System for P2P and

Mobile Ad-hoc Networks. Proceedings of the Second Workshop on the

Economics of Peer-to-Peer Systems, June 2004.

22. P. Michiardi and R. Molva. Core: A COllaborative REputation mechanism

to enforce node cooperation in Mobile Ad Hoc Networks. IFIP-

Communication and Multimedia Security Conference, September 2002,

pages 107-121.

23. P. Yau and C. Mitchell. Reputation methods for routing security for mobile

ad hoc networks. Proceedings of SympoTIC, Joint IST Workshop on Mobile

Future and Symposium on Trends in Communications, October 2003, pages

130-137.

24. S. Marti, T. Giuli, K. Lai, and M. Baker. Mitigating routing misbehavior in

mobile ad hoc networks. Proceedings of MOBICOM, August 2000.

25. S. Bansal and M. Baker. Observation-based Cooperation Enforcement in Ad

Hoc Networks. http://arxiv.org/pdf/cs.NI/0307012, July 2003.

26. P. Dewan and P. Dasgupta. Trusting Routers and Relays in Ad hoc

Networks. First International Workshop on Wireless Security and Privacy in

83
 conjunction with IEEE International Conference on Parallel Processing

Workshops (ICPP), October2003.

27. B. Schneier. Attack Trees: Modeling security threats. Dr Dobb’s Journal,

December 1999.

28. D. Cavin, Y. Sasson, and A. Schiper. On the Accuracy of MANET

Simulators. ACM Principles of Mobile Computing, October 2002, pages 38-

43.

29. Making Networks and Applications Perform. OPNET.

http://www.opnet.com.

30. The Network Simulator. NS2. http://www.isi.edu/nsnam/ns.

31. Scalable Network Technologies. QualNet. http://www.scalable-

networks.com.

32. About GloMoSim. GloMoSim. http://pcl.cs.ucla.edu/projects/glomosim.

33. J. Broch, D. B. Johnson, and D. Maltz. The Dynamic Source Routing

Protocol for Mobile Ad Hoc Networks. Internet-Draft, draft-ietf-manet-dsr-

03.txt, October 1999.

34. Y. Hu, A. Perrig, and D. Johnson. Ariadne: A Secure On-Demand Routing

Protocol for Ad Hoc Networks. In Proceedings of the Eighth Annual

International Conference on Mobile Computing and Networking, September

2002, pages 12-23.

35. K. Sanzgiri, B. Dahill, B. Levine, E. Royer and C. Shields. A Secure Routing

Protocol for Ad hoc Networks. Proceedings of the tenth IEEE International

Conference on Network Protocols, November 2002, pages 78-87.

84
36. C. Perkins and E. Royer. Ad-Hoc On-Demand Distance Vector Routing.

Proceedings of the Second IEEE Workshop on Mobile Computing Systems

and Applications, February 1999, pages 90-100.

37. Y. Hu, D. Johnson, and A. Perrig. SEAD: Secure Efficient Distance Vector

Routing in Mobile Wireless Ad Hoc Networks. In Fourth IEEE Workshop

on Mobile Computing Systems and Applications, June 2002, pages 3-13.

38. P. Papadimitratos, Z. Haas and P. Samar. The Secure Routing Protocol

(SRP) for Ad Hoc Networks. Internet-Draft, draft-papadimitratos-secure-

routing-protocol-00.txt, December 2002.

39. P. Papadimitratos and Z. Haas. Secure data transmission in mobile ad hoc

networks. Proceedings of WiSe, September 2003, pages 41-50.

40. M. Zapata and N. Asokan. Securing Ad Hoc Routing Protocols. In

Proceedings of the ACM Workshop on Wireless Security, September 2002,

pages 1-10.

41. M. Ilyas and R. Dorf. The handbook of ad hoc wireless networks. The

Electrical Engineering Handbook Series archive. Publisher CRC Press, 2003.

42. P. Dewan, P. Dasgupta and A. Bhattacharya. On using reputation in ad hoc

networks to counter malicious nodes. 10th International Conference on

Parallel and Distributed Systems, July 2004.

43. J. Cano and D. Kim. Investigating Performance of Power-aware Routing

Protocols for Mobile Ad Hoc Networks. IEEE MobiWac, October 2002.

44. S. Chakrabarti and A. Mishra. QoS Issues in Ad Hoc Wireless Networks.

IEEE Communication Magazine, February 2001, pages 142-148.

85
45. Y. Lee and G. Riley. DNVR (Dynamic NIx-Vector Routing) for Mobile Ad

Hoc Networks. Proceedings of the IEEE Wireless Communications and

Networking Conference, March 2005.

46. J. Crowcroft, R. Gibbens, F. Kelly and S. Östring. Modeling Incentives for

Collaboration in Mobile Ad Hoc Networks. WiOpt, March 2003.

47. A. Urpi, M. Bonuccelli and S. Giordano. Modeling Cooperation in Mobile

Ad Hoc Networks: a Formal Description of Selfishness. WiOpt, March

2003.

48. Y. Hu, A. Perrig and D. Johnson. Rushing attacks and defense in wireless ad

hoc network routing protocols. Proceedings of second ACM Wireless

Security, September 2003, pages 30-40.

49. J. Hubaux, L. Buttyan and S. Capkun. The Quest for Security in Mobile Ad

Hoc Networks. Proceedings of the second ACM Symposium on Mobile Ad

Hoc Networking and Computing, October 2001, pages 146-155.

50. J. Broch, D. Maltz, D. Johnson, Y. Hu and J. Jetcheva. A Performance

Comparison of Multi-Hop Wireless Ad Hoc Network Routing Protocols.

Proceedings of the Fourth Annual ACM/IEEE International Conference on

Mobile Computing and Networking, October 1998, pages 85-97.

86
Appendix A: List of Protocols

The following list is not comprehensive. New routing protocols are always in the

making. For example one of the most recent protocols is DNVR (Dynamic NIx-Vector

Routing) for Mobile Ad Hoc Networks [45].

Proactive (Table Driven) Protocols

• CGSR (Clusterhead Gateway Switch Routing)

• DBF (Distributed Bellman-Ford routing protocol)

• DSDV (Destination-Sequenced Distance-Vector)

• DTDV (Highly Dynamic Destination-Sequenced Distance Vector routing

protocol)

• HSLS (Hazy Sighted Link State routing protocol)

• HSR (Hierarchial State Routing protocol)

• LCA (Linked Cluster Architecture) MMRP (Mobile Mesh Routing Protocol)

• OLSR (Optimized Link State Routing Protocol)

• STAR (Source Tree Adaptive routing protocol)

• TBRPF (Topology Dissemination Based on Reverse-Path Forwarding)

• WRP (Wireless Routing Protocol)

Reactive (On-Demand) Protocols

• ABR (Associativity-Based Routing)

• AODV (Ad Hoc On-Demand Distance Vector)

• AOMDV (Ad hoc On-demand Multipath Distance Vector)

• ARA (Ant-based Routing-Algorithm)

87
 • BSR (Backup Source Routing protocol)

• CHAMP (CacHing And MultiPath routing protocol)

• DSR (Dynamic Source Routing protocol)

• DSRFLOW (Flow State in the Dynamic Source Routing protocol)

• FORP (Flow Oriented Routing Protocol)

• LBR (Link life Based Routing)

• LMR (Lightweight Mobile Routing protocol)

• LUNAR (Lightweight Underlay Network Ad hoc Routing)

• PLBR (Preferred link based routing)

• RDMAR (Relative-Distance Micro-discovery Ad hoc Routing protocol)

• SSR (Signal Stability Routing)

• SMR (Split Multipath Routing)

• TORA (Temporally Ordered Routing Algorithm)

Security Routing Protocols

• ARAN (Authenticated Routing for Ad hoc Networks)

• Ariadne

• LHAP (Lightweight Hop-by-hop Authentication Protocol)

• SAODV (Secure Ad hoc On-demand Distance Vector)

• SAR (Security-aware Ad hoc Routing)

• SEAD (Secure Efficient Ad hoc Distance vector routing protocol)

• SLSP (Secure Link State Protocol)

• SMT (Secure Message Transmission)

• SPAAR (Secure Position Aided Ad hoc Routing)

88
• SRP (Secure Routing Protocol)

• TESLA (Time Efficient Stream Loss-tolerant Authentication)

89
Appendix B: List of ARAN’s functions with documentation

This appendix presents the functions of the normal ARAN secure routing protocol

with its inline documentation:

//-------------------------------------------------------------------
/*
* RoutingAranInit
* Initialization function for ARAN protocol
*/
void RoutingAranInit(GlomoNode *node,GlomoRoutingAran **aranPtr,const
GlomoNodeInput *nodeInput)
//-------------------------------------------------------------------
/*
* RoutingAranInitStats
* Initialize all the stat variables
*/
void RoutingAranInitStats(GlomoNode *node)
//-------------------------------------------------------------------
/*
* RoutingAranInitRouteTable
* Initialize the route table
*/
void RoutingAranInitRouteTable(ARAN_RT *routeTable)
//-------------------------------------------------------------------
/*
* RoutingAranInitSeenTable
* Initialize the seen table
*/
void RoutingAranInitSeenTable(ARAN_ST *seenTable)
//-------------------------------------------------------------------
/*
* RoutingAranInitBuffer
* Initialize the buffer
*/
void RoutingAranInitBuffer(ARAN_BUFFER *buffer)
//-------------------------------------------------------------------
/*
* RoutingAranInitSent
* Initialize the sent table
*/
void RoutingAranInitSent(ARAN_SENT *sent)
//-------------------------------------------------------------------
/*
* RoutingAranInitNonce
* Initialize the nonce
*/
void RoutingAranInitNonce(GlomoNode *node)
//-------------------------------------------------------------------
/*
* RoutingAranInitCAKey
* Initialize the Ca Public Key
*/
void RoutingAranInitCAKey(GlomoNode *node)
//-------------------------------------------------------------------

90
/*
* RoutingAranInitKeyPair
* Initialize the node's public and private keys, and certificate
*/
void RoutingAranInitKeyPair(GlomoNode *node)
//-------------------------------------------------------------------
/*
* RoutingAranMacLayerStatusHandler
* Reacts to the signal sent by the MAC protocol after link failure
*/
void RoutingAranMacLayerStatusHandler(GlomoNode *node, const Message*
msg)
//-------------------------------------------------------------------
/*
* RoutingAranPacketDropNotificationHandler
* Reacts to the signal sent by the MAC protocol after link failure
*/
void RoutingAranPacketDropNotificationHandler(GlomoNode *node, const
Message* msg,const NODE_ADDR nextHopAddress)
//-------------------------------------------------------------------
/*
* RoutingAranRouterFunction
* Determine the routing action to take for a the given data packet
* set the PacketWasRouted variable to TRUE if no further handling of
* this packet by IP is necessary
*/
void RoutingAranRouterFunction(GlomoNode *node,Message *msg,NODE_ADDR
destAddr,BOOL *packetWasRouted)
//-------------------------------------------------------------------
/*
* RoutingAranCheckRouteExist
* Returns TRUE if a route between the source and the destination is
* known
*/
BOOL RoutingAranCheckRouteExist(GlomoNode* node, NODE_ADDR destAddr,
NODE_ADDR srcAddr, ARAN_RT *routeTable)
//-------------------------------------------------------------------
/*
* RoutingAranLookupBuffer
* Returns TRUE if any packet is buffered to the destination
* NOTE: Buffer is only used at the source node
*
*/
BOOL RoutingAranLookupBuffer(NODE_ADDR destAddr, ARAN_BUFFER *buffer)
//-------------------------------------------------------------------
/*
* RoutingAranInsertBuffer
* Insert a packet into the buffer if no route is available
* NOTE: Buffer is only used at the source node
*/
static void RoutingAranInsertBuffer(Message* msg,NODE_ADDR
destAddr,ARAN_BUFFER* buffer)
//-------------------------------------------------------------------
/*
* RoutingAranHandleData
* Processing procedure when data is received
* This is only called at non-source nodes
* If I am an intermediate node then Relay the packet to the next hop
* of the route
*/

91
void RoutingAranHandleData(GlomoNode *node, Message *msg, NODE_ADDR
destAddr)
//-------------------------------------------------------------------
/*
* RoutingAranUpdateLifetime
* Update the lifetime field of the route entry in the route table
* corresponding to the given source destination pair
*/
void RoutingAranUpdateLifetime(NODE_ADDR destAddr, NODE_ADDR srcAddr,
ARAN_RT *routeTable)
//-------------------------------------------------------------------
/*
* RoutingAranSetTimer
* Set timers for protocol events
*/
void RoutingAranSetTimer(GlomoNode *node, long eventType, NODE_ADDR
destAddr, NODE_ADDR srcAddr, clocktype delay)
//-------------------------------------------------------------------
/*
* RoutingAranTransmitData
* Forward the data packet to the next hop
* This is called at non-destination nodes
*/
void RoutingAranTransmitData(GlomoNode *node, Message *msg, NODE_ADDR
destAddr)
//-------------------------------------------------------------------
/*
* RoutingAranGetNextHop
* Looks up the routing table to obtain next hop to the destination
* If no entry found, returns ANY_DEST
*/
NODE_ADDR RoutingAranGetNextHop(NODE_ADDR destAddr, NODE_ADDR
srcAddr, ARAN_RT *routeTable)
//-------------------------------------------------------------------
/*
* RoutingAranInitiateRDP
* Initiate a Route Discovery packet when no route to destination is
* known
* Assuming that no RDP has been previously sent for this destination
*/
void RoutingAranInitiateRDP(GlomoNode *node, NODE_ADDR destAddr)
//-------------------------------------------------------------------
void RoutingAranCopyCertificate(ARAN_Certificate* src,
ARAN_Certificate* target)
//-------------------------------------------------------------------
void RoutingAranSourceSignRDP(ARAN_RDP_Packet* rdpPkt,
GlomoRoutingAran* aran)
//-------------------------------------------------------------------
void RoutingAranINSignRDP(ARAN_RDP_Packet* rdpPkt, GlomoRoutingAran*
aran)
//-------------------------------------------------------------------
void RoutingAranDestSignREP(ARAN_REP_Packet* repPkt,
GlomoRoutingAran* aran)
//-------------------------------------------------------------------
void RoutingAranINSignREP(ARAN_REP_Packet* repPkt, GlomoRoutingAran*
aran)
//-------------------------------------------------------------------
void RoutingAranInitiatorSignERR(ARAN_ERR_Packet* errPkt,
GlomoRoutingAran* aran)
//-------------------------------------------------------------------

92
/*
* RoutingAranInsertSeenTable
* Insert an entry into the seen table
*/
static void RoutingAranInsertSeenTable(GlomoNode *node,NODE_ADDR
srcAddr,int nonce,NODE_ADDR predecessor,ARAN_ST *seenTable)
//-------------------------------------------------------------------
/*
* RoutingAranInsertSent
* Insert an entry into the sent table if RDP is sent
*/
static void RoutingAranInsertSent(NODE_ADDR destAddr,int ttl,
clocktype timestamp,ARAN_SENT *sent)
//-------------------------------------------------------------------
/*
* RoutingAranCheckSent
* Check if RDP has been sent; return TRUE if sent
*/
BOOL RoutingAranCheckSent(NODE_ADDR destAddr, ARAN_SENT *sent)
//-------------------------------------------------------------------
/*
* RoutingAranHandleRDP
* Processing procedure when RDP is received
* Process only if the packet is not a duplicate and Verify that
* packet is correct .
* If I am destination then Send a Reply packet and Add reverse route
*to routing table
* If I am intermediate node then Relay the packet only if TTL is not
* zero
*/
void RoutingAranHandleRDP(GlomoNode *node, Message *msg, int ttl)
//-------------------------------------------------------------------
/*
* RoutingAranReplaceInsertRouteTable
* Insert/Update an entry into the route table
*/
static void RoutingAranReplaceInsertRouteTable(NODE_ADDR
srcAddr,NODE_ADDR destAddr,NODE_ADDR nextHop,clocktype lifetime,BOOL
activated,ARAN_RT* routeTable)
//-------------------------------------------------------------------
/*
* RoutingAranLookupSeenTable
* Returns TRUE if the RDP packet is processed before
*/
BOOL RoutingAranLookupSeenTable(NODE_ADDR srcAddr, int nonce, ARAN_ST
*seenTable)
//-------------------------------------------------------------------
BOOL RoutingAranVerifySourceCertAndSignInRDP(GlomoNode* node,
ARAN_RDP_Packet* rdpPkt)
//-------------------------------------------------------------------
BOOL RoutingAranVerifyLastNodeCertAndSignInRDP(GlomoNode* node,
ARAN_RDP_Packet* rdpPkt)
//-------------------------------------------------------------------
BOOL RoutingAranVerifyDestCertAndSignInREP(GlomoNode* node,
ARAN_REP_Packet* repPkt)
//-------------------------------------------------------------------
BOOL RoutingAranVerifyLastNodeCertAndSignInREP(GlomoNode* node,
ARAN_REP_Packet* repPkt)
//-------------------------------------------------------------------
/*

93
 * RoutingAranRelayRDP
* Forward (re-broadcast) the RDP
*/
void RoutingAranRelayRDP(GlomoNode *node, Message *msg, int ttl)
//-------------------------------------------------------------------
/*
* RoutingAranInitiateREP
* Destination of the route sends REP in reaction to RDP
*/
void RoutingAranInitiateREP(GlomoNode *node, Message *msg)
//-------------------------------------------------------------------
/*
* RoutingAranHandleREP
* Processing procedure when REP is received
* Verify that packet is correct
* If I am an intermediate node then Forward the packet to the
* upstream of the route
*/
void RoutingAranHandleREP(GlomoNode *node, Message *msg, NODE_ADDR
srcAddr, NODE_ADDR destAddr)
//-------------------------------------------------------------------
/*
* RoutingAranDeleteSent
* Remove an entry from the sent table
*/
void RoutingAranDeleteSent(NODE_ADDR destAddr, ARAN_SENT *sent)
//-------------------------------------------------------------------
/*
* RoutingAranGetBufferedPacket
* Extract the packet that was buffered
*/
Message* RoutingAranGetBufferedPacket(NODE_ADDR destAddr, ARAN_BUFFER
*buffer)
//-------------------------------------------------------------------
/*
* RoutingAranDeleteBuffer
* Remove a packet from the buffer; Return TRUE if deleted
*/
BOOL RoutingAranDeleteBuffer(NODE_ADDR destAddr, ARAN_BUFFER *buffer)
//-------------------------------------------------------------------
/*
* RoutingAranActivateRoute
* Activate a route in the route table
*/
void RoutingAranActivateRoute(NODE_ADDR destAddr, NODE_ADDR srcAddr,
ARAN_RT *routeTable)
//-------------------------------------------------------------------
/*
* RoutingAranRelayREP
* Forward the REP packet
*/
void RoutingAranRelayREP(GlomoNode *node, Message *msg, NODE_ADDR
destAddr)
//-------------------------------------------------------------------
/*
* RoutingAranHandleProtocolPacket
* Called when the packet is received from MAC
* RDP
* REP
* ERR

94
 */
void RoutingAranHandleProtocolPacket(GlomoNode *node, Message *msg,
NODE_ADDR srcAddr,
NODE_ADDR destAddr, int ttl)
//-------------------------------------------------------------------
/*
* RoutingAranHandleProtocolEvent
* Handles all the protocol events:
* Remove the route that has not been used for awhile
* Check if REP is received after sending RDP */
*/
void RoutingAranHandleProtocolEvent(GlomoNode *node, Message *msg)
//-------------------------------------------------------------------
/*
* RoutingAranRetryRDP
* Send RDP again after not receiving any REP
*/
void RoutingAranRetryRDP(GlomoNode *node, NODE_ADDR destAddr)
//-------------------------------------------------------------------
/*
* RoutingAranIncreaseTimes
* Increase the number of times RDP sent in TTL = ARAN_NET_DIAMETER
*/
void RoutingAranIncreaseTimes(NODE_ADDR destAddr, ARAN_SENT *sent)
//-------------------------------------------------------------------
/*
* RoutingAranDeleteSeenTable
* Remove an entry from the seen table
*/
void RoutingAranDeleteSeenTable(ARAN_ST *seenTable)
//-------------------------------------------------------------------
/*
* RoutingAranDeleteRouteTable
* Remove an entry from the route table
*/
void RoutingAranDeleteRouteTable(NODE_ADDR destAddr, NODE_ADDR
srcAddr, ARAN_RT *routeTable)
//-------------------------------------------------------------------
/*
* RoutingAranGetTimes
* Obtains the number of times the RDP was sent in TTL =
* ARAN_NET_DIAMETER
*/
int RoutingAranGetTimes(NODE_ADDR destAddr, ARAN_SENT *sent)
//-------------------------------------------------------------------
/*
* RoutingAranGetTimestamp
* Obtains the timestamp when the RDP was sent
*/
clocktype RoutingAranGetTimestamp(NODE_ADDR destAddr, ARAN_SENT
*sent)
//-------------------------------------------------------------------
/*
* RoutingAranInactivateRoutesAndGetDestinations
* Inactivate routes that use the broken link
* Returns the srcAddr and destAddr for the routes (only those where
* this node is not the source)
*/
void RoutingAranInactivateRoutesAndGetSrcDestPairs(GlomoNode* node,

95
 ARAN_RT* routeTable,NODE_ADDR nextHop,ARAN_SrcDestPair
srcDestPairs[],int maxNumberPairs,int* numberPairs)
//-------------------------------------------------------------------
void RoutingAranInitiateERR(GlomoNode* node, NODE_ADDR destAddr,
NODE_ADDR srcAddr)
//-------------------------------------------------------------------
/*
* RoutingAranHandleERR
* Processing procedure when ERR is received
*/
void RoutingAranHandleERR(GlomoNode *node, Message *msg, NODE_ADDR
srcAddr)
//-------------------------------------------------------------------
/*
* RoutingAranMarkRouteBroken
* Mark the route with the given source and destination broken
*/
void RoutingAranMarkRouteBroken(GlomoNode *node, NODE_ADDR destAddr,
NODE_ADDR srcAddr, ARAN_RT *routeTable)
//-------------------------------------------------------------------
/*
* RoutingAranFinalize
* Called at the end of the simulation to collect the results
*/
void RoutingAranFinalize(GlomoNode *node)
//-------------------------------------------------------------------

96
Appendix C: Pseudo code of Reputed-ARAN

This appendix presents the main pseudo code of the newly proposed reputation-

based scheme, Reputed-ARAN. Initially the reputations of all the nodes are zero. The

Reputed-ARAN assumes that each node stores other nodes’ reputation values locally and

they do not exchange these reputation values. So, these reputation values are only based on

the previous routing history of the node and not on second-hand experience of other nodes.

Let the source node be S, the destination node be D, any intermediate cooperative

node be I, any node be A and any selfish node be denoted by E.

Route Lookup Phase

S: Has data to send for D.

S: Broadcast route discovery packet (RDP) for D in the MANET.

While (I <> D)

Do

I: Insert a record of the source, nonce, destination and previous-hop of this packet

in its routing table.

I: Broadcast RDP for D in the MANET using the normal standard ARAN secure

routing protocol.

End

D: Unicast a route reply packet (RREP) for each RDP packet it receives back using

the reverse-path.

While (I<>S)

Do

I: Update its routing table for the next-hop of the RREP.

97
 I: Unicast this RREP in the reverse-path using the earlier-stored previous-hop node

information.

End

S: Insert a route record for D in its routing table for each received RREP.

Data Transfer Phase

S: Choose the highly-reputed next-hop node for its data transfer. If two next-hop

nodes have the same reputation, S chooses one of them randomly.

S: Store the chosen node information in its sent-table as the path for data transfer.

S: Start a timer before it should receive a data acknowledgement (DACK) for the

data packet from the destination.

While (I <>D)

Do

If (I received data packet from low-reputed node) then

Put at the end of the data queue

Else

Send as soon as possible

I: Choose the highly-reputed next-hop node for its data transfer. If two next-hop

nodes have the same reputation, I chooses one of them randomly.

I: Store the chosen node information in its sent-table as the path for data transfer.

I: Start a timer before it should receive a data acknowledgement (DACK) for the data

packet from the destination.

End

D: Send a signed DACK to the source S traversing the same route as the data packet,

but in the reverse direction.

98
Reputation Phase

While (I<>S)

Do

I: Increment the reputation of the next hop node.

I: Delete this data packet entry from its sent-table.

End

S: Increment the reputation of the next hop node.

S: Delete this data packet entry from its sent-table.

Timeout Phase

Event: a timer for a given data packet expires at A.

A: Give a negative recommendation to the next-hop node.

A: Delete the entry from the sent-table.

Event: Next-hop node’s reputation goes below the threshold,

A: Deactivate this node in its routing table.

A: Send an error message RERR to the upstream nodes in the route.

E: Is now temporally weeded out of the MANET for five minutes.

99
Appendix D: Glomosim’s Configuration Files

This appendix presents two sample Glomosim configuration files of the many that

were created and used. In these files, the different simulation parameters, such as the

number of nodes, their speed, the simulated routing protocol and simulation time are set.

The first configuration file simulates only static nodes. So they do not move at all. The

other configuration file has nodes moving at a fixed speed of 10 m/s.

This is the first Glomosim configuration file:

# ***** GloMoSim Configuration File *****

#
# Anything following a "#" is treated as a comment.
#
#####################################################################
##########
#
# The following parameter represents the maximum simulation time. The
# numbered portion can be followed by optional letters to modify the
# simulation time.
# For example:
# 100NS - 100 nano-seconds
# 100MS - 100 milli-seconds
# 100S - 100 seconds
# 100 - 100 seconds (default case)
# 100M - 100 minutes
# 100H - 100 hours
# 100D - 100 days
#

SIMULATION-TIME 15M

#
# The following is a random number seed used to initialize part of
# the seed of various randomly generated numbers in the simulation.
# This can be used to vary the seed of the simulation to see the
# consistency of the results of the simulation.
#

SEED 1

#
# The following two parameters stand for the physical terrain in
# which the nodes are being simulated. For example, the following
# represents an area of size 100 meters by 100 meters. All range
# parameters are in terms of meters.
#
# Terrain Area we are simulating.
#

TERRAIN-DIMENSIONS (670, 670)

100
#
# The following parameter represents the number of nodes being
# simulated.
#

NUMBER-OF-NODES 20

#
#The following parameter represents the node placement strategy.
#- RANDOM: Nodes are placed randomly within the physical terrain.
#- UNIFORM: Based on the number of nodes in the simulation, the
# physical terrain is divided into a number of cells. Within each
# cell, a node is placed randomly.
#- GRID: Node placement starts at (0, 0) and are placed in grid
# format with each node GRID-UNIT away from its neighbors. The number
# of nodes has to be square of an integer.
#- FILE: Position of nodes is read from NODE-PLACEMENT-FILE. On each
# line of the file, the x and y position of a single node is
# separated by a space.
#

# NODE-PLACEMENT FILE
# NODE-PLACEMENT-FILE ./nodes.input
# NODE-PLACEMENT GRID
# GRID-UNIT 30
#NODE-PLACEMENT UNIFORM
NODE-PLACEMENT RANDOM
#
# The following represent parameters for mobility. If MOBILITY is set
# to NO, than there is no movement of nodes in the model. For the
# RANDOM-DRUNKEN model, if a node is currently at position (x, y), it
# can possibly move to (x-1, y), (x+1, y), (x, y-1), and (x, y+1); as
# long as the new position is within the physical terrain. For random
# waypoint, a node randomly selects a destination from the physical
# terrain. It moves in the direction of the destination in a speed
# uniformly chosen between MOBILITY-WP-MIN-SPEED and MOBILITY-WP-MAX-
# SPEED (meter/sec). After it reaches its destination, the node stays
# there for MOBILITY-WP-PAUSE time period. The MOBILITY-INTERVAL is
# used in some models that a node updates its position every
# MOBILITY-INTERVAL time period. The MOBILITY-D-UPDATE is used that a
# node updates its position based on the distance (in meters).
#

MOBILITY NONE

# Random Waypoint and its required parameters.

#MOBILITY RANDOM-WAYPOINT
#MOBILITY-WP-PAUSE 30S
#MOBILITY-WP-MIN-SPEED 0
#MOBILITY-WP-MAX-SPEED 0

#MOBILITY TRACE
#MOBILITY-TRACE-FILE ./mobility.in

#MOBILITY PATHLOSS-MATRIX

# The following parameters are necessary for all the mobility models

101
MOBILITY-POSITION-GRANULARITY 0.5

#####################################################################
#
# PROPAGATION-LIMIT:
# Signals with powers below PROPAGATION-LIMIT (in dBm)
# are not delivered. This value must be smaller than
# RADIO-RX-SENSITIVITY + RADIO-ANTENNA-GAIN of any node
# in the model. Otherwise, simulation results may be
# incorrect. Lower value should make the simulation more
# precise, but it also make the execution time longer.
#
PROPAGATION-LIMIT -111.0

#
# PROPAGATION-PATHLOSS: pathloss model
# FREE-SPACE:
# Friss free space model.
# (path loss exponent, sigma) = (2.0, 0.0)
# TWO-RAY:
# Two ray model. It uses free space path loss
# (2.0, 0.0) for near sight and plane earth
# path loss (4.0, 0.0) for far sight. The antenna
# height is hard-coded in the model (1.5m).
# PATHLOSS-MATRIX:
#
#PROPAGATION-PATHLOSS FREE-SPACE
PROPAGATION-PATHLOSS TWO-RAY
#PROPAGATION-PATHLOSS PATHLOSS-MATRIX

#
# NOISE-FIGURE: noise figure
#
NOISE-FIGURE 10.0

#
# TEMPARATURE: temparature of the environment (in K)
#
TEMPARATURE 290.0

#########################################
#
# RADIO-TYPE: radio model to transmit and receive packets
# RADIO-ACCNOISE: standard radio model
# RADIO-NONOISE: abstract radio model
# (RADIO-NONOISE is compatible with the current version (2.1b5)
# of ns-2 radio model)
#
RADIO-TYPE RADIO-ACCNOISE
#RADIO-TYPE RADIO-NONOISE

#
# RADIO-FREQUENCY: frequency (in heltz) (Identifying variable for
# multiple radios)
#
RADIO-FREQUENCY 2.4e9

#
# RADIO-BANDWIDTH: bandwidth (in bits per second)

102
#
RADIO-BANDWIDTH 2000000

#
# RADIO-RX-TYPE: packet reception model
# SNR-BOUNDED:
# If the Signal to Noise Ratio (SNR) is more than
# RADIO-RX-SNR-THRESHOLD (in dB), it receives the signal
# without error. Otherwise the packet is dropped.
# RADIO-RX-SNR-THRESHOLD needs to be specified.
# BER-BASED:
# It looks up Bit Error Rate (BER) in the SNR - BER table
# specified by BER-TABLE-FILE.
#
RADIO-RX-TYPE SNR-BOUNDED
RADIO-RX-SNR-THRESHOLD 10.0
#RADIO-RX-SNR-THRESHOLD 8.49583

#RADIO-RX-TYPE BER-BASED
#BER-TABLE-FILE ./ber_bpsk.in

#
# RADIO-TX-POWER: radio transmition power (in dBm)
#
RADIO-TX-POWER 7.9
# 15.0

#
# RADIO-ANTENNA-GAIN: antenna gain (in dB)
#
RADIO-ANTENNA-GAIN 0.0

#
# RADIO-RX-SENSITIVITY: sensitivity of the radio (in dBm)
#
RADIO-RX-SENSITIVITY -91.0

#
# RADIO-RX-THRESHOLD: Minimum power for received packet (in dBm)
#
RADIO-RX-THRESHOLD -81.0

#
##############################
#

MAC-PROTOCOL 802.11
#MAC-PROTOCOL CSMA
#MAC-PROTOCOL MACA

#MAC-PROTOCOL TSMA
#TSMA-MAX-NODE-DEGREE 8

#MAC-PROPAGATION-DELAY 1000NS

#
# PROMISCUOUS-MODE defaults to YES and is necessary if nodes want
# to overhear packets destined to the neighboring node. Currently
# this option needs to be set to YES only for DSR is selected
# as routing protocol. Setting it to "NO" may save a trivial amount

103
# of time for other protocols.

#PROMISCUOUS-MODE NO

##############################
#
# Currently the only choice.

NETWORK-PROTOCOL IP
NETWORK-OUTPUT-QUEUE-SIZE-PER-PRIORITY 100

#RED-MIN-QUEUE-THRESHOLD 150
#RED-MAX-QUEUE-THRESHOLD 200
#RED-MAX-MARKING-PROBABILITY 0.1
#RED-QUEUE-WEIGHT .0001
#RED-TYPICAL-PACKET-TRANSMISSION-TIME 64000NS

##############################
#
#ROUTING-PROTOCOL BELLMANFORD
#ROUTING-PROTOCOL AODV
#ROUTING-PROTOCOL DSR
#ROUTING-PROTOCOL LAR1
#ROUTING-PROTOCOL WRP
#ROUTING-PROTOCOL FISHEYE

#ROUTING-PROTOCOL ZRP
#ZONE-RADIUS 2
ROUTING-PROTOCOL ARAN
#ROUTING-PROTOCOL STATIC
#STATIC-ROUTE-FILE ROUTES.IN

#
# The following is used to setup applications such as FTP and Telnet.
# The file will need to contain parameters that will be use to
# determine connections and other characteristics of the particular
# application.
#

APP-CONFIG-FILE ./all-app.conf

#
# The following parameters determine if you are interested in the
# statistics of a single or multiple layer. By specifying the
# following parameters as YES, the simulation will provide you with
# statistics for that particular layer. All the statistics are
# compiled together into a file called "GLOMO.STAT" that is produced
# at the end of the simulation. If you need the statistics for a
# particular node or particular protocol, it is easy to do the
# filtering. Every single line in the file is of the following
# format:
# Node: 9, Layer: RadioNoCapture, Total number of collisions is
# 0
#

APPLICATION-STATISTICS YES
TCP-STATISTICS YES
UDP-STATISTICS YES
ROUTING-STATISTICS YES

104
NETWORK-LAYER-STATISTICS YES
MAC-LAYER-STATISTICS YES
RADIO-LAYER-STATISTICS YES
CHANNEL-LAYER-STATISTICS YES
MOBILITY-STATISTICS YES

#
# GUI-OPTION: YES allows GloMoSim to communicate with the Java Gui
# Vis Tool
# NO does not

GUI-OPTION YES
GUI-RADIO YES
GUI-ROUTING YES
This is the second Glomosim configuration file:

# ***** GloMoSim Configuration File *****

#
# Anything following a "#" is treated as a comment.
#
#####################################################################
##########
#
# The following parameter represents the maximum simulation time. The
# numbered portion can be followed by optional letters to modify the
# simulation time.
# For example:
# 100NS - 100 nano-seconds
# 100MS - 100 milli-seconds
# 100S - 100 seconds
# 100 - 100 seconds (default case)
# 100M - 100 minutes
# 100H - 100 hours
# 100D - 100 days
#

SIMULATION-TIME 15M

#
# The following is a random number seed used to initialize part of
# the seed of various randomly generated numbers in the simulation.
# This can be used to vary the seed of the simulation to see the
# consistency of the results of the simulation.
#

SEED 1

#
# The following two parameters stand for the physical terrain in
# which the nodes are being simulated. For example, the following
# represents an area of size 100 meters by 100 meters. All range
# parameters are in terms of meters.
#
# Terrain Area we are simulating.
#

TERRAIN-DIMENSIONS (670, 670)

105
# The following parameter represents the number of nodes being
# simulated.
#

NUMBER-OF-NODES 20

#
#The following parameter represents the node placement strategy.
#- RANDOM: Nodes are placed randomly within the physical terrain.
#- UNIFORM: Based on the number of nodes in the simulation, the
# physical terrain is divided into a number of cells. Within each
# cell, a node is placed randomly.
#- GRID: Node placement starts at (0, 0) and are placed in grid
# format with each node GRID-UNIT away from its neighbors. The number
# of nodes has to be square of an integer.
#- FILE: Position of nodes is read from NODE-PLACEMENT-FILE. On each
# line of the file, the x and y position of a single node is
# separated by a space.
#

# NODE-PLACEMENT FILE
# NODE-PLACEMENT-FILE ./nodes.input
# NODE-PLACEMENT GRID
# GRID-UNIT 30
#NODE-PLACEMENT UNIFORM
NODE-PLACEMENT RANDOM
#
# The following represent parameters for mobility. If MOBILITY is set
# to NO, than there is no movement of nodes in the model. For the
# RANDOM-DRUNKEN model, if a node is currently at position (x, y), it
# can possibly move to (x-1, y), (x+1, y), (x, y-1), and (x, y+1); as
# long as the new position is within the physical terrain. For random
# waypoint, a node randomly selects a destination from the physical
# terrain. It moves in the direction of the destination in a speed
# uniformly chosen between MOBILITY-WP-MIN-SPEED and MOBILITY-WP-MAX-
# SPEED (meter/sec). After it reaches its destination, the node stays
# there for MOBILITY-WP-PAUSE time period. The MOBILITY-INTERVAL is
# used in some models that a node updates its position every
# MOBILITY-INTERVAL time period. The MOBILITY-D-UPDATE is used that a
# node updates its position based on the distance (in meters).
#

#MOBILITY NONE

# Random Waypoint and its required parameters.

MOBILITY RANDOM-WAYPOINT
MOBILITY-WP-PAUSE 30S
MOBILITY-WP-MIN-SPEED 10
MOBILITY-WP-MAX-SPEED 10

#MOBILITY TRACE
#MOBILITY-TRACE-FILE ./mobility.in

#MOBILITY PATHLOSS-MATRIX

# The following parameters are necessary for all the mobility models

MOBILITY-POSITION-GRANULARITY 0.5

106
#####################################################################
#
# PROPAGATION-LIMIT:
# Signals with powers below PROPAGATION-LIMIT (in dBm)
# are not delivered. This value must be smaller than
# RADIO-RX-SENSITIVITY + RADIO-ANTENNA-GAIN of any node
# in the model. Otherwise, simulation results may be
# incorrect. Lower value should make the simulation more
# precise, but it also make the execution time longer.
#
PROPAGATION-LIMIT -111.0

#
# PROPAGATION-PATHLOSS: pathloss model
# FREE-SPACE:
# Friss free space model.
# (path loss exponent, sigma) = (2.0, 0.0)
# TWO-RAY:
# Two ray model. It uses free space path loss
# (2.0, 0.0) for near sight and plane earth
# path loss (4.0, 0.0) for far sight. The antenna
# height is hard-coded in the model (1.5m).
# PATHLOSS-MATRIX:
#
#PROPAGATION-PATHLOSS FREE-SPACE
PROPAGATION-PATHLOSS TWO-RAY
#PROPAGATION-PATHLOSS PATHLOSS-MATRIX

#
# NOISE-FIGURE: noise figure
#
NOISE-FIGURE 10.0

#
# TEMPARATURE: temparature of the environment (in K)
#
TEMPARATURE 290.0

#########################################
#
# RADIO-TYPE: radio model to transmit and receive packets
# RADIO-ACCNOISE: standard radio model
# RADIO-NONOISE: abstract radio model
# (RADIO-NONOISE is compatible with the current version (2.1b5)
# of ns-2 radio model)
#
RADIO-TYPE RADIO-ACCNOISE
#RADIO-TYPE RADIO-NONOISE

#
# RADIO-FREQUENCY: frequency (in heltz) (Identifying variable for
# multiple radios)
#
RADIO-FREQUENCY 2.4e9

#
# RADIO-BANDWIDTH: bandwidth (in bits per second)
#
RADIO-BANDWIDTH 2000000

107
#
# RADIO-RX-TYPE: packet reception model
# SNR-BOUNDED:
# If the Signal to Noise Ratio (SNR) is more than
# RADIO-RX-SNR-THRESHOLD (in dB), it receives the signal
# without error. Otherwise the packet is dropped.
# RADIO-RX-SNR-THRESHOLD needs to be specified.
# BER-BASED:
# It looks up Bit Error Rate (BER) in the SNR - BER table
# specified by BER-TABLE-FILE.
#
RADIO-RX-TYPE SNR-BOUNDED
RADIO-RX-SNR-THRESHOLD 10.0
#RADIO-RX-SNR-THRESHOLD 8.49583

#RADIO-RX-TYPE BER-BASED
#BER-TABLE-FILE ./ber_bpsk.in

#
# RADIO-TX-POWER: radio transmition power (in dBm)
#
RADIO-TX-POWER 7.9
# 15.0

#
# RADIO-ANTENNA-GAIN: antenna gain (in dB)
#
RADIO-ANTENNA-GAIN 0.0

#
# RADIO-RX-SENSITIVITY: sensitivity of the radio (in dBm)
#
RADIO-RX-SENSITIVITY -91.0

#
# RADIO-RX-THRESHOLD: Minimum power for received packet (in dBm)
#
RADIO-RX-THRESHOLD -81.0

#
##############################
#

MAC-PROTOCOL 802.11
#MAC-PROTOCOL CSMA
#MAC-PROTOCOL MACA

#MAC-PROTOCOL TSMA
#TSMA-MAX-NODE-DEGREE 8

#MAC-PROPAGATION-DELAY 1000NS

#
# PROMISCUOUS-MODE defaults to YES and is necessary if nodes want
# to overhear packets destined to the neighboring node. Currently
# this option needs to be set to YES only for DSR is selected
# as routing protocol. Setting it to "NO" may save a trivial amount
# of time for other protocols.

108
#PROMISCUOUS-MODE NO

##############################
#
# Currently the only choice.

NETWORK-PROTOCOL IP
NETWORK-OUTPUT-QUEUE-SIZE-PER-PRIORITY 100

#RED-MIN-QUEUE-THRESHOLD 150
#RED-MAX-QUEUE-THRESHOLD 200
#RED-MAX-MARKING-PROBABILITY 0.1
#RED-QUEUE-WEIGHT .0001
#RED-TYPICAL-PACKET-TRANSMISSION-TIME 64000NS

##############################
#
#ROUTING-PROTOCOL BELLMANFORD
#ROUTING-PROTOCOL AODV
#ROUTING-PROTOCOL DSR
#ROUTING-PROTOCOL LAR1
#ROUTING-PROTOCOL WRP
#ROUTING-PROTOCOL FISHEYE

#ROUTING-PROTOCOL ZRP
#ZONE-RADIUS 2
ROUTING-PROTOCOL ARAN
#ROUTING-PROTOCOL STATIC
#STATIC-ROUTE-FILE ROUTES.IN

#
# The following is used to setup applications such as FTP and Telnet.
# The file will need to contain parameters that will be use to
# determine connections and other characteristics of the particular
# application.
#

APP-CONFIG-FILE ./all-app.conf

#
# The following parameters determine if you are interested in the
# statistics of a single or multiple layer. By specifying the
# following parameters as YES, the simulation will provide you with
# statistics for that particular layer. All the statistics are
# compiled together into a file called "GLOMO.STAT" that is produced
# at the end of the simulation. If you need the statistics for a
# particular node or particular protocol, it is easy to do the
# filtering. Every single line in the file is of the following
# format:
# Node: 9, Layer: RadioNoCapture, Total number of collisions is
# 0
#

APPLICATION-STATISTICS YES
TCP-STATISTICS YES
UDP-STATISTICS YES
ROUTING-STATISTICS YES
NETWORK-LAYER-STATISTICS YES
MAC-LAYER-STATISTICS YES

109
RADIO-LAYER-STATISTICS YES
CHANNEL-LAYER-STATISTICS YES
MOBILITY-STATISTICS YES

#
# GUI-OPTION: YES allows GloMoSim to communicate with the Java Gui
# Vis Tool
# NO does not

GUI-OPTION YES
GUI-RADIO YES
GUI-ROUTING YES

110
Appendix E: Glomosim’s Application Configuration File

This appendix presents the Glomosim’s application configuration file. This file is

used to set the traffic generators for the data of the simulations.

# ---------------------------------------------------------------
# CBR
#
# CBR simulates a constant bit rate generator. In order to use CBR,
# the following format is needed:
#
# CBR <src> <dest> <items to send> <item size>
# <interval> <start time> <end time>
#
# where
#
# <src> is the client node.
# <dest> is the server node.
# <items to send> is how many application layer items to send.
# <item size> is size of each application layer item.
# <interval> is the inter-departure time between the application
# layer items.
# <start time> is when to start CBR during the simulation.
# <end time> is when to terminate CBR during the simulation.
#
# If <items to send> is set to 0, CBR will run until the specified
# <end time> or until the end of the simulation, which ever comes
# first.
# If <end time> is set to 0, CBR will run until all <items to
# send> is transmitted or until the end of simulation, which ever
# comes first.
# If <items to send> and <end time> are both greater than 0, CBR will
# will run until either <items to send> is done, <end time> is
# reached, or the simulation ends, which ever comes first.
#
# EXAMPLE:
#
# a) CBR 0 1 10 1460 1S 0S 600S
#
# Node 0 sends node 1 ten items of 1460B each at the start of
# the simulation up to 600 seconds into the simulation. The
# inter-departure time for each item is 1 second. If the ten items
# are sent before 600 seconds elapsed, no other items are sent.
#
# b) CBR 0 1 0 1460 1S 0S 600S
#
# Node 0 continuously sends node 1 items of 1460B each at the
# start of the simulation up to 600 seconds into the simulation. The
# inter-departure time for each item is 1 second.
#
# c) CBR 0 1 0 1460 1S 0S 0S
#
# Node 0 continuously sends node 1 items of 1460B each at the
# start of the simulation up to the end of the simulation. The
# inter-departure time for each item is 1 second.

111
#
# ---------------------------------------------------------------
CBR 18 16 1000 512 0.25S 0S 0S
CBR 10 12 1000 512 0.25S 0S 0S
CBR 19 0 1000 512 0.25S 0S 0S
CBR 14 17 1000 512 0.25S 0S 0S
CBR 13 12 1000 512 0.25S 0S 0S

112
Appendix F: Different Simulation and Linux Scripts

This appendix presents the different simulation and Linux scripts that were created

and used to facilitate the analysis and correlation of the Glomosim simulation runs.

aran-main-script.sh

This is the main script that is called under Linux to run different shell scripts that

were created for different percentages of selfish nodes. Its content is as follows:

./aran-script-for-20-nodes-0selfish.sh
./aran-script-for-20-nodes-10selfish.sh
./aran-script-for-20-nodes-20selfish.sh
./aran-script-for-20-nodes-30selfish.sh

aran-script-for-20-nodes-20selfish.sh

This is one of the files that the main script calls to start the Glomosim simulation

package with a specific configuration file passed to it. Each of these passed configuration

files represent different nodes’ speeds: 0, 1, 5 and 10 (m/s). Then, the output of the

simulation is archived for further analysis of it later on. Its content is as follows:

date;./glomosim 20-0-aran-config.in >/mnt/hgfs/ARAN/why.txt ;date;mv

glomo.stat 20-0-aran-stats/20percent-selfish/20-0-aran-stat#1.txt;cat
/mnt/hgfs/ARAN/why.txt |grep SELFISH > 20-0-aran-stats/20percent-
selfish/20-0-aran-selfish#1.txt;rm -f /mnt/hgfs/ARAN/why.txt

date;./glomosim 20-1-aran-config.in >/mnt/hgfs/ARAN/why.txt ;date;mv

glomo.stat 20-1-aran-stats/20percent-selfish /20-1-aran-
stat#1.txt;cat /mnt/hgfs/ARAN/why.txt |grep SELFISH > 20-1-aran-
stats/20percent-selfish/20-1-aran-selfish#1.txt;rm -f
/mnt/hgfs/ARAN/why.txt

date;./glomosim 20-5-aran-config.in >/mnt/hgfs/ARAN/why.txt ;date;mv

glomo.stat 20-5-aran-stats/20percent-selfish/20-5-aran-stat#1.txt;cat
/mnt/hgfs/ARAN/why.txt |grep SELFISH > 20-5-aran-stats/20percent-
selfish/20-5-aran-selfish#1.txt;rm -f /mnt/hgfs/ARAN/why.txt

date;./glomosim 20-10-aran-config.in >/mnt/hgfs/ARAN/why.txt ;date;mv

glomo.stat 20-10-aran-stats/20percent-selfish/20-10-aran-
stat#1.txt;cat /mnt/hgfs/ARAN/why.txt |grep SELFISH > 20-10-aran-
stats/20percent-selfish/20-10-aran-selfish#1.txt;rm -f
/mnt/hgfs/ARAN/why.txt

113
20-10-aran-stat#1.txt

This is a part of one of the files that was generated by the Glomosim simulation

package as a result of one of my simulation runs. Its content is as follows:

Node: 0, Layer: RadioAccnoise, Signals transmitted: 3073

Node: 0, Layer: RadioAccnoise, Signals arrived with power
above RX sensitivity: 47109
Node: 0, Layer: RadioAccnoise, Signals arrived with power
above RX threshold: 21376
Node: 0, Layer: RadioAccnoise, Signals received and forwarded
to MAC: 18433
Node: 0, Layer: RadioAccnoise, Collisions: 1326
Node: 0, Layer: RadioAccnoise, Energy consumption (in mWhr):
225.039
Node: 0, Layer: 802.11, pkts from network: 0
Node: 0, Layer: 802.11, UCAST (non-frag) pkts sent to
chanl: 207
Node: 0, Layer: 802.11, BCAST pkts sent to chanl: 180
Node: 0, Layer: 802.11, UCAST pkts rcvd clearly: 1179
Node: 0, Layer: 802.11, BCAST pkts rcvd clearly: 1091
Node: 0, Layer: 802.11, retx pkts due to CTS timeout:
42
Node: 0, Layer: 802.11, retx pkts due to ACK timeout:
13
Node: 0, Layer: 802.11, pkt drops due to retx limit: 2
Node: 0, Layer: 802.11, RTS Packets ignored due to Busy
Channel 121
Node: 0, Layer: 802.11, RTS Packets ignored due to NAV
51
Node: 0, Layer: RoutingAran, Number of Route Requests (RDP)
Txed = 180
Node: 0, Layer: RoutingAran, Number of Route Replies (REP)
Txed = 21
Node: 0, Layer: RoutingAran, Number of Route Errors (ERR)
Txed = 4
Node: 0, Layer: RoutingAran, Number of Route Errors (ERR)
Re-sent = 0
Node: 0, Layer: RoutingAran, Number of CTRL Packets (RDP +
REP) Txed = 201
Node: 0, Layer: RoutingAran, Number of Routes Selected = 0
Node: 0, Layer: RoutingAran, Number of Total Routes
Discovered = 0
Node: 0, Layer: RoutingAran, Number of Routes Containing
Malicious Nodes = 0
Node: 0, Layer: RoutingAran, Number of Hop Counts = 0
Node: 0, Layer: RoutingAran, Total Route Acquisition Delay =
0
Node: 0, Layer: RoutingAran, Number of Data Txed = 184
Node: 0, Layer: RoutingAran, Number of Data Packets
Originated = 0
Node: 0, Layer: RoutingAran, Number of Data Packets Sent Out
from Source (after finding route) = 0
Node: 0, Layer: RoutingAran, Number of Data Packets That
Passed Through Malicious Nodes = 213

114
Node: 0, Layer: RoutingAran, Number of Data Packets Received
= 986
Node: 0, Layer: RoutingAran, Number of Data Packets Hops =
1854
Node: 0, Layer: RoutingAran, Number of Packets Dropped = 0
Node: 0, Layer: RoutingAran, Number of Packets Left waiting
for Route = 0
Node: 0, Layer: RoutingAran, Number of Broken Links = 2
Node: 0, Layer: RoutingAran, Number of Broken Link Retries =
0
Node: 0, Layer: RoutingAran, Number of Control bytes
transmitted = 45692
Node: 0, Layer: RoutingAran, Number of Control packets
transmitted = 205
Node: 0, Layer: NetworkIp, Number of Packet Attempted to
be Sent to MAC: 389
Node: 0, Layer: NetworkIp, Number of Packets Routed For
Another Node: 184
Node: 0, Layer: NetworkIp, Number of Packets Delivered To
this Node: 986
Node: 0, Layer: NetworkIp, Total of the TTL's of Delivered
Packets: 61250
Node: 0, Layer: NetworkIp, Average Hop Count Assuming 64
Initial TTL 1.000000
Node: 0, Layer: NetworkIp, Number Fragments dropped
because Node was Unreachable: 0
Node: 0, Layer: NetworkIp, Number Fragments dropped
because TTL expired: 0
Node: 0, Layer: TransportUdp, Number of pkts from application
0.
Node: 0, Layer: TransportUdp, Number of pkts to application
986.
Node: 0, Layer: AppCbrServer, (0) Client address: 19
Node: 0, Layer: AppCbrServer, (0) First packet received at
[s]: 0.044893348
Node: 0, Layer: AppCbrServer, (0) Last packet received at
[s]: 249.771668389
Node: 0, Layer: AppCbrServer, (0) Average end-to-end delay
[s]: 0.023759505
Node: 0, Layer: AppCbrServer, (0) Session status: Closed
Node: 0, Layer: AppCbrServer, (0) Total number of bytes
received: 504832
Node: 0, Layer: AppCbrServer, (0) Total number of packets
received: 986
Node: 0, Layer: AppCbrServer, (0) Throughput (bits per
second): 16172

Network Throughput.sh

This shell script file is used to measure the network throughput metric. The

Glomosim output file, such as the above 20-10-aran-stat#1.txt, is being passed to this shell

script to collect values related to the network throughput metric. Then, the results of this

115
shell script are redirected to another Linux AWK script to do the actual calculation. Its

content is as follows:

grep -e 'AppCbrServer, (0) Total number of packets received:' -e

'AppCbrClient, (0) Total number of packets sent:' $1 | awk -f
Network-Throughput.awk

Network-Throughput.awk

This AWK script file is used to do the calculation of the network throughput metric

and then print it out. Its content is as follows:

BEGIN { sumcountrcv = 0;
sumcountsent=0 }
{
if ($4=="AppCbrServer," && $10=="received:"){sumcountrcv+=$11}
if ($4=="AppCbrClient," && $10=="sent:"){sumcountsent+=$11}
}
END { printf("Packet received = %d \n",sumcountrcv);
printf("Packet sent = %d \n",sumcountsent);
printf("Network Throughput = %f
\n",sumcountrcv/sumcountsent)}

Overhead-bytes.sh

This shell script file is used to measure the overhead metric in bytes. The Glomosim

output file, such as the above 20-10-aran-stat#1.txt, is being passed to this shell script to

collect values related to the overhead metric. Then, the results of this shell script are

redirected to another Linux AWK script to do the actual calculation. Its content is as

follows:

grep -e 'RoutingAran, Number of Data Txed =' -e 'RoutingAran, Number

of Control bytes transmitted =' $1 | awk -f Overhead-bytes.awk

Overhead-bytes.awk

This AWK script file is used to do the calculation of the overhead metric in bytes and

then print it out. Its content is as follows:

BEGIN { sumctrlbytes = 0;
sumdatapkts=0 }
{
if ($4=="RoutingAran," && $7=="Control" &&
$8=="bytes"){sumctrlbytes+=$11}
if ($4=="RoutingAran," && $7=="Data" && $8=="Txed"){sumdatapkts+=$10}

116
}
END { if (sumdatapkts>0)
{printf("Routing Control bytes = %d \n",sumctrlbytes);
printf("Routing Data packets = %d \n",sumdatapkts);
printf("Overhead(bytes) = %f \n",sumctrlbytes/sumdatapkts)}
}

Overhead-packets.sh

This shell script file is used to measure the overhead metric in packets. The

Glomosim output file, such as the above 20-10-aran-stat#1.txt, is being passed to this shell

script to collect values related to the overhead metric. Then, the results of this shell script

are redirected to another Linux AWK script to do the actual calculation. Its content is as

follows:

grep -e 'RoutingAran, Number of Data Txed =' -e 'RoutingAran, Number

of Control packets transmitted =' $1 | awk -f Overhead-packets.awk

Overhead-packets.awk

This AWK script file is used to do the calculation of the overhead metric in packets

and then print it out. Its content is as follows:

BEGIN { sumctrlpkts = 0;
sumdatapkts=0 }
{
if ($4=="RoutingAran," && $7=="Control" &&
$8=="packets"){sumctrlpkts+=$11}
if ($4=="RoutingAran," && $7=="Data" && $8=="Txed"){sumdatapkts+=$10}
}
END { if (sumdatapkts>0)
{printf("Routing Control packets = %d \n",sumctrlpkts);
printf("Routing Data packets = %d \n",sumdatapkts);
printf("Overhead(packets) = %f \n",sumctrlpkts/sumdatapkts)}
}

Average-end-to-end-delay.sh

This shell script file is used to measure the average end-to-end delay metric. The

Glomosim output file, such as the above 20-10-aran-stat#1.txt, is being passed to this shell

script to collect values related to the end-to-end delay metric. Then, the results of this shell

117
script are redirected to another Linux AWK script to do the actual calculation. Its content is

as follows:

grep -e 'AppCbrServer, (0) Average end-to-end delay' $1 | awk -f

Average-end-to-end-delay.awk

Average-end-to-end-delay.awk

This AWK script file is used to do the calculation of the average end-to-end delay

metric and then print it out. Its content is as follows:

BEGIN { sum_average_end_to_end_delay = 0;
count= 0 }
{
if ($4=="AppCbrServer," && $6=="Average" && $7=="end-to-
end"){sum_average_end_to_end_delay +=$10;
count+=1}
}
END { printf("End-to-end-delay = %f
\n",sum_average_end_to_end_delay);
printf("Count of Average-end-to-end-delay = %f \n",count);
printf("Average-end-to-end-delay = %f
\n",sum_average_end_to_end_delay/count)}

Average-Route-Acquisition-Delay.sh

This shell script file is used to measure the average route acquisition delay metric.

The Glomosim output file, such as the above 20-10-aran-stat#1.txt, is being passed to this

shell script to collect values related to the route acquisition delay metric. Then, the results

of this shell script are redirected to another Linux AWK script to do the actual calculation.

Its content is as follows:

grep -e 'RoutingAran, Total Route Acquisition Delay =' $1 | awk -f

Average-Route-Acquisition-Delay.awk

Average-Route-Acquisition-Delay.awk

This AWK script file is used to do the calculation of the average route acquisition

delay metric and then print it out. Its content is as follows:

BEGIN { sum-route-acq-delay = 0;
count = 0 }
{
if ($4=="RoutingAran," && $7="Acquisition" && $8=="Delay"){sum-route-
acq-delay+=$10;

118
 count+=1}
}
END { if (count>0)
{printf("Routing: Route Acquisition Delay = %d \n",sum-
route-acq-delay);
printf("Count of Route Acquisition Delay = %d \n",count);
printf("Routing: Average Route Acquisition Delay = %d
\n",sum-route-acq-delay/count)}
}

Average-Path-Length.sh

This shell script file is used to measure the average path length metric. The

Glomosim output file, such as the above 20-10-aran-stat#1.txt, is being passed to this shell

script to collect values related to the average path length metric. Then, the results of this

shell script are redirected to another Linux AWK script to do the actual calculation. Its

content is as follows:

grep -e 'RoutingAran, Number of Data Txed =' -e 'RoutingAran, Number

of Data Packets Hops =' $1 | awk -f Average-Path-Length.awk

Average-Path-Length.awk

This AWK script file is used to do the calculation of the average path length metric

and then print it out. Its content is as follows:

BEGIN { sumdatapktshops = 0;
sumdatapkts = 0 }
{
if ($4=="RoutingAran," && $7=="Data" && $8=="Txed")
{sumdatapkts+=$10}

if ($4=="RoutingAran," && $7="Data" && $9=="Hops")

{sumdatapktshops+=$11}

}
END {
if (sumdatapktshops>0)
{printf("Routing Data Packets Hops = %f
\n",sumdatapktshops);
printf("Routing Data packets = %f \n",sumdatapkts);
printf("Average Path Length = %f
\n",sumdatapkts/sumdatapktshops)}
}

119
Appendix G: Random number generator to designate selfish nodes

This appendix presents the source code of the random number generator that is used

to select the selfish nodes. I set the percentage of selfish nodes in my MANET

environment and then I mod the nodes’ addresses over the percentage of selfish nodes and

those resulting in a predefined result are designated as selfish nodes. Here is the code that

was used:

//Setting the selfish nodes’ percentage

SelfishNodesPercentage=10;

aran->isSelfish =
if(SelfishNodesPercentage >= 10)
{
if(node->nodeAddr % 10 == 5)
aran->isSelfish = 1;
}
if(SelfishNodesPercentage >= 20)
{
if(node->nodeAddr % 10 == 6)
aran->isSelfish = 1;
}
if(SelfishNodesPercentage >= 30)
{
if(node->nodeAddr % 10 == 7)
aran->isSelfish = 1;
}

120