iv

ABSTRACT
This project entitled TUNNEL ATTACK PREVENTION
ALGORITHM IN MOBILE AD HOC NETWORKS has been
developed using NS2allinone in REDHAT 9.
In Mobile Adhoc networks the problem of tunnel attacks- one malicious
node tunnels packets from its location to other malicious node exists . Such
tunnel attacks result in a fake route. It is difficult to detect tunnel attacks because
malicious nodes impersonate with legitimate nodes. Previous algorithms
detecting a tunnel require specialized hardware or tight time synchronization.
In this project, we develop an effective method called Tunnel attack
prevention without using specialized hardware. The TAP not only detects the
fake route but also adopts some preventive measures against tunnel attacked
malicious nodes which reappears during the route discovery phase. Simulation
results show that tunnel attack can be detected and isolated within the route
discovery phase.
v

CHAPTER TITLE PAGE NO
NO
ABSTRACT iv
LIST OF FIGURES viii
LIST OF ABBREVIATIONS ix
1. INTRODUCTION
1.1 Need for this Project 2
1.2 Feasibility Study Report 3
1.3 Scope 3
1.4 Existing System 4
1.5 Proposed System 4
2. PROJECT DESCRIPTION
2.1 HARDWARE REQUIREMENTS 6
2.2 SOFTWARE REQUIREMENTS 6
2.2.1 Redhat Linux 6
2.2.1.1 Virtualization management 6
2.2.1.2 Kernel 7
2.2.1.3 Eliminate economic
constraints Basing 7
vi


2.2.2 NS2 allinone-2.28 8
2.2.2.1 Trace Graph 2. 05 8
2.2.2.2 Simulation animations 9
2.2.3 J DK 1.5.3 10
2.2.3.1 Development Tools 10
2.2.3.2 Runtime Environment 10
2.2.3.3 Additional Libraries 10
2.2.3.4 Demo Applets and Applications 10
2.2.3.5 C header Files 10
2.2.3.6 Source Code 11
2.2.3.7 The J 2SE Runtime Environment 11
2.3 DESIGN
2.3.1 Data Flow Diagram 12
2.4 IMPLEMENTATION
2.4.1 Module Description 13
2.4.1.1 TAP (Tunnel Attack Prevention) 13
2.4.1.2 Assumption 13
2.4.1.3 Neighbor Node Monitoring 14
2.4.1.4 Neighbor Node Table 17
2.4.1.5 Tunnel Prevention Timer 18
vii

2.4.1.6 Tunnel Route Detection 19
2.5 PROTOCOL DESCRIPTION 20
2.5.1 DSR Protocol 20
2.5.2 DSR Route Maintenance 21
2.5.3 DSR ALGORITHM 22
3. SIMULATION RESULT 25
4. CONCLUSION 26
APPENDIX A
SAMPLE CODE 27
APPENDIX B
SNAPSHOT 49
REFERENCES 57

viii

LIST OF FIGURES
FIGURE NO FIGURE NAME PAGE NO

1. Directional Antenna 4
2. Data Flow Diagram 12
3. Neighbor node monitoring for
Legitimate Node 15

4. Neighbor node monitoring for
Tunnel Attacked node 16
5. DSR Route Maintenance 21
ix

LIST OF ABBREVIATIONS
MANET - Mobile Ad-hoc Network
TAP - Tunnel Attack Prevention
DSDV - Dynamic Source Distance Vector
AODV - Ad hoc on-demand distance vector
DSR - Dynamic Source Routing
MAD - Mutual Authentication with Distance
Bounding
RTT - Round Trip Time
RREQ - Route Request
RREP - Route Reply
DELPHI - Delay per Hop Indicator
DPH - Delay per Hop
TAPT - Tunnel Attack Prevention Timer
CBR - Constant Bit Rate
1


1. INTRODUCTION
2

1. INTRODUCTION
1.1Need for the Project:
A Mobile Ad-hoc Network (MANET) comprises nodes that are
organized and maintained in a distributed manner without a fixed infrastructure.
These nodes, such as laptop, computers, PDAs and wireless phones, have a
limited transmission range. Hence, each node has the ability to communicate
directly with another node and forward messages to neighbors until the messages
arrive at the destination nodes. Since the transmission between two nodes has to
rely on relay nodes, many routing protocol like Ad hoc on-demand distance
vector (AODV), Dynamic Source Distance Vector (DSDV) and Dynamic
Source Routing (DSR) have been proposed for ad hoc networks. However, most
of them assume that other nodes are trustable and hence they do not consider the
security and attack issues. This provides many opportunities for attackers to
break the network. Moreover, the open nature of wireless communication
channels, the lack of infrastructure, rapid deployment practices, and the hostile
environments in which they may be deployed, make them vulnerable to a wide
range of security attacks described in reference projects . However the attacks
are performed by a single malicious node. Many solutions proposed in order to
solve single node attacks in cannot defend attacks that are executed by colluding
malicious node, such as Tunnel attack, which damage is extensive than single
node attacks.
In this project, we focus on an attack launched by a pair of colluding
attackers: Tunnel attack. Two malicious nodes that are separated by a large
distance of several hops build a direct link called a Tunnel and communicate with
3

each other through the Tunnel. The Tunnel can be established in many different
ways, for example, through an out-of-band channel, packet encapsulation and
high-powered transmission. This route via the Tunnel is attractive to the
legitimate nodes because it generally provides less number of hops and less
latency than normal multi-hop routes. The attackers can also launch attacks
without revealing their identities. The Tunnel attack is still possible even if the
adversary does not access the contents of the packet. Therefore, it can be difficult
to detect Tunnel attacks since the contents of the packets are not modified.
However, most of these mechanisms require specialized devices that
can provide the location of the nodes or tight time synchronization. Moreover,
they focus only on the method of detection of the Tunnel route. In this project,
we propose an efficient algorithm based on Dynamic Source Routing (DSR)
protocol. The advantage of this algorithm is that it does not require the location
information of time synchronization.
1.2 Feasibility Study Report:
In this project it is possible to find the tunnel attack from any node in the
mobile ad-hoc network. The neighbor node monitoring is a innovative
concept that helps to identify the tunnel attacked path.
The Building intelligence of each node dynamically changes the path for
and finds the legitimate node and transmits the data. Its nearly 70 % data
loss can be avoided.
4

