Simulation Of Gray Hole Attack

Published Date: 02 Nov 2017

In this work wireless Ad-hoc network is evaluated for the effects in the presence of Gray Hole attacks. We have simulated gray hole node in wireless ad-hoc network using NS Network Simulator program. A new protocol is implemented to simulate Gray Hole node in wireless ad-hoc network which drops data packets after getting them if that node wants to attack on sending node or it can also forward the data packet if the node wants to send the data packet to the desired destination. This chapter consists of new protocol developed and testing of Gray Hole attack in AODV.

4.1. NS (Network Simulator)

NS is an event driven network simulator which is used to simulate different IP networks and it was developed at UC Berkeley. It implements network protocols like UDP and TCP etc., multicasting and MAC layer protocols for LAN simulations. The NS project is a part of VINT project which develops the simulation result display tools, analysis tools , converter tools . NS-2

http://nile.wpi.edu/NS/Figure/fig1.gif Figure4.1. Simplified User's View of NS

is written in C++ and OTCL(Object oriented Tool Command Language) is also available. As shown in Figure 4.1 NS is OTcl script interpreter which is having simulation event scheduler and network component object libraries, and network setup (plumbing) module libraries (actually, plumbing modules are implemented as member functions of the base simulator object). To use NS one has to program in OTcl script language. When OTcl script is being interpreted, NS will create analysis reports where NAM (Network Animator) object will show the visual animation for the simulation of the network and the other one is a trace object which consist of behavior of all simulation objects. These two are created as file for NS. One file used by NAM software is .nam file in NS. Other one is ".tr" file which is having text format simulation traces. NS project is having various packages (ns, nam, tcl, otcl etc.) named as "all-in-one package", which can also be downloaded and found separately. Here we used version 2.29 of ns all-in-one package and it is installed in the Windows environment using Cygwin. In our thesis we will refer version 2 , NS as NS-2. The ".tcl" files iswritten in text editor and ".tr" file results are analyzed by the use of commands of Unix Operating System like "cat", "awk", "wc" and "grep". The implementation phase of the Gray hole behavior to the AODV protocol is written using C++.

4.2 Implementation of Gray hole Attack

In our work, the nodes having gray hole behavior is used in wireless ad-hoc network which uses AODV protocol. A new routing protocol is used which will participate in AODV messaging for gray hole. The implementation explained below is new routing protocol:

"NS-2.29" is the directory where all routing protocol in NS are installed. The work of implementation of gray hole start by duplicating AODV protocol in this directory by changing the name of directory as "grayholeaodv". Names of files which are labeled as "aodv" in the directory are changed to "grayholeaodv" such as grayholeaodv.cc, grayholeaodv.h, grayholeaodv.tcl, grayholeaodv_rqueue.cc, grayholeaodv_rqueue.h etc. in this new directory except for "aodv_packet.h". The main point here in our work is that AODV and Gray Hole AODV protocol will send the same AODV packets to each other. That is why "aodv_packet.h" file is not copied into the grayholeaodv directory. Except the struct names which belongs to AODV packet.h code we have changed all functions, classes , constants and variables names in all files in the directory. We designed grayholeaodv and aodv protocol such that they will send aodv packets to each other. Although these two protocols designed are same. After these changes other changes made are in two common files which are used in NS-2 globally which integrate

new grayholeaodv protocol to the simulator. In our implementation as we don’t need to add a new packet , so we have changed only two files . These changes are explained as below. The first file which is modified or changed is "\tcl\lib\ ns-lib.tcl" where procedures coded are protocol agents.

grayholeAODV {

set ragent [$self create-grayholeaodv-agent $node]

}

Simulator instproc create-grayholeaodv-agent { node } {

set ragent [new Agent/grayholeAODV [$node node-addr]]

$self at 0.0 "$ragent start" # start BEACON/HELLO Messages

$node set ragent_ $ragent

return $ragent

}

Figure 4.2 – "grayholeaodv" protocol agent is added in "\tcl\lib\ ns-lib.tcl"

When grayholeaodv protocol is used by the nodes, at the beginning of the simulation this agent is scheduled which is assigned to the node which will use grayholeadodv protocol. The agent procedure for grayholeaodv is shown in Figure4.2. The other file that is adapted is "\makefile" in the root directory of the "ns-2.29". We have to compile NS-2 again to create object files, when all implementations will get ready. The lines in Figure 4.3 are added to the "\makefile".

grayholeaodv/grayholeaodv_logs.o grayholeaodv/grayholeaodv.o \

