ANALYZING THE PERFORMANCE OF INTRUDER

DETECTION SYSTEM AGAINST VARIOUS PROTOCOLS

Thesis submitted to
MOTHER TERESA WOMEN’S UNIVERSITY
For the award of the degree of

MASTER OF PHILOSOPHY
IN
COMPUTER SCIENCE

By
SUGANYA.S
Reg.No:157205ER043

Under the guidance of

Dr. (Mrs.) N. VANJULAVALLI.
M.C.A., M.Phil. Ph.D.,
Assistant Professor in Computer Science,

DEPARTMENT OF COMPUTER SCIENCE

MOTHER TERESA WOMEN’S UNIVERSITY
KODAIKANAL 624 102

2017
 CERTIFICATE BY THE SUPERVISOR

Certificate that the thesis “ANALYSING THE PERFORMANCE

OF INTRUDER DETECTION SYSTEMS AGAINST VARIOUS
PROTOCOLS” submitted by SUGANYA.S is a record of research work carried
out by her for the degree of Master of Philosophy under my guidance.

This thesis is an original work of the candidate and to the best of my

knowledge has not been submitted, in part or in full, for any Diploma, Degree,
Associateship, Fellowship or other similar titles in this or any other University.
No part(s) of the thesis is reproduced from any other source, published or
unpublished, without acknowledgement

Station:
Date:
Signature of the Supervisor
 DECLARATION BY THE CANDIDATE

I declare that the thesis “ANALYSING THE PERFORMANCE OF

INTRUDER DETECTION SYSTEMS AGAINST VARIOUS PROTOCOLS ”
is the result of a study originally carried out by me/independently under the
guidance and supervision of Dr.N.Vanjulavalli, M.C.A., M.Phil., Ph.D.,
Assistant Professor in Computer Science, and Annai College of Arts & Science.
This work has not been submitted earlier, in full or in part, for any Diploma or
Degree in this or any other University.
I also declare that no part(s) of the thesis is reproduced from any other
source, published or unpublished, without acknowledgement.

Station:
Date:

Signature of the Candidate

(SUGNAYA.S)
 ACKNOWLEDGEMENT

I wish to express my sincere thanks and gratitude to Vice Chancellor, Registrar

and Controller of Examinations of Mother Teresa women’s University who have offered
me an opportunity to pursue research study.

My special thanks to Dr. Mrs. A. Kalaimathi, Director (Regular),, Mother Teresa

Women’s University, Research Extension Centre, Chennai for her kindness in guiding me for
the preparation of the booklet by way of constant discussion, instruction, advice and valuable
suggestions.
My sincere thanks to my research supervisor Dr.N.Vanjulavalli, M.C.A.,M.Phil.,
Ph.D., Assistant Professor in Computer Science, Annai College of Arts & Science for her
assistance in the important stages of preparation of this project work.
I am deeply grateful to the Staff Members of Mother Teresa Women’s University for
their invaluable help in the execution of this work
My thanks go to all Librarians, for facilitating the library for my Research work.
My sincere thanks and gratitude to all, and those names are not mentioned here but
who have directly or indirectly helped me in successful completion of the study.
Praise and glory to the God Almighty who is the source of strength, inspiration and
blessing in every walk of my life.
In the course of this research the investigator has been fortunate enough to receive
help from various sources to complete this dissertation. So I wish to express, my sincere
thanks and deep sense of gratitude to all those who contributed to accomplish this endeavor
successfully.

SUGANYA.S
 ABSTRACT

Ad-Hoc networks are the self structured, controlled and configured networks that are
capable of operating themselves without using any specific communications and
infrastructures. Basically, here exist three different types of Ad-hoc networks such as
MANET- mobile ad-hoc networks, wireless mesh networks as well as wireless sensor
networks. All these ad-hoc networks are capable of operating in a infrastructure free
environment without using any configurations wires. In general, ad-hoc networks include
different types of routing protocols in order to perform the routing process by using the
MANET protocols such as proactive routing protocols, reactive routing protocols and Hybrid
protocols.

Generally, MANETs involve two different types of attacks such as passive attacks as
well as active attacks. The information and data present in the networks will be attacked by
the passive attacks, whereas the worm attacks take place in the networks which are known as
active attacks that duplicates as well as exchanges the data present within the network.
Within the total number of active attacks over ad-hoc networks, black hole attacks are
happened to be serious attacks that make the networks more vulnerable and it will not be able
to perform the routing tasks. In this black hole attacks process, the entire malicious nodes will
request for the new routing processes without transferring the data and information present in
the networks. In general, the black hole attacks that take place in the networks are been
categorized into two different types such as RREQ based black hole attack and RREP based
black hole attack. This study deals with the performance evaluation of AODV under the
black hole attacks by using the OPNET simulation.
 TABLE OF CONTENTS

Page No.
CHAPTER-!
1. Introduction 1-1
1.1 Aim.................................................................................. 1-1
1.2 Objectives........... .................................................... ....... 1-2
1.3 Overview of Ad-hoc networks...................................... 2-4
1.4 Way to achieve the Objectives................................... .•». 4-5
CHAPTER-2
2. Literature Review 6-6
2.1 Overview of AODV Protocol........................................ 6-7
2.2. Unicast Routing of AODV Protocol..................... . 7-9
2.3. Multicast Routing of AODV Protocol........................ 10-11
2.4. Security Considerations of AODV Protocol................ 11-11
2.5 Route Discovery in AODV............................................. 12-13
2.6. Performance of TCP over MANET's............................ 13-14
2.6.1 Scalability....................................................... 14-15
2.7 Factors responsible for the low performance of TCP over
16-17
MANETs .
2.8 Behavior of TCP over CBR............................. 17-19
CHAPTER-3
3. Research Methodology 20-34
3.1 Introduction to software development methodology....... 20-21
3.2 Software Development Lifecycle Models........................ 22-22
 3.2.1 Waterfall Model......................................................... 22-23
3.3 V-Shaped Model.................................................................. 24-25
3.4 Structured evolutionary prototyping model........................ 26-26
3.4.1 Structured Evolutionary Prototyping Strengths....... 26-27
3.4.2 Structured Evolutionary Prototyping Weaknesses... 27-27
3.4.3 When to use Structured Evolutionary Prototyping... 27-28
3.5 Rapid Application Model (RAD)........... ........................ 28-28
3.5.1 RAD Strengths..................................... ...................... 28-29
3.5.2 RAD Weaknesses............... 29-29
3.5.3 When to use RAD..................................................... 30-30
3.6 Introduction to Agile......................................................... . 30-32
3.7 Methodology Used...................................................... 32-32
3.8 Defining methodology....... .............................................. 32-32
3.9 Types of Research Methodologies.................................... 33-33
3.9.1 Quantitative research method........................ 33-33
3.9.2 Primary Data..............................i... ............ 33-33
3.9.3 Source of Primary Data............................................. 34-34
3.10 Ethical Issues......................... .................... ................... . 34-34
CHAPTER-4
4. Simulation Procedure 35-55
4.1 Introduction.......................................................................... 35-35
4.2 Mobile Ad hoc network setup for normal scenario...... 35-38
4.2.1Application configuration definitions................ ... 38-39
4.2.2 Profile configuration settings.................................... ^0-41
4.2.3 Mobility Configuration.............. :........................... 41-43
, . , . ' 43-46
4.2.4 Mobile nodes and wireless LAN Server configuration
 4.2.5 Performance metrics........................... ................... 46-49
4.3 Blackhole attacks scenario............ .................................. 49-51
4.4 AODV perfonnance scenario................................ ........... 51-54
4.5 Running the simulation................................ .................... 54-55
CHAPTER-5
5. Analysis of Results 56-5
5.1 Introduction........................................ 56*66
5.2 AODV metrics considered for three scenarios.............. . 56-58
5.2.1 AODV route discovery time................. ................ ;. 58-59
5.2.2 AODV routing traffic received in bits per sec....... 60-61
5.2.3 AODV Routing traffic received in packets per sec. 61-62
5.2.4 AODV Routing traffic sent in bits per sec........... . 62-63
5.2.5 AODV Routing traffic sent in packets per sec 64-65
5.2.6 AODV Total cache replies sent............................ 65-66
5.2.7 AODV Total packets dropped........................ . 67-68
5.3 File Transfer Protocol results............ ........................... 68-68
5.3.1 Download response time......................................... 68-70
5.3.2 Traffic received bytes per sec................................ . 70-71
5.3.3 Traffic sent in bytes per sec..................... ............. . 71-72
5.3.4 Upload response time....................................... . 73-74
5.4 HTTP application results.............. ........,............................... 74-74
5.4.1 Page response time................................ 74-75
5.4.2 Traffic received bytes per sec................................ 76-77
5.4.3 Traffic sent in bytes per sec............................. 77-80
5.5 Wireless LAN Parameters............................................. 80-80

ix
 CHAPTER-6
6. Conclusion and Future work
6.1 Conclusion..................... 81-82
6.2 Future work................... 83-83
6.3 Appendix.................... 83-119
REFERENCES.......................... 120-134
LIST OF PAPERS.,..,.............. 135-151
 CHAPTER-1

1. Introduction

1.1 Aim

The actual aim of the proposed study is to perform the performance evaluation

process of AODV under the black hole attacks by making use of the OPNET

simulation in order to simulate the results.

1.2 Objectives

The main objectives of this study are

© To analyze the information on ad-hoc networks in association with routing

protocols

• To evaluate the information on different MANET attacks within ad-hoc

networks

• To design the scenarios of OPNET for evaluating the AODV performance

under black hole attacks

• To use the OPNET simulation tool for developing the design scenarios

• To evaluate and analyze the scenarios of simulation by comparing them

under the black hole attacks[l].

1
 • To test and examine the results by evaluating the AODV performance under

the black hole attacks

1.3 Overview of Ad-hoc networks

According to the views of David A. Maltz (2001) nowadays, ad-hoc networks are

playing significant role in the networking processes which includes different types

of routing protocols that are used for managing the routing process within the

mobile adhoc networks. The Unicast as well as multicast are the two different

routing processes that take place in adhoc networks and this particular process is

performed by the adhoc networks with use of the AODV- adhoc on demand

distance vector protocol. This AODV protocol involves a basic algorithm that

performs different tasks such as on demand process through which the main

routing processes will be managed by using different nodes that are present in the

networks.

Parikshit Machwe [2] stated that in order to add or change the predefined rotes

associated with the different types of network parameters such as bandwidth as

well as congestion the different rules are passed to the adhoc networks. In order to

connect the nodes within the networks, the AODV protocol will make use of the

tree based structure that contains different groups related to multicast routing

2
process. In general, the AODV protocol is a type of reactive protocol which is

having similar characteristics of the proactive routing protocols.

The DSSR- dynamic routing protocol is been used for the purpose of implementing

the AODV protocol within the adhoc networks that performs the route discovery

process with use of DSDV- destination sequence distance vector that transfers the

hello messages within the networks. This AODV protocol performs each and every

activity in a timely manner and replicates the new nodes by replacing the old nodes

in the ongoing process. The AODV protocol will even update all the nodes present

in. the network regarding the changes that take place in the routing process of the

networks which regularly uses the destination nodes.

Clifton Lin (2008) opined that routing protocols will make use of the routing tables

for the purpose of managing the routing process because they appear in static

nature which has fixed routing process through which there are not capable of

managing the configuration changes that take place in the network topology.

Reactive routing protocols are known as the on demand routing protocols which

appear in dynamic nature and are highly capable of managing the entire

configuration changes that take place in the network topology. Whereas, hybrid

routing protocols are integrated with the proactive as well as reactive routing

protocol characteristics and will work on multiple conditions and performs the both

tasks done by proactive and reactive protocols.

3
Nevertheless, among the existing MANET protocols, reactive protocols which are

even known as on demand routing protocols are been widely accepted and used in

the mobile ad-hoc networks because they are present in dynamic nature and are

able to manage all die tasks that are to be performed in the network topology.

Among the total number of reactive routing protocols, AODV- Ad hoc on demand

vector is widely used within the ad-hoc networks. This AODV protocols has many

internal characteristics through which it performs wider range of network activities

such as building work nature of the protocol by which the network will be able to

manage and detect the threats or attacks that take place in the networks [2,3].

1.4 Way to achieve the Objectives

In order to achieve the research objectives, different tasks are performed which are

explained in detail as follows:

* Different types of published articles, peer reviewed journals and web

document will be gathered from the internet-and college library sources

which are used as the secondary data sources over the study.

• The existing literature reviews related to adhoc networks will be taken into

consideration and will be analyzed critically in order to get the final

expected outputs.
• Different types of routing protocols of mobile adhoe networks will be

analyzed and evaluated critically.

• The network setup will designed by making use of the OPNET scenarios

• Different routing attacks especially black hole attacks will be identified and

verified by using OPNET simulation tool.

5
 CHAPTER-2

2. Literature Review

2.1 Overview of AODV Protocol

Ad-hoc On Demand Distance Vector (AODV) Protocol was initially introduced by

MANET (Mobile Ad-hoc Networks) working Group in year 2001 for routing. This

protocol was one among DV (Distance Vector Routing Protocols) class. In DV,

each of the node be familiar with its neighbour node and even know the cost to

reach that particular node. Here, the function of node is to uphold its own routing

table, store the entire nodes in network, and the distance and next hop to this node.

In case, whenever the node is not reachable then the distance for that particular

node is kept to infinity. All nodes in the network sends the whole routing table

periodically to its neighbours so that the node can verify whether there is a good

route to another node by making use of its neighbour as next hop. In this process if

a link breaks then automatically count-to infinity enables[4).

Basically, AODV protocol is defined as an on demand routing protocol by

means of diminutive delay. Here, the routes are set up only when required in order

to diminish the traffic overhead. This protocol further supports Unicast, Broadcast

and Multicast exclusive of other protocols. With the help of registration of costs

and sequence numbers, the problem occurred with count-to-infinity and loop issues

6
are solved[5]. Each and every hop in AODV contains constant cost of one. To put

up the mobile nodes movement the routes age very rapidly and link breakages can

be efficiently repaired locally. Moreover to typify AODV, the five norms used by

Keshav is AODV distributed, deterministic, state dependent, hop-by-hop and

single path[5].

AODV protocol makes use of IP (Internet Protocol) and refers IP address as unique

identifier. It can be easily carried out by setting the subnet mask to

255.255.255.255. However the aggregated networks are supported and these are

implemented as subnets. In the complete subnet, barely one router in each has an

ability to function AODV and further it serve as default gateway. It need to uphold

a sequence number for complete subnet and also to forward each and every

paekage[6].

Routing table in AODV is extended by sequence number to each of its target and

time to live for all its entry. Further even it is prolonged by interface, routing flags,

outdated routes the last hop count is stored and for list of precursors.

2.2. Unicast Routing of AODV Protocol

Unicast routing make use of three control messages, which are:

• RREQ (Route REQuest)

• RREP (Route REPly)

7
 RERR (Route ERRor)

Whenever a source node wish to send a packet to other node where it doesn't have

any route then the source node sends RREQ message. If the node receives RREQ

message which it doesn't have seen before it set up reverse route to source node.

Here, if end node fails to route its detonation node (that is source node) then it just

rebroadcasts the updated RREQ message by incrementing the hop count and in

case if end node identify route to source node then it sends RREP message[7].

RREP consists of unique identifier, destination IP address and sequence

number, source IP address and sequence number along with hop count initialized

with zero and flags. RREP is unicasted to source node by taking benefit from its

reverse routes. Now when the source node receives RREP message then it verifies

whether the hop count in RREP is lesser than one in its own routing table or

sequence number of destination is higher than one in its own routing table. If in the

above case, none of the condition is true then it just throw the packet[8]. In case if