1.3 Scope:
Cost of Maintenance is very low.
Its a software program. So easy to configure in any mobile device.
Flexible to reduce the load balancing, maintain the reliable transmission.
1.4 Existing System:
BANAID system is a specialized hardware to identify the tunnel attack on a
wireless sensor network.
Directional Antenna:
Figure 1
Operation Modes : Omni and Directional
In Omni Mode : Nodes send signals with gain go
In Directional Mode: Capable of sending in specified direction
Directional Gain Gd (Gd >Go)
5

1.5 Proposed System:
An efficient algorithm is designed based on Dynamic Source Routing
(DSR) protocol. This Protocol having a dynamic nature in the Mobile Ad-hoc
network. So it supports to maintain the Neighbor node details in the Mobile Ad-
hoc network.
We are going to implement powerful programming in each node for
detecting and overcome the Tunnel attack in the Mobile network. So this system
supports for increase the reliability of the network. The proposed system
identified the malicious nodes in the network and skips the data transmission to
the malicious node. Its also reducing the network traffic.
6

2. PROJECT DESCRIPTION
7

2. PROJECT DESCRIPTION
2.1 Hardware Requirements:
1 PC
PROCESSOR PENT 4
RAM 256MB
HDD 8GB
COLOR MONITOR
STANDARD KEYBOARD
MOUSE
2.2 Software Requirements:
OS REDHAT 9
NS2 allinone 2.28 simulator
J DK 1.5.3
2.2.1 REDHAT LINUX:
2.2.1.1Virtualization management
Comprehensive management capabilities for virtualization are provided,
Including
libvirt: a programmable management library that provides hypervisor
independence
8

virsh: a scriptable command shell
Red Hat Network enhancements that manage guest entitlements
Virt-manager: a graphical interface for virtualization functions (creates,
start, stop, suspend, resume, monitor, etc.)
Red Hat Enterprise Linux Advanced Platform includes Conga, a new
management utility that provides web-based control of storage,
applications, and servers in small and large multi-cluster environments.
Benefits
Easy, comprehensive management of virtualized environments
2.2.1.2Kernel:
Red Hat Enterprise Linux 5 is based on the Linux 2.6.18 kernel and
includes many enhancements over prior releases. These include:
Per queue, switch able on-the-fly I/O schedulers
High performance pipe implementation
IPv4/IPv6 performance enhancements
Support for shared cache and multi-core systems
Kernel SMP locking enhancements for improved scalability and
performance
9

2.2.1.3 Eliminate economic constraints basing
Your solution on open source technologies wherever practical - from
the virtualization hyper visor to the SOA middleware to the end user
application - guarantees you'll make the most of your IT budget. Despite what
vendors of single solutions tell you about their product are cost - its the
overall total cost that matters. And open source solutions offer lower total
costs:
Lower capital expense and operational expense
Elimination of vendor lock-in - puts the customer in control.
Proven superior product quality - better security, higher performance
Technology leadership - driven by industry-wide collaboration
Flexibility - deploy what you need, when you need, how you need it
2.2.2 NS2 allinone-2.28:
2.2.2.1 Trace Graph 2. 05:
Trace graph is a free network trace files analyzer developed for network
simulator ns-2 trace processing.
Trace graph can support any trace format if converted to its own or ns-2
trace format.
10

Trace graph runs under Windows, Linux, and UNIX and MAC OS
systems.
Trace converter processes traces over 80x faster and is available to buy
Some of the program features (version 2.05):
delays, jitter, processing times, round trip times, throughput graphs and
statistics
whole network, link and node graphs and statistics
all the results can be saved to text files, graphs can also be saved as jpeg
and tiff , x, y, z axes information: minimum, mean, maximum, standard
deviation,
median
any graph saved in text file with 2 or 3 columns can be plotted
Script files processing to do the analysis automatically.
238 2D graphs
12 3D graphs
11

2.2.2.2 Simulation animations
When you run a simulation, you can watch an animated view of the
process in operation. This topic describes the information represented in
the animated process simulation as it runs.
In an animation, you can watch the movement of tokens from the inputs of
the process and between activities in the process. A token represents a unit
of work that is received by a process and transferred between different
activities in the process flow. By observing a process during animation,
you can see where the process is operating efficiently and where delays are
occurring.
A token that is transferred to an input of an activity is either processed
immediately or added to a queue on the input. The token will be added to a
queue in either of the following cases:
The tokens transferred to the inputs of the activity do not match the set of
inputs defined in one of the activity's input criteria. For example, if the
activity has only one input criterion that requires two inputs, a token will
be added to a queue for one of the inputs until the second input is received.
A new instance of the activity cannot be created because the maximum
allowable quantity of this activity already exists.
When a token is added to a queue on an input, the number that appears
next to the queue is incremented by 1 (or the number 1 appears, if there
were previously no queued tokens), and one of the vertical bars that
represent the queue may darken in color.
12

2.2. 3 JDK 1.5.3
This section contains a general summary of the files and directories
in the J DK. For details on the files and directories, see J DK File Structure
portion of the J 2SE documentation.
2.2.3.1 Development Tools
(In the bin subdirectory.) Tools and utilities that will help you develop,
execute, debug, and document programs written in the J ava programming
language. For further information, see the tool documentation.
2.2.3.2Runtime Environment
(In the jre subdirectory.) An implementation of the J 2SE runtime
environment for use by the J DK. The runtime environment includes a J ava
virtual machine, class libraries, and other files that support the execution of
programs written in the J ava programming language.
2.2.3.3Additional Libraries
(In the lib subdirectory.) Additional class libraries and support files
required by the development tools.
2.2.3.4Demo Applets and Applications
(In the demo subdirectory.) Examples, with source code, of programming
for the J ava platform. These include examples that use Swing and other
J ava Foundation Classes, and the J ava Platform Debugger Architecture.
13

