Attack Notification and Adaptation in Ad Hoc
Networks
by
Joshua R. Furman
Submitted to the Department of Electrical Engineering and Computer
Science
in partial fulfillment of the requirements for the degree of
Master of Engineering in Computer Science and Engineering
at the
MASSACHUSETTS INSTITUTE OF TECHNOLOGY
September 2002
@ Joshua R. Furman, MMII. All rights reserved.
The author hereby grants to MIT permission to reproduce and
distribute publicly paper and electronic copies of this thesis document
in whole or in part.
$, TECHNOLOUTE
JUL 3 0 2003
....
Author . .....
LIBRARIES
.....................
artment of Electrica
ngineering and Computer Science
August 22, 2002
Certified by
Dr. Clifford J. Weinstein
Group Leader, MIT Lincoln Laboratory
M.I.T. Thesis Supervisor
Certified by...
V
Dr. Bracha M. Epstein
Member, MIT Lincoln Laboratory
I.T<fhirs Supervisor
Accepted by..
............
Arthur C. Smith
Chairman, Department Committee on Graduate Students
ENG
2
Attack Notification and Adaptation in Ad Hoc Networks
by
Joshua R. Furman
Submitted to the Department of Electrical Engineering and Computer Science
on August 22, 2002, in partial fulfillment of the
requirements for the degree of
Master of Engineering in Computer Science and Engineering
Abstract
This project looks at additions to the ad hoc on-demand distance vector (AODV)
routing protocol that allow the network to adapt when a node has been compromised
or attacked. In the scenario we discuss, at least one node in the network has information that a specific node has been attacked. We designed and implemented three
schemes that perform attack notification and permanently exclude the compromised
node from the network using the OPNET simulator. One scheme relies on an outof-band communication mechanism while the other two use broadcasting protocols,
gossiping and self pruning, to perform the attack notification using the ad hoc network itself. The benefits of using the out-of-band mechanism versus the broadcasting
protocols depend on the specifications of the network and the environment in which
the network resides.
M.I.T. Thesis Supervisor: Dr. Clifford J. Weinstein
M.I.T. Thesis Supervisor: Dr. Bracha M. Epstein
3
Acknowledgments
I would like to thank:
Bracha Epstein for the guidance and advice she has provided both thesis related
and personal. Without her limitless patience and help this thesis would not have
been completed.
Clifford Weinstein for giving me the opportunity to work at Lincoln Laboratory.
His help and guidance were invaluable resources throughout the year.
Jerry O'Leary for providing the Matlab scripts in chapter 4 and for general advice
throughout the length of this project.
The members of Group 62 at Lincoln Laboratory for creating a truly stimulating
environment in which to work.
My friends at MIT, you know who you are, for simultaneously encouraging me to
keep on working while providing a supply of infinite distraction. To you I owe my
sanity.
My brothers Andrew and Benjamin, whose love and support I can always count
on.
Most of all, my parents, who have been a source of constant support and encouragement. All that I have achieved is due to their love (and occasional prodding).
4
Contents
1
2
3
4
11
Introduction
1.1
Ad Hoc Wireless Networks . . . . . . . . . . . . . . . . . . . . . . . .
11
1.2
A daptation
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
1.3
Attack Response
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
15
Literature Review
2.1
Ad Hoc Routing Algorithms . . . . . . . . . . . . . . . . . . . . . . .
15
2.2
A OD V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.3
Broadcasting Algorithms . . . . . . . . . . . . . . . . . . . . . . . . .
19
23
System Design
3.1
OPNET Implementation . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.2
Excluding the Compromised Node . . . . . . . . . . . . . . . . . . . .
26
3.3
Attack Dissemination . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.3.1
Out-of-band Notification . . . . . . . . . . . . . . . . . . . . .
28
3.3.2
Network Notification . . . . . . . . . . . . . . . . . . . . . . .
29
3.3.3
Gossip Algorithm . . . . . . . . . . . . . . . .-. . . . . . . . .
30
3.3.4
Self pruning Algorithm . . . . . . . . . . . . . . . . . . . . . .
33
Experimental Results and Discussion
35
4.1
Network behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.2
Out-of-Band Communication
. . . . . . . . . . . . . . . . . . . . . .
39
. . . . . . . . . . . . . . . . . . . . . . .
40
4.2.1
OPNET simulations
5
4.3
4.4
5
Broadcast Algorithms. . . . . . . . . . . . . . . . . . . . . . . . . . .
41
4.3.1
. . . . . . . . . . . . . . . . . . . . . . .
42
Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
OPNET Simulation.
Conclusion
47
5.1
Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
5.2
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
6
List of Figures
3-1
AODV node model provided by NIST . . . . . . . . . . . . . . . . . .
25
3-2
Psuedocode implementation of the gossip algorithm . . . . . . . . . .
32
3-3
Psuedocode implementation of the self prune algorithm . . . . . . . .
34
4-1
Change in node connectivity over time, 10 node network
. . . . . . .
37
4-2
Change in node connectivity over time, 9 node network . . . . . . . .
38
4-3
Varied probability for gossip protocol . . . . . . . . . . . . . . . . . .
44
7
8
List of Tables
4.1
Nodes transmitting and receiving in broadcast protocols
. . . . . . .
42
4.2
Time for algorithms to complete . . . . . . . . . . . . . . . . . . . . .
43
9
10
Chapter 1
Introduction
Wireless networks present a new framework for security and robustness as compared
to their wired counterparts. Considerations which may be negligible in a standard
wired network become paramount in a wireless network. Ad hoc wireless networks,
those with no centralized structure, present even more issues that must be addressed.
One such concern and the focus of this thesis is the compromise of a networked
computer or device by a malicious third party. In a traditional wired network such
a problem was viewed not as a network security issue but one of physical security.
Furthermore, in a wired network the damage can be isolated to a given device that
can be removed from the network. In a wireless environment, the network must adapt
on the fly to lessen the damage done by the seizure of a node. The goal of this thesis
is to look at three mechanisms that allow a network to adapt in the face of a captured
or compromised node.
1.1
Ad Hoc Wireless Networks
A mobile ad hoc network is defined by the IETF MANET
working group as "an
autonomous system of mobile routers (and associated hosts) connected by wireless
links-the union of which form an arbitrary graph."2
'MANET stands for "mobile ad hoc network."
2
http://www.ietf.org/html.charters/manet-charter.html
11
It has no set structure and
is completely decentralized.
These networks may be found in the military, emer-
gency/disaster relief, and at conferences or large gatherings; anywhere that an existing network infrastructure does not exist. The non-structured nature of ad hoc
networks, unlike conventional networks, forces each node to play a dual role. Due
to the lack of any hierarchical structure, each node functions both as a router and
as an end node in communications. Beyond their novel structure, ad hoc networks
often have extra constraints imposed on them. Specifically, these networks are usually
computationally and bandwidth limited and have constantly changing topologies. In
addition uses of the network may make these restrictions more acute. For example,
certain applications may demand extra security in terms of extra encryption and
therefore more limited bandwidth and computational resources. Other applications
may demand nodes that survive autonomously for a long periods of time and must
therefore conserve power by limiting computational overhead and broadcast range.
1.2
Adaptation
Mobile ad hoc wireless networks, by their nature, must be adaptive.
To remain
functional and to successfully transfer data between nodes, they must have the ability
to configure themselves on the fly, to adjust to the changing network topology, and
to maintain connectivity between any two points in the network. For example, any
functioning routing protocol in a mobile network must be able to quickly recompute
paths between nodes so that transfer of information is not interrupted. Furthermore,
each node must be able to do this in a decentralized manner without relying on a
fixed hierarchy of nodes through which information can be routed. In addition, any
overhead must be minimized given the limited bandwidth of most wireless devices.
Devising and implementing such adaptive protocols is currently an active area of
research. 3
Security concerns within ad hoc networks are different from those in traditional
3For example, as mentioned before, the IETF has a current working group on MANETs
http://www.ietf.org/html.charters/manet-charter.htm
12
networks. Since every node is potentially a router, the compromise of a single device
may have devastating effects on the functioning of the overall network. A malicious
node could break paths and disseminate false routing information. A compromised
node could direct all network traffic to itself or stall most communication from occurring. In a wireless environment, each device is not only susceptible to network
based attacks, but physical seizure of a device as well. Security in an ad hoc network
may refer to both preventing an attack as well as reacting once an attack occurs.
This thesis examines security from a reactive perspective. It examines how an ad
hoc network may adapt in the situation where a node has been captured or compromised. Members of an ad hoc network where security is a concern must therefore be
able to quickly adapt to known or perceived threats to avoid compromising the entire
network. Specifically, given that a node has been compromised or attacked, what
mechanisms does the network use to disseminate the relevant information to allow
the remaining nodes to adapt appropriately. Additionally, what is an appropriate
reaction?
1.3
Attack Response
Adapting to an attack depends on two main elements. In this thesis, we rely on
the accurate and specific knowledge of an attack on one or more nodes. Given that
knowledge, the network must disseminate information regarding the existence of an
attack in a timely fashion to all members of the network. After attack notification,
each node must process the new information in a way that will minimize the damage
done by the attack.
We discuss three protocols for attack notification. The first relies on an out-ofband communication mechanism such as a satellite or UAV. The final two use the
network itself to propagate the attack notification. We looked at two algorithms developed for broadcasting packets in ad hoc networks and modified them to accomplish
attack notification.
Each node, after receiving notice of an attack, must utilize that information. The
13
appropriate procedure in the scenario discussed here is to completely remove the
victim of the attack from the network. By doing so, the damage can be kept local to
the specific node while not allowing the attacker access to sensitive information (such
as routing or topology information and other sensitive data). This result may not be
useful when knowledge of an attack is not specific. In that case, the network may not
be able to determine which node to remove from the network. This scenario is not
discussed in this thesis and would necessitate a different adaptation.
The next chapter will discuss the core of ad hoc networks, namely the routing
algorithms, and will look specifically at AODV the algorithm that formed the basis
of the implementation. In addition, there is a discussion of the ad hoc broadcasting
algorithms that were used as a basis for developing the attack adaptation. Following
that, the remainder of this paper discusses the algorithms developed for adaptation
and how they were designed, implemented, and evaluated. In the end, we propose
some future areas we think are worth exploring.
14
Chapter 2
Literature Review
2.1
Ad Hoc Routing Algorithms
The goal of an ad hoc routing algorithm is to route information between any two
endpoints within a wireless, decentralized, mobile environment. These routing algorithms come in many flavors. Two main categories of algorithms are reactive and
proactive [3]. Reactive algorithms find paths within the network when needed. reactive protocols use a route discovery mechanism to find a path when one is needed
for a particular message. An example of a reactive algorithm is AODV [2], which
will be discussed in more detail in the next section. Proactive algorithms, on the
other hand, maintain a constant picture of the network at all times. A proactive
algorithm maps the entire network from the moment the network begins functioning
and continually updates the routing information as nodes move. An example of a
proactive algorithm is OLSR [1]. Reactive algorithms minimize extra overhead by
not maintaining unnecessary routes. This comes at the cost of extra data packet delay since route discovery must be initiated before a packet is sent. Some of this cost
may be mitigated by caching routes once they have been discovered, which they then
reuse the next time they are needed. Proactive algorithms have the tradeoff in the
other direction. A potentially large overhead cost is incurred as a result of keeping
all paths current through constant passing of routing messages between nodes. The
benefit is that message latency is reduced since the path to the destination is known
15
beforehand.
Similar to the Internet routing protocols, ad hoc routing protocols may be further
classified into distance vector and link state algorithms. Distance vector protocols
maintain routing tables that pair destinations with links and associated costs. For
example, in a typical routing table entry for the destination node A the entry would
also list the link (the next hop) on which to send a packet destined for A and the
cost of that path. Distance vector protocols rely on the Distributed Bellman-Ford
algorithm
[4]
to compute paths. Link state algorithms rely on each node having full
topology information. After that information is exchanged, Dijkstra's algorithm [4]
is run to find the shortest path between any two points. A more in depth treatment
of distance vector and link state protocols in the Internet can be found in [4].
Often, ad hoc routing protocols will use some combination of the different protocol
types.
These hybrid protocols will use different routing techniques in concert to
achieve maximum efficiency.
This can be compared to the previously mentioned
algorithms that use a uniform scheme for routing throughout the entire network.
A hybrid protocol such as ZRP [9] divides each node's view of the network into
routing zones. Within each zone, measured by the number of hops between nodes,
packets are routed proactively using an algorithm called IARP (Intrazone routing
protocol). Outside of a zone, routing is done reactively using an algorithm called
IERP (Interzone routing protocol). Finally some ad hoc routing algorithms impose
an artificial structure on the network. Protocols may impose a virtual hierarchy and
use that to route data.
Each ad hoc routing algorithm is optimized for particular constraints such as
mobility, bandwidth, and latency. In ad hoc routing, there is no silver bullet. The
appropriate algorithm for a particular scenario is dependent on the varying constraints
imposed by the environment and the system requirements.
16
2.2
AODV
In this project, the underlying algorithm chosen was the ad hoc on-demand distance
vector protocol or AODV [2].
It is a uniform, reactive, distance vector algorithm
developed by Elizabeth Royer and Charles Perkins. The choice to use AODV was
based on its availability as a model for the OPNET simulator as well as its adoption
as the algorithm of choice in related work at other institutions. Due to the reactive
and distance vector properties of AODV, it is suited to mobile environments that
are memory and bandwidth limited. Bandwidth and memory are conserved by not
maintaining routes that are unnecessary. Furthermore, the highly mobile nature of
the ad hoc networks envisioned for this project lend themselves to reactive protocols.
Higher mobility results in more frequent route updates in proactive protocols, many
of which would be wasted on paths that are never used.
In order to discover paths within the network, AODV utilizes three packet types.
" Route Request or RREQ packets are used to initiate route discovery. These
packets are sent to a node's neighbors to request information for an unknown
destination.
" Route Reply or RREP packets are sent as replies to an RREQ. When a node
has the information requested in a RREQ, it transmits an RREP response
containing path information to a particular destination. These packets are also
used to inform neighbors of a node's presence in the network in the form of
HELLO packets.
" Route Error or RERR packets are used to inform a node of a broken link.
When a previously known path that is no longer valid a node will reply with a
RERR packet to inform the source that it must initiate a new route discovery
procedure.
AODV maintains all routing knowledge in a routing table. Each known destination has a routing table entry. The basic elements of the routing table entry are the
17
destination address and the next hop on the path towards that destination. In addition, the routing table contains information to facilitate route maintenance. Each
table entry stores the length of time the route is expected to be valid. Each time a
route is used, the lifetime field is updated. Each entry also contains the destination
sequence number for the destination and the number of hops to the destination. In
AODV, each node maintains its own sequence number that it uses to mark all replies
to route requests when it is the desired destination. Any entry for a given destination
relies on the sequence number given by that destination. By doing so, reply packets
can be compared to one another and the most recent one is used. This sequence
number is incremented in order to avoid packets from looping and to indicate fresh
routes. A routing table entry is updated only when a received packet has a higher
sequence number, or if the sequence numbers are equal when the new packet has a
smaller hop count than the entry currently in the table. The entry also contains a
precursor list of nodes that may have been using the current node as a way-point to
the destination. This list is used to forward error messages in case a relevant link
breaks.
In order to fully understand how AODV works, it is best to look at a typical route
discovery procedure.
When a node, which we will call N, enters a network running AODV, it broadcasts
unsolicited RREPs as HELLO messages to all its neighbors. This procedure will add
an entry into the routing tables of all of N's neighbors listing N as a destination with
a next hop N and a hop count of 1. HELLO packets are continually broadcast at a
given interval. After one such interval, N will have entries in its routing table for its
neighbors, each with a next hop being the neighbor itself with a hop count of one.
If N decides to transmit a packet to destination D (and D is not a neighbor for
which it already has an entry in its routing table), N will initiate route discovery
by broadcasting an RREQ to all of its neighbors requesting a route to D. Every
neighbor with an entry in its routing table for D will return an RREP packet to N.
The RREP packet verifies it has a path to D, records the number of hops it takes
to get from it to D, and the sequence number it has for D. N will increment the
18
hop count by one and add that entry to the routing table with the next hop being
the source of the RREP packet. If multiple nodes respond with paths to D, they
will only be added to N's routing table if their sequence number is higher or the hop
count is less than the current entry. Every neighbor that does not have a path to D
rebroadcasts the RREQ packet to its neighbors. These recipients may have a path to
D or they themselves will rebroadcast the RREQ. Each time a node sends an RREQ,
it stores a copy of the request so that it knows to whom it must respond when a reply
is received. When a node that has a record of a path to D in its routing table receives
the RREQ, it returns an RREP to the most immediate sender who will update its
tables. This node in turn forwards the RREP back down the chain using the stored
information. This procedure repeats until the RREP has successfully reached N, the
originator of the request.
In order to transmit a data packet, N looks in its table for an entry to the desired
destination. The table entry contains the next hop to the destination and N sends
the packet to that node. If the topology has changed and the next hop no longer
has a valid entry for D, the next hop sends an RERR back to N thereby informing
it that it must re-initiate route discovery. This error procedure can occur anywhere
along the path where a break has occurred.
As nodes move around, links, and hence paths, are broken and created dynamically. AODV employs HELLO packets to allow nodes to announce their presence
to their neighbors. If after a given interval a HELLO message is not received, any
entries in the routing table that have the silent node as a next hop or destination are
purged.
2.3
Broadcasting Algorithms
The goal of an ad hoc broadcast algorithm is to efficiently broadcast information
to every member of a network.
In this thesis, broadcasting algorithms are used
to disseminate attack notification to nodes in the network. Broadcasting algorithms
complement the standard routing algorithms. Many routing algorithms may be made
19
more efficient by utilizing an efficient broadcast algorithm. For example, AODV
utilizes broadcasting to send RREQs for route discovery. Currently, the protocol
specifies a flooding protocol. By employing a more efficient broadcasting protocol,
the overall efficiency of AODV can be increased.
There are four main types of broadcast algorithms for ad hoc networks [8]:
" Flooding- every node that receives a packet broadcasts it to its neighbors.
* Probabilistic- each node that receives a broadcast packet rebroadcasts it with
probability p.(E.g. [5]).
" Area based- the decision to rebroadcast is made based upon knowledge of the
node's location in relation to the sender.
" Neighbor Knowledge- the decision to rebroadcast is based on limited knowledge of the surrounding topology. (E.g.,[7],[6]).
Each type of broadcast algorithm has certain benefits as well as costs. Flooding
is the simplest algorithm (if I haven't seen the packet before, I broadcast it), is the
least efficient, and results in the greatest number of transmissions. Probabilistic algorithms are more efficient, yet may not disseminate the information to the entire
network. Area based protocols rely on knowledge of surrounding nodes and transmissions ranges that could suffer in congested networks due to feedback mechanisms.
Neighbor knowledge protocols depend on knowledge of the network topology. In a
highly mobile environment, the topology knowledge may not be current enough to
be of use. Compensating for this deficiency by updating more frequently (i.e., by
decreasing the interval between HELLO messages) may incur a higher overhead than
flooding.
Williams and Camp [8] implemented members of each of the classes of algorithms
in an ad hoc network and compared the results. They tested the algorithms in three
categories and looked at the cost and benefit of each class in each category. The three
categories are:
e efficiency- minimizing the traffic sent to perform the broadcast.
20
* congestion- performance of the broadcast algorithm in a congested network.
" mobility- algorithm performance in a mobile environment.
Neighbor knowledge protocols were the overall best performer. Neighbor knowledge
protocols can be divided into two categories: those that rely on knowledge of a node's
immediate neighbors (1 hop away), such as self pruning in [6]; and those that utilize
more extensive knowledge of the surrounding network topology beyond immediate
neighbors (generally, up to 2 hops away) such as [7] and dominant pruning in [6].
These 2-hop neighbor knowledge protocols suffered in the mobility category because
maintaining up-to-date knowledge is difficult when the network topology changes
rapidly. In turn, it was 2-hop knowledge protocols that were the most efficient. The
worst case performance in terms of efficiency was flooding, since each node was used
to broadcast.
Looking at the results in [8], it is difficult to describe a broadcast algorithm as the
best or the most efficient. Each category has strengths and weaknesses depending on
the environment in which it is used. In this project, a probabilistic protocol and a 1hop neighbor knowledge protocol were used. The probabilistic protocol chosen was the
gossip protocol [5] by Li, Halpern and Haas. It was chosen because it does not depend
on knowledge of the network structure and for its simplicity. Since probabilistic
protocols have the possibility of not reaching every node in the network, a small
modification was made to overcome any related deficiencies. The neighbor knowledge
protocol chosen was self pruning [6] by Lim and Kim. Self pruning was chosen because
it does not require any information above what is provided by AODV (namely single
hop neighbor knowledge, accomplished through HELLO packets). Since it is a single
hop neighbor knowledge protocol, it suffers only minimally in a mobile network.
21
22
Chapter 3
System Design
As discussed previously, the goal of this thesis was to design and evaluate algorithms
for mobile ad hoc networks that maintain network functionality in the face of an
attack. We assume that information regarding the existence of an attack is known by
at least one node in the network aside from the victim. Furthermore, that knowledge
is assumed to be accurate and indicates a particular node that has been compromised
or attacked. For the purposes of this discussion, we consider two kinds of attacked
nodes: captured and compromised.
Ideally, when an attack occurs, the network
continues routing data while excluding the captured node from all communication.
Since the extent of the compromise may not be known, any information passing
from or through the victim node becomes suspect. Furthermore, even if the attacker
is not tampering with the packets flowing through the compromised device, it is
possible that the attacker compromised the host and is able to eavesdrop on sensitive
information. This is particularly urgent in tactical ad hoc networks where each node,
acting as a router, may receive topology information that discloses the location or
presence of other members of the network or other tactical information.
In order to exclude a node from the network, two main steps must occur. First,
each node in the network must learn of the attack. Second, they need to exclude the
compromised node from any future communication. In order to learn of an attack,
the originating or detecting node must be able to propagate that information to all
the other nodes in the network. After this information has been received, each node
23
must act in a way that will allow it to permanently purge the victim (attacked) device
from all future communications including both routing and data. Regardless of the
dissemination mechanism, each node reacts in the same manner once the information
has been received.
A description of the simulation design and implementation, which used the OPNET simulator, follows in the next section. 1 A detailed description of attack information is processing may be found in section 3.2. Finally, the chapter concludes with
a detailed look at the attack notification algorithms.
3.1
OPNET Implementation
The algorithms designed were based on the AODV ad hoc routing algorithm. In
OPNET, the internal representation of a device on the network is contained in a
node model.
Each component of the node model is in turn described by a state
diagram called a process model. The AODV node model used was provided by NIST
from their web site2
The AODV node model can be seen in Figure 3-1.
Each grey box represents
a different process model. In the NIST implementation, each level in Figure 3-1
represents a different layer in the protocol stack. At both the physical and data link
layers, a standard 802.11b wireless LAN was used the models for that were released
by OPNET in September 2000. Parameters such as the range of the transmitters are
variable at runtime. At the routing or network layer is the working implementation
of the AODV algorithm. All routing packets are received in the aodv-routing module
and decisions regarding how and when to forward data packets is made there as well.
Almost all of the changes made to the model were done at the routing layer. The
most important data structure contained in this layer is the routing table. The routing
table is implemented as a linked list of routing table entries. In the routing table,
entries are keyed on the destination. There is one entry for each known destination.
'Information on the simulator can be found at http://www.opnet.com
http://w3.antd.nist.gov/wctg/manet/prd.aodvfiles.html
2
24
Figure 3-1: AODV node model provided by NIST
For each destination address, the entry includes the next hop in the forwarding path,
the number of hops in that path, the length of time the entry is valid, and any other
information relevant to AODV (as discussed in section 2.2).
Above the routing layer is the application layer that is a basic packet generator.
Data packets originate from the application layer in the src module. Each new packet
generated has its destination randomly selected from all the nodes in the network.
The rate of data packet generation is determined randomly by an exponential pdf
whose mean interarrival time is input at runtime. When a data packet arrives at its
destination, it is passed up the protocol stack to the app-sink module and discarded.
There is no transport layer (such as TCP) and all communications consist of individual
packets sent between two nodes.
The NIST model also defines packet types for the standard AODV packets. Included are: data packets, RREQ packets, RREP packets and RERR packets. Each
packet type defines (except for RERR, which has no destination) a source, destination, and previous hop as well as any relevant fields needed for the specific action.
HELLO packets, used for notifying neighbors of a node's presence, are a type of
25
RREP packet. The rate at which HELLO packets are sent is a parameter variable
set at runtime.
Nodes in the simulator move with a billiard ball style mobility. They move in a
straight line until a boundary is reached. At that point, they randomly compute a
new direction and continue moving. The mobility model is contained in a module in
the node model (it is not shown in Figure 3-1). The speed and boundaries of each
node as well as mobility itself are parameters that can be set at runtime.
3.2
Excluding the Compromised Node
The end goal of adapting to an attack on the network is to exclude the attacked
node. The AODV protocol, like all ad hoc routing algorithms, must be able to adapt
to changing network topologies. In the AODV protocol, if a link is detected as broken
due to mobility or node failure, the destination that was connected by that link is
purged from the now out-of-date routing tables. If, in the future, a device needs to
communicate with the now entry-less destination, route discovery will be initiated. If
the desired destination has changed positions in the network but is still functioning,
route discovery will uncover a new path to that node. If, however, the missing device
has disappeared from the network completely, no new path will be discovered and
any communication between the initiator and the desired destination will not be
successful. When (and if) the node returns to the network, it will notify its neighbors
of its existence through HELLO packets and any future communications or route
discovery will proceed as usual. This adaptive mechanism is a necessary feature of a
mobile network, but it may not be used as is to remove a compromised node from the
network because the mechanism is unable to permanently exclude the compromised
node from the network.
In order to fully exclude a node as an attack scenario requires, more steps are
necessary. First, the attacked node must be permanently excluded from all routing
tables. This requires each node in the network to store the identifier of the attacked
node so that it cannot be reintegrated at a later time. Furthermore, every packet
26
going through the network must be checked to ensure that it did not originate, is not
destined for, and did not traverse the compromised node. This is true for both data
and routing packets since the reliability of both are questionable.
Specifically a new data structure was added to the aodv-routing module called
exclude-list. It is an array containing as many elements as there are nodes in the
network. When an attack packet is processed (the different attack packets and how
they are received are discussed in the next few sections), it contains the identifier of
the node (the node's address) that was the victim of the attack. In the exclude-list
structure, the array element at the index corresponding to the victim is set to true.
Upon receipt of all packets, the exclude-list is checked. If the packet (either routing
or data) contains a reference, whether source, destination, or next hop, to a node that
is set to true in the list, the packet is dropped.
The recipient of the attack packet must then purge all references to the victim
node from its routing table. The node first deletes the routing table entry for the
victim node (if one exists). It then iterates through the routing table entries and
purges any entries who use the victim as the next hop from the recipient. By doing
so, any communication with the purged nodes will initiate route discovery and a path
may be found that does not include the victim node.
3.3
Attack Dissemination
In order to disseminate information about an attack, one must first be detected. In
this thesis, the assumption is made that there is a reliable attack detection mechanism
in place. This may be external to the network, such as detection by sight, or it can be
a complex intrusion detection system running on the network. Regardless, it is the
job of whichever node first detects an attack to disseminate that information to the
remainder of the network as quickly as possible. Three methods have been developed
to relay this notification to all the nodes in the network. Each uses a new type of
packet called an attack packet that minimally contains the identifier of the victim
node. The first mechanism for attack notification relies on a secure, reliable, out-of27
band communication channel. This is a reasonable assumption since communication
systems are often composed of multi-layered architectures with multiple mechanisms
for relaying information. The other two algorithms relax that assumption and attempt
to propagate the attack packet through the network itself using different broadcast
algorithms.
3.3.1
Out-of-band Notification
In this scenario, a node detects an attack on one of its neighbors. It sends an attack
packet to the remainder of the network using the out-of-band communication channel.
The identifying node takes the attack packet and rebroadcasts it to all other nodes in
the network using the out-of-band communication mechanism. Dissemination in this
case is perfect and instantaneous. The delay provided by the external mechanism is
negligible and all nodes receive the attack notification simultaneously.
Two nodes were added to the OPNET simulation node model to incorporate the
out-of-band communication mechanism.
The source node simulates detecting an attack by generating an attack packet.
The sat-manager3 node handles incoming attack packets both from the detecting
node (those broadcast) and packets from the source (attacks that the node itself is
generating). When the source module detects an attack, a packet is generated and is
immediately handed to the sat-manager,which retransmits it to all the other nodes.
In order to simulate a perfect out-of-band mechanism, no physical or link layer were
used. Rather, an OPNET function was called that transfers packets between different
nodes in a network. This function delivers the attack packet to the sat-manager
module of each node in the network. Upon receipt, the packet is handed off to the
upper layer through an association in the node model. The packet is received by the
aodv-routing node and the packet is processed.
The identity of the attacked device is set as a variable when the simulation is
run. If multiple nodes be attacked, each attack will be detected by a different node
3
The term sat-nanager is based on the original assumption that the out-of-band mechanism
would be a satellite
28
(each node can only detect one attack). The source generates attack packets using
an exponential distribution. In order to guarantee that the packet is generated in a
timely fashion, the start and end time for the generator were set close to each other.
The time for an attack is also set at runtime.
In order to receive packets from the out-of-band mechanism, a new transition
was created between the sat-manager module and the aodv-routing module from the
original AODV model. When a packet is received by the sat-manager,it triggers the
Rcv Upcoming state in the internal process model. This state is triggered whenever
a packet arrives from a lower layer and performs the appropriate routing functions.
A new handler was added to the state that correctly processes the attack packet.
Specifically, the attack packet is read, the routing table is updated, and the attacked
node is added to the exclude-list structure.
3.3.2
Network Notification
The two mechanisms for disseminating attack information within the network use
wireless broadcasting algorithms. The two algorithms used are the gossip algorithm,
a probabilistic algorithm developed by Li, Haas and Halpern [5] and self pruning, a
network knowledge protocol developed by Lim and Kim [6]. The choice of these two
algorithms was based on their performance over a blind flooding algorithm [8] and the
efficiency of broadcast algorithms in a mobile environment. Other algorithms exist
that may perform more efficiently in a stationary network. However, with a changing
network topology, the efficiency of the other algorithms decreases due to the lack of
availability of accurate topology information needed to make rebroadcasting decisions.
One concern that may arise with using the network itself for attack notification
is how the attacked node will handle the notification. It is possible that a malicious
attacker could modify the attacked node and not forward the attack packets. In this
project, we assumed that the compromised node would not attempt to compromise
the notification procedure.
Both broadcast algorithms share a common implementation in the AODV node
model. At runtime, the desired algorithm is set as a parameter. Common to both
29
algorithms is attack packet generation and node exclusion. The node exclusion process
is the same as in section 3.2. To generate attacks at a specified time, an interrupt
is scheduled at the beginning of the simulation that will call the packet generating
function. Similar to the out-of-band mechanism, each node can detect at most one
attack on a specified node. The time and identity are set when the simulation is run.
When an attack is generated, the detecting node first processes the information
itself. This includes excluding the victim node from its routing tables as well as
logging the source and sequence number of the packet. Nodes receiving the attack
packet log it as well. A linked list of source and sequence number pairs is used as
the log. The logging prevents a packet from being rebroadcast indefinitely. When a
packet is received that has been seen before, it is dropped.
Depending on the algorithm used, different fields have to be set within the packet.
The detecting node broadcasts the packet using the preselected algorithm. When
the packet is received by the neighbors of the detecting node, the packet is passed
off to the appropriate handler. Rebroadcasting decisions are made by the handler
functions.
Since the packet is transmitted through the network, it is sent through the existing
transmitters in the AODV model and received by the existing receivers. Like other
packets in the network, the physical and link layer used is the 802.11b wireless LAN.
When the attack packet is received, it is passed to the aodvrouting module and
triggers the Rcv_ Upcoming state. A new handler was added to the state to process the
attack packet and to direct it to the appropriate handler for rebroadcasting decisions.
3.3.3
Gossip Algorithm
The gossiping algorithm is a probabilistic algorithm. As compared to a blind flooding
broadcast where every node rebroadcasts a packet, the gossip algorithm only retransmits with a given probability. The protocol used here has 2 parts. The first is the
broadcasting protocol and the second is the neighbor notification protocol whereby
uninformed nodes can learn of an attack after the original algorithm has run. Neighbor notification is necessary since there is a chance that not all nodes will receive the
30
original broadcast.
The gossip protocol chooses to rebroadcast based on a specified probability. By
doing so, the number of attack packets sent is decreased and bandwidth is conserved
compared to blind flooding. In order to guarantee that the packet reaches all nodes in
the network, certain optimizations are included in the algorithm. These optimizations
are described in detail in
[5].
The gossiping protocol has four parameters:
* Pi = the probability that a packet will be rebroadcast given that the previous
hop had a degree (number of neighbors) greater than n
* P2 =
the probability that a packet will be rebroadcast given that previous hop
had a degree less than or equal to n
* k = number of initial hops in which the packet is rebroadcast with a probability
of 1
*
n = the threshold degree to choose between pi or P2
In order to guarantee that the attack packet is transmitted and does not die out,
the first k hops the packet takes will be rebroadcast with probability 1. During the
first k transmissions, each node who receives the packet checks that the packet has
not been received previously. If it has not, the packet is rebroadcast. Within the
packet, a counter is incremented so that the number of hops can be tracked.
Following the initial stage, a weighted coin is flipped when a non-duplicate packet
is received. The probability for retransmitting is based on the number of neighbors of
the sending node. This number is indicated by the parameter n. If the sending node
has less than a specified number of neighbors (less than a certain degree), a flag is set
in the packet and the recipients rebroadcast with a higher probability
P2.
Otherwise,
the packet is rebroadcast with the lower probability pl. A higher probability is used
for lower degree senders since there is a greater chance that none of the recipients
will rebroadcast and the broadcast will not reach all of the intended recipients. A
psuedocode implementation of the algorithm is given in Figure 3-2.
31
GOSSIP(pl,k,p2,n){
// A packet has been received (either as the originator or for
//
rebroadcasting)
if(packet.k <= k){
check-excluded-node(src,previousHop);
check-duplicate-packet(seqNum);
modify-state(;
- -packet.k;
rebroadcast-packet();
10
}
else if (flag == HI){
check-excluded-node(src,previousHop);
check-duplicate-packet(seqNum);
modify-stateo;
if ( num-neighbors() < n){
set-flag(LOW);
}
if ( flip-weighted-coin(p1) == TRUE){
rebroadcast-packet();
}
20
}
else if (flag == LOW){
check-excluded-node(src,previousHop);
check-duplicate-packet(seqNum);
modify-state(;
if ( num-neighbors() >=n){
set-flag(HI);
}
if ( flip-weighted-coin(p1)
== TRUE){
rebroadcast-packet();
}
}
else{
check-excluded-node(src,previousHop);
check-duplicate-packet(seqNum);
modify-state(;
}
}
Figure 3-2: Psuedocode implementation of the gossip algorithm
32
30
Packet format
In order for the protocol to function properly, little additional information is required
within the transmitted packets. The packet has an integer k that corresponds to the
number of hops until pi is used. A flag integer that indicates whether the packet is
transmitted from a node with degree less or greater than n is needed as well. The
flag will also be used to indicate that the origin of the packet is neighbor notification
and therefore should not be rebroadcast.
Notify neighbor
Since the gossip algorithm is probabilistic, there is a chance that some nodes may
not receive an attack packet. The notify neighbor protocol exists to inform otherwise
uninformed nodes of an attack. If a node receives a packet whose source, destination,
or previous hop is an excluded node, the packet is dropped. This is an indication
that the sender of the dropped packet has not been informed of the existence of the
attack and therefore the recipient node initiates the neighbor notification protocol.
The recipient node broadcasts an attack notification packet with the flag
=
NOTIFY. All the neighbors will receive the broadcast and update their state accordingly (including the node who sent the initial message). The attack packet is
not rebroadcast. This is based on the assumption that the gossip protocol ran and
most nodes already received notification of the attack as well as the desire to minimize extra bandwidth usage. In the current models, neighbor notification was not
implemented.
3.3.4
Self pruning Algorithm
Self-pruning is a neighbor knowledge broadcast protocol which means that decisions
to rebroadcast are based on localized knowledge of the network topology. Nodes only
rebroadcast messages when the broadcast will cover more nodes than the previous
broadcast. This is done by calculating whether the neighbors of the recipient are a
subset of the recipient's neighbors. If so, the message is not resent.
33
SelLPruning{
modify-state(;
if(check-duplicate-packet()){
return;
}
log-packet(;
if (source == me){
broadcast-packet();
10
}
if( my-neighbors() - packet.neighbors - packet.src
set-packet-neighbors(my-neighbors());
broadcast-packet();
=){
}
}
Figure 3-3: Psuedocode implementation of the self prune algorithm
Specifically, let i-sender,
j=
recipient, and N(x)= neighbors of x. When a node
receives an attack packet, it calculates N(j) - N(i) - {i}. If it is not equal to the
empty set, then node
j
rebroadcasts the attack packet. A psuedocode implementation
of the protocol is given in Figure 3-3.
Packet Format
Each broadcast packet contains a list of the sender's neighbors and the number of
neighbors contained in the list. This is used with the list of the node's own neighbors
(contained in the routing table and generated by the HELLO messages) to calculate
if an attack packet needs to be rebroadcasted.
The following chapter looks at the results of running all three adaptation algorithms individually and compares their performance.
34
Chapter 4
Experimental Results and
Discussion
After designing and implementing all three of the mechanisms for attack notification,
we need a way to evaluate the systems independently and a method for comparing
them. We gain understanding of how the algorithms would run in "real world" situations by looking at their performance in simulation. This chapter looks at the results
of some simulations and begins the comparison of the three mechanisms. Further
simulations and evaluation are a work in progress that will continue beyond the completion of this thesis. Each of the attack scenarios was run in various configurations
in OPNET in order to gauge its performance. There were two main focuses of the
simulations. The first focus was to look at network performance after an attack has
been detected and all the nodes have received notification and reacted. We wanted
to determine how the network performed as a result of having one or more nodes
permanently excluded. Second, we focused on the dynamics of the attack notification
mechanism itself. It is important to determine how network performance is effected
during the notification process and how the protocols behave under various network
conditions.
35
4.1
Network behavior
One way to understand the effect of adapting to an attack is to see what the network
looks like before and after the attack (ignoring the notification process itself). Figures
4-1 and 4-2 were generated using Matlab scripts.' These scripts simulated a mobile
network. The nodes moved with a billiard ball type of mobility at 1 m/s. Given a 250
meter transmitter range, the number of connections between the nodes over time was
calculated. Nodes that are connected form clusters that are indicated in the figures
as nets. The graphs also list the number of nodes that are isolated or not connected
to any other node (indicated by the isolated terminals). Finally, the graphs show the
longest path within the entire network. In these simulations, we looked in a network
of 10 nodes and a network of 9 nodes (one node has been excluded). The dimensions
of the simulated network were 600 x 600 meters. The duration of the simulation was
4000 s.
Ideally, a network should never partition itself and the number of nets should
always be one. In sparsely populated mobile networks, this is often not the case.
We see in Figure 4-2 that the average number of partitions within the network is
greater than the number of partitions in Figure 4-1. When a node is removed from
the network, the chance of network partitioning increases. Communication becomes
limited when a network becomes partitioned and nodes become unable to send packets
to members of other partitions. Since an ad hoc network has no backbone or other
infrastructure, the density of nodes at any given time coupled with the range of radio
transmitters are the key factors in determining how well connected the network will
be. As nodes are removed from the network and the geographical area and radio range
are kept constant, the network becomes more susceptible to division. In the scenario
we are describing in this thesis, the end result of attack notification is the permanent
removal of a node from the network. In a sparsely populated network similar to the
one depicted in Figure 4-1, removing a node can adversely effect network performance.
'These scripts were written by Gerald O'Leary for use in a related project.
generated these plots for presentation to CECOM on July 17, 2002.
36
Bracha Epstein
Net Statistics15-Jul-2002 19:16:35
MaxPath
N
Nets
Isolated Terminals
5
4
0
1
0
500
1000
1500
2000
Time(sec)
2500
3000
3500
Figure 4-1: Change in node connectivity over time, 10 node network
37
4000
I
Net Statisticsi 5-Jul-2002 19:06:23
MaxPath
-
Nets
Isolated Terminals
U)
C
0
0
3
-l
2
1
0
C
500
1000
1500
2000
Time(sec)
2500
3000
3500
Figure 4-2: Change in node connectivity over time, 9 node network
38
4000
In certain instances, where the attacked node has a large chance of doing harm to
the remainder of the network, the benefit of removing a node may outweigh the cost
of loss of connectivity. In other situations, where the node may be compromised
but poses no danger to the network nor exposes any sensitive information, the cost
of removing the node may be greater than the benefit of removing the node. In
all cases, the possible loss of connectivity must be weighed against the benefits of
removing potentially malicious nodes from the network. The effects of node removal
in more densely populated networks is a topic that should be explored further.
4.2
Out-of-Band Communication
The out-of-band communication mechanism disseminates attack information by utilizing an external channel outside of the network. In simulation, the delivery procedure is instantaneous and perfect. The implemented delivery mechanism for the
attack packets does not utilize a link or data layer to transport the attack packets. Instead, it immediately transfers a copy of the attack packet to all the receiving nodes
using a built in OPNET function. The motivation for this implementation is the
assumption that the out-of-band mechanism would be instantaneous, secure and perfect. In simulation, the network may therefore be in two distinct states: the network
before the attack notification and the network after the notification. The transition
period is not significant due to the instantaneous nature of the notification scheme.
In a real implementation, this assumption would not hold since any system would
have limited bandwidth and latency. Nevertheless, relying on this assumption allows
us to view network will behavior after attack notification has occurred. The following
sections are a preliminary discussion of various experiments run using the out-ofband OPNET simulation model. The experiments are still a work in progress, yet we
can still see general trends that show some of the salient features of the out-of-band
communication mechanism.
39
4.2.1
OPNET simulations
The measurements taken in the OPNET simulation counted both the number of
messages sent as well as the number of transmissions. A message is defined as an
end to end communication between a source and a destination (if A sends a message
to B that traverses 5 hops it is counted as one message).
Messages were divided
into two categories: good messages - those that reached their intended recipient,
and bad messages- those that failed to reach their destination. A transmission is
the sending of data between two adjacent nodes (a message that traverses through
4 nodes between the source and destination uses 5 transmissions).
Transmissions
are divided into three categories: data transmission- a transmission used to send a
data packet, routing transmission- one used to send routing packets, and successful
data transmission - a subset of all the data transmission in which the transmission
ultimately resulted in a good message.
The size of the network used in the simulation was 163 x 163 meters. The base
transmission range of the radios was 50 meters. The speed of the nodes was 5 meters
per 30 second interval (about .17 m/s) moving in a billiard ball fashion. The data rate
for each node averaged 5 packets/sec. The destination for each packet was randomly
chosen over all possible destinations.
The simulations were run for 15 minutes. The first attack was generated after 10
seconds. Subsequent attacks were generated at 30 second intervals.
Ten and twenty node networks were simulated, each with 0 through 5 attacks.
From preliminary experiments, we saw the progressive effects of increased attacks
on overall network performance. As the number of attacks increased, 'the message
success rate dropped regardless of the size of the network (in the larger network the
decrease was less pronounced). As nodes were removed from the network, the number
of available paths between two end points decreases and the chance for partition
increases. Many messages and transmissions failed because messages were unable to
arrive at their intended destinations.
The percentage of routing transmissions over all transmissions remained fairly
40
constant.
As nodes were excluded, the data and routing traffic they contributed
disappeared keeping the percentages of overall traffic constant. Due to the reactive
nature of AODV, node removal did not cause a spike in routing traffic. When a node
was removed and some paths broken, the routes were not regenerated until they were
needed.
The trends shown so far in the experiments give insight into the workings of the
AODV protocol under adverse conditions. While the attack notification itself has
no impact on the functioning of the network, the results of those attacks do effect
performance. Since the communication of the attack and the resultant adaptation
occur instantaneously, the impact of excluding a node is negligible compared to the
other factors effecting a mobile ad hoc network. The most significant result of attack
notification is a decrease in network size, and therefore (as we saw in section 4.1)
a greater chance of partitioning. The reactive nature of AODV masks the impact
removal of a node from the network has on routing information since no new paths are
automatically discovered. Additional overhead in terms of routing will only become
evident when an attempt is made to send data through a now broken path. Since the
node has been permanently excluded no attempts will be made to send data directly
to the excluded node.
4.3
Broadcast Algorithms
Unlike the out-of-band mechanism, broadcast notification is not instantaneous nor is
it necessarily perfect. We therefore focused on the performance of the broadcasting
protocols as they executed. A comparison was done comparing flooding, gossiping,
and self pruning. The simulation recorded two main statistics: the number of nodes
receiving the attack packet, which evaluated the success of the particular algorithm,
and the number of nodes rebroadcasting the attack packet, which determined efficiency of the algorithm. In addition, the time it took to run each algorithm was also
recorded.
41
J
(%)JJ| Nodes rx
10 nod e network Nodes tx Nodes tx
Floodi ig
9
90
Gossip
8
80
Self pr une
8
80
20 nod e network Nodes tx Nodes tx (%)
Floodi ng
20
100
14
70
Gossip
Self pr ne
17
85
50 nod e network Nodes tx I Nodes tx (%)
Floodi ng
50
100
40
80
Gossip
'I
Self pr une
50
100
9
10
10
Nodes rx
20
Nodes rx (%)
90
100
100
Nodes rx (%)I
100
20
100
20
100
Nodes rx [Nodes rx (%)
50
100
100
50
'
100
50
Table 4.1: Nodes transmitting and receiving in broadcast protocols
4.3.1
OPNET Simulation
Simulation parameters
The simulations evaluated networks with 10, 20 and 50 nodes. The size of the network
was 1000 x 1000 meters. The range for each radio transmitter was 200 meters. Each
simulation was run for 20 seconds.
The notification occurred after 15 seconds of
simulation time. The additional 5 seconds was sufficient time for the attack packet
to propagate and the network to reach a steady state. The following tables represent
one run of the simulator for each size network running each protocol (for a total of 9
runs).
Simulation results
The data in Table 4.1 shows the results of running flooding, gossiping and self pruning
in networks of three different sizes. In these initial tests, mobility was disabled in order
to understand how each protocol behaves in an ideal environment.
The flooding
protocol was simulated by running the gossip implementation with the probability
parameters pi and
set to .75 and
P2
P2
set to 1.
was set to .9.
For the gossip protocol runs themselves, pi was
Recall that
42
P2
is the probability used when the
Flooding
Gossiping
Self prune
10 node network
.003708
.003758
.003077
20 node network [50 node network
.004820
.014030
.006657
.008190
.014757
.007447
Table 4.2: Time for algorithms to complete
number of neighbors of the sending node was less than a certain threshold n. In
this case, n was set to 3 and k (the number of guaranteed transmissions after the
initial broadcast) was set to 1. In a later set of simulations, pi was varied in order
to look at how the rebroadcasting probability effects performance.
Furthermore,
neighbor notification was not implemented and was not used in testing the gossip
protocol. Neighbor notification may increase the overall reliability of the broadcast
as the network continues to run. However, its effects are spread throughout time and
do not effect the performance of the gossiping algorithm itself.
In all experiments (except flooding in a 10 node network where one node did not
receive or retransmit the attack packet, which appears to be an anomaly) each node
successfully received the attack packet. In terms of efficiency, flooding was the worst
with 100% of the nodes rebroadcasting the attack packet in both the 20 and 50 node
networks. Gossiping either matched or out-performed self pruning in all the networks.
Table 4.2 indicates how long each network takes to reach a steady state after the
initial notification. We see that overall the algorithms ran quickly. More experiments
are needed to determine the exact relationship between running time and each particular algorithm. It appears that running time of the algorithm is due to how many
nodes rebroadcast as well as computational overhead needed to run each particular
algorithm. Self pruning in the 50 node network takes the longest due to the larger
number of nodes that rebroadcast as well as the increased complexity of the algorithm. Similarly, in both the 20 and 50 node networks, self pruning takes longer
than gossiping due to its additional algorithmic complexity. In the 10 node network,
the running time is about equal for all three protocols due to the small size of the
network.
43
Varied Probability in Gossip Protocol
Nodes tx
.-
0.9
Nodes rx
-
-\
0.8 0.7 0.6 0/
E 0.5 -
0.4 0.3 0.2-
0.1 -
0
0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5 0.55 0.6 0.65 0.7 0.75 0.8 0.85 0.9 0.95 1
Rebroadcast probability (p1)
Figure 4-3: Varied probability for gossip protocol
Experiments similar to those in tables 4.1 and 4.2 were run with mobility enabled.
Nodes were set to move 5 meters every 30 seconds, about .17 m/s. The results were
identical to those of the stationary nodes.
More experiments need to be run to
examine the effects of greater node velocity on the performance of the algorithms.
In theory, since both gossiping and flooding do not rely on any network topology
information they should be unaffected. Self pruning, a neighbor knowledge protocol,
relies on up-to-date information about a node's neighbors. As a result it may lose
efficiency as the nodes move faster.
44
Varied probabilities in gossiping
The graph in figure 4-3 shows the effects of changing pi in the gossip protocol. The
graph was generated by running 50 node networks with pi varied from 0 to 1.0 by
.05 increments. Each run was repeated 5 times and the results were averaged. The
number of nodes rebroadcasting does not match the probabilities exactly (i.e., a
probability of .5 does not mean only 50% of the nodes rebroadcast) due to extra
optimizations in the algorithm. That is,
P2,
n, and k effect the number of nodes
that rebroadcast. The ideal operating point for the gossip protocol would be where
reliability (receipt of the attack packet) is at 100% while the number of nodes rebroadcasting is at a minimum. In these experiments, that point occurred at pi
In [5], the authors show the ideal probability to be pi
and pi
=
.6 in a scheme where
P2
=
=
.72 in a scheme with no
.9.
P2
is used when the neighbors drop below a certain
threshold. the disparity in results may be the result of too few runs of our gossiping
protocol. Furthermore, in each of the five runs, the topology remained the same and
any effects that particular topology had on the network could have carried over to
each run. Further experiments should be run that modify the network topology in
each separate run.
4.4
Comparison
The results evaluated for both the out-of-band mechanism and the broadcast protocols cannot be compared side by side. In the out-of-band simulations, the results
indicated the state of the network before and after an attack. These properties are
probably true for the broadcast algorithms before notification and after they have
reached a steady state. From the simulations, it would appear that the out-of-band
scheme is the ideal notification mechanism for attack information, since notification
is perfect and instantaneous. Any residual effects of removing a node from the network will be experienced regardless of how attack notification is accomplished. The
comparative worth of each of the protocols is more apparent when looked at in a
"real-world" implementation and not in simulation. The existence of an out-of-band
45
mechanism is largely dependent on the environment in which the network operates.
If the infrastructure exists to support an out-of-band system such as a UAV or satellite then it may be the most efficient way to disseminate routing information. Any
increase in efficiency and reliability over the broadcasting protocols is dependent on
the specifications of the particular out-of-band scheme used such as bandwidth and
latency. If, however, the network is run where such a system is unavailable, then the
only choice is to disseminate the attack information through the network itself using
a broadcast protocol.
46
Chapter 5
Conclusion
5.1
Future work
This project developed and began to evaluate mechanisms for attack notification.
Using the models as they have been developed, experiments could be run that look
at the network in particular scenarios. For example:
* Different traffic patterns. Rather than using the connection-less scheme where
each communication is one packet, a scheme looking at more TCP-like traffic
where a conversation of multiple packets occurs between a pair of nodes should
be evaluated. Interesting results would look at the effects of node exclusion as
well as the effects of running a broadcast during a conversation between nodes.
" Different topologies. In each of the experiments in this project, the nodes in
the network were randomly distributed on a grid of a given size. Future work
could look at topologies that contained bottlenecks to evaluate how the topology
effects performance.
* Mobility. The effects of mobility have already been evaluated for the out-of-band
scenario.1 The effects of mobility on the broadcast protocols would similarly be
useful in assessing their performance.
'Work done by Bracha Epstein
47
* Imperfect dissemination. In the current system we assume that all nodes have
been informed of the attack. When this assumption is relaxed and not all nodes
have been notified, some traffic may be compromised. One solution was proposed, that of neighbor notification, for the gossip protocol. In some instances
not all nodes will be informed of the attack, it may be useful to extend neighbor
notification to all the protocols.
* Attack spoofing.
One of the underlying assumptions in this project is that
attack notification is reliable. However, if a node is compromised by a sophisticated attacker, it may be able to generate false attack information. In such a
situation, the network would need to have reliable information before it decides
to exclude a node. One idea is to use an election scheme whereby a node is not
excluded until a critical number of attack packets are originated by multiple
sources.
" Attack recovery. If a node was falsely excluded or was recaptured the network
may want to re-incorporate it. Such a scheme could use a modified attack packet
that lists nodes to include rather than exclude. The dissemination mechanism
could be either broadcasting or out-of-band.
" Additional attack notification schemes. In addition to the three mechanisms
proposed in this thesis, there are other ways of disseminating attack notification.
One such example is to use an ad hoc multicast protocol.
Certain ad hoc
routing protocols, such as AODV, were developed with multicast capabilities.
Such protocols are probably more resource intensive but may add reliability not
available in the broadcast protocols.
5.2
Conclusion
This thesis looked at node exclusion in ad hoc networks when one or more nodes were
compromised by outside intruders. Using the AODV routing protocol as its base, two
types of mechanisms were implemented and evaluated using the OPNET simulator.
48
The first mechanism relies on a reliable and secure out-of-band communication system
to relay information about a compromised node. In the absence of such a mechanism,
two protocols were designed that allow the network to propagate attack notification
within the he network itself using broadcast protocols. The two protocols used were:
gossiping, a probabilistic algorithm, and self pruning, a neighbor knowledge protocol.
Each system has its own strengths and weaknesses which are dependent on the overall
environment in which the network is run.
49
50
References
[1] T. Clausen et al. Optimized link state routing. Internet-Draft Version 7, IETF,
July 2002.
[2] Santanu Das, Charles E. Perkins, and Elizabeth M. Royer. Ad hoc on demand
distance vector (AODV) routing. Internet-Draft Version 4, IETF, October 1999.
[3] Bracha Epstein. Algorithms for ad hoc routing. Technical report, in preperation,
Lincoln Laboratory, 2002.
[4] Christin Huitema. Routing In the Internet. Prentice-Hall, Inc., second edition,
2000.
[5] L. Li, J. Halpern, and Z. Haas. Gossip-based ad hoc routing.
[6] H. Lim and C. Kim. Flooding in wireless ad hoc networks. In Computer Communications, volume 24, pages 353-363, 2001.
[7] J. Sucec and I. Marsic. An efficient distributed network-wide broadcast algorithm
for mobile ad hoc networks.
[8] B. Williams and T. Camp. Comparison of broadcasting techniques for mobile ad
hoc networks. In Proceedings of the ACM InternationalSymposium on Mobile Ad
Hoc Networking and Computing (MOBIHOC), pages 194-205, 2002.
[9] Marc Pearlman Zygmunt Haas and Prince Samar. The zone routing protocol
(ZRP) for ad hoc networks. Internet-Draft Version 4, IETF, July 2002.
51