it is true then it just updates its routing table and if that is not its end node then it

reunicasts the RREP.

Link breakage is one of the common problems in mobile networks. In a

network, if a node comprehends those routes to other nodes are not reachable then

this node broadcasts RERR message which includes list of unreachable nodes
along with their IP addresses and sequence number and some flags. The node that

receives RERR message will again iterate over the list of unreachable destination

nodes and verifies whether the next hop in its routing table includes one of these

nodes or not. If it has the node then it automatically updates its routing table. In

case if the receiving node still maintain routes to unreachable nodes it again sends

RERR message on its own including this data[l,9].

The life time of both routes and links are prolonged by sending the packet

through it and by hello messages. Here, a hello message is a special RRER which

is valid only for its neighbours. In a network, the node can periodically send a hello

message so that no link breaks are assumed whenever they don't get any message

from other node for a long time.

In an active route if the link breaks then the node can easily repair the route

locally. To attain this, the node sends a RREQ message to locate a new route to its

detonation on out of order link side by not disturbing other routes. Here, even there

exists other special package RREP-ACK for unidirectional or unreliable links[10].

Apart from these, even there are mechanisms like precursors which is used to track

the list of active routes for using RERR emission.

9
2.3. Multicast Routing of AODV Protocol

One of the main benefit by making use of AODV is that it is an integrated

multicast routing. Here, in multicast routing table the sequence number of group

and IP address are stored. Apart from these, even it stores leaders EP address and its

hop count along with the next hop in multicasting tree and its lifetime.

If a node wants to join a multicast group then that particular node should

initially send an RREQ message to group address along with join flag set. Any of

the nodes in multicast tree that receives RREQ message can give answer through

RREP message. In this way a requester can receive numerous RREP from various

nodes. Among these entire RREP message the node can select any one of the

message having the shortest distance to its group. A Multicast Activation (MACT)

message is send to selected tree node in order to activate this branch. In case, if a

requester fails to receive any one RREP message from any node then this particular

node is referred as a group leader since there doesn't exist any multicast tree for

this group in that particular segment. The multicast RREP message comprises hop

count to next group member and additional IP of a group leader. Periodically, the

group leader sends group RREP (hello message) and further increments sequence

number each time in a group[l 1].

 Whenever two network segments are connected then two separate group

trees needs to be connected. Each group member that receives two group hello

messages from different leaders will identify a tree connection and simultaneously

emit RREQ message with repair flag set to group. In case, in a group tree if the

node fails to receive any group hello or other group then that particular tree must

be repaired with RREQ message and must make sure that not a RREP message

from node in its own tree is selected[12]. In a group tree if a group member (which

is a leaf) desire to go away from the group then with the help of MACT and flag

prune set the member an easily prune from branch, in case if the member is not a

leaf then that particular group member should carry on it process to serve as a tree

member.

2.4. Security Considerations of AODV Protocol

In mobile communication, the phenomenon security is considered as a

dangerous point. AODV protocol fails in defining any security mechanisms to its

users. So it's very easy for a hacker to attack the information transferred through

AODV protocol. In order to overcome from this issue, it's very essential to make

use of authentication like PKA (Public Key Authentication). However, messages

can easily be intercepted: So, to overcome from this issue user can further can

make use of cipher. Here standard IP security protocols cannot be used with these

protocols[13].
11
2.5 Route Discovery in AODV

In a network, if a node wants to communicate with other nodes then that

particular node build up some parameters and attributes which are discussed

below.

Initially the source node verifies its routing table to identify an access with

the target IP address node. In this process if the source node find the same then

simply it just uses the routing information from table and ends the communication

proeess[7,14].

In case, if the source node fails to identify any access in its routing table then it
V

follows some of the steps to further proceed its communication with destination

node are illustrated below:

• Firstly source node creates RREQ message with some attributes such as

source IP address, hop count to destination, unique broadcast ID, sequence

numbers of source and destination, and destination IP address.

• Once it creates its attributes source node sends RREQ message and stay for

some time for its reply by counting time with timer.

• Now the nodes which receives RREQ message will verify and compares its

message ID with the existing messages. If the node believes that the

message is already processed then it just discard the request.

12
 • In case if the node identify that the request message is unprocessed then it

further checks and compares the destination IP addresses with routing

information of their own tables.

• If the received node is the destination node then the message is processed

and if this node already had a route to its source node then it forwards

message towards the route.

• When the receive node processes RREQ message then it give reply to

source node in the form of unicast message RREP. Finally, source node

maintains IP address of node that delivered this message for further usage

[4,15].

2.6. Performance of TCP over MANET's

TCP (Transmission Control Protocol) is one of the mostly commonly used

transmission protocol across the data services such as file transfer, internet, etc.

Due to this reason even this protocol is being spread towards MANET [5,16].

Generally, there exist multiple TCP connections over MANETs and hence the

networkers face problems in evaluating the TCP performance in case of multiple

connections. Basically, MANET performance depends on some of the attributes

such as traffic load, mobility and scalability. Broad research had been carried out

13
on this aspect across CBR (Constant Bit Rate) against FTP (File Transfer

Protocol), TCP and UDP (User Datagram Protocol).

2.6.1 Scalability

Routing protocols scalability across MANETs mainly depends on attributes as

discussed in above context. Almost in all cases, TCP in current form fails to

support MANETs in terms of congestion control methodologies and in case of

route failures. There are numerous existing techniques which talk about the TCP

performance over mobile ad-hoc networks, however it is showed that it's very

difficult to crack and thus a lot of research is being carried out towards TCP

performance over MANET. In case of route failures, the TCP performance can be

improved with the feedback mechanism called as TCP-F (TCP-Feedback). In this

TCP-F, the intermediate node recognizes the link or route failures and further

sends the notification message called as RFN (Route Failure Notification) o TCP

source[17].

Once the sender TCP receives RFN notification, then it just quits sending the

wanted packets and just blocks the whole communication process. Here, if an

intermediate node has an ability to find out the path to destination node then it

immediately sends RRN (Route Re-establishment Notification) to TCP senders and

hence the source node reactivates its state and further continues with data
transmission process. Hence, from this conversation it can be said that actual TCP

throughput completely relate with the time taken for average repair towards route

or link failures across mobile ad-hoc networks[8,l 1,18].

Later another notification methodology was introduced called as ELFN (Explicit

Link Failure Notification) to improve TCP performance over MANETs. When the

intermediate node informs TCP sender related to link failure the TCP sender will

freeze its- state along with transmission window and timer set. In this notification

the route re-establishment use is not carried out instead TCP sender constantly

send its packets and verifies for the route availability in the MANET. Among

many simulation methods using OPNET and NS2, ELFN is showed to be best

when compare to RFN and is considered as the better choice for improving the

TCP performance over MANETs [7,8,19].

Generally, TCP offers an end-to-end data delivery across wired networks and

showed that it's an efficient means of data transmission. However it unexpectedly

fails in case of wireless networks such as MANETs. This is main reason why TCP

doesn't work in some conditions such as delay or packet loss where case of

MANET the packet delivery delay and packet losses are encouraged simply.

15
2.7 Factors responsible for the low performance of TCP over MANETs

Various factors are responsible for the low performance of TCP when compared

with MAMETS and in them few are discussed below.

BER (Bit Error Rates): These are the vital errors rates which are most responsible

for the performance of the TCP compared with MANETS. Commonly the when

compared with wire routes wireless routes are more responsible to the high bit

error rates and this because of the some kind of the reasons that are present

internally such as multipath fading and signal degradation and then finally this

leads to decrement of packets and based on this the data segment of TCP

losses[20]. Due to this without any reason the TCP invokes the control mechanism

of congestion and therefore the performance of the complete system is affected.

Multipath Routing: MANET’s one of the basic features is multipath routing and

for performance degradation this acts as the vital feature for TCP over MANET.

Most commonly the multipath routing is seen in the features where sender and

receiver signals flow and therefore this result in making the packets out of

sequence at the receiver end. Because of this across the network the duplicate

ACk’s are generated and this process completely similar to the TCP’s congestion

situation and again for reducing the duplicated the TCP again invokes the

mechanism of congestion control.

16
Route Failures: Due to the mobility various reasons are there for the failure of

routes across MANETs and because of this the performance of TCP is affected.

The complete time for reestablishment of the route taken by MANET must be

based on the routing protocol that is completely used in them and in few cases the

time taken is more than expected. Later it starts the congestion control mechanism

and this affects the complete performance of the system[21].

2.8 Behavior of TCP over CBR

For handling the CBR to transmit data such as audio or video User data protocol is

used, but still there are few limitations for the using UDP to support CBR that is

because of firewalls and due to this the connectivity which is achieved is limited. A

research was done for alternative protocols which can handle the CBR and SKYPE

which is one of the VOIP application that has been using the TCP over CBR.

There has been a lot improvement in the TCP for helping the mechanisms of loss

recovery such as SACK and after this the TCP is can be best used in the handling

the CBR workloads in real time. As there has been an increase in the applications

of multimedia and mobile every time a novel QoS are applied and in that most of

them are already existing routing protocols which are wireless and these try to

support the services of Qos and after testing it has been proved that these have

failed in case of mobile environments. For supporting the initial characteristics of

the mobile media a separate Qos standards were introduced and for that the CBR
17
was the initial requirement[22]. The consumption of energy for the MANETs is to

support the services of multimedia and this has been very high in most of the

conditions and in this the TCP has been proved to be an error correlation. There are

different attempts available for improving the TCP efficiency across MANET over

CBR and in this most of them are concentrated on the mechanisms of error control

[9,23].

For some kind of predetermined lifetime the AODV protocols is being considered

as this maintains and stays there for atleast 3 seconds and due to this it has been

called as the hop by hop routing protocol. Basically in any stage a initial route

entry is maintained for certain period of time and this will be maintained even after

the entry is out of scope. It has always been advantageous for maintaining a

minimum life time in the route entry and this was across the dynamic protocols of

routing such as AODV for MANETs. In many cases the CBR decides the life time

of the period. It has been considered that if the CBR period is not that sufficient

then there will not be that need for maintaining the node and route data. Before

generating the data of CBR it is important to make a note of the routing table and

update it if required. Every single nodes life time is being set to the period of CBR

and that to in the static environments only as this may not work for the dynamic

environment. Basically the every nodes period must be set dynamically over the

routing protocol of AODV. When the protocol of AODV sends a request message

18
to the various other nodes then a different period field of CBR is generated and this

is added to the line and then this is broadcasted over the network.

When the message that is broadcasted, is reached to the preferred destination then

that fetches the nodes of the CBR field through the RREQ message and then a

novel CBR field is added to the message of RREP and then this sends back to the

main source. Therefore each and every node is them creates a new life that is based

on the CBR period to the message and through this the life period the route or node

entry is stopped[24]. Due to this there will be a huge burden on the system and this

gets overloaded. These overloaded messages can be controlled and reduced by

implementing the dynamic CBR period in the RREO and RREQ messages which

were newly broadcasted by the routing protocols of AODV over MANETs.

19
 CHAPTER-3

3. Research Methodology

3.1 Introduction to software development methodology

As per the definition of Madsen [2] software development process had changed a

lot and the growth across the recent times is rapid and also includes various

techniques and methods and they are implemented across the overall software

development process. Software development process can be considered as a

complex process as it involves lots of steps towards implementation and a standard

life cycle steps are followed across this process. There are different types of

software development models and most of them are proved to be successful and

there are some failures even. Across the overall software development life cycle

requirements gathering can be considered as the vital step and this is the phase

where most of the software development models fail.

As per the opinions of Sanjay [25] in the software development process the

requirements gathering phase is happened to be typical task for the companies

which are developing the software methods. The requirements gathering phase

involves the different steps in which gathering the client requirements is the first

step, meeting with the client requirements is the second phase and satisfying the

clients requirements is the final step in this process. Most of the software research

20
methods will face failure because miscommunication process will take place

among client and developer.

As per the opinion of Korson [26], most of software development models fail at

the requirement gathering phase due to miscommunication and lower interaction

levels and even there are lots of cases where the projects fail in middle and finally

the clients and vendors need to face issues. Requirements gathering phase has the

key role to play across the overall software development process and there would

be many hidden issues and it is always required to make them clear before freezing

the requirements. It is the responsibility of both the vendors and clients to make

sure all the requirements are discussed at this stage and if anything is missed, the

overall design of the project should be changed [27]. Apart from lots of efforts

consumed across requirements gathering process, there are many chances for

issues and thus a perfect implementation tools are required in this context to avoid

these mistakes.

As per the definition of Vliet(2008), requirements gathering phase has the key role

to play across overall software development and it is always required for a separate

area against the requirements engineering and it includes various methodologies

and frameworks[28,29]. All these techniques should be perfectly implemented

across the requirements gathering phase and thus to avoid all the mistakes possible

at this phase and thus implemented the desired software development model.
21
3.2 Software Development Lifecycle Models

As per the opinion of Cloete (2011), all the phases for software development cycle

are required against developing perfect software and all these phases are executed

in a sequential manner. In general there are different types of software

development model and companies follow these models as per their own