2.2.3.5 C header Files
(In the include subdirectory.) Header files that support native-code
programming using the J ava Native Interface, the J VM
TM
Tool Interface,
and other functionality of the J ava 2 Platform.
2.2.3.6 Source Code
(In src.zip.) J ava programming language source files for all classes that
make up the J ava 2 core API (that is, sources files for the java.*, javax.*
and some org.* packages, but not for com.sun.* packages). This source
code is provided for informational purposes only, to help developers learn
and use the J ava programming language. These files do not include
platform-specific implementation code and cannot be used to rebuild the
class libraries. To extract these file, use any common zip utility. Or, you
may use the J ar utility in the J DK's bin directory: jar xvf src.zip
2.2.3.7 The J2SE Runtime Environment
The J 2SE Runtime Environment is available as a separately downloadable
product. See the download web site.
The J 2SE Runtime Environment allows you to run applications written in
the J ava programming language. Like the J DK, it contains the J ava virtual
machine, classes comprising the J ava 2 Platform API, and supporting files.
Unlike the J DK, it does not contain development tools such as compilers
and debuggers.
You can freely redistribute the J 2SE Runtime Environment with your
application, according to the terms of the Runtime Environment's license.
Once you have developed your application using the J DK, you can ship it
14

with the Runtime Environment so your end-users will have a J ava platform
on which to run your software.
2.3DESIGN:
2.3.1Data Flow Diagram:
Figure 2
Design topology
of MANET
Implementing
TAP Algorithm
Tunnel Attack
detection scheme
Detecting
malicious node in
tunnel
Detecting Tunnel Attacks
without any specialized
hardware
Improve efficiency in
network capacity
Increasing
Transmission
Range
Create and Set the
Nodes using X and
Y Axis
15

2.3 IMPLEMENTATION
2.3.1 Module Description
2.3.3.1TAP (Tunnel Attack Prevention)
In this section, we describe a method for preventing Tunnel attack
called as Tunnel Attack Prevention (TAP). All nodes monitor its neighbors
behavior when they send RREQ messages to the destination by using a special
list called Neighbor List. When a source node receives some RREP messages, it
can detect a route under Tunnel attack among the routes. Once Tunnel node is
detected, source node records them in the Tunnel Node List. Even though
malicious nodes have been excluded from routing in the past, the nodes have a
chance of attack once more. Therefore, we store the information of Tunnel nodes
at the source node to prevent them taking part in routing again. Moreover, the
TAP has the ability of detecting both the hidden and exposed attacks without
special hardware.
2.3.3.2 Assumption
At the link layer, it assumes that a node can always monitor ongoing
transmissions even if the node itself is not the intended receiver. This typically
requires the network interface stay in the promiscuous reception mode during all
transmissions, which is less energy efficient than listening only to packets
directed to oneself. We also assume that radio links are bi-directional; that is, if a
node A is in transmission range of some node B, then B is in transmission range
16

of A. We further assume that the transmission range of a Tunnel node is similar
to a normal node because more powerful transceiver is easy to detect.
2.3.3.3 Neighbor Node Monitoring
Neighbor Node Monitoring is used to detect neighbors that are not
within the maximum transmission range but pretend to be neighbors. In order to
reduce network overheads by additional packets, this mechanism is achieved
during the route discovery process. Originally, the intermediate node which has a
route to destination can send a RREP to source. However, our mechanism does
not support the DSR optimization because it performs end-to-end signature
authentication of routing packet and verification of whether a node is authorized
to send a RREP packet.
Therefore, an intermediate node cannot reply from its cache. Figure
1 shows an example of the secure neighbor monitoring. Node A sends a RREQ,
which starts a Tunnel prevention timer (WPT). When node B receives the RREQ,
B must broadcast to its neighbors because B is not a destination. A can check
whether the RREQ arrives within the timer. If A receives the message after the
timer expires, it suspects B or one of Bs next nodes to be Tunnel nodes.
17

Figure 3
Figure 4
18

Once a malicious node overhears a RREQ, the node can claim to be another
Tunnel node that is actually not within the transmission range of a neighbor node.
For this reason, two nodes may believe that the other is its neighbor which does
not want to expose itself. In order to prevent this problem, nodes monitor the
malicious behavior of neighbors and record it in the own neighbor node table.
2.3.3.4 Neighbor Node Table
Each node maintains a Neighbor node table that contain a RREQ
sequence number, neighbor node ID, sending time and receiving time of the
RREQ and count. By using this table, all nodes monitor the activities of
neighbors in its table and check for malicious behavior of the neighbors. All the
fields of neighbor node table set to zero. Table 1 shows an example of the
neighbor node table.
If any node sends a RREQ, it records the RREQ sequence number and
sending time of the RREQ. Then, on overhearing a RREQ from any node, it
records the address of the neighbor node and the time when it receives the packet.
If the node receives the RREQ after the timer count, called as WPT, it considers
the neighbor node sending the RREQ as a node affected by Tunnel nodes. The
count Value in its table will be increased by 1. It must be noted that the count
value does not exceed the previously configured threshold. If the count value
exceeds the threshold, the node cannot engage in the network. This method
ensures that Tunnels nodes are avoided in all the future data connections.
19

2.3.3.5 Tunnel Prevention Timer
We detect tunnels by using a special timer. For using this timer, all
the nodes do not require clock synchronization, except the source node. As soon
as a node sends a RREQ packet, it must set the WPT and wait after sending the
RREQ packet until it overhears its neighbors retransmission. The WPT consider
the maximum amount of time required for a packet to travels from a node to a
neighbor node and back to the node. If WPT is too small, the legitimate nodes
can be excluded. On the other hand, if it is too large, it is difficult to detect tunnel
attacks. Two formulas are considered to determine whether or not the nodes have
mobility. If the nodes are fixed like sensor node, the WPT is estimated by
Here, TR denotes a distance that a packet can travel and Vp denotes
the propagation speed of a packet. It is assumed that the maximum propagation
speed of the radio signal is the speed of light and the delay from sending and
20