grayholeaodv/grayholeaodv_rtable.o grayholeaodv/grayholeaodv_rqueue.o \

Figure 4.3 – Addition to the "\makefile"

Therefore we have implemented a new routing protocol so far labeled as grayholeaodv. But Gray Hole behavior is not implemented in this new routing protocol so far. To add Gray Hole behavior into the new AODV protocol we have to make some changes in grayholeaodv/grayholeaodv.cc C++ file. These changes made in grayholeaodv/grayholeaodv.cc file explaining working mechanism of the AODV and Gray Hole AODV protocols will be described below. The packet received are processed according to their types received by the "recv" function of the "aodv/aodv.cc". The "recvAODV" will receive the packet if any of the packet is AODV route management packets type. If the received packet is a data packet, in general it is sent to the destination address by the AODV protocol, but behaving as Gray Hole it drops packets while continuing to forward the packets in network. Some time the gray hole node behaves maliciously for a time being by dropping packets for some time after that it starts to behave like a normal node .Gray hole attack sometimes is also known as node misbehaving attack . In the code below, the first "if" condition provides the node to receive data packets if it is the destination. The "else" condition drops all remaining packets. If statement is shown in Figure 4.4

if ( (u_int32_t)ih->saddr() == index)

forward((grayholeaodv_rt_entry*) 0, p, NO_DELAY);

else

drop(p, DROP_RTR_ROUTE_LOOP);

Figure 4.4 – "If" statement for dropping or accepting the packets

case AODVTYPE_RREQ:

recvRequest(p);

break;

case AODVTYPE_RREP:

recvReply(p);

break;

case AODVTYPE_RERR:

recvError(p);

break;

case AODVTYPE_HELLO:

recvHello(p);

break;

default:

fprintf(stderr, "Invalid grayholeAODV type (%x)\n", ah>ah_type);

exit(1);

Figure 4.5 – Case statement for choosing the AODV control message types

The "recv" function sends the packet to "recvgrayholeAODV" function if the packet is AODV management packet. The "recvgrayholeAODV" function will check the packets and their type on the basis of the type of packet it will send them to appropriate function with a "case" statement. For some time , the RREQ packets will be sent to the "recvRequest" function, RREP packet is sent to "recvReply" function etc., case statements of "recvgrayholeAODV" function is shown in Figure 4.5. Here in our case the RREQ function is considered as the Gray Hole behavior is carried out as soon as the attacking node receives an RREQ packet. When the attacking node will get an RREQ packet, RREP packet is sent immediately having fresh enough path to the destination. We will either forward the REQUEST or will initiate a REPLY. Before we use to do anything , we will see that the REVERSE route is there in the route table. If the sequence no. is fresh enough or hop counts are lesser for the same sequence no. the rt entry is updated. Else we won’t bother. The RREP packet sent by the malicious node are same as sent by the AODV RREP messages and it can be forwarded or it can be dropped if the sending node has to be attacked to make it exhausted. When all changes are made NS-2 file has to be recompiled to create object files. When compilation is finished , we will get new test bed to simulate Gray Hole Attack in AODV protocol.

sendReply(rq->rq-src, // IP Destination

1, // Hop Count

index, // Dest IP Address

seqno, // Dest Sequence Num

MY_ROUTE_TIMEOUT, // Lifetime

rq->rq_timestamp); // timestamp

Figure 4.6 –RREP message of Gray Hole Attack

Now simulation scenarios can be understood only with the knowledge of the Tcl language. Now after implementation of Gray Hole attack ,we will present the simulations which will illustrate its effects. Then we will evaluate the effects of Gray Hole Attack in an Ad-Hoc Networks and procedure to detect and remove the gray hole effect.

4.3 Tcl Language in NS

Tool Command Language, TCL is a interpreted programming language which was developed by John Ousterhout at the University of California, Berkeley. It is a dynamic and powerful language. Its usage areas are networking, testing, administration, desktop applications, web etc. It is an extensible, cross platform language. Tcl language is fully compatible with C and Tcl libraries are such that it is interoperated into C program directly. Here the Tcl code is described which we have designed to implement the gray hole attacks.

4.4. Testing of Gray Hole AODV

The implementation is checked to see whether it is working properly or not. To make sure that implementation is running correctly or not NAM (Network Animator) application of NS is used.

