EVALUATION OF SECURE ROUTING PROTOCOLS AND INTRUSION
DETECTION MECHANISMS IN AD-HOC NETWORKS
Dana L. Hickey and Avdhoot K. Saple
Department of Computer Science and Software Engineering
Auburn University
Auburn
AL 36845
[email protected]
[email protected]
Keywords: ad hoc, secure routing, intrusion
detection
ABSTRACT
Unlike wired networks which have a higher
level of security for gateways and routers, AdHoc networks have characteristics such as
dynamically changing topology, lack of clear
lines of defense, the absence of centralized
administration, and high dependence on
inherent node cooperation. As the topology
keeps changing, these networks do not have a
well-defined boundary, and thus, network-based
access control mechanisms such as firewalls are
not directly applicable. It is extremely easy for a
malicious node to bring down the whole
network. As a result, ad hoc networks are
vulnerable to various attacks including
eavesdropping, spoofing, modification of
packets and distributed denial-of-service
(DDoS) attacks. The vast difference between the
two networks makes it extremely difficult to
apply intrusion detection techniques and secure
routing protocols developed for a fixed wired
network to an ad-hoc wireless network.
Furthermore, there may not be a clear separation
between normalcy and anomaly in wireless adhoc networks. A node that sends out false
information could be the one that has been
compromised, or merely the one that is
temporarily out of sync due to volatile physical
movement. Intrusion detection may find it
increasingly difficult to distinguish false alarms
from real intrusions. Intrusion detection systems
for wireless Ad-Hoc should be distributed and
cooperative to suit their needs, they should be
able to detect anomaly based on partial data
sources and finally they must have a good
model of activities in a wireless communication
environment that can separate anomaly from
normalcy. The research paper will basically
comprise of examination of different secure
routing protocols, intrusion and anomaly
detection mechanisms, and architectures that
suit the features of Ad-hoc networks and will
provide a comparative analysis based on certain
parameters.
INTRODUCTION
Wireless and ad hoc networks have been in
focus recently within the wireless research
community. Essentially, these are networks that
do not have an underlying fixed infrastructure.
They consist of a collection of autonomous
nodes that form a dynamic purpose-specific
multihop radio network in a decentralized
fashion. The quintessential nature of such
networks is the conspicuous absence of a fixed
support infrastructure such as mobile switching,
base stations, access points, and other
centralized machinery seen in traditional
wireless networks. With the network topology
changing dynamically and the lack of a
centralized network management functionality,
there networks tend to be vulnerable to a
number of attacks
centralized authority means that the adversaries
can exploit this vulnerability for new types of
attacks designed to break the cooperative
algorithms
To further complicate the problem there
hasn’t been a real push to standardize a routing
protocol. There are a couple of reasons for this.
Probably the biggest reason, as mentioned
earlier, is ad hoc network applications in the
military environment. For the most part any
standardized routing protocol used for military
applications will be kept secret as long as
possible. However, We do believe there is still
room for great growth in this aspect of wireless
routing.
Wireless ad hoc networks find application in
military applications so that planes, tanks and
moving personnel can communicate. Rescue
missions and emergency situations can also find
use for such networks. Other examples include
virtual classrooms and conferences wherein
people can set up a network through their
laptops, PDA’s and other mobile devices,
assuming they share the same physical medium
Ad-hoc routing presents vulnerability. Most
ad-hoc routing protocols are also cooperative in
nature. Unlike with a wired network, where
extra protection can be placed on routers and
gateways, and adversary who hijacks an ad-hoc
node could paralyze the entire wireless network
by disseminating false routing information.
Worse, such false routing information could
result in messages from all nodes being fed to
the compromised node.
The nature of the wireless ad-hoc networks
makes them very vulnerable to an adversary’s
malicious attacks. Firstly, the use of wireless
links renders a wireless ad-hoc network
susceptible to attacks ranging from passive
eavesdropping to active interfering. Unlike
wired networks where an adversary must gain
physical access to the network wires or pass
through several lines of defense at firewalls and
gateways, attacks on a wireless ad-hoc network
can come from all directions and target at any
node. Damages can include leaking secret
information, message contamination, and node
impersonation. All these mean that a wireless
ad-hoc network will not have a clear line of
defense, and every node must be prepared for
encounters with an adversary directly or
indirectly.
Most routing protocols as mentioned above
are cooperative and as such neglect security
concerns when routing packets. The majority of
protocols neglect the fact that a major
application area is military endeavors which are
inherently insecure. That being said it is
important to strive for new routing protocols
that incorporate the need for secure routing. We
will look at some ad hoc routing protocols that
attempt to incorporate security into their routing
decisions and evaluate their performance in
doing so. Each protocol’s performance will be
evaluated on the basis of speed/efficiency and
strength of security offered by the protocol.
Secondly, the decision-making in ad-hoc
networks is usually decentralized and many adhoc network algorithms rely on the cooperative
participation of all nodes. The lack of
2
Intrusion prevention measures, such as
encryption and authentication, can be used in
ad-hoc networks to reduce intrusions, but cannot
eliminate them. For example, encryption and
authentication
cannot
defend
against
compromised mobile nodes, which carry private
keys. Integrity validation being redundant
information (from different nodes), such as
those being used in secure routing, also relies on
the trustworthiness of other nodes, which could
likewise be a weak link for sophisticated
attacks.
destruction to a MANET. Realizing that most
MANET routing protocols never consider
security when making routing decisions, the
creators of SAR implemented a set of security
metrics that could be incorporated into any
MANET routing protocol to ensure a secure
path to any destination node [Yi, Naldurg, and
Kravets 2001]. That being said SAR was
simulated by modifying AODV with the
security metrics. The resulting algorithm will
be referred to as SAODV [Yi, Naldurg, and
Kravets 2001].
In summary, a wireless ad-hoc network has
inherent vulnerabilities that are not preventable.
To build a highly secure wireless ad-hoc
network, we need to deploy secure routing
protocols with intrusion detection and response
techniques. Moreover, an effective secure
routing protocol combined with an intrusion
detection system (IDS) can serve as a deterrent,
acting to prevent intrusions and route packets
securely. Intrusion detection enables the
collection of information about intrusion
techniques to strengthen the intrusion
prevention facility.
We present the fundamentals of intrusion
detection with the classification of these
systems. We then look at the requirements and
characteristics of IDSs in the ad-hoc
environment. We then make a comparative
analysis of the different intrusion detection
schemes.
Battlefield scenario that motivated SAR
Most battlefield environments offer an
inherent internal security hierarchy through each
soldier/officers rank, and this is what SAR bases
its security metrics on [Yi, Naldurg, and Kravets
2001]. For the most part this can be applied
across the board as most organizations offer the
same sort of security hierarchy (CEO, Manager,
and Employee). Back to the battlefield, the
problem we encounter is the need for two
generals to communicate. Normally this would
not be a problem using AODV. However we
suspect that some privates have defected and we
don’t know which ones. This being the case we
can no longer securely route packets through the
SECURITY-AWARE ROUTING
The motivation behind the creation of SAR
(Security Aware Routing Protocol) was the need
to have a secure routing protocol in battlefield
type situations. In such situations malicious
actions are commonplace and must be readily
protected against. As previously discussed, a
corrupted/captured node can cause severe
3
privates. What SAODV attempts to do is find a
path, which is not necessarily the shortest path
but is most definitely the shortest secure path
according to our security needs at the moment.
The way this is accomplished is to take into
account the security rank (based on the rank of
soldier/officer in possession of node) of each
node when routing packets.
Using this
approach SAR is able to route packets around
the possibly defected privates and allow
communication between the two generals
through a secure path. If there is no possible
secure path, no path will be found.
not possess the required security clearance the
packet is dropped [Yi, Naldurg, and Kravets
2001]. If a node is able to forward the packet a
field called RQ_SEC_GUARANTEE is updated
to specify the maximum level of security the
path can offer. To avoid compromised or
captured nodes from performing malicious acts
on these packets, packet header encryption is
employed with each security level maintaining
its own encryption key. If the destination is
reached, it returns a RREP packet normally as in
AODV with the exception that the
RQ_SEC_GUARANTEE from the received
RREQ
packet
is
copied
into
the
RP_SEC_GUARANTEE of the RREP packet.
Upon arriving at intermediate nodes on the
reverse path, each node, with proper security
clearance will update its routing table and
record the new RP_SEC_GUARANTEE value
[Yi, Naldurg, and Kravets 2001].
As mention early, the base protocol behind
SAODV is AODV. SAODV behaves normally
like AODV with the exception that the security
metrics are embedded into the RREQ and RREP
packets [Yi, Naldurg, and Kravets 2001].
Nodes along the path to the destination node are
forced to drop RREQ packets that they do not
have the security clearance to forward. If and
once a path is found meeting the required
security level, a RREP packet is returned down
the reverse path just like in AODV. The
difference here though is that this RREP packet
is returned with the guaranteed security level in
the packet header [Yi, Naldurg, and Kravets
2001]. This premise is based on the assumption
that nodes cannot change their security level.
Evaluation of SAODV
The creators of SAODV evaluated the
algorithm by comparing it to AODV using the
NS-2 network simulator. The test environment
deployed 50 nodes which were classified into
three security levels(15 high, 15 medium, and
20 low). Two simulations were run with 10000
packets (512 byte packet size), 20 flows, and a
constant data rate of 4 packets/second, with the
maximum number of packets per flow is 500
packets. Simulation one had a traffic pattern
consisting of 10% flow between high level
nodes, 20% flow between medium level nodes,
and 70% between low level nodes. Simulation
two had a traffic pattern consisting of 33% flow
between high level nodes, 33% flow between
medium level nodes, and 34% flow between
low level nodes [Yi, Naldurg, and Kravets
2001]. I believe that simulation 2’s traffic
pattern does not accurately represent the traffic
pattern of a network that maintains a security
Implementing SAODV
The RREQ packets of AODV are modified
to include an additional field called
RQ_SEC_REQUIREMENT, which specifies
the security level of the route the sender wishes
to achieve [Yi, Naldurg, and Kravets 2001].
This field will not change during route
discovery. When an intermediate node receives
this RREQ packet it checks to see if it has the
security clearance. If it does possess the
security clearance the node will forward the
request as in AODV. However if the node does
4
hierarchy so I will put less weight in the results
it produces.
chance for network congestion using SAODV
than AODV.
Efficiency/speed
Strength of security
For the first part of my evaluation I would
like to analyze the efficiency/speed of SAODV.
For the most part the speed of SAODV, should
be less than AODV. This is obvious since the
algorithm merely adds overhead to the AODV
algorithm. The creators’ results support this.
SAODV will always find a “secure” path if
one exists and find the shortest “secure” path at
that. However, SAODV still relies on an
inherently bad trust your neighbor policy.
While this policy only trusts your neighbor if he
has a high/higher security rank, it still lacks the
true robustness it needs to perform in the
battlefield environment.
A battlefield is
inherently dangerous environment in respect to
network maintenance; nodes are easily captured,
corrupted, and damaged. If a high or relatively
high security level node is captured or more
likely has a vulnerability exploited, what will
the protocol do? The only protection the
creators offer for a captured node is to either
enter a password before every transmission or
use some biometrics i.e. a fingerprint analyzer
(fpa) to prevent a captured node from being
exploited [Yi, Naldurg, and Kravets 2001]. The
problems with these solutions are the fact that
neither applies themselves well to a battlefield
situation. Entering a password before each
transmission may be too time-consuming to be
beneficial. Not to mention that a captured
soldier if threatened/tortured may very well give
up the password. Using a fpa will definitely not
work. Currently fpa technology has enough
trouble working correctly and consistently
enough in a controlled environment, let alone
the dirty destructive environment a battlefield.
While this algorithm handles small scale attacks
on low level security nodes fine, it does not
handle a successful high level security attack
very well. If a high ranking node is corrupted
the only solution using SAODV is to use a
higher security level node.
This solution
removes a lot of secure nodes in the same
security level out of the need to know loop.
Because of these security flaws I would rate the
The amount of time it took AODV to complete
simulation 1 is 2844 units (creators do not
specify what units of time are used) and
SAODV took 2911 units. The amount of time it
took AODV to complete simulation 2 is 2918
units and SAODV took 2925 units. For test run
1 SAODV performed only 2.3% slower and for
test run 2 SAODV performed only 0.2% slower
[Yi, Naldurg, and Kravets 2001]. This speed
difference as far as I’m concerned is negligible.
In a battlefield situation speed is important, but I
would argue that security is more important, so I
believe this tradeoff is very acceptable. To
follow the amount of transmitted data for
AODV in simulation 1 was 10023 units (again
authors didn’t specify units) and 10022 units for
simulation 2 while SAODV transmitted 10028
units and 10017 units respectively [Yi, Naldurg,
and Kravets 2001]. My educated guess is that if
more simulations were to run we would see
more results like simulation 2. The reason for
this should be easily understood.
Since
SAODV doesn’t allow nodes without security
clearance to forward packets, these packets are
dropped. This allows for greater utilization of
the bandwidth meaning there should be a lower
5
strength of security of this algorithm as
mediocre. While it does step up and offer some
routing security it still does not truly fulfill the
needs of secure MANET routing protocol.
Phase 3 then takes this information and updates
and maintains the link weight list. If a link is
found to be faulty its weight is doubled. This
list is in turn used by phase 1 to discover routes
[Awerbuch et al. 2002]. Using this protocol
even poorly performing routes even if they are
not behaving maliciously will be avoided.
Furthermore strong attacks such as wormholes,
where two attackers tunnel packets back and
forth to one another, can not be avoided but can
be routed around. Also traditional DOS attacks
are not addressed by ODSR
ON-DEMAND SECURE ROUTING
The next routing protocol that we look at is
name less, but is describe as “an on-demand
secure routing protocol resilient to Byzantine
failures, where Byzantine failures is defined as a
failure that results in disruption or degradation
of the routing service [Awerbuch et al. 2002].
From this point forward I will refer to this
protocol as ODSR. The creators of ODSR
attempted to implement an algorithm that would
not merely assign blame to an individual node
but to the data link between them. In this way
any node can be communicated with as long as
there is a fault-free link path between the nodes.
In this protocol only two nodes are trusted . . .
the source node and the destination node. The
purpose for this approach is to focus on route
maintenance and not necessarily node security.
ODSR takes the trust element away from the
node and places it entirely on the route, as
evidenced by the blame association on the link
and not the route. It must be noted that ODSR
will only work when all links on the network are
bi-directional [Awerbuch et al. 2002]. ODSR is
compromised of three phases. Phase 1 attempts
to find a route with respect to fault avoidance.
This is accomplished using flooding in
conjunction with a faulty link weight list. The
protocol will return a route with the least
weighted path to the destination node
[Awerbuch et al. 2002]. Phase 2 employs the
Byzantine fault detection part of the protocol.
During this phase faulty link paths are
discovered. If a link has log(n) or more faults,
where n is the distance between the nodes, That
link is determined to be faulty. Once it is
determined that a link is faulty, phase 2 begins
to isolate that link [Awerbuch et al. 2002].
Route discovery is tackled by flooding
requests and replies so that if a fault free path
does exist it will be found [Awerbuch et al.
2002]. The initial flooding of the request is
executed because of the need to find the
destination node; while the flooding of the reply
is intended to eliminate the affect of an
adversarial node dropping reply packets.
Digital signatures are used to verify each node.
This prevents unauthorized nodes from flooding
the network with request packets [Awerbuch et
al. 2002]. A path is found based on determining
the current lowest link weight path cost. A path
will be forwarded if and only if its link weight is
less than the previously stored value. Each node
adds its digital signature to the request before
forwarding packets to prevent adversarial nodes
from forwarding arbitrary paths. Each node
must verify the weights and digital signatures of
each packet before forwarding this packet.
Faulty links are detected using ack packets.
If a timeout occurs it is assumed that an ack has
been lost, either by malicious or non-malicious
means. To allow for normal network behavior a
threshold variable is maintained. This threshold
variable according to the creators should be as
close to what is normally expected for the
network as possible. If a path has a fault rate
equal to or greater than the threshold value it is
deemed faulty. Once a path has been deemed
6
faulty the protocol attempts to isolate the faulty
link so that it can be routed around.
Implementing ODSR phase II
The fault detection scheme is employed by
using ack packets to isolate faulty links. Using
the threshold limit, which is evaluated within a
window or time frame, phase II will determine
if a certain path exceeds its fault acceptance
rate. Once the algorithm has determined that
there is faulty link on a path it will initiate a
binary search on that path [Awerbuch et al.
2002]. The source node controls the search
method by sending a list of the intermediate
nodes in a packet to every intermediate node on
its path to the destination node. Each node on
this list must reply with an ack packet. The
search is implemented by picking a node to
probe which is the node in the middle of path
and trying to reach it. If this new path is
determined to be faulty this path is cut in half as
well and the process continues until the faulty
link is isolated and verified. This information is
then passed on to phase III [Awerbuch et al.
2002].
ODSR Routing Protocol Phases
Implementing ODSR phase I
Phase I consists of five steps. During Step I
the source node creates and signs a route
request.
This request is forwarded (via
broadcast) to all of its neighbors, who then
verify through digital signatures, update, and
forward the request following the same
procedure themselves. At step II nodes receive
the broadcasted request. A node will check its
list of recently received broadcasts and if all the
information from this packet matches a request
in its list the request will be dropped. If the
request can not be found in its list it will update
the list and then rebroadcast the request. The
destination node receives the request during step
III. If this is the first time the request has been
received by the destination node, it will verify
the authenticity of the request and then create
and sign a reply which will then be broadcast
back towards the source node. At step IV the
packet is received by an intermediate node that
will add up the weight of all the links along the
path and if it is less than the current value in its
table will verify every nodes authenticity along
the path before signing and forwarding the
packet. Finally the response is received by the
source node in step V. Upon receipt of the
response the source node will perform the same
verification and computation as the intermediate
nodes did. If this new path is better than the
current path stored, it will be stored [Awerbuch
et al. 2002].
Byzantine Fault Detection: an Example
The list packets sent to a probe contain an
identifier at the beginning of the list that
specifically and uniquely identifies the current
7
probe [Awerbuch et al. 2002]. If a node
receives the list packet it checks to see if it is the
target probe. If it is target probe the node then
verifies the HMAC of the packet and replaces
the list of the packet with the list of the
remaining nodes. This feature makes the ack
packet travel the nodes back in the reverse order
to the source node. Also it verifies the contents
of the ack at each node [Awerbuch et al. 2002].
Malicious nodes can drop the entire list but they
can not drop an individual node on the list,
which allows a node displaying this behavior to
be quickly identified. Furthermore, to prevent
individual acks from being dropped a node must
wait some specified time limit for the next
probe to send its ack before sending. If the
timeout occurs the probe continues normally
with the ack packet. Once the source node
receives the ack packets it verifies the HMACs
of each ack on the list and then verifies all the
acks or isolates the faulty link, which can then
be delivered to phase III [Awerbuch et al.
2002].
simulation runs offered for us to analyze, but
there is a mathematical proof that the affect
malicious node(s) can have on an ad hoc
network using ODSR is limited to a bounded
effect.
Efficiency/speed
We believe this is the area that hurts ODSR
the most. It seems that the creators of ODSR
never took into effect that medium that they
were using was a radio signal. As such the
medium inherently does not reach its potential
data transfer rates due to the numerous factors
that decrease signal strength and transfer rates.
While the implementation they offer does take
security into account it is these specific
implementation details that promote the
undesired effect. Phase I and phase II in
particular create way too much overhead for a
mobile network propagating data over a radio
signal to be very useful. During phase I each
node must digitally sign and verify the digital
signatures of each node before it in the list
carried in the packet it received [Awerbuch et
al. 2002]. This may not be a terrible problem in
small networks but larger networks such as most
likely seen in military applications will probably
suffer greatly from the performance loss. To
further complicate the problem after the
overhead incurred in the route discovery phase
more overhead is incurred by the fault detection
scheme. Each node on the path searched by the
fault detection scheme must again digitally sign
and verify the signature of other nodes and then
encrypt the packet before sending [Awerbuch et
al. 2002]. This continues till the source node
receives the ack and then must decrypt and
verify each packet to identify a faulty link. This
process may happen several times using the
binary search scheme before the actual faulty
link is ever detected. This being said to us it is
incomprehensible how any designing an ondemand mobile network protocol could involve
Implementing ODSR phase III
If a link has been determined to be faulty its
link weight is doubled. This scheme ensures for
the most part that a link will be avoided when
routing packets to a destination node. A link
weight can be reduced by half if the time
associated with that link has reached zero and
there have been no more excessive fault rates
associated with that link [Awerbuch et al. 2002].
Evaluating ODSR
The creators of ODSR never tried to
eliminate malicious network activity effects,
realizing this may never be possible. Instead
they attempted to bound these effects to what
they felt was an acceptable limit. The analysis
the creators of ODSR offer exemplifies this
thought.
There are no actual network
8
so much overhead in the route discovery and
maintenance protocol.
because some of the DSR optimizations are
extremely difficult to secure even if they are
capable of being secured. For this reason when
we evaluate Ariadne we will do so by
comparing Ariadne with the non-optimized
DSR. The basic way that route discovery in
DSR works is when a node wants to send a
message to another node, it issues a Route
Request packet. This route request is broadcast
locally to the initiator’s neighbors who then
check to see if they have recently received this
request.
If so they discard the request.
However if it hasn’t it will add its own address
to the address list and rebroadcast the packet to
its neighbors. The protocol will continue this
behavior till the packet reaches the destination
node. Once it reaches the destination node, this
node will add the list of addresses to a packet
and issue a Route Reply packet back to the
initiator node. The initiator node will then add
the path to its route cache list.
Route
maintenance is implemented by each node
checking to see if the packet it delivered was
successfully received.
After several
retransmissions if the packet still has not been
received the node will send a Route Error
packet back to the initiator node. The initiator
node will then remove this link from its route
cache [Hu, Perrig, and Johnson 2002].
Strength of security
What makes ODSR perform so poorly
regarding speed and efficiency actually makes it
perform well regarding security. However the
amount of overhead involved just doesn’t justify
the security benefits of this algorithm. In
addition a patient and dedicated enemy could
perform malicious attacks to the network and
view packets transmitted by merely not meeting
or exceeding the fault rate. While this protocol
does find fault-free routes within the threshold
limit, it does not prevent malicious nodes from
continuing to disrupt network service.
A
malicious node can either nit-pick at the service
and never be detected as faulty or can simply
just wait till his fault time out occurs and then
again issue a malicious attack and this node will
never be completely removed from the network
[Awerbuch et al. 2002]. As far as we are
concerned this protocol does meet the security
needs of a mobile ad hoc network environment.
ARIADNE
The final ad hoc network routing protocol we
look at is Ariadne. Ariadne is describe as a
secure on-demand routing protocol based on
DSR [Hu, Perrig, and Johnson 2002]. The
creators of Ariadne wanted to implement a
secure routing protocol for ad hoc networks that
not only applied to the network itself but was
able to run on low resource devices where
computing power and battery life was a concern
[Hu, Perrig, and Johnson 2002]. In choosing
this as a goal, efficiency and security were
priorities from the start with the design of
Ariadne. The base implementation of the route
discovery and the route maintenance are for the
most part an un-optimized version of DSR. The
reason an un-optimized version is used is
In conjunction with DSR, Ariadne uses
TESLA broadcast authentication as an efficient
way to authenticate nodes on a path. TESLA is
a non-traditional asymmetric cryptographic
scheme that achieves asymmetry from clock
synchronization and delayed key disclosure as
opposed to computation intensive one-way
trapdoor functions [Hu, Perrig, and Johnson
2002]. The TESLA scheme need not be further
discussed here as its effects will reveal
themselves in the simulation results. Just be
aware that nodes are able to be verified on paths
using the TESLA scheme.
9
There are a couple of assumptions that are
incorporated into the Ariadne protocol.
Physical layer attacks are not considered
because plenty of research has proven ways to
defend against them [Hu, Perrig, and Johnson
2002]. Medium access protocol attacks are
disregarded, and they assumed the network will
duplicate, reorder, corrupt, or drop packets.
Also any assumptions that a protocol that
Ariadne employs such as TESLA makes
Ariadne assumes too. Furthermore, the creators
assumed that the node had limited resources, i.e.
Palm Pilot, to allow a more general result set
[Hu, Perrig, and Johnson 2002].
Finally
tamperproof/trusted hardware is not considered.
packet. If the packet is verified the destination
node will return a Route Reply packet to the
source node. This packet will contain the
following fields: <Route Reply, destination,
source, time interval, node list, MAC list,
destination MAC, key list>, where everything
from the request packet is carried over except
for the destination MAC and the key list. The
destination MAC is set to a MAC computed on
the fields before it in the packet using the key
KDS, and the key list is empty. This packet is
then sent back to the source node along the
reverse path the Route Request packet traveled.
Intermediate nodes along the path back to the
source node will append its appropriate TESLA
key to the key list before forwarding the packet.
After finally receiving the Route Reply packet
the source node will verify that all the keys in
the key list are correct and that the destination
MAC and all the MACs in the MAC list are
correct as well. If this is so the source node
updates its route cache with the new path.
Implementation: Ariadne route discovery
To begin with the source node creates a
packet with the following fields:
<Route
Request, source, destination, id, time interval,
hash chain, node list, MAC list>, where id is a
DSR route variable and time interval is a
TESLA variable. The source node initializes
the hash chain to the value of MACKSD(source,
destination, id, time interval), where KSD is a
shared key between the source and destination
nodes.
Ariadne Route Discovery Example
When a node that is not the destination node
receives this packet it checks the source, id
contents of the packet to see if it has received
this request already. If it has it will drop the
packet. If this is a new request the node will
then verify the TESLA information, and if this
is correct will then add its address to the node
list of the packet, change the hash chain to H[A,
hash chain], and then add a MAC of the entire
packet to the MAC list using the appropriate
TESLA key. Then the node rebroadcasts the
packet.
S = source, D = destination
Bold underlined = changed field
Implementation: Ariadne route maintenance
If an intermediate node is unable to forward
a packet, it will send a Route Error packet back
to the source node. To prevent malicious
Once the destination node finally receives
the request it will verify the validity of the
10
activity regarding Route Error packets, the
sender of the packet must authenticate it. Using
TESLA this packet contains the following
fields:
<Route Error, sending address,
receiving address, time interval, error MAC,
recent TESLA key>, where sending address is
the node trying to forward the packet and
receiving address is the node the packet is
intended for. The recent TESLA key field is the
most recent TESLA key for the sender of the
packet. This field is used to authenticate the
Route Error packets. The packet travels back to
the source node along the reverse path the
original data packet traveled. Nodes along the
path will check their route cache to see if they
have a route stored with <sending address,
receiving address>. If they do not they will just
forward the packet, but if they do they will
update their route cache appropriately. Upon
reaching the source node, the packet will be
verified and the source node’s route cache will
be updated if the packet is valid [Hu, Perrig, and
Johnson 2002].
Evaluating Ariadne
The designers of Ariadne really thought out
their design plan. They didn’t just attempt to
make a previous routing protocol incorporate
security metrics. The sought out to classify
security threats in an ad hoc network, and then
design a protocol robust enough to defend
against these attacks yet simple enough to be
run on resource sparse equipment. This patient
planning has led to a well designed secure
routing protocol for ad hoc networks. Ariadne
was tested using the ns-2 network simulator.
The DSR was modified to accurately portray the
new routing protocol in the simulator.
Ariadne simulator parameters
In order to defend against routing
misbehavior, Ariadne chooses routes based on
previous packet delivery success. The creators
of Ariadne do not specify how to implement
this, but they do mention that this could be
handled through lower level protocol ack
packets, such as the transport layer. They also
insist that the ack packets travel the reverse path
to prevent malicious nodes from interrupting
and modifying these packets [Hu, Perrig, and
Johnson 2002]. Next to defend against Route
Request flooding, the creators introduce Route
Discovery chains. This allows each node to
limit the rate at which each node can issue
requests. These chains are one-chains that
allow intermediate nodes to recognize and drop
duplicate requests [Hu, Perrig, and Johnson
2002].
Efficiency/speed
Focusing the design of Ariadne on resource
limit equipment has given the protocol great
efficiency/speed results. Not only does this
speed make the protocol operate at an
acceptable rate but it prevents malicious nodes
from taking advantage of a slow process in the
protocol, and isolating flooding attacks there.
When tested against DSR-NoOpt Ariadne
typically performs better as seen in the graphs
below. This is the main reason that we are
pleased the efficiency/speed of Ariadne. In a
11
military/battlefield setting speed is a crucial
aspect when dealing with data communications,
and Ariadne more than reaches an acceptable
rate.
adversarial setting like a battlefield. That being
said we believe packet security to be easily and
efficiently incorporated into this routing
protocol. For the most part Ariadne offers a
secure means of routing packets through an unsecure medium while being flexible enough to
allow other well established methods of security
to be incorporated. It is the computing resource
conscious design that allows/will allow this
protocol to evolve with other technologies and
protocols. For this reason we believe that while
Ariadne does not completely meet the needs of
an ad hoc network environment, it is the best
choice of the three we have evaluated.
INTRUSION DETECTION SYSTEMS
Intrusion detection can be defined as the
automated detection and subsequent generation
of an alarm to alert the security apparatus at a
location if intrusions have taken place or are
taking place. An IDS is a defense system that
detects hostile activities in a network and then
tries to possibly prevent such activities that may
compromise system security. IDSs achieve
detection by continuously monitoring the
network for unusual activity. The prevention
part may involve issuing alerts as well as taking
direct preventive measures such as blocking a
suspected connection. In other words, intrusion
detection is a process of identifying and
responding to malicious activity targeted at
computing and networking resources. In
addition, IDS tools are capable of distinguishing
between insider attacks originating from inside
the network and external ones. Unlike firewalls
which are the first line of defense, IDSs come
into the picture only after an intrusion has
occurred and a node or network has been
compromised.
Average Latency
99.99th Percentile Latency
Strength of Security
The security that Ariadne offers in the
context of strictly routing packets is very well
implemented. However the packets themselves
are not as secure. The creators themselves
mention that an enemy can eavesdrop on
packets and perform traffic analysis. These are
potentially serious security issues in an
The primary assumptions of intrusion
detection are: user and program activities are
observable, for example via system auditing
12
mechanisms; and more importantly, normal and
intrusion activities have distinct behavior.
Intrusion detection therefore involves capturing
audit data and reasoning about the evidence in
the data to determine whether the system is
under attack. Based on the type of audit data
used, intrusion detection systems (IDSs) can be
categorized as network-based or host-based. A
network-based IDS normally runs at the
gateway of a network and "captures" and
examines network packets that go through the
network hardware interface. A host-based IDS
relies on operating system audit data to monitor
and analyze the events generated by programs
or users on the host. Intrusion detection
techniques can be categorized into three broad
categories: anomaly detection, signature or
misuse detection, and specification detection.
Misuse detection
In misuse detection, decisions are made on
basis of knowledge of a model of the intrusive
process and what traces it ought to leave in the
observed system. Legal or illegal behavior can
be defined and observed behavior compared
accordingly. Such a system tries to detect
evidence of intrusive activity irrespective of any
knowledge regarding the background traffic.
Misuse detection systems, e.g., IDIOT [S.
Kumar and E. H. Spafford 1995] and STAT [K.
Ilgun, R. A. Kemmerer and P. A. Porras, 1995],
use patterns of well-known attacks or weak
spots of the system to match and identify known
intrusions. For example, a signature rule for the
"guessing password attack" can be "there are
more than 4 failed login attempts within 2
minutes". The main advantage of misuse
detection is that it can accurately and efficiently
detect instances of known attacks. The main
disadvantage is that it lacks the ability to detect
the truly innovative attacks.
Anomaly detection
In an anomaly detection system a baseline
profile of normal system activity is created. Any
system activity that deviates from the baseline is
treated as a possible intrusion
REQUIREMENT OF IDS FOR MOBILE
AD HOC NETWORKS
Anomaly detection systems, for example,
IDES [T. Lunt et al. 1992], flag observed
activities that deviate significantly from the
established normal usage profiles as anomalies,
i.e., possible intrusions. For example, the
normal profile of a user may contain the
averaged frequencies of some system
commands used in his or her login sessions. If
for a session that is being monitored, the
frequencies are significantly lower or higher,
then an anomaly alarm will be raised. The main
advantage of anomaly detection is that it does
not require prior knowledge of intrusion and can
thus detect new intrusions. The main
disadvantage is that it may not be able to
describe what the attack is and may have high
false positive rate.
There are two key requirements that any IDS
must fulfill. These are effectiveness — how to
make the intrusion detection system classify
malign and benign activity correctly — and
efficiency — how to run the IDS in a cost
effective manner as far as possible. In other
words, these two requirements in essence
suggest that an IDS should detect a substantial
percentage of intrusions into the supervised
system, while keeping the false alarm rate at an
acceptable level at a lower cost. It is expected
that an ideal IDS is likely to support several of
the following requirements:
• The IDS should not introduce a new weakness
in the MANET. That is, the IDS itself should
not make a node any weaker than it already is.
13
• An IDS should run continuously and remain
transparent to the system and users.
• The IDS should use as little system resources
as possible to detect and prevent intrusions.
IDSs that require excessive communication
among nodes or run complex algorithms are not
desirable.
• It must be fault-tolerant in the sense that it
must be able to recover from system crashes,
hopefully recover to the previous state, and
resume the operations before the crash
• Apart from detecting and responding to
intrusions, an IDS should also resist subversion.
It should monitor itself and detect if it has been
compromised by an attacker.
• An IDS should have a proper response. In
other words, IDS should not only detect but also
respond to detected intrusions, preferably
without human intervention.
• Accuracy of the IDS is another major factor in
MANETs. Fewer false positives and false
negatives are desired.
• It should interoperate with other intrusion
detection systems to collaboratively detect
intrusions. For example, the Internet
Engineering Task Force (IETF) Intrusion
Detection Working Group (IDWG) is working
toward proposing such a specification.
algorithms of the IDS are cooperative, it
becomes important to be skeptical of which
nodes one can trust. Therefore, intrusion
detection systems on ad hoc networks have to
be wary of attacks made from nodes in the
network itself, not just attacks from outside the
network. Also, mobile networks cannot
communicate as frequently as their wired
counterparts to detect intrusions in order to
conserve bandwidth resources. Bandwidth and
other issues such as battery life compound the
problem even further.
The availability of partial audit data makes it
harder to distinguish an attack from regular
network use. In the following section we present
a state-of-the-art view of research in IDSs for
mobile ad-hoc networks.
A DISTRIBUTED IDS
In their work pertaining to intrusion
detection in MANETs, Zhang and Lee describe
a distributed and cooperative intrusion detection
model where every node in the network
participates in intrusion detection and response.
In this model, an IDS agent runs at each mobile
node, and performs local data collection and
local detection, whereas cooperative detection
and global intrusion response can be triggered
when a node reports an anomaly.
Wireless ad hoc networks, due to their
vulnerabilities, provide a tougher challenge for
designing an IDS. Without centralized audit
points such as routers and gateways, an IDS for
ad hoc networks is limited to using only the
current traffic coming in and out of the node as
audit data. Another key requirement is that the
algorithms the IDS uses must be distributed in
nature, and should take into account the fact that
a node can only see a portion of the network
traffic. Moreover, since ad hoc networks are
dynamic and nodes can move about freely, there
is a possibility that one or more nodes could be
captured and compromised, especially if the
network is in a hostile environment. If the
An intrusion detection system for MANETs
The internals of an IDS agent are structured
into six pieces as shown in figure. Each node
does local intrusion detection independently,
14
and neighboring nodes collaboratively work on
a larger scale. Individual IDS agents placed on
each and every node run independently and
monitor local activities, detect intrusions from
local traces, and initiate responses. Neighboring
IDS agents cooperatively participate in global
intrusion detection actions when an anomaly is
detected in local data or if there is inconclusive
evidence. The data collection module gathers
local audit traces and activity logs that are used
by the local detection engine to detect local
anomaly. Detection methods that need broader
data sets or require collaborations among local
IDS agents use the cooperative detection engine.
Both the local and global response modules
provide intrusion response actions. The local
response module triggers actions local to this
mobile node, while the global one coordinates
actions among neighboring nodes, such as the
IDS agents in the network electing a remedial
action. A secure communication module
provides a high-confidence communication
channel among IDS agents.
The source node or the intermediate nodes
that receives RREP will update its forward route
to destination in the routing tables. Otherwise, it
continues broadcasting the RREQ. If a node
receives a RREQ message that has already
processed, it discards the RREQ and does not
forward it. In AODV, sequence number (SN)
plays a role to indicate the freshness of the
routing information and guarantee loop-free
routes. Sequence number is increased under
only two conditions: when the source node
initiates RREQ and when the destination node
replies with RREP. Sequence number can be
updated only by the source or destination. Hop
count (HC) is used to determine the shortest
path and it is increased by 1 if RREQ or RREP
is forwarded each hop. When a link is broken,
route error packets (RERR) are propagated to
the source node along the reverse route and all
intermediate nodes will erase the entry in their
routing tables.
AODV maintains
the
connectivity of neighbor nodes by sending hello
message periodically.
AODV PROTOCOL-BASED IDS
Specification-based monitoring of AODV
The Ad hoc On-demand Distance Vector
(AODV) routing protocol is a reactive and
stateless protocol that establishes routes only as
desired by a source node using route request
(RREQ) and route reply (RREP) messages.
When a node wants to find a route to a
destination node, it broadcasts a Route Request
(RREQ) message with a unique RREQ ID
(RID) to all its neighbors. When a node receives
a RREQ message, it updates the sequence
number of source node and sets up reverse
routes to the source node in the routing tables. If
the node is the destination or the node has a
route to the destination that meet the freshness
requirements1, it unicasts a route reply (RREP)
back to the source node.
Specification-based monitoring compares the
behavior of objects with their associated
security specifications that capture the correct
behavior of the objects. The specifications are
usually manually crafted based on the security
policy, functionalities of the objects, and
expected usage. Specification-based detection
does not detect intrusions directly – it detects
the effect of the intrusions as run-time violation
of the specifications instead. As the
specifications are concerned with the correct
behavior of objects, specification-based
detection does not limit itself to detecting just
known attacks. The specification-based
detection approach has been successfully
applied to monitor security critical programs,
applications, and protocols. In particular,
15
specifications for the Address Resolution
Protocol
(ARP) and the Dynamic Host Configuration
Protocol (DHCP) have been used to detect
attacks that exploit vulnerabilities in these
protocols.
and supports secure enclaves for dynamic
coalitions.
Research efforts at Architecture Technology
Corporation are aimed at demonstrating a set of
innovative design techniques, collectively called
TIARA, that secure ad hoc networks against
DoS attacks. The TIARA approach involves
fully distributed lightweight firewalls for ad hoc
wireless networks, distributed traffic policing
mechanisms,
intrusion-tolerant
routing,
distributed intrusion detection mechanisms,
flow monitoring, reconfiguration mechanisms,
multipath routing, and source-initiated route
switching. The flow-based route access control
(FRAC) rules define admissible flows. Per-flow
security association is instantiated by secure
session setup signaling protocol and contains
information for packet authentication. Also, fast
authentication enables low-overhead integrity
checks on packet flow-ids and sequence
numbers. There is referral-based resource
allocation, which limits networks’ exposure to
resource usurpation by spurious sessions, and
flows are assigned an initial allowable resource
usage. Moreover, additional resources are only
granted if the source of the flow can present
referrals from a certain number of trusted nodes.
Referrals have time-bound validity. Flowspecific sequence numbers limit and contain the
impact of traffic replay attacks; sequence
numbers are embedded within secret locations
within each packet. The destination of flow
monitors select flow parameters to detect
intrusion-induced path failures, and multipath
routing and source-initiated route switching
divert flow through available alternate paths to
circumvent intruders. Efforts are on to
implement dynamic on-the-fly modifications to
FRAC (firewall) policies, real-time referralbased
resource
allocation,
lightweight
implementation of traffic policing, fast
authentication mechanisms resistant to traffic
analysis, and embedding sequence numbers and
In general, a specification for a network
protocol constrains the messages exchanged by
the network nodes. The specifications could
restrict the way the messages are exchanged
(e.g., an ACK followed by a SYN), the contents
of the messages. The specifications could also
be derived from some desirable global
invariants about the protocol.
In applying the specification techniques to
monitor AODV, we focus first on the routing
messages that are exchanged in the discovery of
routes. In particular, we attempt to monitor all
the RREQ and RREP messages in a requestreply flow from a source node to a destination
node and back to the source. Our specification
requires that all nodes send RREQ and RREP
messages
according
to
the
protocol
specifications, and the hop count, RREQ ID,
and the sequence numbers are correct.
TECHNIQUES FOR INTRUSIONRESISTANT AD-HOC ROUTING
ALGORITHMS
Techniques for Intrusion-Resistant Ad Hoc
Routing Algorithms (TIARA) is a set of design
techniques that strengthen MANETs against
DoS attacks. The TIARA mechanisms limit the
damage sustained by MANETs from intrusion
attacks and allow continued network operation
at an acceptable level during such attacks. It
provides protection against attacks on control
routing traffic as well as data traffic, thereby
providing a comprehensive defense against
intruders. Because of routing algorithm
independence it allows widespread applicability
16
path labels in encrypted packets. Although the
proposed architecture seems to cover most of
the important aspects of intrusion detection and
prevention in MANETs, implementation of such
a design methodology entails extensive
modification of the routing algorithms in a
MANET.
nodes with link reliability data to pick the route
most likely to be reliable. Each node maintains a
rating for every other node it knows about in the
network. It calculates a path metric by
averaging the node ratings in the path.
LOCAL INTRUSION DETECTION
SYSTEM (LIDS)
WATCH DOG-PATHRATER APPROACH
The LIDS is distributed in nature and utilizes
mobile agents on each of the nodes of the ad
hoc network. In order to make local intrusions a
global concern for the entire network, the LIDSs
existing on different nodes collaborate.
Collaboration among the nodes is achieved
using two types of data: security data to obtain
complementary information from collaborating
hosts, and intrusion alerts to inform others of a
locally detected intrusion. LIDS has chosen to
use Simple Network Management Protocol
(SNMP) data located in management
information bases (MIBs) as the audit source
because SNMP offers several advantages;
principal is that the cost of local information
collection is negligible if an SNMP agent is
running on a node. Mobile agents (which must
be autonomous and adaptive) are used to
transport SNMP requests to remote hosts to
overcome the unreliability of SNMP message
transfer over UDP. A LIDS can delegate a
specific mission to an agent that it will achieve
in an autonomous and asynchronous manner
without any help from its LIDS.
There are two techniques that improve
throughput in MANETs in the presence of
compromised nodes that agree to forward
packets but fail to do so [S. Marti et al. 2000]. A
node may misbehave because it is overloaded,
selfish, malicious, or broken. An overloaded
node lacks the CPU cycles, buffer space, or
available network bandwidth to forward
packets. A selfish node is unwilling to spend
battery life, CPU cycles, or available network
bandwidth to forward packets not of direct
interest to it, even though it expects others to
forward packets on its behalf. A malicious node
launches a DoS attack by dropping packets. A
broken node might have a software fault that
prevents it from forwarding packets.
To mitigate the decrease in the throughput
due to the above node categories, the authors
use watchdogs that identify misbehaving nodes
and a pathrater that helps routing protocols
avoid these nodes. When a node forwards a
packet, the node’s watchdog verifies that the
next node in the path also forwards the packet.
The watchdog does this by listening
promiscuously to the next node’s transmissions.
If the next node does not forward the packet, it
is misbehaving. The watchdog detects
misbehaving nodes. Every time a node fails to
forward the packet, the watchdog increments the
failure tally. If the tally exceeds a certain
threshold, it determines that the node is
misbehaving; this node is then avoided using the
pathrater. The pathrater, run by each node in the
network, combines knowledge of misbehaving
The LIDS architecture is shown in Figure.
The key elements of the architecture are:
i. A common communication framework to
facilitate
all
external
and
internal
communication with a LIDS
ii. Several data collecting agents for different
tasks, such as:
• A local LIDS agent is in charge of local
intrusion detection and response, and also for
reacting to intrusion alerts provided by other
17
nodes in order to protect itself against this
intrusion.
• Mobile agents that collect and process data on
remote hosts with an ability to transfer the
results of a computation back to their home
LIDS or to migrate to another node for further
investigation. The mobile agent place is
responsible for security control of these agents,
but an agent should also be able to protect itself
from malicious mobile agent places.
• The local MIB agent provides a means of
collecting MIB variables for either mobile
agents or the local LIDS agent. If SNMP runs
on the node, the local MIB agent will be the
interface with the running SNMP agent. For
other scenarios an SNMP-based agent has to be
developed to allow optimized updates and
retrieval of the MIB variables used by intrusion
detection. The local MIB agent would in that
case act as an interface between the LIDS and
this tailor-made agent.
community until it re-authenticates itself. By
being informed of intrusions on remote hosts, a
LIDS can act as a security tool and prevent the
intruder from attacking it. The authors
recommend that for the best security in an ad
hoc network, all the LIDSs on nodes should run
and cooperate continuously.
INTRUSION DETECTION
ARCHITECTURE FOR STATIC
STATIONARY DATABASE
A distributed IDS has been proposed at
Mississippi State University in which each node
on the network has an IDS agent running on it.
The IDS agents on each node in the network
work together via a cooperative intrusion
detection algorithm to decide when and how the
network is being attacked. The architecture is
divided into parts: the mobile IDS agent, which
resides on each node in the network, and the
stationary secure database, which contains
global signatures of known misuse attacks and
stores patterns of each user’s normal activity in
a non-hostile environment.
LIDS Architecture
In this design the local LIDS agent could use
either misuse or anomaly detection as an
intrusion detection mechanism. As far as
response is concerned, as soon as a LIDS
detects an intrusion locally it informs the other
nodes of the network. Locally, the node is
empowered to refuse connections with the
suspicious node, exclude it when performing
cooperative actions, or exclude it from its
A proposed IDS based on stationary secure
database
Mobile IDS Agents
Each node in the network will have an IDS
agent running on it all the time. This agent is
18
responsible for detecting intrusions based on
local audit data and participating in cooperative
algorithms with other IDS agents to decide if
the network is being attacked. Each agent has
five parts: a local audit trial, a local intrusion
database (LID), a secure communication
module, anomaly detection modules (ADMs),
and misuse detection modules (MDMs), as
shown in Figure. The LID is a local database
that warehouses all information necessary for
the IDS agent, such as the signature files of
known attacks, the established patterns of users
on the network, and the normal traffic flow of
the network. The ADMs and MDMs
communicate directly with the LID to determine
if an intrusion is taking place. The secure
communication module is necessary to enable
an IDS agent to communicate with other IDS
agents on other nodes. It will allow the MDMs
and ADMs to use cooperative algorithms to
detect intrusions. It may also be used to initiate
a global response when an IDS agent or a group
of IDS agents detects an intrusion. Data
communicated via the secure communication
module needs to be encrypted. The ADMs are
responsible for detecting a different type of
anomaly. There can be from one to many ADMs
on each mobile IDS agent, each working
separately or cooperatively with other ADMs.
The MDMs identify known patterns of attacks
that are specified in the LID. Like the ADMs, if
the audit data available locally is sufficient to
determine if an intrusion is taking place, the
proper response can be initiated. It is also
possible for an MDM to use a cooperative
algorithm to identify an intrusion.
not compromise the SSD, as it is stored in an
area of high physical security. The mobile IDS
agents will collect and store audit data (user
commands, network traffic, etc.) while in the
field, and will transfer this information when
they are attached to the SSD. The SSD will then
use this information for data mining of new
anomaly association rules. The SSD will also be
the place where the system administrator can
specify the newest misuse signatures. When the
IDS agents are connected to SSD, they will gain
access to the latest attack signatures
automatically. Using the SSD to communicate
the new attack signatures and establish new
patterns of normalcy limits the amount of
communication that must take place between
IDS agents in the MANET. Despite all the
benefits of having an SSD in a mobile IDS
architecture, there are a few disadvantages in
relying on a stationary database to provide vital
IDS information. If an SSD is used, mobile
nodes will have to be attached to the non-mobile
database periodically to stay up to date with the
latest intrusion information. This may not be an
option for some mobile ad hoc environments.
Also, since the SSD must be a trusted source, it
cannot be taken onsite without significant risk.
DISTRIBUTED INTRUSION DETECTION
USING MOBILE AGENTS
Kachirski and Guha have proposed a
distributed intrusion detection system for ad hoc
wireless networks based on mobile agent
technology . By efficiently merging audit data
from multiple network sensors, their bandwidthconscious scheme analyzes the entire ad hoc
wireless network for intrusions at multiple
levels, tries to
inhibit intrusion attempts, and provides a
lightweight low-overhead mechanism based on
the mobile agent concept.
Stationary Secure Database
The stationary secure database (SSD) acts as
a secure trusted repository for mobile nodes to
obtain information about the latest misuse
signatures and find the latest patterns of normal
user activity. It is assumed that the attacker will
19
There is an efficient distribution of mobile
agents with specific IDS tasks according to their
functionality across a wireless ad hoc network.
The agents used are dynamically updateable,
have limited functionality, and can be viewed as
components of a flexible, dynamically
configurable IDS. Additionally, this scheme
restricts computation-intensive analysis of
overall network security state to a few key
nodes. These nodes are dynamically elected,
and overall network security is not entirely
dependent on any particular node. The modular
approach taken has advantages such as
increased fault tolerance, communications cost
reduction, improved performance of the entire
network, and scalability.
There are three major agent categories:
monitoring, decision-making, and action agents.
Some are present on all mobile hosts, while
others are distributed to only a selected group of
nodes. While all nodes accommodate host-based
monitoring sensors of the IDS, a distributed
algorithm is utilized to assign a few nodes to
host sensors that monitor network packets and
agents that make decisions. The mobile network
is logically divided into clusters with a single
cluster head for each cluster that monitors
packets within the cluster. The selected nodes
host network monitoring sensors that collect all
packets within the communication range and
analyze the packets for known patterns of
attacks. Monitoring agents are categorized into
packet monitoring sensors, user activity sensors,
and system-level sensors. Local detection agents
are located on each node of an ad hoc network,
and act as user-level and system-level anomalybased monitoring sensors. These agents look for
suspicious activities on the host node, such as
unusual process memory allocations, CPU
activity, I/O activity, user operations (invalid
login attempts with a certain pattern, super-user
actions, etc.). If an anomaly is detected with
strong evidence, a local detection agent will
terminate the suspicious process or lock out a
user and initiate reissue of security keys for the
entire network. If some inconclusive anomalous
activity is detected on a host node by a
monitoring agent, the node is reported to the
decision agent of the same cluster of which the
suspicious node is a member. If more
conclusive evidence is gathered about this node
from any source (including packet monitoring
results from a network monitoring agent), the
action is undertaken by the agent on that node.
The proposed IDS is built on a mobile agent
framework as shown in Figure. It is a nonmonolithic system and employs several sensor
types that perform specific functions, such as:
Network monitoring: Only certain nodes have
sensor agents for network packet monitoring to
preserve total computational power and battery
power of mobile hosts.
Host monitoring: Every node on the MANET
is monitored internally by a host monitoring
agent. This includes monitoring system-level
and application-level activities.
Decision-making: Every node decides on its
intrusion threat level on a host-level basis.
Certain nodes collect intrusion information and
make collective decisions about the network
level intrusions.
Action: Every node has an action module
responsible for resolving intrusion situations on
a host.
Decision agents are located on the same
nodes as packet monitoring agents. A decision
agent contains a state machine for all the nodes
within the cluster it resides in. As intrusion or
anomalous activity evidence is gathered for
Intrusion detection using mobile agents
20
each node, the agent can decide that a node has
been compromised by looking at reports from
the node’s own local monitoring agents and the
packet monitoring information pertaining to that
node. When a certain level of threat is reached
for a node in question, the decision agent
dispatches a command that an action must be
undertaken by the local agents on that node. In
time, the threat level decreases for each node in
the decision agent’s database.
Time of detection: Two main groups can be
identified in wireless ad hoc networks too: those
that attempt to detect intrusions in real time and
those that process audit data with some delay.
Locus of data processing: The audit data in
general is processed, and new rules are derived
from it in a distributed fashion. Each node in
most of the surveyed systems takes the
distributed approach to avoid being a single
database being the only exception, where audit
Comparison of different proposed architectures against ideal characteristics for IDSs in MANETs
is transferred to the stationary secure database
with the help of mobile agents, and this audit
data is then mined for new misuse patterns.
Security: The ability to withstand a hostile
attack against the IDS itself. This area has been
the subject of little investigation. With the trend
toward using mobile agents for intrusion
detection, most of the surveyed systems that use
mobile agents still do not consider the security
of the agent platform itself.
Degree of Interoperability: The degree to
which the system can interoperate in
conjunction with other IDSs, and accept audit
data and reports from different sources. This is
not the same as the number of different
platforms on which the IDS itself runs. With the
COMPARATIVE ANALYSIS
We compare different IDSs presented in this
article against the attributes of an ideal IDS.
These attributes are fault tolerance, scalability,
interoperability with other IDSs, ability to detect
new attack patterns, and whether the proposed
system introduces new weaknesses in terms of
excessive overheads for communication,
storage, energy, or computation.
We see the following in system
characteristics hold true for wireless ad hoc
networks.
point of failure. The intrusion detection
architecture is based on a secure stationary data
21
exception of one, most of the proposed systems
are not interoperable with each other.
Marti, S.; T. J. Giuli; Kevin Lai; and Mary
Baker. 2000. Mitigating routing misbehavior in
mobile ad hoc networks. In Proceedings of the
6th annual international conference on mobile
computing and networking, ACM, Boston MA
USA
CONCLUSION
This article presents the current techniques
employed in the area of secure routing and
intrusion detection/response for wireless mobile
ad hoc networks. Wireless ad-hoc networks are
intrinsically resource-constrained, which makes
several of the schemes proposed in the wired
world inadequate, as discussed earlier. Instead
schemes that are distributed and collaborative
are likely to be much more applicable.
Mishra. A, Nadkarni. K and Patcha. A. 2004.
Intrusion detection in wireless ad-hoc
networks.Wireless communications, IEEE,
Volume:11, Issue:1.
Tseng,
Chin-Yang;
Poornima
Balasubramanyam; Calvin Ko; Rattapon
Limprasittiporn; Jeff Rowe; and Karl Levitt.
2003. Intrusion detection: A specification based
intrusion detection system for AODV. In
Proceedings of the 1st ACM workshop on
security and ad-hoc and sensor networks.
Fairfax, Virginia
References
Awerbuch, Baruch; David Holmer; Cristina
Nita-Rotaru; and Herber Rubens. 2002. An OnDemand Secure Routing Protocol Resilient to
Byzantine Failures. In Proceedings of the Wise
’02 (Atlanta, GA, Sept. 28). ACM.
Axelsson, S. 2003. Intrusion Detection Systems:
A taxonomy and survey. Technical Report 9915. Department of Computer Engineering,
Chalmers University of Technology, Sweden.
Yi, Seung; Prasad Naldurg, and Robin Kravets.
2001. A Security-Aware Routing Protocol for
Wireless Ad Hoc Networks. Technical Report
UIUCDCS-R-2001-2241.
Department
of
Computer Science, University of Illinois at
Urbana-Champaign, Urbana, IL.
Hu, Yih-Chun; Adrian Perrig; and David B.
Johnson. 2002. Ariadne: A Secure On-Demand
Routing Protocol for Ad Hoc Networks. In
Proceedings of the MobiCom ’02 (Atlanta, GA
Sept. 23-26). ACM.
Yongguang Zhang and Wenke Lee. 2000.
Intrusion detection in wireless ad-hoc networks.
In Proceedings of the 6th annual international
conference on mobile computing and
networking.ACM, Boston MA USA
Ilgun, K.; R.A. Kemmerer; and P. A. Porras.
1995. State transition analysis: A rule based
intrusion detection approach. IEEE Transactions
on
Software
Engineering,
21(3):181199(March).
Biography
Avdhoot K. Saple is presently pursuing his
Masters degree in computer science and
software engineering at Auburn University. His
research work includes analysis of reactive and
anticipatory fault management systems for
computer networks
with an Agent based
paradigm .He acquired his bachelor’s degree in
computer science from University of Mumbai,
India.
Kumar, S. and E. H. Spafford. 1995. A software
architecture to support misuse intrusion
detection. 1995. In Proceedings of the 18th
National Information Security Conference.
22
Dana L. Hickey is currently achieving his
Masters degree at Auburn University in Auburn,
Alabama where he received his bachelor’s of
science in computer science. He is currently
employed through Auburn University as a GTA
and plans to write his thesis on individual agents
working together as a cooperative team. He
expects to receive his Masters degree in
Summer 2006.
23