requirements[24,30J. In this section the most common phases of software

development are discussed. There is always a connection from phase to another

phase across the software development process and the output of one phase will be

input to the next phase. The very first step across software development process is

requirement gathering and it plays the vital role. Once all the requirements are

gathered and freeze, they are translated to a raw design phase. Ample design is

generated across this phase and once the design is ready it is taken towards

implementation phase. The required business logic is developed using the code and

once the coding is done, it is sent for testing phase. Once the testing is done the

corresponding product is delivered to the user. There are many software

development models and few of them are discussed as below.

3.2.1 Waterfall Model

As per the definition of Korkmaz(2007), waterfall model is the typical and

traditional models among all the software development models and it follows the

22
liner sequential lifecycle process and it can be considered as the easy process to

implement[31]. Every phase is started once the previous phase is completed and

thus a sequential method is followed. The most important advantage with this

model is that, at end of each and every phase a detailed evaluation of the project is

provided and a detailed analysis can be done against the overall success of the

phase. It can be observed that the phases across water fall model never overlap.

Agile development interpreted in the waterfall model

/

Figure -1: Waterfall Model

23
3.3 V-Shaped Model

As per the opinion of Kothari (2010), V-shaped model can be considered as

another lifecycle model which is almost similar to waterfall model. Different

sequential paths are executed across this process similar to waterfall model and

even in this model each phase is started once the previous phase is completed[32].

The main step across this model is the testing phase, where the main concentration

is given to requirements gathering phase across waterfall model.

Requirements gathering are the very first phase even in this model and when the

requirements are done, a clear test plan is provided against the requirements

gathered. Once the core functionalities are defined across the requirements

gathering phase, a detailed test plan for these functionalities is developed and thus

the level of development requirements are understood. Design phase across this

model is divided into two levels like high level design phase and low level design

phase [33].

24
 Figure - 2: V-Shaped model for SDM

As per the opinion of Ghezzi (2004) it is clear that the architecture and design of

the software system mainly concentrates across the high level design. All the

possible fragments of the software system being developed are considered and the

level of integration possible is tested across integration testing and an integration

test plan is created after the design is done[34]. The actual design is done at the

low level design phase and once it is done unit test cases are done and they are

used across the testing phase. Coding and implementation is done once the design

and unit test cases are done, an execution path is developed and thus across the

shape-V the required test plans are created and implemented once the coding is

done.

25
3.4 Structured evolutionary prototyping model

A basic prototype is created across this model once all the requirements are

gathered and the created prototype is evaluated by the clients and based on the

feedback from the client the prototype is changed. Developers and clients need to

maintain a perfect communication in this model, as the prototype need to be

critically evaluated. This process is repeated till the client or end user is satisfied

and once it is done the prototype is finalized and the product is developed [35].

There are various evolutionary steps in this context and they are as given below

• A basic project plan is developed initially

• High level paper prototype is developed

• All the raw requirements are analyzed

• Prototype is created based on the basic attributes

® Required database, algorithms and user interface screens are designed.

® Developed prototype is demonstrated and send to user for evaluation

• This process is repeated till the end user is satisfied (Clayton, 1995).

3.4.1 Structured Evolutionary Prototyping Strengths

The main advantage with prototype model is that the customer can understand all

the requirements and even the developers can gain the required knowledge based

on the customer requirements. This model is more flexible for both the design and

26
development and the requirements gathered can be easily analyzed based on the

customer feedback. All the additional requirements based on the customer

feedback and they can be added across the design phase.

3.4.2 Structured Evolutionary Prototyping Weaknesses

As per the opinion of Griffith(2008), the main disadvantage with prototype model

is that code-and-fix is not all accurate and there are chances for the reputed quick-

and-dirty models. When it comes to maintenance phase few important issues may

be bypassed across this model[36].

3.4.3 When to use Structured Evolutionary Prototyping

The main usage of prototyping model can be analyzed across the requirements

clarification and thus when it is required to improve the user interface. Prototype

model provided the real demonstration of the products in prior to final release and

thus the developers and customers can have ample idea in this context and always

an object oriented development is done at this model. All the important phases

where prototype model is applied are discussed as below

• When the requirements are unclear and unstable

• At the requirements clarification phase

• While developing the user interface

27
 . • When a short lived demonstration is required to the customer

® While developing a new and original development plan

8 When the system requires object oriented design (Jhonson, 2009).

3.5 Rapid Application Model (RAD)

As per the opinion of Langer (2008), the key process included across Rapid

Application Model (RAD) is as discussed as below

® A detailed workshop is conducted and the overall business process is

discussed across the requirements planning phase

® All the required automated tools are reviewed and the user requirements are

analyzed across the user description phase.

• Construction phase is related to production purely and all the production

tools are reviewed to generate the code and screens etc.

® User acceptance testing is done at cutover phase, -where the user acceptance

is gathered while delivering the actual product[37].

3.5.1 RAD Strengths

There are many advantages with RAD software development model and few of

them are discussed in this section. The main advantage with model is that it

requires lower human resources and thus the overall costs are reduced. Time box

28
approach leads to reduce the overall costs and also the risk involved while

scheduling the project. The other advantage with this model is that there is a

continuous interaction with customers throughout the software development.

Documentation is reduced a lot and coding is given more priority in this mode and

all the requirements are gathered using modeling (Kemzer, 2009) [3 8].

Figure 3: RAD mode!

Figure - 3: RAD model

3.5.2 RAD Weaknesses

The key advantage with RAD is discussed in the previous section and apart from

these advantages there are few limitations and they are discussed in this section. As

per the opinion of Goertzel (2007), the main limitation with this model is that it is

always hard to apply for legacy systems. When the level of risk is analyzed the

modularized systems are more prone for skipping the risk analysis and thus the

customers need to face the risk finally.

29
3.5.3 When to use RAD

The main usage of RAD can be analyzed when all the requirements are gathered

and developer need to involved across all the lifecycle stage of software

development. Time boxed requirements can be analyzed across the implementing

RAD. This model is used when the performance of the system is given lower

priority and also when the technical risks are ignored across the process of

modularized.

3.6 Introduction to Agile

As per the opinion of Attarzadeh(2008), agile can be defined as the light weight

process and it can be used widely across the project management. It has lots of

differences when compared to the other project management techniques and it

involves the role of project manager to define the tasks to all the team members

and thus take the required control over the project. Team involvement is always

required in this model and the deadlines are decided over the team meetings that

were conducted across this model[39].

Project manager is involved across developing the high level project plan and this

can be considered as the main difference when compared to other models. The

actual start of project and work is done based on the high level plan developed and

thus all the long term requirements are analyzed and they are broken down in this

30
model. Solution to the project is created based on high level vision where iteration

based approach is followed by the project managers across the software

development process. A new model is developed based on the iteration results

achieved from the previous model across Agile and the required process

description is given as below (Wysochi, 2003).

Figure - 4: Agile Methodology

As per the opinion of Cohn(2004), it is clear that the main advantage with agile

project management is that, there is always required feasibility for the team
31
 /

members to develop their own work plan irrespective of the plan followed by the

project managers. The level of collaboration among the stakeholders, customers,

team members and top level project managers is streamlined with the

implementation of agile project management techniques[40]. A proper

communication channel can be maintained when there are some changes across the

requirements and the roles of the team members can be clearly defined by the

project mangers using this mode.

3.7 Methodology Used

A clear discussion is done against different software development models are done

in the previous section and the actual methodology followed in this project is given

in this section. Waterfall model is followed in the simulation process and the main

aim of this project is to evaluate the performance of AODV under black hole

effect.

3.8 Defining methodology

In general methodology can be defined as the process of gathering the available

resources to develop a research and following the require procedures while solving

the research problem. There are different types of research methodologies and few

of them are as discussed below

32
3.9 Types of Research Methodologies

There are different types of research methodologies and among them qualitative

and quantitative research methodologies are discussed as below[3,41].

3.9.1 Quantitative research method

Quantitative research methodology is used in this research and it includes all the

required articles and also a case study as well. The main topic considered is

intruder detection using the data mining systems and thus internet resources are

used to gather the required information. A typical theoretical based approach is

used at this level and the required empirical analysis is done. The required primary

data is gathered from different sources and they are given as below

3.9.2 Primary Data

• Journals

• Articles

® Books

® Web materials

• Case studies

33
3.9.3 Source of Primary Data

The required primary source of data is gathered using the case studies, articles,

journals and websites and this information is analyzed for the research. All the

required articles, books and case studies are analyzed and the required information

is gathered as per the requirements of the research problem considered [42].

3.10 Ethical Issues

There are few ethical issues involved across this research and they are discussed in

this section. Authentication may be required to gather the information from

different articles and journals and this can be considered as the primary ethical

problem. As the main aim of this project is to develop intruder detection system

based on data mining concepts, it may be required to interact with different

network administrators and thus while gathering information from them the ethics

need to be followed.

34
 CHAPTER-4

4. Simulation procedure

4.1 Introduction

The main aim of this chapter is to discuss the simulation procedure followed in

evaluating the performance of AODV under black hole attacks. As discussed in the

previous chapters OPNET modeler is used as the simulation tool and three

scenarios are created. First scenario has normal mobile ad hoc network with

AODV as routing protocol and works under ideal working conditions. Second

scenario has Balckhole attacks and the third scenario is used to analyze and

improve the performance of AODV. The actual simulation setup used and the

procedure followed to create the required scenarios is given in this chapter as

below.

4.2 Mobile Ad hoc network setup for normal scenario

As discussed Mobile ad hoc network is used for evaluating the performance of

AODV routing protocol under black hole attacks and thus in this context a simple

MANET is simulated using OPNET. Following steps are followed to create the

basic MANET

35
• A new project is chosen from the file menu and a blank scenario is used to

create the first scenario

• Campus is chosen as the required network scale and the size is set to

1000X1000 meters and thus now the MANET operates within a campus

• MANET is chosen as the model family from the list of models available

with OPNET modeler

• Now a blank workspace is created and the required objects can be used for

the simulation from the object palette and a typical object palette provided

with OPNET modeler is as given below

36
 Find Next""]-
jjjsj Search by name: jj
Dragmodefor subnet icon into workspace ; •
0' _____
MANET Defalt GT
EKia Node Models
Hi Application Config
i/l
Application !|
Fixed Node
manet_gt’Ayjftten_ethemet_sIip4 Fixed Node MANET 6*
j-~§§ manet_station fixed Node Wireless J V.j
j-~g manet_station Mobile Node Wireless li
j-gj Mobility Config fixed Node Ml
i~itft Profile Config fixed Node Profile Con j
l~S Fbcgroup Config fixed Node Receiver C.'i
I--” Task Config fixed Node Custom Apr -
V-'f
l~|| vdan2_router fixed Node
wbn2_router Mobile Node
wian_etbemet_router fixed Node Wireless b " '* -
ydan_ethemet_router Mobile Node Wireless Li" Logical Subnet -K
j~tfj w!an_sejver Fixed Node Wireless b;
{H*| wlan_server Mobile Node Wireless b';,
I—g wlan wkstn fixed Node Wireless bT]
I ‘~g wian_wkstn Wireless b ' • SatelBe Subnet
Mobile Node
L.f
Wireless Domain Models
| HU Mobffity Domain Wseless Domain
3
Hp-Xl McData S-i • MobileSubnet
11-^1 MIPvSjadv
f)-^ mobileJp
JE&-S1. MPLS . ..... ........... .............................. Wr.
,. ■. Subnet ;;

:| Mod^Petafe' | 'Create Custom Modeh-J Close Help

From the above screen it can be observed that there are number of objects for

MANET simulation and few of them are used across this scenario and they are as

listed below

37
 • Wireless LAN mobile workstations are used as the mobile clients and in this

scenario a total of 26 mobile nodes are used[43]. They are dragged from the

object palette towards the workspace

• Application configuration is used to set the applications used across the

network and in this scenario FTP and Web applications are used.

• Profile configuration object is used to set the required profiles for the

applications and detailed configuration details are discussed in the later

sections

• Mobile configuration object is used to set the mobility profiles for all the

mobile nodes and a detailed configuration is discussed in the later

sections[2,12,44].

Above listed objects are used for the simulation of the MANET and the detailed

configuration settings done are as explained below

4.2.1 Application Configuration definitions

Application configuration object is used to define the required applications that

generate the traffic over the network. Application configuration object has an

option to create any number of applications and in this simulation two applications

38
are used like FTP (File Transfer Protocol) and Web. Required configurations are

used to set the applications and the corresponding screenshot is as given below

07 "j-Bnal ' _____ 77°?

0 _ r Up. „ __ _ jMediumload
^7Z777j7®fl' 777.7 77777" 7q?7 77.
0! _____ j-Remrfe Login _ _
77 7.7777"
______
’91.7777
i.Off,,
0 ... „ j-Video Conferencing ____ _ Off _
07' 3ys5p”" ”'”'77""" 777.7.77*7 777 I
' 7^®vi/eb
0;
7777.7" 777______
l-Name
7.7- 7'Web 77'.77
B Description
0777 Ziicustom 7.. .7 777' .7°?" 77 777.'
0 r Database Off
077......f:b™*7......................................off....... "
0 .77l!EI...77’77.7~ "W 777777
0' _ j- Http \ Heavy Browsing^
_
0; 77..>***77777777 7.77 77779? "7"7777777
0: ’ j- Remote Login :Off
0! I-Video Conferencing ’Off

From the above graph it can be understood that there are two applications used like

FTP where medium load is imposed over the network and for the Web application

a simple HTTP is used with heavy browsing[45]. Once the required applications

are create now the corresponding profiles should be created to support the

application traffic and the corresponding procedure followed in this context is as

given below

39
4.2.2 Profile configuration settings

There are two applications across the network and to generate the required

application traffic corresponding profiles need to be created. Profile configuration

object is used to create the profile and as there are two application two profiles are

created and the corresponding screenshot is as given below