Here we have tested implementation using two simulation out of which one scenario is such that where we havn’t used Gray Hole AODV Node (the attacking node which will did gray hole attack is known as "Gray Hole Node". The next scenario is one where Gray Hole AODV Node is there in simulation. Then both the results of simulation are compared using NAM.

4.4.1. Simulation Parameters and Metrices

We have used UDP protocol so that simulation results can be taken accurately. In UDP protocol the source node continue to send the UDP packets, even if they are dropped by the attacking node, but in TCP protocol connection is finished by the node. During simulation the connection flow is observed between sending node and receiving node. We are able to count the received and sent packets as the UDP connection doesn’t lost during simulation. But case is different in TCP protocol where the received and sent packets can’t be counted because the node which has started the TCP connection will end the connection after sometime if it will not receive the TCP ACK packet. Here we have simulated a small network having 7 nodes and created UDP connection between Node 5 and Node 2 ant CBR which is constant bit rate is attached that will generate constant packets via UDP connection of size 512 bytes long and data rate of 1 Mbyte. Here simulation scenarios duration is of 20 seconds , the CBR connection continue until the end of simulation after starting at 1.0 seconds, in flat space of 79 x 659 meter. The position of the nodes is defined manually which will show the data flow and also introduce Node 1 movement which will show data flow changes in the network.

4.4.2. Simulation Assessment

In the first scenario where there is not a Gray Hole AODV Node, connection can be flawed correctly between Node 4 and Node 5 when using NAM animation are seen of the simulation.

Figure 4.7– Data flow between Node 2 and Node 5 via Node 1 and Node 6

Figure 4.7 shows the data flow from Node 2 to Node 5. When the Node 1 leaves the propagation range of the Node 2 while moving, the new connection is established via Node 3. The new connection path is shown in Figure 4.8.

Figure 4.8 – Data flow between Node 2 and Node 5 via Node 3 and Node 4

In the second case, by writing the three statements in the Tcl script, shown in Fig 4.9, we can add the Gray Hole behavior to Node 0. The first statement, "$ns node-config -adhocRouting grayholeAODV" is to add the Gray Hole AODV behavior to the nodes created. Here we will define Node 0 as a Gray Hole AODV and we will have to change to AODV protocol after Node 0 with the statement third . The second statement is like putting notification to Node 0 for defining it as a Gray Hole Node. As Node 0 is a Gray Hole AODV Node it will absorbs the packets between the connection Node 2 to Node 5. Figure 4.10 shows how the Gray Hole AODV Node attacks the victim node which is sending the data packets. Here we will make sure that implementation of the Gray Hole AODV is working correctly. Then, actual simulation is performed which we will describe in the next section. As the effects of Gray Hole AODV Node can’t be seen easily in large number of Nodes and connections so actual simulation has to be carried out with small number of nodes .

# $ns node-config -adhocRouting grayholeAODV

set node_(0) [$ns node]

# $ns at 0.0 "$node_(0) label \"GrayHoleAODV Node\""

# $ns node-config -adhocRouting AODV

set node_(1) [$ns node]

set node_(2) [$ns node]

$ns at 0.0 "$node_(2) label \"Sending Node\""

set node_(3) [$ns node]

set node_(4) [$ns node]

set node_(5) [$ns node]

$ns at 0.0 "$node_(5) label \"Receiving Node\""

set node_(6) [$ns node]

Figure 4.9 - Node creation and configuration in Tcl script

Figure 4.10- Node 0 (Gray Hole Node) absorbs the connection Node 2 to Node 5

4.5. Simulation of Gray Hole Attack

4.5.1. Measured Metrics and Simulation Parameters

The UDP connections will be established between even and odd numbered nodes so 20 nodes are used and here Node 18 as well as Node 19 are not having any connection to other nodes in the network. In each scenarios even node will send the data packet to the odd number nodes so even number nodes are sending nodes whereas the odd number nodes are receiving nodes. So the data packets sent and received can be counted between any two nodes. In scenarios ,UDP agent is attached to each even numbered node and a NULL agent to the odd numbered nodes. So there are total 9 connections in between 18 nodes and all connections are between same nodes. In each scenario , each node is in different coordinates and will exhibit different type of movements which will help us to get different results for same nodes. The "./setdest", will randomly generate movements and node position, its parameters are used to name each scenario. for example; "scen1forAODV-n20-t500-x750-y750". "./setdest" application will generate scenario of 20 nodes which will move randomly from starting point to the destination with a randomly selected speed ,in flat space 750 x 750 meter , during 500 secs. We will attach CBR application which will generate constant packets over UDP connection. Scenarios are of duration 500 secs where the CBR connection will last at 450 secs of the scenario after starting at the 1 sec of the scenario. Here in each scenario packet used is of size 512 bytes and data rate is of 10 Kbits and random packets are not used in the simulation. "./cbrgen" ,third party application, generate the connection types which is saved as file "cbr" in directory of the simulation root "/scenarios". For loop will create same cbr connections. The "for" loop statement generates the nodes using Tcl language in the simulation. Figure 4.11 will show the statements which will create the nodes.

The configuration in Figure 4.12 is used to create first 19 nodes using first loop. "$ns_ node-config -adhocRouting grayholeAODV" statement will change the routing protocol of the node configuration as "grayholeAODV" . Last node is created by the second loop. AODV and Gray Hole AODV nodes can be created according to our wish by changing the "$val(nnaodv)" variable. Changing the "$val(nnaodv)" variable we can create AODV and Gray Hole AODV nodes as we wish.

for {set i 0} {$i < $val(nnaodv)} {incr i} {

set node_($i) [$ns_ node]

$node_($i) random-motion 0 ; # disable random motion

}

# The last node behave as grayhole

$ns_ node-config -adhocRouting grayholeAODV

for {set i $val(nnaodv)} {$i < $val(nn)} {incr i} {

set node_($i) [$ns_ node]

$node_($i) random-motion 0 ; # disable random motion

$ns_ at 0.01 "$node_($i) label \"grayhole node\""

}

Figure 4.11 - "for" loop statement that create wireless nodes

Simulation files are saved according to simulation number and "GraykHole"definition like , "sim1forGrayHole.tcl" is used for simulation 1. To compare simulations having Gray Hole AODV node and one which is not having that , we changed the "$val(nnaodv)" variable to 20 and by put the comment "#" in front of the "$ns_ node-config -adhocRouting grayholeAODV"

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) 150 ;# max packet in ifq