receiving packets is negligible. On the other hand, if the nodes have a mobility
with an average velocity of Vn, the distance that packet can travel may be
different. The maximum transmission distance of a packet is calculated by
Consequently, when network are formed in the mobile environment,
the WPT of nodes is given by,
By using the formulas 1, 3, when a node overhears its neighbor nodes
re-transmission, it checks whether the packet has arrived before the WPT
expired. If a hidden tunnel attack is launched, the packet transmission time
between two fake neighbor nodes may be longer than the normal transmission
time of one hop. Therefore, we can detect a route through a tunnel.
2.3.3.6 Tunnel Route Detection
We detect exposed tunnel node when a source node selects one route
among all the routes collected from the RREP packets within the RREP waiting
timer. In the DSR protocol, the route selection without any tunnel attack is
simple. The source node selects the smallest hop count route among all the
21

received routes. Unfortunately, the smallest hop count route may contain tunnel
nodes. Hidden attacks can be detected by neighbor node monitoring. However, if
tunnel nodes are exposed and act like a legitimate node, it is difficult to detect a
tunnel route by using only the neighbor node monitoring mechanism. Therefore,
nodes must check a RREP packet on receiving it from neighbor nodes. When a
tunnel node sends a RREP to indicate that a colluding node is its neighbor,
normal neighbor nodes of the tunnel node examine whether they have
corresponding RREQ packet reviously received from the node in their table. For
example, in figure 2, suppose a source node S broadcasts RREQ at time Ta, and
then receives a RREP at time Tb; the source node can calculate the time delay per
hop in the route by using hop count field in the RREP. The formula is given by
2.4PROTOCOL DESCRIPTION:
2.4.1DSR Protocol:
The header of the packet, which originates from a source node S to a
destination node D, contains the source route, which gives the sequence of hops
that the packet should traverse. A suitable source route is found normally when
searching the Route Cache of routes obtained previously but if no route is found
then the Route Discovery protocol is initiated to find a new route to D. Here S is
the initiator and D the target. [5] Node A transmits a ROUTE REQUEST
message, which is received by all the nodes in the transmission range of A.
22

Each ROUTE REQUEST message identifies the initiator and target of the
Route Discovery and also contains a unique request ID, determined by the
initiator of the REQUEST. Each ROUTE REQUEST also contains a record
listing the address of each intermediate node through which this particular copy
of the ROUTE REQUEST message has been forwarded. The initiator of the
Route Discovery initializes the route record to an empty list. [5] When the target
node receives the ROUTE REQUEST message, it returns a ROUTE REPLY
message to the ROUTE Discovery initiator with a copy of the accumulated route
record from the ROUTE REQUEST. This route is cached in the Route Cache
when the initiator receives the ROUTE REPLY and is used in sending
subsequent packets to this destination.
When the target node finds a ROUTE REQUEST message from the
same initiator bearing the same request ID or if it finds its own address is already
listed in the route record of the ROUTE REQUEST message, it discards the
REQUEST. If the target node does not find the ROUTE REQUEST message
from the initiator, then it appends its address to the route record in the ROUTE
REQUEST message and propagates it by transmitting it as a local broadcast
packet. When Route Discovery is initiated the copy of the original packet is
saved in a local buffer called Send Buffer. The Send Buffer contains copies of
each packet that cannot be transmitted by the sending node. The packets are kept
until a source route is available or a timeout or Send Buffer overflow occurs. As
long as a packet is in the Send Buffer, the node should initiate new Route
Discovery until time out occurs or overflow of Buffer occurs. An exponential
23

Back off algorithm is designed to limit the rate at which new ROUTE
Discoveries may be initiated by any node for the same target.
2.4.2 DSR Route Maintenance:
When a packet with a source route is forwarded, each node in the source
route makes sure that the packet has been received by the next hop in the source
route. The confirmation of receipt will be received only by re-transmitting the
packet for a number of times.
Fig 5: DSR Route Maintenance
Node A is the originator of a packet to the desired destination E. The
packet has a source route through intermediate nodes B, C and D. Node A is
responsible for receipt of the packet at B, node B at C, node C at D and node D at
E. Node B confirms receipt of packet at C by overhearing C transmit the packet
to forward it to D. The confirmation of acknowledgement is done by passive
acknowledgements or as link-layer mechanisms such as option in MAC protocol.
The node receiving the packet can return a DSR specific software
acknowledgement if neither of the acknowledgements is available. This is done
by setting up a bit in the packets header and then requesting a DSR specific
software acknowledgement by the node transmitting the packet. When a node is
A B C D E
24

unable to deliver a packet to the next node then the node sends a ROUTE
ERROR message to the original sender of the packet. The broken link is then
removed from the cache by the originator of the packet and retransmissions to the
same destination are done by upper layer protocols like TCP.
2.4.3 DSR ALGORITHM:
1. initialization phase,
2. send PKT;
3. run server thread with IP:10.1.1.2
4. synchronize internal clock with the global clock;
5. If PKT_MSG_Type==0 then
6. If PKT_MSG_ID is not in RREQ list then
7. add entry into Routing Table;
8. add PKT_MSG_ID into RREQ list;
9. if PKT_Orgin_Destin==Current_Mote_Address then
10. prepare RREP PKT and send it;
11. else
12. forward PKT:
13. end if
14. else
15. Check RT for PKT_Orgin_Source and get the Hop_Count;
16. if Hop_Count>PKT_Hop_Count then
17. update the entry in Routing Table;
18. Send PKT;
19. end if
25

