Submitted For Partial Fulfillment For The Award of The Degree

PROJECT REPORT
On
DEFENDING AGAINST COLLABORATIVE ATTACKS BY MALICIOUS NODES IN
MOBILE AD-HOC NETWORKS
Submitted for partial fulfillment for the award of the degree
BACHELOR OF TECHNOLOGY
in
ELECTRONICS AND COMMUNICATION ENGINEERING
by
VENKATESH PYDE
(1041110200)
AVINASH CHOWDARY KOGANTI
(1041110215)
PAVAN NALLAGORLA
(1041110219)
Under the guidance of

Mr. S. BASHYAM
(Assistant Professor (O.G), Department of Electronics and Communication Engineering)
DEPARTMENT OF ELECTRONICS & COMMUNICATION ENGINEERING

FACULTY OF ENGINEERING AND TECHNOLOGY
SRM UNIVERSITY, KATTANKULATHUR- 603 203
APRIL 2015
DEPARTMENT OF ELECTRONICS & COMMUNICATION ENGINEERING
FACULTY OF ENGINEERING AND TECHNOLOGY
SRM UNIVERSITY, KATTANKULATHUR 603 203
BONAFIDE CERTIFICATE
1
Certified that this project report titled DEFENDING AGAINST COLLABORATIVE

ATTACKS BY MALICIOUS NODES IN MOBILE AD-HOC NETWORKS is the
Bonafide work of Mr. VENKATESH PYDE (Reg. No.1041110200), Mr. AVINASH
CHOWDARY KOGANTI (Reg. No. 1041110215) and Mr. PAVAN NALLAGORLA
(Reg. No. 1041110219) who carried out the project work under my supervision as a batch.
Certified further, that to the best of my knowledge the work reported herein does not form
any other project report on the basis of which a degree or award was conferred on an earlier
occasion for this or any other candidate.
Project guide
Head of the Department
(Mr. S. Bashyam)
(Dr. S. Malarvizhi)
Date:
Submitted for University Examination held in April 2015 at SRM UNIVERSITY, S.R.M.
Nagar, Kattankulathur, Kancheepuram District -603 203.
Date:
Internal Examiner
External Examiner
ACKNOWLEDGEMENT
We express our sincere gratitude and thanks to our Management for giving us a wonderful
chance to show our attitude towards our career and gain knowledge.
We extend our humble and sincere thanks to our Head of the Department, Dr. S
Malarvizhi, Department of Electronics and communication for her moral support
encouragement throughout the development of our project work.
We express our heartful gratitude and thanks to our project coordinator, Mrs. R.
Bhakkiyalakshmi, Assistant professor (O.G), Electronics and Communication Department
for providing moral support and motivation.
We are indebted to our guide Mr. S. Bashyam, Assistant Professor (O.G), Department of
Electronics and Communication for his valuable guidance, encouragement and timely
help throughout our project work.
We extend our sincere thanks to all other faculty of our department for their kind cooperation and help in completing our project.
Finally we would like to thank our parents and our friends whose kind encouragement,
affection and moral support have helped us to complete the project successfully.
ABSTRACT
In mobile ad hoc networks (MANETs), a primary requirement for the establishment