set val(rp) AODV ;# routing protocol

Figure 4.12 - Wireless Node Configurations

statement and the Tcl script is copied in same directory by changing "GrayHole" definition of the file name with "AODV", for example, "sim1forAODV.tcl" for simulation 1.

4.5.2. The Trace File Examining and The Results

The simulation results can be taken by the output trace file having .tr extension of the Tcl script.

Trace file are having all events about the simulation like when data packets are sent, from where they are generated , where they are received ,what are the types of data packets sent, if it is dropped then its reason why it is dropped etc. "new-trace" file format is used in our simulation which is in use for wireless networks these days and it is having all event information. To trace result event type in Field 0 ,(-Ni) node id and (-N1) trace level in Field 4, destination and source address and the type of apacket in Field 5 are used from the trace files. "cat" command is used to identify the above information and the outputs are written in some other file for all simulation trace files. Out of all outputs, fields needed are:

"s" the event information value in the Field 0, which will count CBR packets sent by the sending node

"r" the event information value in the Field 0, which will count CBR packets received by the receiving node

"node id" the node id information value in the Field 4, for receiving nodes or the sending nodes

"MAC" the trace level information value in the Field 4, which will filter MAC level.

"source address" and "destination address" values information of the source and destination address in Field 5, which will count the packets which will be sent from the sending node to the node which will receive them.

"cbr" the packet type information value in the Field 5, which will filter CBR packets.

So to filter these information "grep" UNIX command will be used , file generated by "cat" command is read and it is given as output to "wc" command. And then the result is written to a new file. For example; to count CBR packets sent by Node 0 (sending node) the command "grep "s 0 MAC --- 0.0 1.0 cbr" sim1forGrayHole.txt | wc -l >> result.txt" is used.

On the other hand, to count CBR packets received by Node 1 (receiving node), "grep "r 1 MAC --- 0.0 1.0 cbr" sim1forGrayHole.txt | wc -l >> result.txt" is used.

These commands are used for all nodes in all simulations and they are written as a batch file.

4.6 Process for detection and removal of Gray hole Attacks

4.6.1 Detection Process

Gray Hole Attack detection process by source node:

Data packets are divided into k equal parts. A message is sent to the destination which will be having the number of messages. After that messages are broadcasted to all neighbouring nodes of the route. After making sure that the destination node knows count of messages sent, source will start to send data. A timer is set until number of data packets are received at the destination node. If the number declared previously is less than the packets received at the destination then the removal process for gray hole attack is initiated. If after termination of the timer any message is not received at the destination then also the removal process is initiated.

Gray Hole Attack detection process by the destination node:

After sending the number of data packets to be sent by the source node timer is set to zero and data packets are counted at the initiation of the timer. After timeout the number of data packet number received are sent to the source node.