type: J Utilities
, jMrib’ijte::. ■'y;’ : • ’■ ' iValue .•*(
; j-Number of Rows 1 < ■ -^
17....IjBFTP............. ...... ^7........... ............... . _""j
® _...~ 77.77.1 1777.7... 1 J .1717 7.. 7.171 77 '1 . T
Si. b Start Time Offset (seconds)
: constant (100) _ ^ 7.'
(§) f- Duration (seconds) _ 'End of Profile _ j
sr i rr rcRepe^iy.7~~7~~ (). 777 7111 11 717711
. . ~ ,J ■
©' {-Operation Mode__ ________ :S^ (Ordered) __ __f; . /
<j|£........f Start Tmne^econds) ^constant (TOO)_____ ____ _ j
(J); ^ |;{^i^Bon (seccnds) End of SimuJation _ ! . ;
(f) © Repeatability _ ;Once at Start Time j • J
.... Lj3w<*.... _ .7*7 ............ ..7... 1.. ... 77777.777.7.77.77 1:;
(fj__ i-Profile^Name__ _ ______ iWeb _ _ ______ i. .
(f)!..... SApplications ____ __ ;(.„) _ ___ _____ __
!- Number of Rows 1 1"
g Web
(f)i j^Name Web ’
Sl._............. j- Start Time Offset (seconds) ^constant (100) ___ 1 /
(f)£ __ h Duration (seconds) __End of Profile | .
®> __ iUnSjnted^ _ ___f7-
(f)l j-Operation Mode _ -Send (Ordaretfli _ _ ^ 7~
(?) i- Start Time (seconds'! constant (100) IZJ;.

From the above screen it is clear that there are two profiles like FTP and Web and

the corresponding settings are done. Start time offset for both the profiles is set to a

40
constant value of 100 seconds and duration is set to end of simulation. Once the

profiles are created now all the mobile nodes and the wireless LAN server should

support the corresponding application traffic and the configuration are explained in

the later sections. [46]

4.2.3 Mobility configuration

Mobility configuration is required to set the mobility patterns for all the 26 mobile

nodes used across the simulation. There are number of mobility models available

for simulation and in this scenario default random way point mobility is used and

the corresponding screen is as given below.

41
 .Attribute. Value-; •" '.j'. -,
■name iMob% _
t- Mobility Modeling Status Enabled
0 Random Mobility Proves IF. 7;::::::
Number of Rovvs_ ;3 .............. ............ i
.J
B Default Random Waypoirrt t
__t\
v-,
ProfijeName • Default Random Waypoint _3
(-Mobility Model : Random Waypoint _
ES Random Waypoint Parameters ¥£37.1777
(f); ___ |- Mobility Domain Name •Not Used _
<2),......... .. j-x_min (meters) ;o'o 7 7.........
@i, hy_min(meters) 0.0"
j-?c_max (meters) :500 ........ ~"7
(f)‘ ___ j-y_max (meters) ____ ■500' 7733; ’
(f)i_____ |- Speed (meters/seconds) constant (50)___ _
<_|~Pai«e11iw|»ecaKfe) ^constant®
(Dt___ ___{-SartjQme (seconds)....... ^constant (IS__________
<f>‘ j- StopTime^seconds) End of Simulation
(f)j_
^
J-AnimationUpdate Frequencyj(se._.
L RecordTr^edtoiy;
to
• Disabled
777' 33 Jy
'{
j ® Random Waypoint (Record Trajectory)
i B Satie
- V Advanced
filter Tj Apply to selected objects
■I”; trari'matah’-. ’ y,-. :y Cancel ‘ |
QK

From the above screen it is clear that default random way point is used as the

required mobility model for the mobile nodes. Speed of the mobile nodes is set o a

constant value of 50 seconds, pause time I set to 0 seconds, start time is set to a

constant value of 15 seconds and the stop time is till end of the simulation. Once

the mobility model is set for the mobile nodes across the network now the nodes

should support the mobility and the corresponding procedure is as explained below

42
4.2.4 Mobile nodes and wireless LAN server configurations

As discussed in the previous sections there are 26 mobile nodes and a single

wireless LAN server and these mobile nodes acts as application clients and WLAN

server acts as application server. For communication among these clients and

server always a protocol is required and in this simulation AODV is used as the

required routing protocol. The actual procedure followed in this context is given in

the below screen[47].

gp,! i wircri ivwr^ca^wurf^ggc

;
Type: workstation ......... ■ ..., v; _ ..,,.j'

(f); rname _ mobi!e_ncde_25

® ^trajectory....... ......... ........ ....... .. ~ .VECTOR '
g AD-HOC Routing Parameters
<D; j~ AD-HOC Routing Protocol Z .AODV .................. ...................... \ '
® ji AODV Parameters ZZ.ZZZ.£:> II ,*Z Z Z..Z... II IZZZ3
® DSR Parameters _ ^Default _ .
(f) ©GRP Parameters ^ ; Default j .
(f): fflO LSR Parameters Default _
; © TORA/IMEPParametefs _ [Default {••.
® Applications \

From the above screen it is clear that AODV is used as the ad hoc routing protocol.

All the mobile nodes and the wireless LAN server are selected and similar settings

are done. Now all the nodes and server communicates using the AODV protocol

and as the main aim of this simulation is to evaluate the performance of AODV

under Balckhole attacks the corresponding AODV attributes are modified due to

the attacks in the next scenario. In this scenario default AODV routing protocol

43
parameters are used. Once the AODV routing protocol is set for the simulation

now the next process is to assign the application traffic to the mobile nodes and the

procedure followed in this context is given below

• Deploy defined applications option is chosen from the protocols application

menu

• All the mobile nodes are deployed towards the FTP and Web clients and the

wireless LAN server is assigned to both the FTP and HTTP server and the

corresponding screenshot is as given below[48].

ndevica
' '•inOrtyseleSsi;.,' o
FM 'iiytovaa''*- ’’ I Ms:7IP
Sxice
.* :'N*ak|aS5S3ff V;_ •-j:
I fWk'tfsb’
Sate
-jj mbfejwteO 1$
isibtejtxfeJ i.
iradejwfeJO
11
-g roWsjwfe.W ' I
-g (nfcfejwfetE
-g iwHsjBde.H
-g robfejofeJS
MeW
Application: "WEb* t f.
-jj nnifejafeJE
rrifejwte.1?
-g frobtejwfeJE
-g wife mdsJS

44
From the above screen it is clear that all the mobile nodes are assigned to source of

both the FTP and Web profiles and the WLAN server is assigned to FTP and Web

server. Now the mobile nodes act as the FTP and Web clients and the WLAN

server acts as both the FTP and Web server. Now all the mobile nodes should

support the mobility model created across the mobile configuration object and the

corresponding procedure is shown in the below screenshot[49].

Terrain .■
Define Trajectory...
Clear Trajectory; Assignment..
'y
’ s' •*< r‘
—*—‘ re

off m
..... ”” '*
‘
\ .-Random^obility • Set Mobility Profile.;. / .. ____ :
A ■

; ClearMobilityPrbfile... ; 4 .
Import STK Orbit.. y -1
,• { Set Trajectory Created from Rand om Mobility.,,
Verify, Links... • Ctrl+L *-

Shared Risk Grouos ■ ‘ , . : . : .V...:A..CA‘ ►.:

* . iTr»-
T
Set mobility profile is used to set the mobility defined across the mobile

configuration and as the mobility used is default mobility all the mobile nodes now

follow the corresponding mobility patterns. Once the basic network setup is ready

the corresponding network is as shown below

45
4.2.5 Performance metrics

As the main aim of this simulation is to evaluate the performance of AODV under

Black hole attacks evaluation of performance is required. OPNET provides options

to evaluate the performance across global level, node level and link level and in

this simulation global level metrics are chosen and the corresponding screenshot is

as given below

46
 igrchdose Results'” ~r?8awaB5jWWi—w
n~i . ass.
&{*] tijlaiaLStatistics. r. Safe*® WomeHon;
a* ace
a-$• ACE Whiteboard
Description: .
AODV
a- Cache
a- - Custom Application . .
a- DB Entry
a- - DB Query
® DHCP
&■ DSR
a- Email
$- k RP
a- 1 ; GRP
m -E; H323 ‘ ,y
a- s'} HAIPE
®. V
a-
HTTP
IP
.El
» IPv6 Draw style: Mocf1/;.
a* Mobile IP
m A. MobSe IPv6 ! ■
s* GcHeciion mode:' Sfedf/...
OLSR
& OLSR Peifoimance . -
S’ P1M-SM
T"
a- Print
eh i Remote Login - Data axsciion —
a- RSVP
& RTP :■ j«7 Generate-veda date '
a- i: SIP :.£rwiSiion
a- tcp ;
& TORA IMEP I~ Generate livdsiaii'sLc
£ j
V5deo Conferencing
a- Voice _ jeratS'Sceiocoeia
a* VPN h-
a- Wireless LAN LEf Using last Value -: L'ZJ
a- WLAN O’er HCF Access Category) LtJ

From the above screen it can be observed that four levels of performance metrics

are chosen for this simulation like AODV, FTP, HTTP and wireless LAN and the

actual values used in here are as given below[50].

Following are the performance metrics used for AODV routing protocol

47
 • Number of hopes per route

• Route discovery time

• Routing traffic received and sent in bits per sec and packets per sec

• Total acknowledgments and cache replies sent

® Total packets dropped

• Total replies sent from destination

• Total route errors sent

• Total route replies sent

• Total requests sent

Following are the performance metrics used for FTP application

• Download response time

• Total traffic sent and received in bytes per sec and packets per sec

® Upload response time

Following are the performance metrics used for HTTP application

® Object response time

• Page response time

• Traffic sent and received in bytes per sec and packets per sec

Following are the performance metrics used for Wireless LAN server

48
 ® Data dropped

® Delay

® Load

• Medium access delay

• Network load

• Retransmission attempts

® Throughput

Once the required simulation metrics are chosen first scenario is ready to simulate

and the procedure followed to create the second scenario is as given below

4.3 Blackhole attacks scenario

First scenario is duplicated to create the second scenario and the main aim of this

scenario is to impose Blackhole attacks across the network[51]. As it is not

possible to impose physical attacks over the network required configuration

changes are done for creating the simulated Blackhole attacks. In general when

there are some Blackhole attacks over the network behavior of the AODY routing

protocol is altered against the configuration details. Following are few changes

made to the parameters of AODV routing protocol and the corresponding

screenshot is as given below

49
 0 AODV Parameters (...)
B Route Ois
(fX j- Route Request Retries^ ___ ,2
M, __ ••• Route Request Rate Limtt fekts/.- 5
(f) ____|" Gratuitous Route Repiy Hag __ _ i Disabled
01.............j-DesMnaBon Only Hag .......... JDisabled _
(|X ______- AckntrA-ledgement Required _ ! Disabled
0____ j-Mtye RoiAeJimeotA (seccmds)___
0__ 1-Heio Interval (seconds) iunifonn (1.1,1}
0___j-Allowed Helto Loss_______ J4_ _
Ml.__ j-ttoDiameter...... __ __ ____ -20 _
0 j- Mode Traversal Time (seconds) )0.07 ________
(f), Route Error Rate Limit (pkts/sec) 15____ ______
0[__ _|jmMut Bi#er^ __> 4 __
^ ©TILParameters __ _______________ iDefeuI
®L r- Packet Queue Size (packets) jjnfinBy __
M_ j-Local Repair ___ Enabled
Ml „ ^Addresi^Hode ____ __ |IPv4

From the above screen it is clear that route discovery parameters, active route

timeout, hello interval loss, allowed hello loss and other parameters are altered

when compared to first scenario. Few changes are also made to wireless LAN

server parameters and they are as given below

50
 ' (Attribute • ; "• - |Va!ue • /
(|); Wireless LAN Mfe Address Auto Assigned
ti Wireless LAM Parameters
(f); _ j-BSS Identifier __ ____ iAuto Assigned __
(|) Access PoirfiFunctionality _ {Disabled
____ j-Physical Characteristics {Direct Sequence
j;Date Rate____J5.5Mbps _
(f)i S Channel Sitings ___ _____ ;Auto Assigned
(f)i _ I- Transmit Power (W)_ _ _ _ _ _ __ ■0.030 ______
(£>,____j~ Packet Reception-Power Threshold... -35_____
<£); j- Rs Threshold kbytes) _____ jNone.
(jj): ___ Fragmentation Threshold (bytes) None
<D j- CTS^o-self Option Enabled
m r Short Retry Limit
1- Long Retry Unfit
i9
;7
®L |~ AP Beacon Interval (secs) ;o.o2
j- Max Receive Lifetime (secs) ;0.5
®,
j- Buffer Size (bits) 256000
j- Roaming Capability Disabled
®\
!•• Large Packet Processing ‘Drop
@
ffi PCF Parameters i Disabled
®.
© HCF Parameters Not Supported

With this configurations simulation of Blackhole attacks over the MANET is done

and the third scenario is used to improve the performance of AODV and the

configurations changes made are discussed in the next section

4.4 AODV performance scenario

This scenario is used to improve the performance of AODV under Blackhole

attacks and this scenario is created by duplicating the second scenario.

51
Configuration changes are made to AODV routing protocol parameters and

Wireless LAN parameters and they are shown below

j 0 AD-HOC Routing Parameters f;

jL__ j-AD-HOC Rotting Protocol jAODV
.. .... ...St--.
)5 0 AODV Parameters
)fi 63 Route Discovery Parameters iy "i*;"'.;: !r-
i j~ Route Request R^nes _ :7
|" Route Request Rate Ur^Jpkis/., '•7 7\ Z'.. '
» j- Gratuitous Route Reply Rag i Disabled
i f
); __ R Destination Only Rag JDisabled
>: _L Acknowtedgement Reqinred m 'Enabled
»■ j- /^ye Route Tirneout (seconds) _
>: [-He|o Irteival ^seoonds} uniform (1,1.1)
* I- Allowed Hello Loss "{2 ..........
* ....!|-Net Diameter ;43 ' "* "7
■ Node Traversal Time (seconds) _
l ;ai “'T
j-Route Bror RateLima frMs/sec) "'•5 ........ !'■
l j-Trmeout Buffer ’ll. .. . ,':7
>i B TTL Parameters ___ J Default
j-Packet Queue Size (packets) ; Infinity
I i i n___ m

Above are change changes made to AODV routing protocol parameters and with

these configurations overall performance of MANET network and AODV is

improved under Blackhole attacks as well. Following are the changes made to

wireless LAN parameters and thus performance of application server is also

improved and thus the overall performance of applications as well

52
 B Wireless IAN Parameters
j-BSS Identifier _ _ jAuto Assigned
J-Access^PoW RfficBoneffly {Disabled
J" Pl^ical Qiaracten^cs ‘Direct Sequence
j- Data Rate {bps}................... !2 Mbps
© Channel Settings__ jAuto Assgned
p Transmit Power^/V) 0.100
^ PacketReception-PowerThreshold...j-90
j- Fits Threshold (bytes) _,None __
j- Fragmentation Threshold (bytes) . JNone
wl._{-CTSitKjdf Option, __ _ {Enabled
0 J-ShoftRetiyUmft >7
.......j-l^ng R^iy LM;________ _________ ,9
(f); j-APEeacon tnteiyaljsecs) ___ !0.02
(f):__ j-- Max Receive Lifetime (secs) ;1.D ___
<&'" t ' rrr.......
!
(f) !■• Roammg Capiifiy 'Disabled
®: j- Large Packet Processing _ jDrap _
0 __ JS PCF Parameters __ I Disabled _ __
0; S HCF Parameters ^Not Supported

Once all the three scenarios are created simulation is run for 1 hour and manage

scenarios option is used. Similar performance metrics are used for all the three

scenario and the manage scenario screen is as shown below

53
 V

Once the simulation is done results are compared for performance evaluation and a

detailed discussion is done in the next chapter[52,53].

4.5 Running the simulation

Main aim of this simulation is to evaluate and improve performance of AODV

routing protocol under Blackhole attacks. Mobile ad hoc network (MANET) is

simulated using OPNET modeler and three scenarios are created. First scenario has

normal MANET working conditions with AODV routing protocol, second scenario

has Blackhole attacks and third scenario has improved AODV working conditions.

AODV routing protocol parameters and wireless LAN parameters are configured

54
to simulate the Blackhole attacks and same parameters are used to improve the

AODV performance and overall network and application performance.

Performance metrics are chosen at AODV, FTP, HTTP and Wireless LAN server

level and the simulation is run for one hour to evaluate the results and they are

discussed in the next chapter[54].

55
 CHAPTER-5

5. Analysis of Results

5.1 Introduction

A detailed evaluation of the simulation procedure followed to create the Mobile ad

hoc network and the estimating the performance of AODV routing protocol under

Blackhole attacks is discussed in the previous chapter. As mentioned in the

previous chapter there are three important scenarios where the first scenario has

idle working conditions of AODV routing protocol, second scenario has Blackhole

attacks on the network and the third scenario has improved performance of AODV.

Three scenarios are run for one hour and the corresponding results are explained in

this chapter. Performance metrics are chosen at global level like AODV, FTP,

HTTP and Wireless LAN level and the corresponding graphs are explained as

below

5.2 AODV metrics considered for three scenarios

As the main aim of this simulation is to evaluate die performance of AODV under

black hole attacks, AODV routing protocol parameters are chosen. Comparison

graphs of three scenarios for the AODV parameters is as given below

56
Number of hopes per route

Number of hopes per route indicates the overall hopes traversed during the

communication process and it plays an important role in evaluating the

performance of AODY routing protocol. The actual number of hopes traversed

across the route by the three scenarios is given below

From the above graph it is clear that across the first scenario the number of hopes

is constant at the beginning of simulation and later it was decreased against its

normal working conditions. When the case with attacks scenario is considered the
57
number of hopes traversed is always increasing and also more when compared to

rest of the scenarios. In the third scenario a standard rate of hopes are traversed and

this indicates that the performance of AODV has increased even in case of

Blackhole attacks[20,21,55].

5.2,1 Route discovery time

Route discovery time indicates the overall time taken to discover the route across

the communication process. Route discovery time depends on several factors like

the overall traffic over the network and the nature of the applications and the actual

comparison of the scenarios is as given below

58
From the above graph it is clear that across the first scenario the route discovery

time is constant at the beginning of simulation and later it was decreased against its

normal working conditions. When the case with attacks scenario is considered the

discovery time is high initially and later on decreased due to increase number of

hopes when compared to rest of the scenarios. In the third scenario a standard route

discovery time is recorded and this indicates that the performance of AODV has

increased even in case of Blackhole attacks[56].

59
5.2.2 AOD V routing traffic received in bits per sec

Routing traffic received across the network indicates the overall performance of

the mobile nodes and the wireless LAN server. The actual performance of AODV

is estimated based on the routing traffic received in bits per sec and the actual bit

rate for the three scenarios is as given below

Qi average (in ACDyiRbuting Traffic Rec«iyedH[bits^sec)j dMh i

m ATTACKSAODV-AODVPER-DES-1
BATTACKSAODV-Madks-DES-1 .
B ATTACKSAODV-Normaf-DES-1
avera^ pi AODVJRcWinO Tralfic ReoBived Olis/sec))'r 5
J- 300,000
\ 280,000
] 260,000
| , 240,000
jv:220$0
| 200,000

f 180,000
!• 160,000
j 140,000
|, 120,000

] 100,000

j 80,000
j - .60,000
f .40,000
|"^‘i(§jqo
\ 0
.;
'

: OM
&
■

From the above graph it is clear that the overall traffic received in bits per sec is

more across the first scenario as there are normal working conditions. When the

60
case with second scenario is considered the overall traffic received is very less due

to the Blackhole attacks and in the third scenario the overall traffic received has

increased and the performance of AODV has improved a lot when compared to

second scenario[57].

5.2.3 AODV Routing traffic received in packets per sec

Routing traffic received across the network indicates the overall performance of

the mobile nodes and the wireless LAN server. The actual performance of AODV

is estimated based on the routing traffic received in packets per sec and the actual

bit rate for the three scenarios is as given below

61
From the above graph it is clear that the overall traffic received in packets per sec

is more across the first scenario as there are normal working conditions. When the

case with second scenario is considered the overall traffic received is very less due

to the Blackhole attacks and in the third scenario the overall traffic received has

increased and the performance of AODV has improved a lot when compared to

second scenario[58].

5.2.4 AODV Routing traffic sent in bits per sec

Routing traffic sent across the network indicates the overall performance of the

mobile nodes and the wireless LAN server. The actual performance of AODV is

estimated based on the routing traffic sent in bits per sec and the actual bit rate for

the three scenarios is as given below

62
From the above graph it is clear that the overall traffic sent in bits per sec is more

across the first scenario as there are normal working conditions. When the case

with second scenario is considered the overall traffic sent is very less due to the

Blackhole attacks and in the third scenario the overall traffic received has

increased and the performance of AODV has improved a lot when compared to

second seenario[59].

63
5.2.5 AODV Routing traffic sent in packets per sec

Routing traffic sent across the network indicates the overall performance of the

mobile nodes and the wireless LAN server. The actual performance of AODV is

estimated based on the routing traffic sent in packets per sec and the actual bit rate

for the three scenarios is as given below

64
From the above graph it is clear that the overall traffic sent in packets per sec is

more across the first scenario as there are normal working conditions[60]. When

the case with second scenario is considered the overall traffic sent is very less due

to the Blackhole attacks and in the third scenario the overall traffic received has

increased and the performance of AODV has improved a lot when compared to

second scenario.

5.2.6 AOD V Total cache replies sent

Total cache replies sent indicates the overall response sent from the wireless LAN

server and the actual performance of AODV routing protocol depends on the cache

replies sent[61,62]. Cache replies should be less for the idle working conditions of

AODV and the actual comparison graph is as shown below

65
From the above graph it is clear that the overall cache replies are less in the first

scenario and thus indicates the idle working conditions of the network. When the

case with second scenario is considered the overall cache replies sent is more due

to the Blackhole attacks and thus the value has increased a lot[63,64,65]. When the

case with third scenario is considered the number of cache replies are reduced

when compared to the second scenario and thus the performance of the AODV has

increased.

66
 ★ (AJW. LIBRARY)^
^^S££RS] ^ 3
5.2.7 AODV Total packets dropped
not for loan
Total packets dropped indicate the traffic conditions over the network due to

routing protocol performance. The actual number of packets dropped across the

network and performance of AODV for the three scenarios is given in the below

screen
137907
i average (in AODV.TotalPackets Dropped)^ assaaBBH
■ ATTACKSAODV-AODVPER-DES-1.'; ' f - ;'
’ ■ ATTACKSAODV-Attacks-DES-1 ’ -
B ATTACKSAODV-Normal-DES-1 ' =
, > average (in ApDV.Total PacketsDropped)
50-
•-

as 45;

40-

35-

30
■ *;
25-

20-

'1S-

: 10-

-- 5-

O'® #
4? 4* Ǥ?: 4'

.MBEDKAR MEMORIAL LIBRARY

Acharya Nagaijuna University

67
137907
From the above graph it is clear that across the first scenario initially the packet

drop is low and later on the value has maintained a constant value due to the idle

working conditions of the network and AODV[66,67]. When the case with second

scenario is considered due to Blackhole attacks the packet drop is regularly

increasing as the overall intruder traffic has increased. When the case with third

scenario the performance of AODV has improved a lot and the packet drop has

decreased throughout the simulation time.

S3 File Transfer Protocol results

Two applications are used across the simulation like FTP and HTTP and the

performance metrics of FTP are evaluated in this section and given below

5.3.1 Download response time

Download response time indicates the actual time taken to download a file from

the server by the clients. The actual download response time consumed across the

three scenarios is given as below

68
From the above graph it is clear that the overall download response time is

increasing across the first scenario and later on the value has reduced due to idle

working conditions[68]. When the case with second scenario is considered the

download response time has increased due to Blackhole attacks over the network

and initially the value was very high and due to less traffic conditions the value has

reduced maintained a constant value. Performance of the AODV routing protocol

has increased across the third scenario and the download response time is reduced
69
when compared to rest of the scenarios and thus the performance has improved a

lot[4,8,69].

5.3.2 Traffic received bytes per sec

Traffic received due to the FTP application across the network indicates the overall

performance of the AODV routing protocol across the network. In general the

overall traffic received should be less for a better performance of AODV and the

actual comparison of the scenarios is given below

70
From the above screen it is clear that the overall traffic received is less across the

first scenario and this is due to the idle working conditions of the network. When

the case with second scenario is considered the overall traffic received is more due

to the Blackhole attacks as the attacks always pretend fake traffic to access the file

access and thus the server can’t be reached. The overall traffic received has

reduced when compared to attacks scenario and thus the performance has

increased[61,70,71].

5.3.3 Traffic sent in bytes per sec

Traffic sent due to the FTP application across the network indicates the overall

performance of the AODV routing protocol across the network. In general the

overall traffic sent should be less for a better performance of AODV and the actual

comparison of the scenarios is given below

71
From the above screen it is dear that the overall traffic received is less across the

first scenario and this is due to the idle working conditions of the network. When

the case with second scenario is considered the overall traffic received is more due

to the Blackhole attacks as the attacks always pretend fake traffic to access the file

access and thus the server can’t be reached. The overall traffic received has

reduced when compared to attacks scenario and thus the performance has

increased[72].

72
5.3.4 Upload response time

Upload response time indicates the actual time taken to upload any file to the

server and the role of AODV routing protocol is significant in this context. The

actual upload response time recorded across the three scenarios is given in the

below screen

Upload response time is high across the first scenario due to the normal and ideal

conditions across the network and the values are varying as well. When the second

73
scenario is considered due to the Blaekhole attacks the upload response time is

reduced a lot and the upload response time has improved in the case with the third

scenario. Due to the wireless LAN parameters and AODV configuration

parameters set across the third scenario the overall performance of AODV under

Blaekhole attack has increased exponentially[62,73].

5.4 HTTP application results

HTTP application is used to estimate the performance of web applications against

the AODV routing protocol under Blaekhole attacks[74]. There are many aspects

under HTTP that can be considered while estimating the performance of AODV

and few of them are listed as below

5.4.1 Page response time

Page response time indicates the actual time taken to load a page from the web

server and in ideal conditions the response time should be high. When the three

scenarios are compared the actual comparison graph is as given below

74
From the above graph it is clear that the overall page response time is high across

the first scenario due to the normal working conditions of the MANET and AODV

routing protocol[75]. When the case with second scenario is considered the overall

page response time is very low due to the Blackhole attacks. Across the third

scenario is considered performance of AODV is improved due to the integral

configurations and the overall page response time is also increased.

75
5.4.2 Traffic received bytes per sec

Traffic received across the web server indicates the application range and also the

performance of AODV routing protocol. The actual traffic received in bytes per

sec across all the three scenarios is as shown below

76
From the above screen it is clear that the application traffic received across the web

server for the first scenario is low when compared to other scenarios and this is due

to the normal working conditions of AODV. When the case with second scenario

is considered the overall traffic received is very high when compared to rest of the

scenarios as the routing protocol is affected with Blackhole attacks. Third scenario

has improved a lot in terms of overall traffic received and thus the performance of

AODV has improved due to the internal configurations done to AODV and

Wireless LAN server[52,76,77].

5.4.3 Traffic sent in bytes per sec

Traffic sent across the web server indicates the application range and also the

performance of AODV routing protocol. The actual traffic sent in bytes per sec

across all the three scenarios is as shown below

77
From the above screen it is clear that the application traffic sent across the web

server for the first scenario is low when compared to other scenarios and this is due

to the normal working conditions of AODV. When the case with second scenario

is considered the overall traffic sent is very high when compared to rest of the

scenarios as the routing protocol is affected with Blackhole attacks[64,78]. Third

scenario has improved a lot in terms of overall traffic received and thus the

78
performance of AODV has improved due to the internal configurations done to

AODV and Wireless LAN server[79].

Following are some of the important tables that can be used to compare the

performance of the network with tested IDS with rest of the normal and attacks

scenario. AODV routing protocol parameters are as listed in the tabular format

Parameter Normal scenario Attacks scenario AODV

Performance

scenario

AODV route 0.0487 sec 0.1986 0.1288

discovery time

Routing traffic 667.24 637.13 667.59

received in packets

per sec

Routing traffic sent 29.79 29.47 29.49

in packets per sec

Total packets 19.88 39.5 8.41

dropped

Total route errors 11.40 1 12.14

79
sent

Total route replies 92.8 122.72 115.83

sent

Total route 28.31 23.14 20.57

requests sent

5.5 Wireless LAN Parameters

Parameters Normal scenario Attacks scenario AODV

performance

scenario

Data dropped bits 221.97 504.48 53.44

per sec

Load 46568.55 49264.2 47907.1

Network Load 46411.3 49023.4 47959.68

Retransmission 0.1163 0.1404 0.1408

attempts

Throughput bits 302598.8 288330.26 278858.26

per see

80
 CHAPTER-6

6.1 Conclusion

Wireless communication has gained lots of popularity these days due to the nature

of flexibility and usage standards. There are wide ranges of applications that are

being supported across the wireless networks and thus gained more research

interest as well. The main aim of this research is to evaluate the impact of

Blackhole attacks over AODV routing protocol and thus mobile ad hoc network

(MANET) is considered as the required wireless network. OPNET modeler

simulation is done to create the MANET and three scenarios are used to evaluate

the performance of AODV under Blackhole attacks[80,81]. First scenario is

created with 26 mobile nodes, a single wireless LAN server, Application

configuration, Profile configuration and mobility configuration. All the mobile

nodes and wireless LAN server are set to support the AODV routing protocol and

two applications are created like FTP and Web applications. Second scenario is

created by duplicating the first scenario and Blackhole attacks are imposed over

the network. As it is not possible to impose physical attacks over the network,

AODV and WLAN server parameters are configured in a way such that Blackhole

attacks are simulated over the network. Third scenario is duplicated from second
scenario and AODV and WLAN parameters are edited such that performance of

AODV is improved[5,82]. All the three scenarios are run for one hour and the

corresponding results are evaluated. Performance metrics are chosen at global level

including the metrics of AODV, FTP and HTTP. Three scenarios are compared

against the performance metrics and from the overall analysis of the results it is

clear that performance of AODV has reduced a lot due to Blackhole attacks and

can be observed from the graphs of second scenario. Overall routing traffic and

other important aspects of FTP, HTTP and AODV are high affected with the

Blackhole attacks and when the case with first scenario is considered performance

of AODV is as per the required conditions as there are no attacks and it works

under normal ideal conditions[83]. Performance of AODV was affected a lot due

to Blackhole attacks and when the results from third scenario are analyzed

performance of AODV has improved a lot when compared to Blackhole attacks

scenario. As the internal configurations of AODV and WLAN are altered the

impact that was created with Blackhole attacks was reduced. Thus from the overall

analysis of the simulation it is clear that Blackhole attacks can degrade the

performance of AODV routing protocol and with utter care taken across the

routing parameters and wireless LAN parameters performance of any routing

protocol can be improved even under attacks[84].

82
6.2 Future work and recommendations

There are few recommendations and scope for fixture work and as listed below

• Mobile ad hoc network is considered as the wireless network for simulating

the Blackhole attacks and in future wireless sensor networks and Zigbee

networks can be used to analyze the impact of Blackhole attacks over

AODY routing protocol

• External and internal configuration level attacks are used across the

simulation and in future physical attacks can be imposed for better analysis

of routing protocols performance

• AODV is used the routing protocol and in future more number of routing

protocols like TORA and DSR can be used and compared for a better

analysis

6.3 Appendix

• Detailed simulation steps followed in this project is given with the required

screenshots is given in this section

83
Above screen shows the basic network with 30 mobile nodes, application

configuration, profile configuration and the wireless LAN server[l 1,85]. All

these nodes are dragged from the object palette and this palette is shown in

the simulation procedure chapter.

84
 s a e c |

i _jg ! **»•■*>
[ *>«■*
ll ® -m
•M
cocarcrcoT;
J
I if) - ktkmor U/rtcrt
'crt* i =oi I
i 1
| ® fH—
*08
:<
I ® -*r y
1 | I*K4« JXC
I ® « y
! t * y
■'•‘l.'Wj J ® •» y
*«**.'■*.» i ji »« y
» \J) • ^-ott -^7 y
1 | .'4n Ccrtnrcr^ y
* .90* y
•J; ♦ r5« roar kvti H >T«i

If 'r»k.ne»J] Z J1
r ‘c.tae )
®i r jfCff X WKXC X*C1 I
ti r 305 -*s 2< | i«* |
1

Above screen shows the application configuration and from this it is clear

that DB is used as the application and it is set by medium load across the

database option.

85
 C *(rtow »Q

A *C* PWB'TS
w
4*

’»rtr ? 1

* C€£t»<
$
’W.’WO'
4

'jn :i
a ir.'ntyvraKT*
jjxr »ura •”i *

* * **mx*;- IWK
■*>V»-3 $ CWrjKr »»!
•
»*MW 9k '<M =re»t23
4 i.o' irtj Sn/ea-
4 • iw*!i >» 1 Jar. V<

s . SSI
•<*«t.<eoi^) J
' *virc*:

Procedure to setup the profile configuration is shown in the above screen.

From this it is clear that DB application is used to set the profile and the start

time and duration are set in the profile settings as shown in the above screen

86
 * I

Application settings to the nodes are shown in the above screen[67,85,86].

From this screen it is clear that application destination preferences and the

application supported profiles are set against the database application

created.

87
 Tmj’Jtta
1 t«u
■J1 'rt •sofrjrca**; .
<J) Mn r«<ec
•J * Ryoo- Uoa*>
'txtci 3
* Mwt Zmr Wsewt
'$ ’»r*< s»w iv»K»t
■J) 'tofc'W :r«r AviOOrt
M )
•J Moo4t> jonr '«jr« Not JWC
•J «.«r r«i: CS
>.w r«*r C3
<.*» P**! sc
sc
$ 'xx*: r*r. wxnt snMrtAC
<$ -IM V* iKT&
® Saf.Tnesecr* arm K5
(J) Sue 'n* SKj-ss rKi