20. end if
21. else if PKT_MSG_Type==1 then // RREP mode
22. If PKT_MSG_ID is not in RREP list then
23. add entry into Routing Table;
24. add PKT_MSG_ID into RREP list;
25. if PKT_Orgin_Destin==Current_Mote_Address then
26. prepare RREP PKT and send it;
27. Send routing information for this mote;
28. else
29. Forward PKT;
30. end if
31. else
32. check RT for PKT_Orgin_Source and get the Hop_Count;
33. if Hop_Count>PKT_Hop_Count then
34. update the entry in Routing Table;
35. end if
36. end if
37. else if PKT_MSG_Type==2 then
38. if PKT_Orgin_Destin==Current_Mote_Address then
39. packet reaches its destination;
40. else
41. Check RT for PKT Orgin_Source and get Next Hop;
42. send PKT for the next hop;
26

43. end if
44. end if
Source Side:
1. Initialization phase
2. Open serial port;
3. Run server thread with IP: 10.1.12
4. //the previous command runs forever to receive any
5. ://msg from starage2 with 1p:10.1.13 and forward it
6. //to the serial port to be sent by Mica2 sensor via radio
7. for (1) do
8. if Stargate receive a msg from the serial then
9. if msg comes from mote 1 and it is RREQ then
10. call client to forward the msg through WiFi to Stargate 2;
11. end if
12. end if
13. end for
Destination Side:
1. initialization phase
27

2. open serial port;
3. run server thread with IP: 10.1.1.3
4. //it runs forever to receive any msg from Stargate 1 with
5. //IP:10.1.1.2 and forward it
6. to the serial port to be sent by Mica2 sensor via radio
7. for(1) do
8. if Stargate receive a msg from the serial then
9. if msg comes from mote 4 and it is RREP then
10. call client to forward the msg through WiFi to Stargate 1;
11. end if
12. end if
13. end for

28