Gray Hole Attack detection process by the neighbouring nodes:

When monitoring message is received by the source node, counter is started by each neighbouring node which will count the number of data packets.

4.6.2Removal Process

Gray hole attack removal process by the source node:

Source node will get information for any one node’s neighbours about the attack. According to the information of neighbouring node, starts the counter for attacking node in FindMalicious table. If the votes that are received from the neighbouring nodes exceeds the limit for the maliciousness, that node is entered in Gray hole table by the source node and new route for destination is find out. And the network is announced about the malicious node.

Remove process for gray hole attack by neighbour nodes:

When the nodes in the network will get monitoring message, then the neighbouring nodes will start to count the number of packets that are sent by the malicious node. If the number of the received packets is less than a limit then the source node is informed about it.

4.7 Evaluation of Results

There are two simulations for each scenarios. To keep the communication on in the network every node work in cooperation with each other. The second simulation will be having one adversary node which carries out the Gray Hole Attack. In our study, we will try to compare the results of the two simulations so that network and node behaviours can be understood. The packet loss is tried to be evaluated first. Therefore we will count the number of data packets sent by the sending node and the number of data packets received by the receiving node. In previous section it is described how we will get the number of packets. And then the network having Gray hole network and the network which is not having it is compared. Then it is noticed by us that how many packets are sent by the sending node and how much packets are received by the receiving node. After that it is calculated that how many packets will reach the destination node and how much packets will drop or absorbed by the Gray Hole Node, by calculating the difference of the tables of Gray Hole AODV network and the network without the Gray Hole Node. We then noticed that the data loss percentage of Gray Hole AODV will be increased as compared to the normal AODV network scenarios simulations. It is also understood by the analysis of the network that the packet loss already exist in the network which is because of density of data traffic because of which at the node interface queue the packets are dropped. Node and packet parameters are altered to minimize the data traffic. To evaluate the Gray Hole effect in the network, the packet loss has to be minimized which will happen in the network. In wireless ad-hoc network which is not having any Gray Hole, data packets will get lost due to dense data traffic in FTP traffic for instance. In our simulations of AODV network without gray hole node, we see that data loss has increased up to 35% to 40% when the parameters are changed. Therefore, the data loss does not always mean that there was a Gray Hole Node in the network. So it is not easy to detect the Gray Hole Node in the network.

4.8 Simulation Environment

For the simulations here, we have used NS-2 (v-2.29) network simulator. NS-2 provides trustworthy implementations of the different network protocols. IEEE 802.11 algorithm is used at the data and physical link layer. The channel used is Wireless Channel with Two Ray Ground radio propagation model. At the network layer, we use AODV as the routing algorithm. UDP is used in transport layer. All the data packets are CBR (continuous bit rate) packets. The size of packets is 512 bytes having transmission rate 0.2 Mbps.The connection pattern is generated using cbrgen and the mobility model is generated using setdest utility. Setdest generates random positions of the nodes in the network with specified mobility and pause time. The terrain area is 800m X 800m with number of nodes varying from minimum 10 to maximum 80 with chosen maximum speed up to from 10 m/s to 70 m/s. The simulation parameters are summarized in table.Each data point represents an average of ten runs. The same connection pattern and mobility model is used in simulations to maintain the uniformity across the protocols.

Parameter Value

Simulator

Ns-2(ver.2.29)

Simulation Time

100s

Number of nodes

10 to 80

Routing Protocol

AODV

Traffic Model

CBR

Pause Time

2s

Mobility

10-70 m/s

Terrain area

800m X 800m

Transmission Range

250m

No of Malicious node

1

Table 4.1 Simulation Parameters

4.9. Metrics used for Simulation

To analyze the performance of our solution, various contexts are created by varying the number of nodes and node mobility. The metrics used to evaluate the performance of these contexts are given below.

Packet Delivery Ratio: The ratio between the number of packets originated by the "application layer" CBR sources and the number of packets received by the CBR sink at the final destination.

Average End-to-End Delay: This is the average delay between the sending of the data packet by the CBR source and its receipt at the corresponding CBR receiver. This includes all the delays caused during route acquisition, buffering and processing at intermediate nodes, retransmission delays at the MAC layer, etc. It is measured in milliseconds .

Throughput is the measure of how fast we can actually send through network. The number of packets delivered to the receiver provides the throughput of the network.

Normalized routing overhead: The number of routing packets transmitted per data packet delivered at the destination. Each hop-wise transmission of a routing packet is counted as one transmission.