Mobility configuration is set and the process is shown in the above

screen[87]. From this screen it is clear that default random waypoint is used

as the required mobility model and few' aspects like speed, pause time, start

time and stop time are set as shown in the above screen[69.76,87].

88
 P’CtocoH 0f$ ttndDM Hrip

AppiMcns >

itr.tr. >
* ■JM s
Mpflfcvnc *

TCP •

ye*i{
t ► Aasrnjn^ > A(/tc Any. P Apdtfwi.

PA > » XjIc Mvqn PA A3>r'-r,

»
SOP * CMFAMtob
CWnc-. »
D1*P > (**» p ^i3*r,sr. o* Al
QcS »
K» • Cm P A<5*fii« cf .iwtUc>*J PfysM W«f*R
M.Sxii; »
s-s > CM F AJS>e.»« ft- '.ck: «vj IrttAtcr.

CSPf > MAR »

Ccnfqjt AS NsnMf ft; S*ti«*J IbklM
s? *
Ccr/^jrntr, R.jpc'Ti * CM AS TM-’&er Sptcfaun .
PP-J *
Mead Umt Aute-AK^nPtsM'Ds

CM Pjtttr E>! on »•' rattr.

(cnhijMU lM« 0 n LKt*Xt AtertfS

$ft«r N»5« «t*»jP Addres:.

—a-----a

Assigning the IP addresses to all the mobile nodes is shown in the above

screen and it is clear from the above screen that IPV4 address are added to

all the nodes and the wireless LAN server[70,88].

89
 0 ‘ttrar,«)iOflMts £ n

1
• hV nwrc :TT«*!
?<a*c«rs
ft «:a»cxjr
ft * kwcjw '.«! / C «8
ft * TWtoJsr «c«(J sm
ft • ka'.*<c *>.-.«■:

Q iAppkKicn Su$oc<!(d M Ttt«

'«r* ,»^cr

J
*CJT1

9 0?

Database is set as the required application to be supported across the server

and the corresponding screen is as shown below

90
 - , Lny/ m.'

Drift jfKwMti
Diffc-* ftvttes Ntt«rt.
Dtfri Tr*j«ctC^. •'ox.'o*.* pg^ HH -w.ra.l!
(’<!' Tfjjtctcr, Asvytmrf -OM.ttt.S pg^

S*tf3*MceriY » S«tM<i6*v*0H«
ClurMctriyfcc'tt-
V»pO<t STl. Or*t -cm.mo*.;"
Set TlqtCftty CrtHti hem F.tfJCf'" Uzt‘ t)
V«nf> Iris- Cst*1. r-

W-K f.i» C-'Sup

F»‘ SfffffJ ObjKK

ttce-r Srirttd Otfcv. sa

Procedure to set the mobility to all the mobile nodes against the mobile

configuration is shown in the above screen and by this the default random

waypoint is set to all the nodes across the network[71,89.90,91],

Fittowli, MS Http
iffaCIbcn Dtp<. ~ 'A <r. U i! r.j Ntc^tri. *
Stfttr, Ccf.*t AC? Tttftc lf«tn < • • DtCffe)
■K
Wtri-tme Otpki Cttmed Afpetbem. Cw»A«*A
OfV Appfjff* DfptCyf't'W!
TC*
Dtpffr MS AppUttW' 0t"tnei
V
1(S*

£K»
W®
5-5
05®«
np
•9^)

91
Process to deploy the application is shown in the above screen and this

option is available from the protocols menu and applications sub menu and

the corresponding screen is as shown below

4 I m&ot’ittr JVC* *c*utri 3

r •
Pnfi
j
- 3 =-**
* Sajr,
~3
• 3 J'CP*c-*«r 'Cl*

-weii/cet.2

-tXM.X&j:
•XOH.X&.V
» ;
■yXitjVttJj

•CtM/o>.T*

*
J
J
- jtqtrC------------

» Sr-rrma *-xa | £~r * ' •’•jtet >n Cawicw

‘OP csv.- D*<iq Set Mp» .* d*&><*•$ Pw ►Sft-CKU'l r. n* mSyW-Ts cofrtau'r • P'tfk or r ipctason * « roarer « w» s' t»<
1- S«i«! ISwrr * S* Mr*0>t SM 0* !M *<t SW *fc
2 StW tM pro** cr aostuCon Mr v P» rqM hand sde See
J- Q*a 1M entp {»' Sjdor te Mptai !M s*! e» ne4« » 9» »*el*a Sr

To ree-d* ?* [re<4< apfxx.rr *rom t r«Je

1. Setrj (from ?»rqpt M-iS nie see
2 CM S» remote (X) bason so remote IM -oSe ‘rom 9» Mr J’J

2v*o Zjrmtarc, C*p» ^ *a ft rr?i Ot

Once the deploy option is selected the corresponding deployment screen is

as shown above. From this screen it is clear that all the mobile nodes are

shown on the left side and the corresponding source and destination are

defined at the right side. Arrow mark av ailable on middle of the window can

be used to deploy the nodes and server to the source and destination

respectively [ 11,72,74,92],

92
 Go Tc
Zccm Tc
Zccm Tc Li
Zc&nk
Zoom Out

futrt$**c!«Cfcj«cisIr9**uv« »
l* SdtCfcd Otafftt

C>>co» MmOiuI KS St««G

V*» r.«wS:

CpwKSUj

DsS (a $«to«t

Once the applications are deployed the next step is to choose the individual

DES statistics and the corresponding screen is as shown above. DES

statistics are used to set the performance metrics and the corresponding

screen is as shown below

93
 CCbOOKfou*! o -6 gg

,' ■ 1 *cca ?r Eoj*

2 'Att JKTtVf Tr*
:«ktnj W< -ere.e: &a w
2 Wr;TVc :e^vr:p>3.»
• Eoars T'rf; ierj fettwt
2 ^0O*j T*^< Set pctieci
'2 Ts<* <xr<**3)<r** "eijrf
■'' Tot* •cxrcweijeurtj xrt J
2 T«* '*?♦] >£•*•. $*-!
■_ ?a* Vy t-xejieo; S«jw:»
~2 Taut 5iSi«u >»o*J
•“ Tx* hekm Stops
2 Ta* =•*****; :<cm« Srt—i
• Ta* =«**•. Srt'v ONMh
•7 Taa %ui Em S«rt
■y f» 'AM -«>« S«rt
■-H T«j -am =Wj»si >rt
~ Taj Taffc -*»>*: tst mc
2 Taj =*:».*: pcs i«
y Taj W< Sea Sxi toe! r
‘Taj ?•*■: Set pa *c
•2 &•«
iH yis
*2 Hffi J
«□ h»7E 4 y | ianMf

DSR parameters are set across the performance evaluation process and the

actual parameters chosen from the global statistics are shown in the above

screen

94
 S 'Imobit.AOfc O <!>

!p? »*t«r

tot* »*ue 1
t

ft irjnor* •rdtfsruxr
ft * Sr: :rrttr. u
ft rift.
ft boo''r3Kyii X
ft ? xat Dee*y :vrm
ft alarm i:
ft '>ers ’a <anf K
ft ■V^nr^ui^trrsK
ft «mr vjjrf?wu»ar i:
ft rti Vx«:«w:9ecy*; ft
»rf
ft •w
ft i
ftl ; fei* ¥»tfrjet ’tnim In
ft '4«rv &/e S* pKMb IX
ft Kirtenrce t*39* Tr* j*« cx
ft Mmur Mertews "Ott: 2
ft Hlflwai ^towWywW n
*W
ft ■&SS%uew* Cc'ctstf

The actual attributes edited for the DSR routing protocol in the second

scenario are shown in the above screen and thus the node 2 acts as the

intruder node[6,73].

95
 0 (meWe.ncdHitofcwte o «/

■e-bjt Vau 4i
1

^ «A
$ Tr» 9»«rA IS
'!> * Sr4 wV 0
"<U &/* i.t p»CMtt ixe
$ &O0 Tear v:r* so
$ * Ss/» Onwjvy s«nr<ri ()
3> Segue* ’*« >]* CMW it
<!> Mwrwr Segue* ’aw 4ett It
Q 'Sstrii' Rrw^sk 1}
$ '<wv «iegjf* crcd jr.r >v
Q hM Segue* htK xcra cs
$ V ^spsrg Segue* W 903
$ jrtJba Swe Sep* Tne- ix 1
k)
<M 3 fiwe Urtenrce 'rrWm
$ ''bcnj- bfr S:t tX
e Vtenrce So®? Ire jkj 02i
$ M®n.r '4rwr\rc« fierrs 2
$ '■'jne’gra Syo^cj-rer jg
G DSflRM»&o« Dc'es-ctf
Sx:e s«*« jr; 3gre: =At«5 ■TX*
r Sji.rctf
$ ft*
1 __ r fppylowKStCstiecSi
r a»2*'*J [“_c*__ i__ ~—~ !

DSR parameters set for the node 4 is shown in the above screen

96
 Q (fflcMt.ncde.6) Wtnbwfn o

: V*J* J
® w* C*h* rTrty
® Swe ocr> ’rp worUs MC
® * jWWd* ()
® Ssj been
$ * Tires; Spectator ( )
't/w 1 s<*n I
a end 4 jruascr
® Tire je»rej £r^>rv«w
$ • j«rc &>(!• *wws U
d> u* 5/e" Sre 1500
®_ sore W sKPVi «
a D*ccverv Prr**j fu
® Sea.es T»e S* ran w
® Sea** Tsoe etrtf i
® u«mu> -exes srmiK 15
® w«crur sea** taod secer 50
® rt* SeaitS sccrot •k
® • 'O'- rr»mift; Seaett Tr* :c3
® Jisuxs Salt new Trer « i
® * =ojt* '-V«rer>j* ?«r*« u
(?) u«v BtAr >« w>.«j K d

a r
r Jcfircec
®l * 1
r s&> !c Kteaed objeci*
F t«4c:raw | -__ . |

DSR parameters set for the node 6 in the third scenario are shown in the

above screen and thus there are three attack nodes across the network.

97
 RESULTS

Few of the AODV routing parameters are compared and the corresponding data is

exported to excel and they are as given below

ATTACKSAODV- ATTACKSAODV- ATTACKSAODV-

AODVPER-DES- Attacks-DES-1: Normal-DES-1:

time 1: AODV.Number AODV.Number of AODV.Number of

(sec) of Hops per Route Hops per Route Hops per Route

0 #N/A #N/A #N/A

36 #N/A #N/A #N/A

72 #N/A #N/A #N/A

108 #N/A #N/A #N/A

144 #N/A #N/A #N/A

180 1.012821 1.01567 1.031339

216 1.00641 1.007835 1.01567

252 1.004274 1.005223 1.010446

288 1.003205 1.003917 1.007835

324 1.002564 1.003423 1.006449

360 1.003864 1.003519 1.005374

98
396 1.004196 1.003816 1.006804

432 1.003671 1.003339 1.006083

468 1.004425 1.00319 1.005407

504 1.003983 1.003757 1.004866

540 1.003784 1.003416 1.004511

576 1.003469 1.003711 1.004135

612 1.003202 1.00385 1.003817

648 1.002973 1.003694 1.003545

684 1.002775 1.003559 1.003308

720 1.002602 1.003337 1.003102

756 1.002448 1.003247 1.003197

792 1.002312 1.003067 1.003164

828 1.002191 1.003172 1.002997

864 1.002081 1.003433 1.002847

900 1.001982 1.003353 1.002712

936 1.001892 1.003611 1.002588

972 1.001913 1.004042 1.002785

1008 1.001833 1.004128 1.002669

1044 1.00176 1.004106 1.002562

1080 1.001692 1.003948 1.002464

99
1116 1.001629 1.003802 1.002498

1152 1.001571 1.003862 1.002409

1188 1.001517 1.003729 1.002326

1224 1.001466 1.003604 1.002248

1260 1.001658 1.003553 1.002176

1296 1.001714 1.003442 1.002108

1332 1.00173 1.003615 1.002044

1368 1.001679 1.003509 1.001984

1404 1.001631 1.003409 1.002017

1440 1.001586 1.003427 1.001961

1476 1.001543 1.00362 1.001908

1512 1.001502 1.003613 1.001858

1548 1.001464 1.00352 1.00181

1584 1.001551 1.003491 1.001765

1620 1.001513 1.003406 1.001722

1656 1.00153 1.003325 1.001681

1692 1.001592 1.003247 1.001714

1728 1.001555 1.003173 1.001696

1764 1.001521 1.003103 1.001658

1800 1.001488 1.003035 1.001622

100
1836 1.001704 1.002971 1.001588

1872 1.001669 ,1.002909 1.001555

1908 1.001635 1.00285 1.001523

1944 1.00179 1.002793 1.001493

1980 1.001755 1.002738 1.001463

2016 1.001721 1.002685 1.001435

2052 1.001738 1.002635 1.001408

2088 1.001706 1.002586 1.001382

2124 1.001675 1.002539 1.001401

2160 1.001645 1.002665 1.001375

2196 1.001616 1.002717 1.001351

2232 1.001714 1.002856 1.001328

2268 1.001685 1.002837 1.001306

2304 1.001902 1.00279 1.001284

2340 1.002004 1.002744 1.001263

2376 1.001972 1.0027 1.001242

2412 1.001941 1.002935 1.001223

2448 1.00191 1.003176 1.001204

2484 1.001881 1.003127 1.001216

2520 1.001853 1.003226 1.001216

101
2556 1.001825 1.003177 1.001212

2592 1.001798 1.003131 1.001195

2628 1.001772 1.003085 1.001177

2664 1.002031 1.003041 1.00116

2700 1.0022 1.003257 1.001144

2736 1.002247 1.003212 1.001144

2772 1.002289 1.003168 1.001128

2808 1.002472 1.003147 1.001113

2844 1.002439 1.003135 1.001098

2880 1.002407 1.003094 1.001084

2916 1.002375 1.003077 1.00107

2952 1.002345 1.003038 1.001056

2988 1.002315 1.002999 1.001042

3024 1.002286 1.003075 1.001029

3060 1.002399 1.003353 1.001017

3096 1.002536 1.003312 1.001004

3132 1.002535 1.003272 1.000992

3168 1.002619 1.003272 1.000991

3204 1.002589 1.003298 1.001041

3240 1.002559 1.003315 1.001029

102
3276 1.002529 1.003277 1.001017

3312 1.0025 1.00324 1.001006

3348 1.002472 1.003203 1.000994

3384 1.002445 1.003168 1.001029

3420 1.002439 1.003133 1.001018

3456 1.002412 1.003099 1.001007

3492 1.002386 1.003066 1.000996

3528 1.002423 1.003033 1.000986

3564 1.002438 1.003001 1.000975

3600 #N/A #N/A #N/A

ATTACKSAODV- ATTACKSAODV- ATTACKSAODV-

AODVPER-DES- Attacks-DES-1: Normal-DES-1:

time 1: AODV.Route AODV.Route AODV.Route

(sec) Discovery Time Discovery Time Discovery Time

0 #N/A #N/A #N/A

36 #N/A #N/A #N/A

72 #N/A #N/A #N/A

103
108 #N/A #N/A #N/A

144 #N/A #N/A #N/A

180 0.128816 0.198607 0.04872

216 0.066688 0.101855 0.028586

252 0.046473 0.069973 0.020332

288 0.036043 0.053903 0.016796

324 0.030176 0.044249 0.015587

360 0.025978 0.037756 0.014146

396 0.023219 0.033132 ■ 0.013142

432 0.02104 0.050369 0.012245

468 0.019263 0.045533 0.011553

504 0.017971 0.041569 0.010951

540 0.016697 0.038173 0.010522

576 0.015811 0.035543 0.010097

612 0.015046 0.033257 0.009866

648 0.014356 0.031204 0.009471

684 0.013974 0.029462 0.009207

720 0.013628 0.028007 0.008978

756 0.013253 0.026684 0.00879

792 0.012906 0.025478 0.008652

828 0.012466 0.024416 0.00839

864 0.012174 0.023493 0.008289

900 0.011849 0.022612 0.008155

936 0.011578 0.021854 0.008052

972 0.011346 0.021124 0.007967

1008 0.011123 0.020469 0.007915

1044 0.01755 0.019826 0.007889

*

1080 0.017091 0.019276 0.007805

1116 0.0167 0.018787 0.007783

1152 0.016321 0.018333 0.007684

1188 0.015965 0.017924 0.007639

1224 0.015581 0.017528 0.007583

1260 0.015236 0.017171 0.007575

1296 0.014901 0.016896 0.007509

1332 0.014575 0.016584 0.00744

1368 0.01433 0.016224 0.007338

1404 0.014074 0.015957 0.007309

1440 0.013883 0.015652 0.007304

1476 0.013757 0.015375 0.007245

1512 0.01354 0.015098 0.007202

105
1548 0.013332 0.014862 0.007138

1584 0.013161 0.014658 0.007075

1620 0.012972 0.014424 0.007053

1656 0.012779 0.014225 0.007042

1692 0.012613 0.015544 0.007012

1728 0.012477 0.015284 0.007002

1764 0.012309 0.015069 0.006971

1800 0.012137 0.014872 0.006958

1836 0.01203. 0.014686 0.006907

1872 0.011893 0.014507 0.006891

1908 0.011752 0.014328 0.006863

1944 0.011616 0.014132 0.006897

1980 0.011479 0.014008 0.00687

2016 0.011381 0.013836 0.006854

2052 0.011271 0.013682 0.006809

2088 0.011187 0.013525 0.006803

2124 0.011143 0.013397 . 0.006799

2160 0.011056 0.01325 0.006777

2196 0.010963 0.013121 0.00678

2232 0.010859 0.01299 0.006762

106
2268 0.010757 0.012848 0.006767

2304 0.010678 0.012704 0.006721

2340 0.010608 0.012596 0.006704

2376 0.010542 0.012495 0.006681

2412 0.010517 0.012388 0.006707

2448 0.010437 0.01229 0.00671

2484 0.010372 0.012161 0.0067

2520 0.010318 0.012065 0.006704

2556 0.010277 0.011966 0.006708

2592 0.010217 0.011883 0.006694

2628 0.01015 0.011777 0.006707

2664 0.010087 0.011691 0.006691

2700 0.010028 0.011621 0.006665

2736 . 0.009987 0.011539 0.006665

2772 0.009899 0.011485 0.00665

2808 0.009841 0.01142 0.006649

2844 0.009799 0.01135 0.006641

2880 0.009735 0.011273 0.006613

2916 0.009684 0.011206 0.006611

2952 0.00966 0.01113 0.006583

107
2988 0.009625 0.011075 0.006569

3024 0.009598 0.011006 0.006558

3060 0.009558 0.011427 0.006555

3096 0.009531 0.011361 0.006538

3132 0.00949 0.0113 0.006517

3168 0.00945 0.011228 0.006501

3204 0.009403 0.011156 0.006494

3240 0.009358 0.01108 0.006483

3276 0.009313 0.011023 0.006466

3312 0.009267 0.010966 0.006436

3348 0.009215 0.010911 0.006443

3384 0.009183 0.010854 0.006453

3420 0.009159 0.010791 0.006449

3456 0.00914 0.010749 0.006422

3492 0.009142 0.010696 0.006445

3528 0.009116 0.010651 0.006432

3564 0.009148 0.010597 0.006416

3600 #N/A #N/A #N/A

108
 ATTACKSAODV- ATTACKSAODV- ATTACKSAODV-

AODVPER-DES- Attacks-DES-1: Normal-DES-1:

time 1: AODV.Total AODV.Total AODV.Total

(sec) Packets Dropped Packets Dropped Packets Dropped

0 #N/A #N/A #N/A

36 #N/A #N/A #N/A

72 #N/A #N/A #N/A

108 #N/A #N/A #N/A

144 #N/A #N/A #N/A

180 #N/A 1 42

216 17 11.5 39.5

252 12.5 11.33333 34.66667

288 12.33333 10.25 31.75

324 14.25 9 29

360 13.2 8.5 27.33333

396 11.66667 8.428571 27.42857

432 11.71429 8.375 27

468 11.375 8.222222 25.66667

504 11.55556 8.4 25.6

540 12.4 8.636364 24

109
576 11.90909 8.416667 23.75

612 11.5 8.153846 23.76923

648 11.69231 8.142857 23.64286

684 11.64286 8.466667 23.53333

720 11.66667 8.8125 23.25

756 11.4375 8.529412 22.11765

792 11.05882 8.833333 21.33333

828 10.94444 8.578947 21.31579

864 10.84211 8.4 21.1

900 10.65 8.285714 21.09524

936 10.66667 8.136364 21

972 10.36364 8 20.17391

1008 10.34783 8.041667 20.29167

1044 10.45833 8 20.36

1080 10.2 8 20.19231

1116 10.15385 8 19.74074

1152 10.03704 8.035714 19.75

1188 10.17857 8.103448 20.17241

1224 10.13793 8.133333 20

1260 9.933333 8.064516 19.93548

110

Q
1296 9.774194 8.21875 20.0625

1332 9.53125 8.181818 20

1368 9.545455 8.264706 20

1404 9.529412 8.342857 19.82857

1440 9.542857 8.25 19.80556

1476 9.722222 8.108108 19.94595

1512 9.621622 8.131579 20.10526

1548 9.552632 8 20.15385

1584 9.384615 7.975 19.95

1620 9.275 8.04878 20.07317

1656 9.195122 8.02381 20.04762

1692 9.142857 8.023256 19.83721

1728 9.093023 8.159091 19.84091

1764 9.068182 8.444444 19.77778

1800 9.066667 8.456522 19.71739

1836 9 8.574468 19.80851

1872 9 8.645833 19.91667

1908 8.895833 8.612245 19.79592

1944 8.795918 8.62 19.78

1980 8.78 8.647059 19.72549

111
2016 8.882353 8.75 19.94231

2052 8.865385 8.811321 19.92453

2088 8.943396 8.888889 19.92593

2124 9 8.945455 19.74545

2160 8.963636 8.910714 19.80357

2196 8.964286 8.807018 19.78947

2232 8.894737 8.775862 19.82759

2268 9.017241 8.762712 19.89831

2304 8.881356 8.8 19.91667

2340 8.8 8.901639 20.01639

2376 8.786885 8.806452 20.01613

2412 8.774194 8.761905 20.06349

2448 8.746032 8.65625 20.17188

2484 8.71875 8.569231 20.07692

2520 8.707692 8.515152 19.95455

2556 8.757576 8.61194 19.89552

2592 8.746269 8.691176 19.88235

2628 8.720588 8.695652 19.94203

2664 8.623188 8.671429 19.92857

2700 8.542857 8.633803 20.04225

112
2736 8.464789 8.680556 20.11111

2772 8.388889 8.60274 20.0411

2808 8.287671 8.567568 20.05405

2844 8.256757 8.56 20.06667

2880 8.28 8.539474 20.05263

2916 8.289474 8.506494 20.1039

2952 8.272727 8.487179 19.97436

2988 8.333333 8.468354 19.98734

3024 8.379747 8.425 20.05

3060 8.35 8.333333 20.08642

3096 8.308642 8.426829 19.97561

3132 8.365854 8.445783 20.0241

3168 8.313253 8.452381 20.04762

3204 8.369048 8.411765 19.89412

3240 8.341176 8.395349 19.94186

3276 8.302326 8.390805 19.86207

3312 8.333333 8.420455 19.92045

3348 8.363636 8.370787 19.91011

3384 8.404494 8.333333 19.77778

3420 8.444444 8.351648 19.83516

113
3456 8.428571 8.336957 19.80435

3492 8.5 8.354839 19.84946

3528 8.44086 8.319149 19.78723

3564 8.414894 8.389474 19.88421

3600 #N/A #N/A #N/A

ATTACKSAODV- ATTACKSAODV- ATTACKSAODV-

AODVPER-DES- Attacks-DES-1: Normal-DES-1:

time 1: AODV.Total AODV.Total AODV.Total

(sec) Route Replies Sent Route Replies Sent Route Replies Sent

0 #N/A #N/A #N/A

36 #N/A #N/A #N/A

72 #N/A #N/A #N/A

108 #N/A #N/A • #N/A

144 #N/A #N/A #N/A

180 340 165 377

216 182.5 154.5 273

252 146 188.3333 191.3333

114
288 133.5 163.5 161

324 120.4 155.2 136.2

360 140 154.5 127.6667

396 140.7143 141.1429 126.2857

432 132.375 129.75 125

468 137.8889 132.5556 126.1111

504 130 135.2 119.4

540 123.4545 132.6364 121.5455

576 120.0833 142.5833 115

612 118.9231 144.3846 118.0769

648 115.7857 145.8571 116.0714

684 110.5333 141.6667 112.9333

720 112.75 140.375 113.875

756 113.8824 137.3529 116.8235

792 117.0556 133.4444 115.5

828 112.5789 131.9474 115.7368

864 110.15 130.95 113.25

900 108.1429 132.619 112

936 107.5455 131.5 109.0455

972 109.5217 130.3043 108.7391

115
1008 108.0833 131.625 107.125

1044 108.76 129.88 105.48

1080 111.2308 129.7692 105.7692

1116 109.1111 133.6296 103.9259

1152 107.5714 133.5357 102.9286

1188 107 130.2414 103.7241

1224 106.9667 127.9333 104.2667

1260 107.0323 127.4839 102.4839

1296 105.2188 127.5 101.3438

1332 105 130.6061 100.4545

1368 104.4412 128.6471 100.6471

1404 103.4571 126.7429 99.82857

1440 101.5 127.7778 99.05556

1476 100.027 126.8108 98.2973

1512 103.7632 125.8947 100.2632

1548 103.4359 125.8205 100.4615

1584 105.025 126.35 100.1

1620 . 104.1951 127.4634 99.65854

1656 104.5714 126.7857 98.66667

1692 104.0465 126.7674 98.93023

116
1728 103.2955
•
124.4091 98.04545

1764 102.2 125.0667 97.08889

1800 102 123.9348 96.26087

1836 103.9574 125.2766 95.19149

1872 103.5 124.7917 95.27083

1908 103.7347 123.5714 94.69388

1944 104.12 124.28 95.92

1980 104.0588 123.8431 96

2016 105.2115 122.8269 97.63462

2052 106.3396 124.3962 96.66038

2088 105.5185 124 96.03704

2124 105.5636 123.5273 95.52727

2160 106.5714 123.9107 95

2196 107.7018 122.7368 94.17544

2232 108.6034 123.431 93.89655

2268 108.1864 122.4746 93.55932

2304 111.0333 122.35 92.95

2340 111.7049 121.8361 93.40984

2376 112.4677 124.0968 94.29032

2412 112.9841 124.127 93.69841

2448 112.0313 123.9219 92.96875

2484 112.1385 123.1692 93.04615

2520 112.2576 124.0606 93.93939

2556 111.7761 122.8358 94.1194

2592 112.7353 123.1471 93.39706

2628 113.7971 122.5942 92.7971

2664 115.1857 122.7143 92.92857

2700 116.4789 124.0282 93.07042

2736 116.4583 123.25 92.98611

2772 115.4795 123.0959 93.67123

2808 115.5 122.473 94.52703

2844 116.1467 123.3333 95.26667

2880 116.5658 123.1974 94.78947

2916 116.8571 123.4026 93.98701

2952 117.4359 123.6282 93.19231

2988 116.519 122.8861 92.89873

3024 115.6125 122.1 93.3875

3060 116.9877 123.5802 92.90123

3096 117.5854 123.4756 92.65854

3132 118.3373 122.5422 93.59036

118
3168 118.7738 122.2738 93.95238

3204 118.1059 122.5412 94.28235

3240 118.0465 123 95

3276 118.3908 122.908 95.36782

3312 117.2614 122.8864 95.07955

3348 116.6067 122.9775 95.32584

3384 115.8333 122.9333 95.23333

3420 116.4615 122.2308 94.83516

3456 116.0435 122.5761 94.18478

3492 115.6129 122.8925 93.78495

3528 116.0213 122.8085 93.2234

3564 115.4211 122.7263 92.8

3600 #N/A #N/A #N/A

REFERENCES

1. Parikshit Machwe. (.)• Routing Protocols For Ad-hoc Networks.

Available: http://www.facweb.iitkgp.emet.in/~agupta/ IWT /

Sample2.pdf.

2. Clifton Lin. (.). AODV Routing Implementation for Scalable Wireless

Ad-Hoc Network Simulation (SWANS). Available:

http://jist.ece.comell.edu/docs/040421 -swans-aodv.pdf.

3. Frank Aune. (2004). Cross-Layer Design

<“7
Tutorial.
l
Available:

http://mobiledevices.kom.aau.dk/uploads/media/AmeTutorial_02.pdf.

4. Abhishek Kumar. (2000). Performance of Multiple TCP Connections

over Different Routing Protocols in Mobile Ad-hoc Networks.

Available:http://www.worldcolleges.info/College/E-Books/ download

/tcp.pdf.

5. Md. Abdullah-Al-Mamun. (2006). PERFORMANCE EVALUATION

OF TCP OVER ROUTING PROTOCOLS FOR MOBILE AD HOC

NETWORKS. Available: http://www.mee.tcd.ie /~ledoyle /

EMERGINGNETWORKS/pages/pubs/chinacom2006.pdf.

6. H. M. El-Sayed. (2005). PERFORMANCE EVALUATION OF TCP

IN MOBILE AD-HOC NETWORKS. The Second International

Conference on Innovations in Information Technology. 1 (3), p2-3.

120
7. Salman A. Baset. (2007). Understanding the Behavior of TCP for

Realtime CBR Workloads. Available: http://wwwl.cs.

colnmbia.edu/~salman/publications/votcp-conext07.pdf.

8. Abdul Samada. (2010). Registration and Aggregate Cache Routing for

Ad hoc Network. Int. J. Advanced Networking and Applications. 02

(3), p2-4.

9. Jin-woo Hyun. (2008). CBR Period Dependent Adaptive Routing

Algorithm for MANET. Proceedings of the 8th WSEAS International

Conference on APPLIED COMPUTER SCIENCE (ACS'08). 8 (2), p2-

3.

10. Manohar Gosul. (2011). High Speed Attack Detection in the

Network.Available:http://www.technicaljoumals.org/JPDF/TJ~

RJCSE-IJ-02-16.pdf. Last accessed 23rd-sep-2012.

11. Dr. Fengmin Gong. (2003). Deciphering Detection Techniques: Part II

Anomaly-Based Intrusion Detection. Available: https://

secure.mcafee.com/japan/products/pdf/Deciphering_Detection_Techn

iques-Anomaly-Based_Detection_WP_en.pdf. Last accessed 23rd sep

2012.

121
12.Steve Petri. (2001). An Introduction to Smart Cards. Available:

http://artofconfusion.org/smartcards/docs/intro.pdf. Last accessed

13th-sep 2012.

13 Joel Esler. (2007). Snort ® IDS and IPS Toolkit. Available:

http://doc.hackbbs.org/Docs HackAngel/Svngress%20-%20Snort%20

IDS%20and%20IPS%20Toolkit.pdf. Last accessed 23rd July 2011

14.Steve Lodin, (1998). Intrusion Detection Product Evaluation

Criteria. Available: citeseerx.ist.psu.edu/viewdoc/download?doi=

10.1.1.40...type.... Last accessed sep-10th-2012.

15. Harley Kozushko. (2003).: Host-Based and Network-Based Intrusion

Detection Systems. Available: http://infohost.nmt.edu /~sfs/

Students/HarleyKozushko/Papers/IntmsionDetectionPaper.pdf. Last

accessed sep5th-2012.

16. Tom Karygiannis. (1999). Applying Mobile Agents to Intrusion

Detection and Response. Available: http://csrc.nist.gov

/publications/nistir/ir6416.pdf. Last accessed aug-30th-2012.

17. Focus Editors. (2008). IDS vs. IPS Explained. Available:

http://www.focus.com/fyi/ids-vs-ips/. Last accessed 22nd-2012.

122
18. T J Samuell. (2009). Security Certification. Available: http: //

axishosting.net/books/Certifications/CompTIA/Mike.Meyers.CompTI

A.Security.Plus.Certification.pdf. Last accessed 24th sep-2012.

19. Jeff Roberts. (2006). ATTACK AND DEFEND TOOLS FOR

REMOTELY ACCESSIBLE CONTROL AND PROTECTION

EQUIPMENT IN ELECTRIC POWER SYSTEMS. Available:

http://www2.selinc.com/techpprs/6132.pdf. Last accessed 20th-sep-

2012.

20. Michele Adams. (2009). Honeypots: Concepts, Approaches, and

Challenges. Available:http://cs.millersville.edu/~csweb/lib/userfiles/h

oneypot.pdf. Last accessed 24th July 2011

21. Brain Kenyon. (2010). Hardening the network

infrastructure. Available:http://doc.hackbbs.org/Docs HackAngel/Svn

gress%20-%20Securitv %20Sage's%20Guide%20to%20Hardening

%20the%20Network.pdf. Last accessed 24th sep-2012.

22. Dieter Joho. (2004). Active Honeypots. Available: http://

www.ifi.uzh.ch/archive/mastertheses/DA_Arbeiten_2004/Joho_Dieter

.pdf. Last accessed 24th sep-2012.

123 -
23. Craig Valli. (2006). Honeypots: How do you know when you are

inside one?. Available: http://ro.ecu.edu.au/cgi/viewcontent.cgi7article

= 1027&context=adf. Last accessed 24th sep-2012.

24. Ralph Niederberger. (2006). Firewall Issues overview. Available:

http://www.ogf.org/documents/GFD.83.pdf. Last accessed 24th July

2011

25. Murugiah Souppaya. (2009). Guide to Enterprise Telework and

Remote Access Security. Available: http://csrc.nist.gov/publications

/nistpubs/800-46-revl/sp800-46rl.pdf. Last accessed 24th sep-2012.

26. Chuck Semeria. (2007). Internet Firewalls and Security. Available:

http://baggins.nottingham.edu.my/~hsooihock/G54ACC/Intemet_Fire

wall_and_Security.pdf Last accessed 24th sep-2012.

27. Tim Grance. (2009). Computer Security Incident Handling

Guide. Available: http://csrc.nist.gov/publications/nistpubs/800-61 -

revl/SP800-61revl.pdf. Last accessed26th -sep-2012.

28. James Cannady. (1996). New Methods of Intrusion Detection using

GontrolLoop Measurement. Available: http://scis.nova.edu/~cannadv/

ids_newm.pdf Last accessed 26th July 2011

124
29. David Henning. (2009). Creating a Patch and Vulnerability

Management Program. Available: http://csrc.nist.gov/publications/

nistpubs/800-40-Ver2/SP800-40v2.pdf. Last accessed 26th sep-2012.

30. Karen Rustad. (2008). Suck It Up, Princess": Outreach and Diversity
A

in FOSS Communities. Available: http://littlegreenriver.com/stuffs

/Outreach-Diversity-FOSS.html. Last accessed 26th sep-2012.

31. Angela Orebaugh. (2008). Technical Guide to Information Security

Testing and Assessment. Available: http://csrc.nist.gov/publications

/nistpubs/800-115/SP800-l 15.pdf. Last accessed 26th sep-2012.

32. Christopher Ger. (2004). Managing Security with Snort and IDS

Tools.Available: http://seclab.pl/pdf7Q,Reillv%20-%20Managing

%20 Security%20With%20 Snort%20 And%20Ids%20Tools%20-

%201St.pdf. Last accessed 26th sep-2012.

33. Judy Novak. (2002). Network Intrusion Detection, Third

Edition.Available:

citeseerx.ist.psu.edu/viewdoc/download?doi=l 0.1.1.163.... Last

accessed 26th sep-2012.

34. Sven Dietrich. (2004). Internet Denial of Service: Attack and Defense

Mechanisms. Available:

http ://dump .udderweb. com/Books/unsorted/Intemet_Denial_Of_S ervi

125
 ce_-_Attack_And_Defense_Mechanisms_2004.pdf. Last accessed

26th sep-2012.

35. Vasileios Pappas. (2010). mproving the scalability of data center

networks with traffic-aware virtual machine placement. Available:

http://dl.acm.org/citation.cfm?id=l 833515.1833690. Last accessed

26th sep-2012.

36. M W Pearson. (2000). Measurement of VOIP traffic. Available:

http://www.cs.waikato.ac.nz/pam2000/pdf_papers/pam2000c.pdf.

Last accessed 26th sep-2-12.

37. Mohsen Beheshti. (2006). Packet Information Collection and

Transformation for Network Intrusion Detection and

Prevention.Available: http://csc.csudh.edu/mbeheshti/ Spring09 /

SamplePaper.pdf. Last accessed 26th sep-2-12.

38. Leon. (2008). BUILDING A GENERIC STRESS TOOL FOR

SERVER PERFORMANCE AND BEHAVIOR ANALYSIS.

Available: http://upcommons.upc.edu/pfc/bitstream /2099.1 /5610 /

l/50010.pdf. Last accessed 12th-sep-2012.

39. Addicam.V.Sanjay . (2005). Overview of Agile Management &

Development Methods. Available: http://www.proiectperfect.com.au/

126
 downloads/Info/info_agile__programming.pdf. Last accessed 12th-sep-

2012.

40. Dr. Timothy Korson . (2002). The Misuse of Use Cases . Available:

http://www.usna.edu/Users/cs/needham/courses/ic470/fallAY 11/Uie

MisuseofUseCases.pdf. Last accessed 10th-sep-2012.

41. K. Cloete. (2011). STRATEGY TO PROCEED TO THE NEXT

PHASE.Available: http://www.skatelescope.org/~cloete/2011-

02_System_delta_CoDR_Documents/l 7-WP2-005.010.030-PLA-

002-B_NextPhase.pdf. Last accessed 8th-sep-2012.

42.0MER KORKMAZ. (2007). SYSTEM SIMULATION FOR

SOFTWARE QUALITY ASSURANCE (SQA). Available:

acikarsiv.atilim.edu.tr/browse/192/205.pdf.

43. Mihir Kothari. (2010). Early Warning Signs in Software Projects.

Available: http://aut.researchgatewav.ac.nz/bitstream/ 10292/1327/3/

KothariM.pdf. Last accessed 8th-sep-2012.

44. V. Mohabay. (2011). Analysis and Modeling of Change Management

Process Model. Available: http ://www. sersc.org/i oumals/IJSEIAV

vol5_no2_2011/10.pdf. Last accessed 18th-sep-2012

45. Tonja Molin-Juustila. (2002). CROSS-FUNCTIONAL

INTERACTION DURING THE EARLY PHASES OF

127
 USERCENTERED SOFTWARE NEW PRODUCT

DEVELOPMENT: RECONSIDERING THE COMMON AREA OF

INTEREST.Available: http ://herkules.oulu.fi/isbn9514280458/

isbn9514280458.pdf. Last accessed 5th-sep-2012

46. Rean Griffith. (2008). The 7U Evaluation Method: Evaluating

Software Systems via Runtime Fault-Injection and Reliability,

Availability and Serviceability (RAS) Metrics and

citeseerx.ist.psu.edu/viewdoc/download?doi=l 0.1.1.157.23&rep.

47. Arthur M. Langer. (2008). Analysis and Design of Information

Systems. Available: http://www.dss.dpem.tuc.gr/pdft Analysis% 20

and%20Design%20of%20Information%20Systems.pdf. Last accessed

5th-sep-2012

48. Harold Kemzer. (2009). Project managment. Available:

http://www.scribd.com/doc/26455407/Proiect-Management-A-

Svstems -Approach-to-Planning-Scheduling-and-Controlling.

49. H van Vliet. (2002). Software Engineering: Principles and

Practice.Available: citeseerx.ist.psu.edu/viewdoc /download? Doi =

10.1.1.128. Last accessed 5th-feb-2012.

50.Shweta Deshpande. (2011). A Study Of Software Engineering

Practices for Micro Teams. Available: http://etd.ohiolink.edu/send-

128
 pdf.cgi/Deshpande%20Shweta.pdf?osul299620089. Last accessed

5th-sep-2012.

51. David Cohen. (2003). Agile Software Development A DACS State-

of-the-Art Report. Available: citeseerx.ist.psu.edu/viewdoc/ download

?doi=10.1.1.94.7&rep... Last accessed 15th-sep-2012.

52. RJ Madachy. (2005). Early Draft Version - Center for Systems and

SoftwareEngineering. Available: csse.usc.edu/~madachy/spdworking

/spd%20all%204.9.02.doc.

53. Pirkka Rannikko. (2011). User-Centered Design in Agile Software

Development. Available: http://www.cs.uta.fi/research/thesis/masters

/Rannikko_Pirkka.pdf.

54. K Orr. (2010). CMM VERSUS AGILE DEVELOPMENT. Available:

www.orbytesolutions.com/services/images/doc/cmmvsagile.doc. Last

accessed 3rd-sep-2012.

55. Michael Lang. (2007). Web-based systems design: a study of

contemporary practices and an explanatory framework. Available:

http://ulir.ul.ie/bitstream/10344/95/3/0SSE2015.pdf.txt.

56. Hans van Vliet. (2008). Answers to Exercises SOFTWARE

ENGINEERING: Principles and Practice Third Edition. Available:

http://www.few.vu.nl/~JC.van.Vliet/SEguide08.pdf.

129
57. Carlton Northern. (2010). Handbook for Implementing Agile in

Department of Defense Information Technology Acquisition.

Available: http://www.mitre.org/work/tech papers/2011 /II 0401/

ll_0401.pdf

58. Barry Boehm. (2007). A Survey of Agile Development

Methodologies. Available: http://agile.csc.ncsu.edu/SEMaterials/

AgileMethods.pdf. Last accessed 6th jan-2012.

59. Deemer. (2008). THE SCRUM PRIMER. Available: http:// faculty.

ksu.edu.sa/zohair/Documents/CSC541/Chap2SWE%20processes/Scru

m%20Primer.pdf

60. Ghauri, P. and Gronhaug, K. (2005) “Research Methods in Business

Studies: A practical Guide”. (3rdedn.), Pearson Education Limited.

61.Sasha Hurrell. (2004), DATA COLLECTION CHALLENGES.

Available: http:// thepartneringinitiative.org/docs/tpi/ DataCollection

Challenges.pdf. Last accessed lst-sep-2012.

62. Dave Raggett, Amaud Le Hors, and Ian Jacobs. HTML

4.01 Specification- W3C Recommendation 24. World Wide Web
Consortium (W3C), Online:http://www.w3.org/TR/html401/, last
access February 2006, December 1999.
63. David A. Wheeler. Secure Programming for Linux and Unix
HOWTO -Creating Secure Software. World Wide Web Consortium

130
 (W3C), Online:http://www.dwheeler.com/secure-programs/, last
accessed November 2005, 3rd edition, March 2003.
64. James D. Wynne. Learning Statistics, A Common-Sence Approach.
MacMillanPublishing Co., Inc., New York, 1982.
65. Paul Innella and Oba McMillan, Tetrad Digital Integrity, LLC “An
Introduction to Intrusion Detection Systems” December 6, 2001
66. Micheal E. Whitman and Herbert J. Mattord, “Principles of
Information Security” page 289-294

67. Christos Douligeris and Dimitrios N. Serpanos “Network Security

Current Status and Future Trends”
68. Varan Chandola, Arindam Baneijee, and Vipin Kumar“Anomaly
Detection: A Survey” August 15,2007
69. Anita K. Jones and Robert S. Sielken, Department of Computer
Science University of Virginia “Computer System Intrusion
Detection: A Survey”
70. Dr. Fengmin Gong, Chief Scientist, McAfee Network Security
Technologies Group, “Deciphering Detection Techniques: Part II
Anomaly-Based Intrusion Detection” March 2003
71. Carl Endorf, Eugene Schultz, Jim Mellander “Intrusion detection &
prevention” page 18
72. Deccan Herald, “Cyber attacks cripple websites”,
http://www.deccanherald.com/content/12577/cyber-attacks-cripple-w
ebsites.html
73. “Top 5 Intrusion Detection Systems”, http://sectools.org/ids.html
74. Alok Sharma, Aran K. Pujari, Kuldip K. Paliwal, "Intrusion detection
using text processing techniques with a kernel based similarity

131
 measure", Computers & Security, Vol: 26, No: 7-8, pp: 488-495,
2007.
75. Shi-Jinn Homg, Ming-Yang Su, Yuan-Hsin Chen, Tzong-Wann Kao,
Rong-Jian Chen, Jui-Lin Lai, Citra Dwi Perkasa,"A novel intrusion
detection system based on hierarchical clustering and support vector
machines", Expert Systems with Applications, Vol: 38, No: 1, pp:
306-313,2011.
76. Abadeh, M.S., Habibi, J., "Computer Intrusion Detection Using an
Iterative Fuzzy Rule Learning Approach", in Proceedings of the IEEE
International Conference on Fuzzy Systems, pp: 1-6, London, 2007.
77. Bharanidharan Shanmugam, Norbik Bashah Idris, "Improved
Intrusion Detection System Using Fuzzy Logic for Detecting
Anamoly and Misuse Type of Attacks", in Proceedings of the
International Conference of Soft Computing and Pattern Recognition,
pp: 212-217, 2009.
78. O. Adetunmbi Adebayo, Zhiwei Shi, Zhongzhi Shi, Olumide S.
Adewale, "Network Anomalous Intrusion Detection using Fuzzy-
Bayes", IFIP International Federation for Information Processing,
Vol: 228, pp: 525-530, 2007.
79. Arman Tajbakhsh, Mohammad Rahmati, Abdolreza Mirzaei,
"Intrusion detection using fuzzy association rules", Applied Soft
Computing, Vol: 9, No: 2, pp: 462-469,2009.
80. Zhenwei Yu, Tsai, J.J.P., Weigert, T., "An Automatically Tuning
Intrusion Detection System", IEEE Transactions on Systems, Man,
and Cybernetics, Vol: 37, No: 2, pp: 373 - 384,2007.
81. Qiang Wang and Vasileios Megalooikonomou, "A clustering
algorithm for intrusion detection", in Proceedings of the conference

132
 on Data Mining, Intrusion Detection, Information Assurance, and
Data Networks Security, vol. 5812, pp.31-38, March 2005.
82. Cordon O, Gomide F, Herrera F, Hoffmann F, Magdalena L, “Ten
years of genetic fuzzy systems: current framework and new trends”,
Fuzzy Sets and Systems, vol. 141, no.l, pp. 5-31,2004.
83. M. Saniee Abadeh, J. Habib and C. Lucas, “Intrusion detection using
a fuzzy genetics-based learning algorithm”, Journal of Network and
Computer Applications, vol.30, no.l, pp. 414-428, 2007.
84. R. Agrawal, T. Imielinski, A., Swami, “Mining association rules
between sets of items in large databases”, in Proceedings of 1993
ACM SIGMOD Inti. Conf. on Management of Data, Washington, DC,
pp. 207-216, 1993.
85. http.7/www.ll.mit.edu/mission/communications/ist/corpora/ideval/data
/1998data.html
86. http://www.sigkdd.org/kddcup/index.php?section=1999&method=dat
a
87. Mahbod Tavallaee, Ebrahim Bagheri, Wei Lu and Ali A. Ghorbani,
"A detailed analysis of the KDD CUP 99 data set", in Proceedings of
the Second IEEE international conference on Computational
intelligence for security and defense applications, pp. 53-58, Ottawa,
Ontario, Canada, 2009.
88. Zadeh, L.A., “Fuzzy sets”, Information and control, vol.8, pp. 338-
353, 1965.
89. Jiawei Han, Jian Pei, Yiwen Yin, Runying Mao, "Mining Frequent
Patterns without Candidate Generation: A Frequent-Pattern Tree
Approach", Data Mining and Knowledge Discovery, Vol: 8, No: 1,
pp: 53 - 87, 2004.

133
90. B.V. Dasarathy, “Intrusion Detection”, Information Fusion, Vol.4,
No.4, pp.243-245, 2003.
91. R.G.Bace, “Intrusion Detection”, Macmillan Technical Publishing,
Indianapolis, USA, 2000.
92. Marcos M. Campos, Boriana L. Milenova, “Creation and
Deployment of Data Mining-Based Intrusion Detection Systems in
Oracle Database lOg”, in Proceedings of the Fourth International
Conference on Machine Learning and Applications, 2005.

134