3. SIMULATION RESULT
The network throughput is measured for the basic DSR routing
protocol and DSR with the TAP method. The speed of nodes is varied to compare
the results. Figure 3 shows the results of the network throughput of both
techniques for different node speeds. Even if there are no tunnel nodes, the
network throughput diminishes in the environment of both DSR and TAP method
as the node speed increases because the network generally becomes more fragile
as the node speed increases However, the network throughput of the basic DSR
protocol dramatically decreases when there are tunnel nodes in the networks. For
example, the throughput value is 74.7% when the basic DSR is used and when
the nodes are moving with a speed of 10 m/s. However, the throughput value is
88.9% when the TAP is used under a tunnel attack.
`This proves that the network throughput of the TAP algorithm exceeds
that of the basic DSR protocol. We experiment on the capability of tunnel
detection and isolation with TAP method. Generally, in the basic DSR protocol,
each node does not check a RREQ packet overheard from its neighbor nodes.
Therefore, the fraction of packets sent through the tunnel is high. In contrast,
each node that uses the neighbor node table and tunnel node list take into account
the information of the subsequent node before forwarding a packet. Therefore,
the packets sent through a tunnel are mostly dropped to prevent the packets from
arriving at the destination. Figure 4 provides the fraction of packets sent over
tunnel routes in the basic DSR and modified DSR with the TAP algorithm at
varying speeds.
29

4. CONCLUSION
With development in computing environments, the services based on ad
hoc networks have been increased. However, wireless ad hoc networks are
vulnerable to various attacks due to the physical characteristic of both the
environment and the nodes. A tunnel attack is such an attack, that is, it is
executed by two malicious nodes causing serious damage to networks and nodes.
The detection of tunnels in ad hoc networks is still considered to be a challenging
task. In order to protect networks from tunnel attack, previous solutions require
specialized hardwares. Thus, in this project, we propose an algorithm to detect
tunnels without any special hardwares.
We achieve this through the use of the neighbor node monitoring method
of each node and tunnel route detection method of the source node on the
selected route. Our mechanism is implemented based on the DSR protocol and is
proven to be capable through simulation results. In future studies, we plan to
study false positive problems with regard to the detection of tunnels and a
mechanism to solve such problems. Moreover, we plan to apply the TAP
algorithm to other on-demand routing protocols.
30

APPENDIX A
SAMPLE CODE:
TCL (Command Tool Language) Program:
set val(chan) Channel/WirelessChannel
set val(prop) Propagation/TwoRayGround
set val(netif) Phy/WirelessPhy
set val(mac) Mac/802_11
set val(ifq) Queue/DropTail/PriQueue
set val(ll) LL
set val(ant) Antenna/OmniAntenna
set val(x) 700
set val(y) 700
set val(ifqlen) 200
set val(seed) 1.0
set val(adhocRouting) DSR
set val(nn) 10
set val(cp) cbr
set val(cp) scen
set val(stop) 4.2
31

set ns_ [new Simulator]
set topo [new Topography]
set tracefd [open out.tr.w]
set namtrace [open out.nam.w]
$ns_ trace-all $tracefd
$ns_ namtrace-all-wireless $namtrace $var(x) $var(y)
$topo load_flatgrid $val(x) $val(y)
set god_ [create-god $val(nn)]
$ns_ node-config -adhocRouting $val(adhocRouting) \
-llType $val(ll) \
-macType $val(mac) \
-ifqType $val(ifq) \
-ifqType $var(ifqlen) \
-antType $val(ant) \
-propType $val(prop) \
-phyType $val(netif) \
-channelType $val(chan) \
-topoInstance $topo \
-agentTrace ON \
32

-routerTrace ON \
-macTrace ON \
-movementTrace ON \
set myagent [new Agent/MyAgent()tcl]
$myagent call-my-priv-func
Proc finish{} {
Global ns tracefd
$ns flush-trace
Close $tracefd
Exec nam out.nam&
Exit 0
}
set tcp [new Agent/TCP]
$tcp set class_ 3
set sink [new Agent/TCPSink]
$ns_ attach-agent $node_1 $tcp
$ns_ attach-agent $node_0 $sink
$ns_ connect $tcp $sink
Set ftp [new Application/FTP]
33

$ftp attach-agent $tcp
$ns_ at .3 $ftp start
$ns_ at .8 $ftp stop
set tcp [new Agent/TCP]
$tcp set class_ 3
set sink [new Agent/TCPSink]
$ns_ attach-agent $node_0 $tcp
$ns_ attach-agent $node_5 $sink
$ns_ connect $tcp $sink
Set ftp [new Application/FTP]
$ftp attach-agent $tcp
$ns_ at 1.2 $ftp start
$ns_ at 2.11 $ftp stop
set tcp [new Agent/TCP]
$tcp set class_ 3
34

set sink [new Agent/TCPSink]
$ns_ attach-agent $node_9 $tcp
$ns_ attach-agent $node_5 $sink
$ns_ connect $tcp $sink
Set ftp [new Application/FTP]
$ftp attach-agent $tcp
$ns_ at 1.2 $ftp start
$ns_ at 2.25 $ftp stop
set tcp [new Agent/TCP]
$tcp set class_ 3
set sink [new Agent/TCPSink]
$ns_ attach-agent $node_5 $tcp
$ns_ attach-agent $node_3 $sink
$ns_ connect $tcp $sink
Set ftp [new Application/FTP]
$ftp attach-agent $tcp
$ns_ at 2.2 $ftp start
$ns_ at 2.5 $ftp stop
35

set tcp [new Agent/TCP]
$tcp set class_ 3
set sink [new Agent/TCPSink]
$ns_ attach-agent $node_5 $tcp
$ns_ attach-agent $node_6 $sink
$ns_ connect $tcp $sink
Set ftp [new Application/FTP]
$ftp attach-agent $tcp
$ns_ at 2.6 $ftp start
$ns_ at 3.11 $ftp stop
set tcp [new Agent/TCP]
$tcp set class_ 3
set sink [new Agent/TCPSink]
$ns_ attach-agent $node_6 $tcp
$ns_ attach-agent $node_7 $sink
$ns_ connect $tcp $sink
36

Set ftp [new Application/FTP]
$ftp attach-agent $tcp
$ns_ at 3.2 $ftp start
$ns_ at 4.11 $ftp stop
$ns_ at 0.1 $node_1 label Dest
$ns_ at 0.1 $node_1 add-mark m red circle
$ns_ at 0.1 $node_7 label Dest
$ns_ at 0.1 $node_1 add-mark m green circle
$ns_ at 2.55 $node_3 add-mark m red circle
$ns_ at 2.55 $node_3 add-mark m red circle
$ns_ at 2.2 $ns_ trace_annotate \ Sending HELLO message signal
from Node 5
to Node 3 \
$ns_ at 2.2 $ns_ trace_annotate \Tunnel Tunnel Detected from
malicious Node3
37

to Dest Node \
$ns_ at 2.2 $ns_ trace_annotate \ Node 5 Monitors Neighbor node
6 and sent the
Data \
$ns_ $var(stop).0002 puts \ NS EXITING \ ; $ns _halt
puts $tracefd M 0.0 nn x $val(nn) x $val(x) y $val(y) rp
$val(adhocRouting)
puts $tracefd M 0.0 prop $val(prop) ant $val(ant)
puts Starting Simulation
$ns _run
Connect program : connect.c++
#include <stdio.h>
#include <string.h>
#include <math.h>
#include "agent.h"
#include <god.h>
38

#include "diffusion/hash_table.h"
#include "mobilenode.h"
class MyAgent : public Agent {
public:
MyAgent();
protected:
int command(int argc, const char*const* argv);
private:
int my_var1;
double my_var2;
void MyPrivFunc(void);
};
static class MyAgentClass : public TclClass {
public:
MyAgentClass() : TclClass("Agent/MyAgentOtcl") {}
TclObject* create(int, const char*const*) {
return(new MyAgent());
}
} class_my_agent;
39

MyAgent::MyAgent() : Agent(PT_UDP) {
}
int MyAgent::command(int argc, const char*const* argv) {
if(argc ==2) {
if(strcmp(argv[1], "call-my-priv-func") ==0) {
MyPrivFunc();
return(TCL_OK);
}
}
return(Agent::command(argc, argv));
}
void MyAgent::MyPrivFunc(void) {
Tcl& tcl =Tcl::instance();
{
int n=10;
float ID[11];
float nx[]={-96,-263,-471,216,498,72,241,440,637,-78};
float ny[]={428,281,192,131,439,274,389,249,225,163};
40

printf("x position of node1 %f",nx[0]);
float na;
float angle;
char create_node1[128];
char create_node2[128];
char initialize_node1[128];
char space[128];
char nodename[128];
char c[128];
strcpy(c,"$ns at 0.1");
char c2[128];
strcpy(c2,"$");
char c3[128];
strcpy(c3,"add-mark m green circle");
strcpy(create_node1,"set");
strcpy(create_node2," [$ns_ node]");
strcpy(initialize_node1,"$ns_ initial_node_pos");
strcpy(space," ");
strcpy(nodename,"node_");
41

for(int i=0;i<n;i++)
{
char create_node[128];
char create_node1[128];
char create_node2[128];
char initialize_node1[128];
char initialize_node[128];
char space[128];
char node_size[45];
char nodename[128];
char ini_nodename[128];
char node_pos1[128];
char node_pos2[128];
char node_pos3[128];
char node_pos4[128];
char node_pos5[128];
char node_pos[128];
char str[128];
char pos_X[128];
42

char pos_Y[128];
char pos_Z[128];
float X_pos[]={-96,-263,-471,216,498,72,241,440,637,-78};
float Y_pos[]={428,281,192,131,439,274,389,249,225,163};
float Z_pos=0;
int nodesize=70;
strcpy(create_node1,"set");
strcpy(create_node2," [$ns_ node]");
strcpy(initialize_node1,"$ns_ initial_node_pos");
strcpy(space," ");
strcpy(nodename,"node_");
strcpy(node_pos1,"set X_");
strcpy(node_pos2,"set Y_");
strcpy(node_pos5,"set Z_");
sprintf(str, "%d", i);
ID[i]=i+10;
strcat(create_node1,space);
strcat(create_node1,nodename);
strcat(create_node1,str);
43

strcat(create_node1,create_node2);
strcpy(create_node,create_node1);
printf("command to create Node %s\n",create_node);
sprintf(node_size,"%d",nodesize);
strcpy(ini_nodename,"$");
strcat(ini_nodename,nodename);
strcat(ini_nodename,str);
strcat(initialize_node1,space);
strcat(initialize_node1,ini_nodename);
strcat(initialize_node1,space);
strcat(initialize_node1,node_size);
strcpy(initialize_node,initialize_node1);
sprintf(pos_X,"%f",X_pos[i]);
strcpy(node_pos,"$");
strcat(node_pos,nodename);
strcat(node_pos,str);
strcat(node_pos,space);
strcat(node_pos,node_pos1);
strcat(node_pos,space);
44

strcat(node_pos,pos_X) ;
printf("Command to set X position %s\n",node_pos);
sprintf(pos_Y,"%f",Y_pos[i]);
strcpy(node_pos3,"$");
strcat(node_pos3,nodename);
strcat(node_pos3,str);
strcat(node_pos3,space);
strcat(node_pos3,node_pos2);
strcat(node_pos3,space);
strcat(node_pos3,pos_Y);
printf("Command to set Y position %s\n",node_pos3);
sprintf(pos_Z,"%f",Z_pos);strcpy(node_pos4,"$");
strcat(node_pos4,nodename);
strcat(node_pos4,str);
strcat(node_pos4,space);
strcat(node_pos4,node_pos5);
strcat(node_pos4,space);
strcat(node_pos4,pos_Z);
printf("Command to set Z position %s\n",node_pos4);
45

tcl.eval(create_node);
tcl.eval(node_pos);
tcl.eval(node_pos3);
tcl.eval(node_pos4);
tcl.eval(initialize_node);
}
int k=0;
for(int j=0;j<n;j++)
{
for(int z=0;z<n;z++)
{
if(j!=z)
{
float sub,sub1,sqr,sqr1,add,dis;
sub=nx[j]-nx[z];
sub1=ny[j]-ny[z];
sqr=sub*sub;
sqr1=sub1*sub1;
add=sqr+sqr1;
46

dis=sqrt(add);
printf("NODE [%d] to NODE[%d]",j,z);
printf("Distance ===========%f\n",dis);
float sub3,sub4;
sub3=ny[j]-ny[z];
sub4=nx[j]-nx[z];
na=sub3/sub4;
angle=atan(na);
printf("Angle of node[%d] to node[%d] is %f\n",j,z,angle);
if(j!=z)
{
if((j==0)&&((dis<240)&&(angle<0.5)))
{
printf("node %d is neighbour to %d \n",j,z);
}
if((j==1)&&((dis<200)&&(angle<0.5)))
{
printf("node %d is neighbour to %d \n",j,z);
}
47

if((j==2)&&((dis<200)&&(angle<0.5)))
{
printf("node %d is neighbour to %d \n",j,z);
}
if((j==3)&&(dis>200)&&(dis<250))
{
printf("node %d is neighbour to %d \n",j,z);
}
if((j==4)&&((dis<200)&&(angle<0.5)))
{
printf("node %d is neighbour to %d \n",j,z);
}
if((j==5)&&((dis<220)&&(angle<0.5)))
{
printf("node %d is neighbour to %d \n",j,z);
}
if((j==6)&&((dis<200)&&(angle<0.5)))
48

{
printf("node %d is neighbour to %d \n",j,z);
}
if((j==7)&&((dis<200)&&(angle<0.5)))
{
printf("node %d is neighbour to %d \n",j,z);
}
if((j==8)&&((dis<200)&&(angle<0.5)))
{
printf("node %d is neighbour to %d \n",j,z);
}
if((j==9)&&((dis<200)&&(angle<0.5)))
{ printf("node %d is neighbour to %d \n",j,z);
}
if((j==10)&&((dis<200)&&(angle<0.5)))
{
printf("node %d is neighbour to %d \n",j,z);
}
49

}
}
}
k++;
}
float TAPT,TR=250,Vp=10,Vn=1;
TAPT=((2*Vn*TR)/(Vp*Vp));
printf("\nTunnel Prevension timer TAPT =%f\n",WPT);
}
}
Neighbor Node Table ( in Java)
import java.io.*;
import java.util.ArrayList;
import java.util.StringTokenizer;
import java.util.Vector;
import com.sun.java_cup.internal.sym;
public class test
50

{
public static void main(String[] args)
{
try {
BufferedWriter outfile = new BufferedWriter(new
FileWriter("table.txt"));
FileReader fin = new FileReader ("output.tr");
BufferedReader br1 =new BufferedReader(fin);
String thisLine1=null;
Vector allsr=new Vector();
String req=null,rstr=null;;
Vector fvec=new Vector();
StringTokenizer tokenizer=null;
String st_time=null,end_time=null;
String nodeid=null;
String seqno=null;
ArrayList list=new ArrayList();
int count=0;
while ((thisLine1 =br1.readLine()) !=null)
51

{
if(thisLine1.startsWith("s"))
{
// System.out.println("IF.."+thisLine1);
tokenizer=new StringTokenizer(thisLine1);
while(tokenizer.hasMoreTokens())
{
list.add(tokenizer.nextToken());

}
// System.out.println("list====="+list);
st_time=list.get(1).toString();
nodeid=list.get(2).toString();

if(nodeid.contains("_"))
{
nodeid=nodeid.replace("_", " ");
}
System.out.println("Node Id..."+nodeid);
52

outfile.write("Node Id..."+nodeid +"\n");


list.clear();
// System.out.println("Cleared Item.."+list);
}

else if(thisLine1.startsWith("r"))
{
tokenizer=new StringTokenizer(thisLine1);

while(tokenizer.hasMoreTokens())
{
list.add(tokenizer.nextToken());
}

end_time=list.get(1).toString();
nodeid=list.get(2).toString();
if(nodeid.contains("_"))
53

{
nodeid=nodeid.replace("_", " ");
}
seqno=list.get(18).toString();
if(seqno.contains("]"))
{
seqno=seqno.replace("]", " ");
}

list.clear();

System.out.println("RREQ Seq No ="+seqno);
System.out.println("Neighbor Node Id="+nodeid);
System.out.println("Starting Time="+st_time);
System.out.println("Ending Time="+end_time);
outfile.write("RREQ Seq No ="+seqno+"\n");
outfile.write("Neighbor Node Id="+nodeid+"\n");
outfile.write("Starting Time="+st_time+"\n");
outfile.write("Ending Time="+end_time+"\n");
54

}
}
}
catch (Exception e)
{
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
55

APPENDIX B
SNAPSHOTS
1. SOURCE AND DESTIONATION IN NETORK
Source node identifies the Destination in the Mobile Ad-hoc
network using its building Intelligence.
Then short list the parameters of Destination node in the neighbor
node table.
56

2. SOURCE NODE TRANSMITS THE DATA TO NEIGHBOR
NODES:
Source nodes 1 transmit the datas to neighbor node 0 and node 9.
57

3. NODE 0 AND NODE 9 TRANSMIT THE DATA TO NODE 5:
Node 0 and Node 9 transmit the data to node 5.
Node 5 coupled the data and searching the nearest legitimate node.
58

4. NODE 3 IS TUNNEL ATTACKED NODE:
Sending HELLO message signal from node 5 to node 3.
Tunnel Attack detected from malicious node 3 to Destination node
Node 5 monitors neighbor node 6 and sent the Data
59

5. NODE 6 SENDS DATA TO DESTINATION:
Node 6 send the Data to Destination
The reliable Transmission occurred in the Mobile Ad-hoc Network
60

6. HISTOGRAM REPRESENTATION:
61

7. 3D GRAPH REPRESENTATION:
62

8. 2D GRAPH REPRESENTATION :
G
63

REFERENCES
[1] L. Buttyan and J .-P. Hubaux. Report on a working session on security in
wireless ad hoc networks. ACM SIGMOBILE Mobile Computing and
Communications Review, 7(1):7494, J an 2003.
[2] H. Yang, H. Luo, F. Ye, S. Lu, and L. Zhang. Security in mobile ad hoc
networks: challenges and solutions. IEEE Wireless Communications, 11(1):38
47, Feb 2004.
[3] L. Hu and D. Evans. Using directional antennas to prevent Tunnel attacks. In
Network and Distributed System Security Symposium (NDSS). The Internet
Society, Feb 2004.
[4] Y.-C. Hu, A. Perrig, and D. B. J ohnson. Packet leashes: A defense against
Tunnel attacks in wireless networks. IEEE INFOCOM, Mar 2003.
[5] J . Zhen and S. Srinivas. Preventing replay attacks for secure routing in ad hoc
networks. In ADHOC-NOW, LNCS 2865, pages 140150, 2003.
[6] Y.-C. Hu, A. Perrig, and D. B. J ohnson. Rushing attacks and defense in
wireless ad hoc network routing protocols. In W. D. Maughan and A. Perrig,
editors, ACM Workshop on Wireless Security (WiSe), pages 3040, Sep 2003.
[7] S. Capkun, L. Buttyan, and J .-P. Hubaux. SECTOR: secure tracking of node
encounters in multi-hop wireless networks. In ACM Workshop on Security of Ad
Hoc and Sensor Networks (SASN), pages 2132, Oct 2003.
64

[8] I. Khalil, S. Bagchi, and N. B. Shroff. LITEWORP: A lightweight
countermeasure for the Tunnel attack in multihop wireless networks. In
Dependable Systems and Networks (DSN), pages 612621, J un 2005.
[9] I. Khalil, S. Bagchi, and N. B. Shroff. MOBIWORP: Mitigation of the Tunnel
attack in mobile multihop wireless networks. Securecomm and Workshops 2006,
pages 112,Aug 2006.
[10] L. Tamilselvan and D. V. Sankaranarayanan. Prevention of impersonation
attack in wireless mobile ad hoc networks.International J ournal of Computer
Science and Network Security (IJ CSNS), 7(3):118123, Mar 2007.
[11] C. E. Perkins, E. M. Belding-Royer, and S. R. Das. Ad hoc on-demand
distance vector (AODV) routing. RFC 3561, The Internet Engineering Task
Force, Network Working Group, J ul 2003. http://www.ietf.org/rfc/rfc3561.txt.
[12] D. B. J ohnson and D. A. Maltz. Dynamic source routing in ad hoc wireless
networks. In Imielinski and Korth, editors, Mobile Computing, volume 353,
pages 153181. Kluwer Academic Publishers, 1996.
[13] D. A. Maltz and D. B. J ohnson and Y. Hu. The dynamic source routing
protocol (DSR) for mobile ad hoc networks for IPv4. RFC 4728, The Internet
Engineering Task Force, Network Working Group, Feb 2007.
http://www.ietf.org/rfc/rfc4728.txt.
[14] R. V. Boppana and S. P. Konduru. An adaptive distance vector routing
algorithm for mobile, ad hoc networks. In IEEE Computer and communications
Societies (INFOCOM 2001), pages 17531762, 2001.
65

[15] P. Papadimitratos and Z. J . Haas. Secure routing for mobile ad hoc networks.
In Proceedings of SCS Communication Networks and Distributed Systems
Modeling and Simulation Conference (CNDS 2002), J an 2002.
[16] Y.-C. Hu, D. B. J ohnson, and A. Perrig. SEAD: Secure efficient distance
vector routing for mobile wireless ad hoc networks. In IEEE Workshop on
Mobile Computing Systems and Applications (WMCSA), pages 313. IEEE
Computer Society, Dec 2002.
[17] Scalable Network Technologies (SNT). QualNet. http://www.qualnet.com/.
[18] J . Broch, D. A. Maltz, D. B. J ohnson, Y.-C. Hu, and J . G. J etcheva. A
performance comparison of multi-hop wireless ad hoc network routing protocols.
In ACM/IEEE International Conference on Mobile Computing and Networking
(MOBICOM), pages 8597, Oct 1998.