of communication among nodes is that nodes should cooperate with each other. In the
presence of malevolent nodes, this requirement may lead to serious security concerns; for
instance, such nodes may disrupt the routing process. In this context, preventing or detecting
malicious nodes launching gray-hole or collaborative black-hole attacks is a challenge. This
paper attempts to resolve this issue by designing a routing mechanism, which is an
improvement to the existing cooperative bait detection scheme (CBDS), which integrates the
advantages of both proactive and reactive defence architectures.
Our method implements a reverse tracing technique to help in achieving the stated
goal. Simulation results are provided, showing that in the presence of malicious-node attacks,
this method outperforms the DSR, 2ACK, and best-effort fault-tolerant routing (BFTR)
protocols (chosen as benchmarks) in terms of packet delivery ratio and end to end delay
(chosen as performance metrics).
CHAPTER 1
INTRODUCTION
Due to the widespread availability of mobile devices, mobile ad-hoc networks have been
widely used for various operations such as military crisis operations and emergency
preparedness and response operations. This is primarily due to their infrastructureless
property. In a MANET, each node not only works as a host but can also act as a router. While
receiving data, nodes also need cooperation with each other to forward the data packets,
thereby forming a wireless local area network [3]. These great features also come with
serious drawbacks from a security point of view. Indeed, the aforementioned applications
impose some stringent constraints on the security of the network topology, routing, and data
traffic. For instance, the presence and collaboration of malicious nodes in the network may
disrupt the routing process, leading to a malfunctioning of the network operations.
Many research works have focused on the security of MANETs. Most of them deal with
prevention and detection approaches to combat individual misbehaving nodes. In this regard,
the effectiveness of these approaches becomes weak when multiple malicious nodes collude
together to initiate a collaborative attack, which may result to more devastating damages to
the network.
The lack of any infrastructure added with the dynamic topol-ogy feature of MANETs make
these networks highly vulnera-ble to routing attacks such as blackhole and grayhole (known
as variants of blackhole attacks). In blackhole attacks (see Fig. 1), a node transmits a
malicious broadcast informing that it has the shortest path to the destination, with the goal of
intercepting messages. In this case, a malicious node (so-called blackhole node) can attract all
packets by using forged Route Reply (RREP) packet to falsely claim that fake shortest
route to the destination and then discard these packets without forwarding them to the
destination. In grayhole attacks, the malicious node is not initially recognized as such since it
turns malicious only at a later time, preventing a trust-based security solution from detecting
its presence in the network. It then selectively discards/forwards the data packets when
packets go through it. In this paper, our focus is on detecting grayhole/collaborative blackhole
attacks using a dynamic source routing (DSR)-based routing technique.
DSR [4] involves two main processes: route discovery and route maintenance. To execute
the route discovery phase, the source node broadcasts a Route Request (RREQ) packet
through the network. If an intermediate node has routing in-formation to the destination in its
route cache, it will reply with a RREP to the source node. When the RREQ is forwarded to a
node, the node adds its address information into the route record in the RREQ packet. When
destination receives the RREQ, it can know each intermediary nodes address among the
route. The destination node relies on the collected routing information among the packets in
order to send a reply RREP message to the source node along with the whole routing
information of the established route. DSR does not have any detection mechanism, but the
source node can get all route information concerning the nodes on the route. In our approach,
we make use of this feature.
In this paper, a mechanism [so-called cooperative bait detec-tion scheme (CBDS)] is
presented that effectively detects the malicious nodes that attempt to launch
grayhole/collaborative blackhole attacks. In our scheme, the address of an adjacent node is
5
used as bait destination address to bait malicious nodes to send a reply RREP message, and
malicious nodes are detected using a reverse tracing technique. Any detected malicious node
is kept in a blackhole list so that all other nodes that participate to the routing of the message
are alerted to stop communicating with any node in that list. Unlike previous works, the merit
of CBDS lies in the fact that it integrates the proactive and reactive defense architectures to
achieve the aforementioned goal.
CHAPTER 2
SYSTEM DESIGN
2.1 SYSTEM ARCHITECTURE:
Proposed Architecture diagram
Neighbor node
Detection
Network creation
Network Activity
Attack
detection
TDMA
Choose
another Route
Data
Transmission
success
Reduce delay
time
CBDS
Approach
Network
Misbehave
Identification
Reverse
Tracing
Technique
Attack Detection
7
Data Transfer
Message Security
DATA FLOW DIAGRAM:

1. The DFD is also called as bubble chart. It is a simple graphical formalism that can be
used to represent a system in terms of input data to the system, various processing
carried out on this data, and the output data is generated by this system.
2. The data flow diagram (DFD) is one of the most important modeling tools. It is used
to model the system components. These components are the system process, the data
used by the process, an external entity that interacts with the system and the
information flows in the system.
3. DFD shows how the information moves through the system and how it is modified by
a series of transformations. It is a graphical technique that depicts information flow
and the transformations that are applied as data moves from input to output.
4. DFD is also known as bubble chart. A DFD may be used to represent a system at any
level of abstraction. DFD may be partitioned into levels that represent increasing
information flow and functional detail.
Data Flow Diagram:
Level 0:
Source
Intermediate Nodes
Neighbor Nodes
Level 1:
Source
Request to one hop

neighbor node
Neighbor node
Sent destination address
Level 2:
Source
Send GHELLO message
Route
identification
Intermediates node
Receiver node
Sent ACK and path

address
Level 3:
Source
Intermediate nodes
Normal Mode
9
ACK-Mode
Malicious Node
Sent fake destination

path to sender
Reverse
Tracing
technique
Detect malicious
node
Receiver
CBDS
Detect Exact
malicious node
UML DIAGRAMS
UML stands for Unified Modeling Language. UML is a standardized general-purpose
modeling language in the field of object-oriented software engineering. The standard is
managed, and was created by, the Object Management Group.
The goal is for UML to become a common language for creating models of object
oriented computer software. In its current form UML is comprised of two major components:
a Meta-model and a notation. In the future, some form of method or process may also be
10
added to; or associated with, UML.

The Unified Modeling Language is a standard language for specifying, Visualization,
Constructing and documenting the artifacts of software system, as well as for business
modeling and other non-software systems.
The UML represents a collection of best engineering practices that have proven
successful in the modeling of large and complex systems.
The UML is a very important part of developing objects oriented software and the
software development process. The UML uses mostly graphical notations to express the
design of software projects.
GOALS:
The Primary goals in the design of the UML are as follows:
1. Provide users a ready-to-use, expressive visual modeling Language so that they can
develop and exchange meaningful models.
2. Provide extendibility and specialization mechanisms to extend the core concepts.
3. Be independent of particular programming languages and development process.
4. Provide a formal basis for understanding the modeling language.
5. Encourage the growth of OO tools market.
6. Support higher level development concepts such as collaborations, frameworks,
patterns and components.
7. Integrate best practices.
11
USE CASE DIAGRAM:

A use case diagram in the Unified Modeling Language (UML) is a type of behavioral
diagram defined by and created from a Use-case analysis. Its purpose is to present a graphical
overview of the functionality provided by a system in terms of actors, their goals (represented
as use cases), and any dependencies between those use cases. The main purpose of a use case
diagram is to show what system functions are performed for which actor. Roles of the actors
in the system can be depicted.
CLASS DIAGRAM:
In software engineering, a class diagram in the Unified Modeling Language (UML) is a type
of static structure diagram that describes the structure of a system by showing the system's
classes, their attributes, operations (or methods), and the relationships among the classes. It
explains which class contains information.
12
SEQUENCE DIAGRAM:
A sequence diagram in Unified Modeling Language (UML) is a kind of interaction diagram
that shows how processes operate with one another and in what order. It is a construct of a
Message Sequence Chart. Sequence diagrams are sometimes called event diagrams, event
scenarios, and timing diagrams.
13
CHAPTER 3
SYSTEM SPECIFICATIONS
14
SYSTEM REQUIREMENTS:
HARDWARE REQUIREMENTS:
System
Pentium IV 2.4 GHz.
Hard Disk
40 GB.
Floppy Drive
1.44 Mb.
Monitor
15 VGA Colour.
Mouse
Logitech.
Ram
512 Mb.
SOFTWARE REQUIREMENTS:
Operating system
Windows XP/7/LINUX.
Implementation
NS2
NS2 Version
NS2.2.28
Front End
OTCL
Cygwin (To simulate in Windows OS)
(Object
Oriented
Tool
Language
Tool
15
Command
Chapter 4
SOFTWARE DESCRIPTION
THE NETWORK SIMULATOR 2.33 (NS2)
Network Simulator (NS2) is a discrete event driven simulator developed at UC
Berkeley. It is part of the VINT project. The goal of NS2 is to support networking research
and education. It is suitable for designing new protocols, comparing different protocols and
traffic evaluations. NS2 is developed as a collaborative environment. It is distributed freely
and open source. A large amount of institutes and people in development and research use,
maintain and develop NS2. This increases the confidence in it. Versions are available for
FreeBSD, Linux, Solaris, Windows and Mac OS X.
STRUCTURE OF NS2
NS2 is built using object oriented methods in C++ and OTcl (object oriented variant
of Tcl.
Fig 5.1 Simplified Users View of Ns

can see in Fig 5.1, NS2 interprets the simulation scripts written in OTcl. A user has to set the
different components (e.g. event scheduler objects, network components libraries and setup
module libraries) up in the simulation environment. The user writes his simulation as a OTcl
script, plumbs the network components together to the complete simulation. The event
scheduler as the other major component besides network components triggers the events of
the simulation (e.g. sends packets, starts and stops tracing). Some parts of NS2 are written in
C++ for efficiency reasons. The data path (written in C++) is separated from the control path
(written in OTcl). Data path object are compiled and then made available to the OTcl
16
interpreter through an OTcl linkage (tclcl) which maps methods and member variables of the
C++ object to methods and variables of the linked OTcl object. The C++ objects are
controlled by OTcl objects. It is possible to add methods and member variables to a C++
linked OTcl object.
FUNCTIONALITIES OF NS2.33
Functionalities for wired, wireless networks, tracing, and visualization are available in
NS2.
Support for the wired world include
Routing DV, LS, and PIM-SM.
Transport protocols: TCP and UDP for unicast and SRM for multicast.
Traffic sources: web, ftp, telnet, cbr (constant bit rate), stochastic, real audio.
Different types of Queues: drop-tail, RED, FQ, SFQ, DRR.
Quality of Service: Integrated Services and Differentiated Services.
Emulation.
Support for the wireless world include
Ad hoc routing with different protocols, e.g. AODV, DSR, DSDV, TORA
Wired-cum-wireless networks
Mobile IP
Directed diffusion
Satellite
Senso-MAC
Multiple propagation models (Free space, two-ray ground, shadowing)
Energy models
Tracing
Visualization
Network Animator (NAM)
Trace Graph
17
Fig 5.2 OTcl and C++: the duality

MOBILE NETWORKING IN NS2.33
This section describes the wireless model that was originally ported as CMUs
Monarch groups mobility extension to NS2. The first section covers the original mobility
model ported from CMU/Monarch group. In this section, we cover the internals of a mobile
node, routing mechanisms and network components that are used to construct the network
stack for a mobile node. The components that are covered briefly are Channel, Network
interface, Radio propagation model, MAC protocols, Interface Queue, Link layer and
Address resolution protocol model (ARP). CMU trace support and Generation of node
movement and traffic scenario files are also covered in this section. The original CMU model
allows simulation of pure wireless LANs or multihop ad-hoc networks. Further extensions
were made to this model to allow combined simulation of wired and wireless networks.
MobileIP was also extended to the wireless model.
THE BASIC WIRELESS MODEL IN NS
The wireless model essentially consists of the MobileNode at the core, with additional
supporting features that allows simulations of multi-hop ad-hoc networks, wireless LANs etc.
The MobileNode object is a split object. The C++ class MobileNode is derived from parent
class Node. A MobileNode thus is the basic Node object with added functionalities of a
wireless and mobile node like ability to move within a given topology, ability to receive and
18
transmit signals to and from a wireless channel etc. A major difference between them, though,
is that a MobileNode is not connected by means of Links to other nodes or mobilenodes. In
this section we shall describe the internals of MobileNode, its routing mechanisms, the
routing protocols dsdv, aodv, tora and dsr, creation of network stack allowing channel access
in MobileNode, brief description of each stack component, trace support and
movement/traffic scenario generation for wireless simulations.
MOBILE NODE: CREATING WIRELESS TOPOLOGY
MobileNode is the basic nsNode object with added functionalities like movement,
ability to transmit and receive on a channel that allows it to be used to create mobile, wireless
simulation environments. The class MobileNode is derived from the base class Node.
MobileNode is a split object. The mobility features including node movement, periodic
position updates, maintaining topology boundary etc are implemented in C++ while
plumbing of network components within MobileNode itself (like classifiers, dmux , LL, Mac,
Channel etc) have been implemented in Otcl.
Table 5.1: Available Options For Node Configuration
Option
Available Values
D
efault
General
Address type
Flat, Hierarchical
Fl
at
MPLS
ON,OFF
O
FF
Both Satellite and Wireless Oriented

Wired Routing
ON,OFF
O
FF
II Type
LL,LL/sat
O
FF
Mac Type
ifq Type
Mac/802_11,Mac/Csma/Ca,
Mac/Sat/Unslotted/Aloha,Mac/Tdma
Queue/DropTail,Queue/Droptail/PriQuee
O
FF
O
FF
Phy Type
Phy/wirelessPhy,Physat
O
FF
Option
Available Values
D
efault
Satellite Oriented
19
satNodeTy
Polar,Geo,Terminal,Geo-repeater
downlinkB
<bandwidth value, e.g 2MB>
pe
O
FF
O
FF
Wireless Oriented
Adhoc
DIFFUSION/RATE,DIFFUSION/PROB,DSDV,
Routing
propType
FLOODING,OMNICAST,AODV,TORA
Propagation/2RayGround,Propagation Shadowing
O
FF
O
FF
propInstanc
Propagation/2RayGround,Propagation Shadowing
O
FF
antType
Antenna/Omni Antenna
O
FF
Channel
Channel/Wireless Channel,Channel/sat
topoInstanc
<toplogy file>
MobileIP
ON,OFF
O
FF
O
FF
O
FF
Energy
Energy model
model
FF
Initial
<value in joules>
Energy
O
FF
rxPower
<value in W>
O
FF
txPower
<value in W>
O
FF
Idle Power
<value in W>
O
FF
AgentTrace
ON,OFF
routerTrace
ON,OFF
macTrace
ON,OFF
O
FF
O
FF
O
FF
movement
ON,OFF
Trace
FF
Errproc
UniformErrorProc
O
FF
20
FECProc
toraDebug
?
ON,OFF
?
O
FF
CHAPTER 5
IMPLEMENTATION ENVIRONMENT
Network simulator 2 is used as the simulation tool in this project. NS was chosen as
the simulator partly because of the range of features it provides and partly because it has an
open source code that can be modified and extended.
NETWORK SIMULATOR (NS)
Network simulator (NS) is an objectoriented, discrete event simulator for networking
research. NS provides substantial support for simulation of TCP, routing and multicast
protocols over wired and wireless networks. The simulator is a result of an ongoing effort of
research and developed. Even though there is a considerable confidence in NS, it is not a
polished product yet and bugs are being discovered and corrected continuously.
21
NS is written in C++, with an OTcl1 interpreter as a command and configuration

interface. The C++ part, which is fast to run but slower to change, is used for detailed
protocol implementation. The OTcl part, on the other hand, which runs much slower but can
be changed very fast Quickly, is used for simulation configuration. One of the advantages of
this split-language program approach is that it allows for fast generation of large scenarios.
To simply use the simulator, it is sufficient to know OTcl. On the other hand, one
disadvantage is that modifying and extending the simulator requires programming and
debugging in both languages.
NS can simulate the following:

1. Topology: Wired, wireless
2. Sheduling Algorithms: RED, Drop Tail,
3. Transport Protocols: TCP, UDP
4. Routing: Static and dynamic routing
5. Application: FTP, HTTP, Telnet, Traffic generators
USERS VIEW OF NS-2
Simulation OTcl Script
OTcl Interpreter
Simulation Results
C++ Libraries
Figure 5.1 Block diagram of Architecture of NS-2
NETWORK COMPONENTS
This section talks about the NS components, mostly compound network components.
Figure 1.1 shows a partial OTcl class hierarchy of NS, which will help understanding the
22
basic network components.
Figure 5.2 OTcl Class Hierarchy

The root of the hierarchy is the TclObject class that is the super class of all OTcl
library objects (scheduler, network components, timers and the other objects including NAM
related ones). As an ancestor class of TclObject, NsObject class is the super class of all basic
network component objects that handle packets, which may compose compound network
objects such as nodes and links. The basic network components are further divided into two
subclasses, Connector and Classifier, based on the number of the possible output DATA
paths. The basic network and objects that have only one output DATA path are under the
Connector class, and switching objects that have possible multiple output DATA paths are
under the Classifier class.
CLASS TCL
The class Tcl encapsulates the actual instance of the OTcl interpreter and provides the
methods to access and communicate with that interpreter, code. The class provides methods
for the following operations:
1. Obtain a reference to the Tel instance
2. Invoke OTcl procedures through the interpreter
3. Retrieve, or pass back results to the interpreter
4. Report error situations and exit in a uniform manner
5. Store and lookup "TclObjects"
23
6. Acquire direct access to the interpreter.

Obtain a Reference to the class Tcl instance
A single instance of the class is declared in -tclcl/Tcl.cc as a static member
variable.The statement required to access this instance is Tel& tel = Tcl::instance();
Invoking OTcl Procedures
There are four different methods to invoke an OTcl command through the instance,
tcl. They differ essentially in their calling arguments. Each function passes a string to the
interpreter that then evaluates the string in a global context. These methods will return to the
caller if the interpreter returns TCL_OK. On the other hand, if the interpreter returns
TCL_ERROR, the methods will call tkerror{}. The user can overload this procedure to
selectively disregard certain types of errors.
Passing Results to/from the Interpreter: When the interpreter invokes a C++ method, it
expects the result back in the private member variable, tcl-> result.
Error Reporting and Exit: This method provides a uniform way to report errors in the
compiled code.
MOBILE NETWORKING IN NS
The wireless model essentially consists of the Mobile Node at the core with additional
supporting features that allows simulations of multi-hop ad-hoc networks, wireless LANs etc.
The Mobile Node object is a split object. The C++ class Mobile Node is derived from parent
class Node. A Mobile Node thus is the basic Node object with added functionalities of a
wireless and mobile node like ability to move within a given topology, ability to receive and
transmit signals to and from a wireless channel etc. A major difference between them is that a
mobile Node is not connected by means of Links to other nodes or mobile nodes.
Mobile Node is the basic nsNode object with added functionalities like movement,
ability to transmit and receive on a channel that allows it to be used to create mobile, wireless
simulation environments. The class Mobile Node is derived from the base class Node. The
four ad-hoc routing protocols that are currently supported are, Dynamic Source Routing
(DSR), Temporally ordered Routing Algorithm (TORA) and Adhoc On-demand Distance
Vector (AODV).
The general structure for defining a mobile node in ns2 is described as follows
$ns node-config -adhocRouting $opt (adhocRouting)
-IIType $opt (II)
24
-macType $opt (mac)

-ifqType $opt (ifq) -ifqLen $opt (ifqlen)
-antType $opt (ant)
-proplnstance [new $opt (prop) -phyType $opt (netif)
-channel [new $opt (chan)]
-topolnstance $topo
-wiredRouting OFF
-agentTrace ON
-routerTrace OFF
-macTrace OFF
The above API configures for a mobile node with all the given values of ad hocrouting protocol, network stack, channel, topography, propagation model, with wired routing
turned on or off (required for wired-cum-wireless scenarios) and tracing turned on or off at
different levels (router, mac, agent).
CHAPTER 6
IMPLEMENTATION
MODULES:
Network creation (wireless sensor networks)
Sink &source nodes
Dynamic Source Routing
CBDS
Reverse Tracing Technique

25
Network Creation (Wireless sensor Networks)

Creation of nodes in the wireless networks is the first module that is done using NS2
Software. In this module we deploy the nodes in the network and each node pass the
information through the HELLO packets to its neighbor nodes and update the neighbor node
id, location information in each node in order to find the route. It also create group. If you
enter into the group first you have to send your id to group head.
Composed of many small nodes deployed in an ad hoc fashion
Most communication will be between nodes as peers, rather than to a single base
station
Nodes must self-configure
Dedicated to a single application or a few collaborative applications
Involves in-network processing to reduce traffic and thereby increase the life-time
This implies that data will be processed as whole messages at a time in store-andforward fashion
Hence packet or fragment-level interleaving from multiple sources only delays overall
latency
Applications will have long idle periods and can tolerate some latency
26
SINK &SOURCE NODES:

The sink is the point of contact for users of the sensor network. Each time the sink
receives a question from a user, it first translates the question into multiple queries and then
disseminates the queries to the corresponding mobile relay, which process the queries based
on their data and return the query results to the sink. The sink unifies the query results from
multiple storage nodes into the final answer and sends it back to the user.
The source nodes in our problem formulation serve as storage points which cache the
data gathered by other nodes and periodically transmit to the sink, in response to user queries.
Such network architecture is consistent with the design of storage centric sensor networks.
Our problem formulation also considers the initial positions of nodes and the amount of data
that needs to be transmitted from each storage node to the sink.
27
Dynamic Source Routing

In this module, we focus is on detecting gray hole/collaborative blackhole attacks
using a dynamic source routing based routing technique. DSR involves two main processes:
route discovery and route maintenance. To execute the route discovery phase, the source node
broadcasts a Route Request packet through the network. If an intermediate node has routing
information to the destination in its route cache, it will reply with a RREP to the source node.
When the RREQ is forwarded to a node, the node adds its address information into the route
record in the RREQ packet. When destination receives the RREQ, it can know each
intermediary nodes address among the route. The destination node relies on the collected
routing information among the packets in order to send a reply RREP message to the source
node along with the whole routing information of the established route. DSR does not have
any detection mechanism,
But the source node can get all route information concerning the nodes on the route.
CBDS (Cooperative Bait Detection Approach)

The Cooperative bait detection approach detects the malicious nodes that attempt to
launch gray hole/collaborative blackhole attacks. In our scheme, the address of an adjacent
node is used as bait destination address to bait malicious nodes to send a reply RREP
message, and malicious nodes are detected using a reverse tracing technique. Any detected
malicious node is kept in a blackhole list so that all other nodes that participate to the routing
of the message are alerted to stop communicating with any node in that list. Unlike previous
works, the merit of CBDS lies in the fact that it integrates the proactive and reactive defense
architectures to achieve the aforementioned goal.
28
Reverse Tracing Technique

The Malicious nodes are thereby detected and prevented from participating in the
routing operation, using a reverse tracing technique. The reverse tracing program is used to
detect the behaviors of malicious nodes through the route reply to the RREQ_ message. If a
malicious node has received the RREQ, it will reply with a false RREP. Accordingly, the
reverse tracing operation will be conducted for nodes receiving the RREP, with the goal to
deduce the dubious path information and the temporarily trusted zone in the route. It should
be emphasized that the CBDS is able to detect more than one malicious node simultaneously
when these nodes send reply RREPs.
29
CHAPTER 7
CODING
# ======================================================================
# Define options
# ======================================================================
set val(chan) Channel/WirelessChannel ;# channel type
set val(prop) Propagation/TwoRayGround ;# radio-propagation model
set val(netif) Phy/WirelessPhy ;# network interface type
set val(mac) Mac/802_11 ;# MAC type
set val(ifq) Queue/DropTail/PriQueue ;# interface queue type
set val(ll) LL ;# link layer type
set val(ant) Antenna/OmniAntenna ;# antenna model
set val(ifqlen) 200 ;# max packet in ifq
set val(nn) 50 ;# number of mobilenodes
set val(rp) DSDV ;# routing protocol
set val(x) 5000;# X dimension of topography
set val(y) 5000 ;# Ydimension of topography
set val(stop) 130 ;# time of simulation end
set ns [new Simulator]
set tracefd [open changevoip.tr w]
set namtrace [open changevoip.nam w]
$ns trace-all $tracefd
$ns namtrace-all-wireless $namtrace $val(x) $val(y)
# set up topography object
set topo [new Topography]
$topo load_flatgrid $val(x) $val(y)
create-god $val(nn)
# configure the nodes

$ns node-config -adhocRouting $val(rp) \
-llType $val(ll) \
-macType $val(mac) \
-ifqType $val(ifq) \
-ifqLen $val(ifqlen) \
-antType $val(ant) \
-propType $val(prop) \
-phyType $val(netif) \
-channelType $val(chan) \
-topoInstance $topo \
-agentTrace ON \
30
-routerTrace ON \
-macTrace OFF \
-movementTrace ON
for {set i 0} {$i < $val(nn) } { incr i } {
set n($i) [$ns node]
}
# Provide initial location of mobilenodes
$n(0) set X_ 587.0
$n(0) set Y_ 3.0
$n(0) set Z_ 0.0
$n(1) set X_ 445.0
$n(1) set Y_ 36.0 #36.0
$n(1) set Z_ 0.0
$n(3) set X_ 47.0

$n(3) set Y_ 60.0
$n(3) set Z_ 0.0
$n(5) set X_ 149.0

$n(5) set Y_ 20.0
$n(5) set Z_ 0.0
$n(20) set X_ 300.0

$n(20) set Y_ 01.0
$n(20) set Z_ 0.0
$n(4) set X_ 5.0
$n(4) set Y_ 40.0
$n(4) set Z_ 0.0
$n(7) set X_ 300.0
$n(7) set Y_ 95.0
$n(7) set Z_ 0.0
$n(9) set X_ 149.0
$n(9) set Y_ 110.0
$n(9) set Z_ 0.0
31
$n(6) set X_ 5.0

$n(6) set Y_ 100.0
$n(6) set Z_ 0.0
set tcp [new Agent/TCP/Newreno]

$ns attach-agent $n(3) $tcp
set sink [new Agent/TCPSink/DelAck]
$ns attach-agent $n(5) $sink
$ns connect $tcp $sink
$tcp set fid_ 3
$tcp set window_ 2000
$tcp set packetSize_ 200
#Setup a FTP over TCP connection
set ftp [new Application/FTP]
$ftp attach-agent $tcp
$ftp set type_ FTP
$ns at 5.0 "$ftp start"
$ns at 107.0 "$ftp stop"
$tcp set fid_ 3
$ftp set type_ FTP
$tcp set fid_ 3
32

$ftp set type_ FTP
$tcp set fid_ 3
$ftp set type_ FTP
$tcp set fid_ 3
$ftp set type_ FTP

33

$tcp set fid_ 3
$ftp set type_ FTP
$tcp set fid_ 3
$ftp set type_ FTP
$tcp set fid_ 3
$ftp set type_ FTP
$tcp set fid_ 3
34

$ftp set type_ FTP
$ns at 4.0 "$n(3) label sourcenode"

$ns at 4.5 "$n(4) label onehopneighbornode"
$ns at 107.0 "$n(1) label Maliciousnode"
$ns at 107.0 "$n(0) label fakedestinationnode"
$ns at 4.0 "$n(3) add-mark N4 green circle"
$ns at 4.5 "$n(4) add-mark N4 brown circle"
$ns at 107.0 "$n(0) add-mark N4 red circle"
$ns at 107.0 "$n(1) add-mark N2 blue circle"
#$ns at 87.0 "$n(26) delete-mark N26"
#Define node initial position in nam
for {set i 0} {$i < $val(nn)} { incr i } {
# 20 defines the node size for nam
$ns initial_node_pos $n($i) 20
}
# Telling nodes when the simulation ends

for {set i O} {$i < $val(nn) } { incr i } {
$ns at $val(stop) "$n($i) reset";
}
# ending nam and the simulation
$ns at $val(stop) "$ns nam-end-wireless $val(stop)"
$ns at $val(stop) "stop"
$ns at 150.01 "puts \"end simulation\" ; $ns halt"
proc stop {} { global ns_ tracefd n1
# $ns flush-trace
close $tracefd
global ns tracefd namtrace
close $namtrace
35
exec nam changevoip.nam &

exec gnuplot data.gp
exit 0
}
$ns run
CHAPTER 8
SIMULATION SCREENSHOTS
36
OPENING THE DIRECTORY
SIMULATING THE CODE
37
MOBILE AD-HOC NETWORK CREATION
SHOWING SOURCE, DESTINATION AND NEIGHBOUR NODES

38
REVERSE TRACING TECHNIQUE
MALICIOUS NODE DETECTION

39
OUTPUT GRAPH
40
CHAPTER 9
REALISTIC CONSTRAINTS AND STANDARDS
REALISTIC CONSTRAINTS:
1. The coding/programming that is written should be executed in NETWORK
SIMULATOR(NS2).
2. Reducing the end to end delay of data transmission than that of the existing routing
protocols.
3. The scheme should defend against Collaborative black hole attacks and Collaborative
Packet Drop attacks in mobile ad hoc networks without interrupting data transmission.
4. The scheme should work accurately even in case of mobile ad hoc networks having
5. large number of nodes.
STANDARDS REFERRED:
1. IEEE 802.11 MAC (Media Access Control)
2. RFC 2501(Routing Protocol Performance Issues and Evaluation Considerations)
3. REAct (resource-efcient accountability for node misbehavior in ad hoc networks
based on random audits)
CHAPTER 10
41
CONCLUSION
In this paper, we have proposed a new mechanism (improvement to the CBDS) for
detecting malicious nodes in MANETs under gray/collaborative blackhole attacks. Our
simulation results revealed that this method outperforms the DSR, 2ACK, and BFTR
schemes, chosen as benchmark schemes, in terms of routing overhead and packet delivery
ratio.
CHAPTER 11
42
REFERENCES
P.-C. Tsou, J.-M. Chang, H.-C. Chao, and J.-L. Chen, CBDS: A cooperative bait
detection scheme to prevent malicious node for MANET based on hybrid defense
architecture, in Proc. 2nd Intl. Conf. Wireless Commun., VITAE, Chenai, India, Feb.
28Mar., 03, 2011, pp. 15.
S. Corson and J. Macker, RFC 2501, Mobile Ad hoc Networking (MANET): Routing
Protocol Performance Issues and Evaluation Considerations, Jan. 1999. (Last
retrieved
March
18,
2013).
[Online].
Available:
http://www.elook.org/computing/rfc/rfc2501.html
C. Chang, Y.Wang, and H. Chao, An efficient Mesh-based core multicast routing
protocol on MANETs, J. Internet Technol., vol. 8, no. 2, pp. 229239, Apr. 2007.
D. Johnson and D. Maltz, Dynamic source routing in ad hoc wireless networks,
Mobile Comput., pp. 153181, 1996.
Rubin, A. Behzad, R. Zhang, H. Luo, and E. Caballero, TBONE: A mobile-backbone
protocol for ad hoc wireless networks, in Proc. IEEE Aerosp. Conf., 2002, vol. 6, pp.
27272740.
Baadache and A. Belmehdi, Avoiding blackhole and cooperative blackhole attacks in
wireless ad hoc networks, Intl. J. Comput. Sci. Inf. Security, vol. 7, no. 1, 2010.
S. Marti, T. J. Giuli, K. Lai, and M. Baker, Mitigating routing misbehavior in mobile
ad hoc networks, in Proc. 6th Annu. Intl. Conf. MobiCom, 2000, pp. 255265.
K. Vishnu and A. J Paul, Detection and removal of cooperative black/gray hole
attack in mobile ad hoc networks, Int. J. Comput. Appl., vol. 1, no. 22, pp. 2832,
2010.
43
K. Liu, D. Pramod, K. Varshney, and K. Balakrishnan, An Acknowledgement based

approach for the detection of routing misbehavior in MANETs, IEEE Trans. Mobile
Comput., vol. 6, no. 5, pp. 536550, May 2007.
H. Deng, W. Li, and D. Agrawal, Routing security in wireless ad hoc network,
IEEE Commun. Mag., vol. 40, no. 10, Oct. 2002.
S. Ramaswamy, H. Fu, M. Sreekantaradhya, J. Dixon, and K. Nygard, Prevention of
cooperative blackhole attacks in wireless ad hoc networks, in Proc. Int. Conf.
Wireless Netw., Jun. 2003, pp. 570575.
H. Weerasinghe and H. Fu, Preventing cooperative blackhole attacks in mobile ad
hoc networks: Simulation implementation and evaluation, in Proc. IEEE ICC, 2007,
pp. 362367.
Y. Xue and K. Nahrstedt, Providing fault-tolerant ad hoc routing service in
adversarial environments, Wireless Pers.Commun., vol. 29, pp. 367 388, 2004.
44

Submitted For Partial Fulfillment For The Award of The Degree

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Submitted For Partial Fulfillment For The Award of The Degree

Uploaded by

Copyright:

Available Formats

PROJECT REPORT

AVINASH CHOWDARY KOGANTI

Under the guidance of

DEPARTMENT OF ELECTRONICS & COMMUNICATION ENGINEERING

Certified that this project report titled DEFENDING AGAINST COLLABORATIVE

Head of the Department

In mobile ad hoc networks (MANETs), a primary requirement for the establishment

2.1 SYSTEM ARCHITECTURE:

Proposed Architecture diagram

DATA FLOW DIAGRAM:

Request to one hop

Sent destination address

Send GHELLO message

Sent ACK and path

Sent fake destination

added to; or associated with, UML.

USE CASE DIAGRAM:

Pentium IV 2.4 GHz.

Cygwin (To simulate in Windows OS)

Fig 5.1 Simplified Users View of Ns

Fig 5.2 OTcl and C++: the duality

Both Satellite and Wireless Oriented

<bandwidth value, e.g 2MB>

NS is written in C++, with an OTcl1 interpreter as a command and configuration

NS can simulate the following:

USERS VIEW OF NS-2

Simulation OTcl Script

basic network components.

Figure 5.2 OTcl Class Hierarchy

6. Acquire direct access to the interpreter.

-macType $opt (mac)

Network creation (wireless sensor networks)

Sink &source nodes

Dynamic Source Routing

Reverse Tracing Technique

Network Creation (Wireless sensor Networks)

SINK &SOURCE NODES:

Dynamic Source Routing

CBDS (Cooperative Bait Detection Approach)

Reverse Tracing Technique

# configure the nodes

$n(3) set X_ 47.0

$n(5) set X_ 149.0

$n(20) set X_ 300.0

$n(6) set X_ 5.0

set tcp [new Agent/TCP/Newreno]

#Setup a FTP over TCP connection

set tcp [new Agent/TCP/Newreno]

$ns connect $tcp $sink

$tcp set window_ 2000

$ns at 4.0 "$n(3) label sourcenode"

# Telling nodes when the simulation ends

exec nam changevoip.nam &

OPENING THE DIRECTORY

SIMULATING THE CODE

MOBILE AD-HOC NETWORK CREATION

SHOWING SOURCE, DESTINATION AND NEIGHBOUR NODES

REVERSE TRACING TECHNIQUE

MALICIOUS NODE DETECTION

K. Liu, D. Pramod, K. Varshney, and K. Balakrishnan, An Acknowledgement based

You might also like