Fast Detection of Mobile Replica Node Attacks in Wireless Sensor Networks Using Sequential Hypothesis Testing

spongereasonInternet and Web Development

Nov 12, 2013 (3 years and 8 months ago)


Fast Detection of Mobile Replica Node

Attacks in Wireless Sensor Networks

Using Sequential Hypothesis Testing


Student ID number:



Due to the unattended nature of wireless sensor networks, an adversary can
capture and compromise sensor nodes, make replicas of them, and then mount a
variety of attacks with t
hese replicas. These replica node attacks are dangerous
because they allow the attacker to leverage the compromise of a few nodes to
exert control over much of the network. Several replica node detection schemes
have been proposed in the literature to de
fend against such attacks in static sensor
networks. However, these schemes rely on fixed sensor locations and hence do not
work in mobile sensor networks, where sensors are expected to move. In this work.

we propose a fast and effective mobi
le replica node detection
scheme using the Sequential Probability Ratio Test. To the best of our knowledge,
this is the first work to tackle the problem of replica node attacks in mobile sensor
networks. We show analytically and through simulation experi
ments that our
scheme detects mobile replicas in an efficient and robust manner at the cost of
reasonable overheads.



In Avances in robotics have made it

possible to develop a variety of
new architectures for autonomous wireless networks of sensors. Mobile nodes,
essentially small robots with sensing, wireless communications, and movement
capabilities, are useful for tasks such as static sensor deployment,

sampling, network repair, and event detection.These advanced sensor network
architectures could be used for a variety of applications including intruder
detection, border monitoring, and military patrols.In potentially hostile
environments, the s
ecurity of unattended mobile nodes is extremely critical. The
attacker may be able to capture and compromise mobile nodes, and then use them
to inject fake data, disrupt network operations, and eavesdrop on network
communications.In this scenario, a partic
ularly dangerous attack is the replica node
attack, in which the adversary takes the secret keying materials from a
compromised node, generates a large number of attacker
controlled replicas that
share the compromised node’s keying materials and ID, and th
en spreads these
replicas throughout the network. With a single captured node, the adversary can
create as many replica nodes as he has the hardware to generate. Note that replica
nodes need not be identical robots; a group of static nodes can mimic the
vement of a robot and other mobile nodes or even humans with handheld
devices could be used. The only requirement is that they have the software and
keying material to communicate in the network, all of which can be obtained from
the captured node.The time

and effort needed to inject these replica nodes into the
network should be much less than the effort to capture and compromise the
equivalent number of original nodes.

The replica nodes are controlled by the adversary, but have
keying ma
terials that allow them to seem like authorized participants in the
network. Protocols for secure sensor network communication would allow replica
nodes to create pairwise shared keys with other nodes and the base station, thereby
enabling the nodes to enc
rypt, decrypt, and authenticate all of their
communications as if they were the original captured node.The adversary can then
leverage this insider position in many ways. For example, he can simply monitor a
significant fraction of the network traffic that

would pass through these nodes.
Alternately, he could jam legitimate signals from benign nodes or inject falsified
data to corrupt the sensors’ monitoring operation. A more aggressive attacker
could undermine common network protocols, including cluster fo
localization, and data aggrega
tion, thereby causing continual disruption to
network operations. Through these methods, an adversary with a large number of
replica nodes can easily defeat the mission of the deployed network.

A stra
ightforward solution to stop replica node attacks is to prevent
the adversary from extracting secret key materials from mobile nodes by equipping
them with tamper
resistant hardware. We might expect such measures to be
implemented in mobile nodes with secu
critical missions. However, although
resistant hardware can make it significantly harder and more time
consuming to extract keying materials from captured nodes, it may still be possible
to bypass tamper resistance for a small number of nodes g
iven enough time and
attacker expertise. Since he adversary can generate many replicas from a single
captured node, this means that replica attacks are even more dangerous when
compared with the possibility of compromising many nodes. We thus believe that
it is very important to develop software
based countermeasures to defend mobile
sensor networks against replica node attacks.Several software
based replica node
detection schemes have been proposed for static sensor networks.

The primary method use
d by these schemes is to have nodes report
location claims that identify their positions and for other nodes to attempt to detect
conflicting reports that signal one node in multiple locations. However, since this
approach requires fixed node locations, it

cannot be used when nodes are expected
to move. Thus, our challenge is to design an effective, fast, and robust replica
detection scheme specifically for mobile sensor networks.In this paper, we propose
a novel mobile replica detection scheme based on the

Sequential Probability Ratio
Test (SPRT). We use the fact that an uncompromised mobile node should never
move at speeds in excess of the system
configured maximum speed. As a result, a
benign mobile sensor node’s measured speed will nearly always be less
than the
configured maximum speed as long as we employ a speed measurement
system with a low error rate. On the other hand, replica nodes are in two or more
places at the same time. This makes it appear as if the replicated node is moving
much faste
r than any of the benign nodes, and thus the replica nodes’ measured
speeds will often be over the system
configured maximum speed. Accordingly, if
we observe that a mobile node’s measured speed is over the system
maximum speed, it is then highl
y likely that at least two nodes with the same
identity are present in the network. However, if the system decides that a node has
been replicated based on a single observation of a node moving faster than it
should, we might get many false positives becau
se of errors in speed measurement.
Raising the speed threshold or other simple ways of compensating can lead to high
false negative rates.We apply the SPRT, a hypothesis testing method that can make
decisions quickly and accurately.

We p
erform the SPRT on every mobile node using a null
hypothesis that the mobile node has not been replicated and an alternate hypothesis
that it has been replicated. In using the SPRT, the occurrence of a speed that is less
than or exceeds the system
ed maximum speed will lead to acceptance of
the null or alternate hypotheses, respectively. Once the alternate hypothesis is
accepted, the replica nodes will be revoked from the network. We validate the
effectiveness, efficiency, and robustness of our sche
me through analysis and
simulation experiments. Specifically, we find that the main attack against the
based scheme is when replica nodes fail to provide signed location and time
information for speed measurement. To overcome this attack, we employ a
quarantine defense technique to block the noncompliant nodes.

We show through quarantine analysis that the amount of time,
during a given time slot, that the replicas can impact the network is very limited.
Second, we provide a detailed game
theoretic analysis that shows the limits of any
attacker strategy over any number of time slots. Specifically, we formulate a two
player game to model the interaction between the attacker and the defender, derive
the optimal attack and defense strategies,
and show that the attacker’s gain is
greatly limited when the attacker and the defender follow their respective optimal
strategies. We provide analyses of the number of speed measurements needed to
make replica detection decisions, which we show is quite
low, and the amount of
overhead incurred by running the protocol.We investigate how replica mobility
affects the detection capability of our scheme. In case of static (immobile) replicas,
the attacker keeps his replica nodes close together and immobile to
lessen the
chance of speed
based detection. An exploration of the static replica case is useful
since this case represents the worst case for detection, and thus we can see how our
scheme works in the worst case. The simulation results of both cases show t
hat this
scheme very quickly detects mobile replicas.




Driven (or Proactive)

The nodes maintain a table of routes to every destination in the network, for
this reason they periodically exchan
ge messages. At all times the routes to all
destinations are ready to use and as a consequence initial delays before sending
data are small. Keeping routes to all destinations up
date, even if they are not
used, is a disadvantage with regard to the usag
e of bandwidth and of network

Demand (or Reactive)

These protocols were designed to overcome the wasted effort in maintaining
unused routes. Routing information is acquired only when there is a need for it.
The needed routes are calculate
d on demand. This saves the overhead of
maintaining unused routes at each node, but on the other hand the latency for
sending data packets will considerably increase.


DSDV (Destination
Sequence Distance Vector)

DSDV has one routing table,
each entry in the table contains:
destination address, number of hopstoward destination, next hop
address. Routing table contains all the destinations that one node can
communicate. When a source A communicates with a destination B, it
looks up routing tab
le for the entry which contains

address as
B. Next hop address C was taken from that entry. A then sends its
packets to C and asks C to forward to B. C and other intermediate nodes
will work in a similar way until the packets reach B. DSDV mark
s each
entry by sequence number to distinguish between old and new route for
preventing loop.

DSDV use two types of packet to transfer routing information: full
dump and incremental packet.The first time two DSDV nodes meet, they
exchange all of their avai
lable routing information in full dump packet.
From that time, they only use incremental packets to notice about
change in the

routing table to reduce the packet size. Every node in DSDV has to send
update routing information periodically. When two routes
discovered, route with larger sequence number will be chosen. If two
routes have the same sequence number, route with smaller hop count to
destination will be chosen.

DSDV has advantages of simple routing table format, simple routing
operation and guar
antee loop
freedom. The disadvantages are (i) a large
overhead caused by periodical update (ii) waste

resource for finding all possible routes between each pair, but only one
route is used.


demand Routing Protocols

In on
demand trend, routin
g information is only created to
requested destination. Link is also monitored by periodical Hello
messages. If a link in the path is broken, the source needs to rediscovery
the path. On
demand strategy causes less overhead and easier to
scalability. Howev
er, there is more delay because the path is not always
ready. The following part will present AODV, DSR, TORA and ABR as
characteristic protocols of on
demand trend.

AODV Routing

Ad hoc on demand distance vector routing (AODV) is the combination
of DSDV an

each node maintains one routing table. Each routing table entry contains:

Active neighbor list: a list of neighbor nodes that are actively using
this route entry.

Once the link in the entry is broken, neighbor nodes in this list will be

Destination address

hop address toward that destination

Number of hops to destination

Sequence number: for choosing route and prevent loop

Lifetime: time when that entry expires

Routing in AODV consists of two phases: Route Discovery and

Maintenance. When a node

wants to communicate with a destination, it looks up in the routing table.
If the destination is found, node transmits data in the same way as in
DSDV. If not, it start Route Discovery mechanism: Source node
broadcast the Ro
ute Request packet to its neighbor nodes, which in turns
rebroadcast this request to their neighbor nodes until finding possible
way to the destination. When intermediate node receives a RREQ, it
updates the route to previous node and checks whether it sat
isfies the
two conditions:


there is an available entry which has the same destination with
RREQ (ii) its sequence number is greater or equal to sequence
number of RREQ. If no, it rebroadcast RREQ.


If yes, it generates a RREP message to the source node.
en RREP is routed back, node in the reverse path updates their
routing table with the added next hop information. If a node
receives a RREQ that it has seen before (checked by the sequence
number), it discards the RREQ for preventing loop. If source node
eceives more than one RREP, the one with greater sequence
number will be chosen. For two RREPs with the same sequence
number, the one will less number of hops to destination will be
chosen. When a route is found, it is maintained by Route
Maintenance mecha
nism: Each node periodically send Hello
packet to its neighbors for proving its availability. When Hello
packet is not received from a node in a time, link to that node is
considered to be broken. The node which does not receive Hello
message will invalida
te all of its related routes to the failed node
and inform other neighbor using this node by Route Error packet.
The source if still want to transmit data to the destination should
restart Route Discovery to get a new path. AODV has advantages
of decreasin
g the overhead control messages, low processing,
quick adapt to net work topology change, more scalable up to
10000 mobile nodes . However, the disadvantages are that AODV
only accepts bi
directional link and has much delay when it
initiates a route and re
pairs the broken link.


DSR is a reactive routing protocol which is able to manage a
MANET without using periodic table
update messages like table
routing protocols do. DSR was specifically designed for use in multi
wireless ad hoc networks. Ad
hoc protocol allows the network to be
completely self
organizing and self
configuring which means that there
is no need for an existing network infrastructure or administration.

For restricting the bandwidth, the process to

find a path is only
executed when a path is required by a node (On
Routing). In
DSR the sender (source, initiator) determines the whole path from the
source to the destination node (
) and deposits the addresses of
the intermediate nodes of the route in the packets.

Compared to other reactive routing protocols like ABR or SSA,
DSR is beacon
less which means that there are no hello
messages used
between the nodes to notify

their neighbors about her presence.

DSR was developed for MANETs with a small diameter between 5
and 10 hops and the nodes should only move around at a moderate

DSR is based on the Link
Algorithms which mean that each node
is capable to save

the best way to a destination. Also if a change appears
in the network topology, then the whole network will get this
information by flooding.

DSR contains 2 phases

Route Discovery

(find a


Route Maintenance

(maintain a path)

Route Discovery

If node A has in his Route Cache a route to the destination E, this route
is immediately used. If not
, the Route Discovery

protocol is started:


Node A (initiator) sends a

packet by flooding the


If node B has recently seen another RouteRequest from the same
target or if the address of node B
is already listed in the
Route Record
Then node B discards the request!


If node B is the target of the Route Discovery, it returns a
RouteReply to the initiator. The RouteReply contains a lis
t of the
“best” path from the initiator to the target. When the initiator
receives this RouteReply, it caches this route in its Route Cache for
use in sending subsequent packets to this destination.


Otherwise node B isn’t the target and it forwards the Ro
Request to his neighbors (except to the initiator).

process: Route Request & Route Reply

Route Maintenance

In DSR every node is responsible for confirming that the next hop
in the Source Route receives the packet. Also each packe
t is only
forwarded once by a node (hop
hop routing). If a packet can’t be
received by a node, it is retransmitted up to some maximum number of
times until a confirmation is received from the next hop.

Only if retransmission results then in a failure, a

message is sent to the initiator that can remove that Source Route from
its Route Cache. So the initiator can check his Route Cache for another
route to the target. If there is no route in the cache, a RouteRequest
packet is broadcasted.


f node C does not receive an acknowledgement from node D after
some number of requests, it returns a RouteError to the initiator A.


As soon as node receives the RouteError message, it deletes the
route from its cache. If A has another route to

E, it
sends the packet immediately using this new route.


Otherwise the initiator A is starting the Route Discovery process


Reactive routing protocols have no need to periodically flood the
network for updating the routing tables like t
driven routing
protocols do. Intermediate nodes are able to utilize the Route Cache
information efficiently to reduce the control overhead. The initiator only
tries to find a route (path) if actually no route is known (in cache).
Current and bandwidth

saving because there are no hello messages
needed (beacon


The Route Maintenance protocol does not locally repair a broken
link. The broken link is only communicated to the initiator. The DSR
protocol is only efficient in MANETs with l
ess then 200 nodes.
Problems appear by fast moving of more hosts, so that the nodes can
only move around in this case with a moderate speed. Flooding the
network can cause collusions between the packets. Also there is always
a small time delay at the begin

of a new connection because the initiator
must first find the route to the target.

2.2.3. TORA (Temporary Ordered Routing Algorithm)

TORA is based on link reversal algorithm. Each node in TORA
maintains a table with the distance and status of all the avai
lable links.
Detail information can be seen at [38]. TORA has three mechanisms for

Route Creation: TORA uses the "height" concept for discovering
multiple routes to a destination. Communication in TORA network is
downstream, from higher to lower

node. When source node does not
have a route to destination, it starts Route Creation by broadcasting the
Query messages (QRY). QRY is continuing broadcasted until reaching
the destination or intermediate node that have the route to the
destination. The r
eached node then broadcast Update (UPD) message
which includes its height. Nodes receiv e this UPD set a larger height for
itself than the height in UPD, appendthis height in its own UPD and
broadcast. This mechanism is called reversal algorithm and is cla
imed to
create number of direct links from the originator to the destination.

Route Maintenance: Once a broken link is discovered, nodes make a
new reference height and broadcast to their neighbors. All nodes in the
link will change their reference height

and Route Creation is done to
reflect the change.

Route Erasure: Erases the invalid routes by flooding the "clear
packet" through the network The advantages of TORA are: having
multiple paths to destination decreases the route creation in link broken
se therefore decrease overhead and delay to the network. TORA is
also claimed to be effective on large and mildly congested network [9].
The drawbacks are requiring node synchroniza tion due to "height"
metric and potential for oscillation. Besides that, T
ORA may not
guarantee to find all the routes for reserving in some cases.




To develop this system with IBM compatible personal computer
with Pentium IV processor was used.

Main processor


Pentium IV processor 1.13 GHz

Hard disk capacity



Cache memory


512 MB


Operating system


Fedora 8 (linux)

Scripting language


Network Simulator 2.33

Protocol developed



ting : Tool Command Language

Problem existing

Several replica node detection schemes have been proposed in the
literature to defend against such attacks in static sensor networks. However, these
schemes rely

on fixed sensor locations and hence do not work in mobile sensor
networks, where sensors are expected to move.

Proposed Method

The replica attacker can allow his nodes to randomly move or he
could move his replica nodes in different patterns i
n an attempt to frustrate our
proposed scheme.Replica nodes will appear to move much faster than benign

and thus their measured speeds will likely be over Vmax because they need to be
at two (or more) different places at

once. Accordingly, if the m
obile node’s measured speed exceeds Vmax , it is then
highly likely that at least two nodes

with the same identity are present in the network.


1.Topology formation

2.Data gathering

3.Functionality of replica node

4.Detection and Avoid
ance of replica nodes

1. Topology formation

This module describes the Deployment of sensor nodes and
neighbor node and region estimation in WSN.

2. Data gathering

This module deals with the nodes in the network. It shows

Sending sensed data to base station using corresponding neighbors.

3. Functionality of replica node

Capture and compromise mobile nodes,and then use them to inject fake
data, disrupt network operations, and eavesdrop on network communicatio

4. Detection and Avoidance of replica nodes

Replica nodes will appear to move much faster than Vmax.
Accordingly, if the mobile node’s measured speed exceeds Vmax,it is then highly
likely that at least two nodes with the same identity ar
e present in the network.

Future Enhancement

In this phase we address the probelm of sensor node failure.When a
sensor node fails because of energy depletion we need to choose alternative sensor
for that particular region.We will fix energy

threshold for each sensor,if it reaches
that threshold it will inform the base station about the death.The base station
should route another near
by energy
efficient sensor node to collect sensed data
from that particular failed region.



Network Simulator (NS2) is a discrete event driven simulator developed at
UC Berkeley. It is part of the VINT project. The goal of NS2 is to support
networking research and education. It is su
itable for designing new protocols,
comparing different protocols and traffic evaluations. NS2 is developed as a
collaborative environment. It is distributed freely and open source. A large amount
of institutes and people in development and research use, m
aintain and develop
NS2. This increases the confidence in it. Versions are available for FreeBSD,
Linux, Solaris, Windows and Mac OS X.


NS2 is built using object oriented methods in C++ and OTcl (object oriented
variant of Tcl.

ig 5.1 Simplified User’s View of Ns

can see in Fig 5.1, NS2 interprets the simulation scripts written in OTcl. A user has
to set the different components (e.g. event scheduler objects, network components
libraries and setup module libraries) up in the simu
lation environment. The user
writes his simulation as a OTcl script, plumbs the network components together to
the complete simulation. If he needs new network components, he is free to
implement them and to set them up in his simulation as well. The event

as the other major component besides network components triggers the events of
the simulation (e.g. sends packets, starts and stops tracing). Some parts of NS2 are
written in C++ for efficiency reasons. The data path (written in C++) is separate
from the control path (written in OTcl). Data path object are compiled and then
made available to the OTcl interpreter through an OTcl linkage (tclcl) which maps
methods and member variables of the C++ object to methods and variables of the
linked OTcl o
bject. The C++ objects are controlled by OTcl objects. It is possible
to add methods and member variables to a C++ linked OTcl object.


Functionalities for wired, wireless networks, tracing, and visualization are
available i
n NS2.

Support for the wired world include

Routing DV, LS, and PIM

Transport protocols: TCP and UDP for unicast and SRM for multicast.

Traffic sources: web, ftp, telnet, cbr (constant bit rate), stochastic, real audio.

nt types of Queues: drop
tail, RED, FQ, SFQ, DRR.

Quality of Service: Integrated Services and Differentiated Services.


Support for the wireless world include

Ad hoc routing with different protocols, e.g. AODV, DSR, DSDV, TORA

wireless networks

Mobile IP

Directed diffusion



Multiple propagation models (Free space, two
ray ground, shadowing)

Energy models



Network Animator (NAM)

ce Graph


Mobile Movement Generator

Fig 5.2 OTcl and C++: the duality MOBILE NETWORKING IN NS2.33

This section describes the wireless model that was originally ported as
CMU’s Monarch group’s mobility extension to
. The first
section covers the
original mobility model ported from CMU/Monarch group. In this section, we
cover the internals of a mobile node, routing mechanisms and network components
that are used to construct the network stack for a mobile node. The components
t are covered briefly are Channel, Network interface, Radio propagation model,
MAC protocols, Interface Queue, Link layer and Address resolution protocol
model (ARP). CMU trace support and Generation of node movement and traffic
scenario files are also cov
ered in this section. The original CMU model allows
simulation of pure wireless LANs or multihop ad
hoc networks. Further extensions
were made to this model to allow combined simulation of wired and wireless
networks. MobileIP was also extended to the wire

The wireless model essentially consists of the MobileNode at the core, with
additional supporting features that allows simulations of multi
hop ad
networks, wireless LANs etc. The MobileNode object is

a split object. The C++
class MobileNode is derived from parent class Node. A MobileNode thus is the
basic Node object with added functionalities of a wireless and mobile node like
ability to move within a given topology, ability to receive and transmit s
ignals to
and from a wireless channel etc. A major difference between them, though, is that
a MobileNode is not connected by means of Links to other nodes or mobilenodes.
In this section we shall describe the internals of MobileNode, its routing
, the routing protocols dsdv, aodv, tora and dsr, creation of network
stack allowing channel access in MobileNode, brief description of each stack
component, trace support and movement/traffic scenario generation for wireless
simulations. MOBILE NO

MobileNode is the basic
Node object with added functionalities like movement,
ability to transmit and receive on a channel that allows it to be used to create
mobile, wireless simulation environments. The class MobileNode i
s derived from
the base class Node. MobileNode is a split object. The mobility features including
node movement, periodic position updates, maintaining topology boundary etc are
implemented in C++ while plumbing of network components within MobileNode
lf (like classifiers, dmux , LL, Mac, Channel etc) have been implemented in

Table 5.1: Available Options For Node Configuration


Available Values



Address type

Flat, Hierarchical





Both Satellite and Wireless Oriented

Wired Routing



II Type



Mac Type



ifq Type



Phy Type




Available Values


Satellite Oriented





<bandwidth value, e.g “2MB”>


Wireless Oriented

Adhoc Routing





Propagation/2RayGround,Propagation Shadowing



Propagation/2RayGround,Propagation Shadowing



Antenna/Omni Antenna



Channel/Wireless Channel,Channel/sat



<toplogy file>





Energy model

Energy model


Initial Energy

<value in joules>



<value in W>



<value in W>


Idle Power

<value in W>
























Fast Detection of Mobile Replica Node

Attacks in Wireless Sensor Networks

Using Sequential Hypothesis Testing

We assume that an adversar
y may compromise and fully control a
subset of the sensor nodes, enabling him to mount various kinds of attacks. For
instance, he can inject control protocols such as localization, time synchroniza

tion,and route discovery process. Furthermore, he can la
unch denial
attacks by jamming the signals from benign nodes. However, we place some limits
on the ability of the adversary to compromise nodes. We note that if the adversary
can compromise a major fraction nodes of the network, he will not nee
d nor benefit
much from the deployment of replicas.To amplify his effectiveness, the adversary
can also launch a replica node attack, which is the subject of our investigation.

We assume that the adversary can produce many replica nodes

and that they will be accepted as a legitimate part of the network. We also assume
that the attacker attempts to employ as many replicas of one or more compromised
sensor nodes in the network as will be effective for his attacks. The attacker can
allow hi
s replica nodes to randomly move or he could move his replica nodes in
different patterns in an attempt to frustrate our proposed scheme. We also assume
that the base station is a trusted entity. This is a reasonable assumption in mobile
sensor networks, b
ecause the network operator collects all sensor data and can
typically control the nodes’ operation through the base station. Thus, the basic
mission of the sensor network is already completely undermin if the base station is



The details of our technique to detect replica node attacks in mobile
sensor networks. In static sensor networks, a sensor node is regarded as being
replicated if it is placed i
n more than one location. If nodes are moving around in
network, however, this technique does not work, because a benign mobile node
would be treated as a replica due to its continuous change in location. Hence, we
must use some other technique to detect r
eplica nodes in mobile sensor networks.
Fortunately,mobility provides us with a clue to help resolve the mobile replica
detection problem. Specifically, a benign mobile sensor node should never move
faster than the system
configured maximum speed, Vmax .

As a result, a benign mobile sensor node’s measured speed will
appear to be at most Vmax as long as we employ a speed measurement system
with a low rate of error. On the other hand, replica nodes will appear to move
much faster than benign no
des and thus their measured speeds will likely be over
Vmax because they need to be at two (or more) different places at once.
Accordingly, if the mobile node’s measured speed exceeds Vmax , it is then highly
likely that at least two nodes with the same id
entity are present in the network.We
propose a mobile replica detection scheme by leveraging this intuition. Our scheme
is based on the Sequential Probability Ratio Test which is a statistical decision

The SPRT can be thought of

as one
dimensional random walk
with the lower and upper limits. Before the random walk starts, null and alternate
hypotheses are defined in such a way that the null hypothesis is associated with the
lower limit while the alternate one is associated with t
he upper limit. A random
walk starts from a point between two limits and moves toward the lower or upper
limit in accordance with each observation. If the walk reaches (or exceeds) the
lower or upper limit, it terminates and the null or alternate hypothesi
s is selected,
respectively. We believe that the SPRT is well suited for tackling the mobile
replica detection problem since we can construct a random walk with two limits in
such a way that each walk is determined by the observed speed of a mobile node.
he lower and upper limits can be configured to be associated with speeds less
than and in excess of Vmax , respectively.

We apply the SPRT to the mobile replica detection problem as
follows: Each time a mobile sensor node moves to a new lo
cation, each of its
neighbors asks for a signed claim containing its location and time information and
decides probabilistically whether to forward the received claim to the base station.
The base station computes the speed from every two consecutive claim
s of a
mobile node and performs the SPRT by considering speed as an observed sample.
Each time the mobile node’s speed ,exceeds (respectively, remains below) Vmax ,
it will expedite the random walk to hit or cross the upper (respectively,lower) limit
and t
hus lead to the base station accepting the alternate (respectively, null)
hypothesis that the mobile node has been (respectively, not been) replicated. Once
the base station decides that a mobile node has been replicated, it revokes the
replica nodes from
the network.Let us first describe the detection scheme and then
analyze its security and performance.



Network simulator 2 is used as the simulation tool in this
project. NS was chose
n as the simulator partly because of the range of features it
provides and partly because it has an open source code that can be modified and
extended. There are different versions of NS and the latest version is ns
while ns
2.1b10 is under developm


Network simulator (NS) is an object

oriented, discrete
event simulator for networking research. NS provides substantial support for
simulation of TCP, routing and multicast protocols o
ver wired and wireless
networks. The simulator is a result of an ongoing effort of research and developed.
Even though there is a considerable confidence in NS, it is not a polished product
yet and bugs are being discovered and corrected continuously.

NS is written in C++, with an OTcl1 interpreter as a command and
configuration interface. The C++ part, which is fast to run but slower to change, is
used for detailed protocol implementation. The OTcl part, on the other hand, which
runs much slower bu
t can be changed very fast quickly, is used for simulation
configuration. One of the advantages of this split
language program approach is
that it allows for fast generation of large scenarios. To simply use the simulator, it
is sufficient to know OTcl. O
n the other hand, one disadvantage is that modifying
and extending the simulator requires programming and debugging in both

NS can simulate the following:

1. Topology:
Wired, wireless

2. Sheduling Algorithms:
RED, Dro
p Tail,

3. Transport Protocols:

4. Routing:
Static and dynamic routing

5. Application:
FTP, HTTP, Telnet, Traffic generators



OTcl Script

OTcl Interpreter

imulation Results

re 5.1

Block diagram of Architecture of NS


This section talks about the NS components, mostly compound network
components. Figure 1.1 shows a partial OTcl class hierarchy of NS, which will
help understanding the basic network c

Figure 5.2

OTcl Class Hierarchy

The root of the hierarchy is the TclObject class that is the super class of

C++ Libraries

all OTcl library objects (scheduler, network components, timers and the other
objects including NA
M related ones). As an ancestor class of TclObject, NsObject
class is the super class of all basic network component objects that handle packets,
which may compose compound network objects such as nodes and links. The basic
network components are further d
ivided into two subclasses, Connector and
Classifier, based on the number of the possible output DATA paths. The basic
network and

objects that have only one output DATA path are under the Connector class, and
switching objects that have possible multiple
output DATA paths are under the
Classifier class.


The class Tcl encapsulates the actual instance of the OTcl interpreter and
provides the methods to access and communicate with that interpreter, code. The
class provides methods for the foll
owing operations:

1.obtain a reference to the Tel instance

2.invoke OTcl procedures through the interpreter

3.retrieve, or pass back results to the interpreter error situations and exit in an uniform manner and lookup "TclObjec

6.acquire direct access to the interpreter.

5.4.1 Obtain a Reference to the class Tcl instance

A single instance of the class is declared in
tclcl/ as a static
member variable. The statement required to access this instance is Tel& tel =

5.4.2 Invoking OTcl Procedures

There are four different methods to invoke an OTcl command
through the instance, tcl. They differ essentially in their calling arguments. Each
function passes a string to the interp
reter that then evaluates the string in a global
context. These methods will return to the caller if the interpreter returns TCL_OK.
On the other hand, if the interpreter returns TCL_ERROR, the methods will call
tkerror{}. The user can overload this proced
ure to selectively disregard certain
types of errors.


Passing Results to/from the Interpreter :
When the interpreter invokes a
C++ method, it expects the result back in the private member variable, tcl


Error Reporting and Exit:
This method provi
des a uniform way to report
errors in the compiled code.


For every TclObject that is created, ns establishes the instance
procedure,cmd{}, as a hook to executing methods through the compiled shadow
object. Th
e procedure cmd{} invokes the method command() of the shadow object
automatically, passing the arguments to cmd{} as an argument vector to the
command() method. The user can invoke the cmd {} method in one of two ways,
by explicitly invoking the procedure,

specifying the desired operation as the first
argument, or implicitly, as if there were an instance procedure of the same name as
the desired operation. Most simulation scripts will use the latter form.

Consider the distance computation in S
RM is done by the compiled
object. It is often used by the interpreted object. It is usually invoked as
$srmObject distance? (agentAddress)If there is no instance procedure called
distance? the interpreter will invoke the instance procedure unknown{}, def
ined in
the base class TclObject. The unknown procedure then invokes

$srmObject cmd distance? (agentAddress)

to execute the operation through the compiled object's command()
procedure. The user could explicitly invoke the operation directly. One reason fo
this might be to overload the operation by using an instance procedure of the same

For example,

Agent/SRM/Adaptive instproc distance? addr {

$self instvar distanceCache_($addr)

if![info exists distanceCache_($addr)] {

set distanceCache_($addr)
[$self cmd distance? $addr]


set distanceCache_($addr)


The following shows how the command() method using SRMAgent::command()

int ASRMAgent::command(int argc, const char*const*argv) {

Tcl& tcl = Tcl::instance();

if (argc == 3) {

if (strcmp(argv[1], "di
stance?") == 0) {

int sender = atoi(argv[2]);

SRMinfo* sp = get_state(sender);

tcl.tesultf("%f", sp

return TCL_OK;




return (SRMAgent::command(argc, argv));

The following observations are made from this piece of code:

The function is cal
led with two arguments. The first argument (argc)
indicates the number of arguments specified in the command line to the interpreter.
The command line arguments vector (argv) consists of argv[0] contains the name
of the method, "cmd" and argv[1] specifies
the desired operation. If the user
specified any arguments, then they are placed in argv[2...(argc

1)]. The arguments
are passed as strings. They must be converted to the appropriate data type.If the
operation is successfully matched, the match should re
turn the result of the
operation,command () itself must return either TCL_OK or TCL_ERROR to
indicate success or failure as its return code. If matched in this method, it must
invoke its parent's command method, and return the corresponding result. This
ermits the user to conceive of operations as having the same inheritance
properties as instance procedures or compiled methods.In the event that this
command method is defined for a class with multipleinheritance, one of two
implementations can be chosen

ither they can invoke one of the parent's command method, and return
the result of that invocation.

2.They can each of the parent's command methods in some sequence, and
return the result of the first invocation that is successful. If none of them ar
successful, then they should return an error.


The wireless model essentially consists of the Mobile Node at the core
with additional supporting features that allows simulations of multi
hop ad
networks, wireless LANs etc.

The Mobile Node object is a split object. The C++
class Mobile Node is derived from parent class Node. A Mobile Node thus is the
basic Node object with added functionalities of a wireless and mobile node like
ability to move within a given topology, abili
ty to receive and transmit signals to
and from a wireless channel etc. A major difference between them is that a mobile
Node is not connected by means of Links to other nodes or mobile nodes.

Mobile Node is the basic nsNode object with added functionalitie
s like
movement, ability to transmit and receive on a channel that allows it

to be used to
create mobile, wireless simulation environments. The class Mobile Node is derived
from the base class Node. The four ad
hoc routing protocols that are currently
orted are, Dynamic Source Routing (DSR), Temporally ordered Routing
Algorithm (TORA) and Adhoc On
demand Distance Vector (AODV).

The general structure for defining a mobile node in ns2 is described as

$ns node
adhocRouting $
opt (adhocRouting)

IIType $opt (II)

macType $opt (mac)

ifqType $opt (ifq)
ifqLen $opt (ifqlen)

antType $opt (ant)

proplnstance [new $opt (prop)
phyType $opt (netif)

channel [new $opt (chan)]

topolnstance $topo

wiredRouting OFF


routerTrace OFF

macTrace OFF

The above API configures for a mobile node with all the given values of
ad hoc
routing protocol, network stack, channel, topography, propagation model,
with wired routing turned on or off (required for wired

and tracing turned on or off at different levels (router, mac, agent).


In this paper, we have proposed a replica detection scheme for
mobile sensor networks based on the SPRT. We have analytically

the limitations of attacker strategies to evade our detection technique. In particular,
we first showed the limitations of a group attack strategy in which the attacker
controls the movements of a group of replicas.We presented quantitative a
of the limit on the amount of time for which a group of replicas can avoid
detection and quarantine. We also modeled the interaction between the detector
and the adversary as a repeated game and found a Nash equilibrium. This Nash
equilibrium sho
ws that even the attacker’s optimal gains are still greatly limited by
the combination of detection and quarantine. We performed simulations of the
scheme under a random movement attack strategy in which the attacker lets
replicas randomly move in the netw
ork and under a static placement attack strategy
in which he keeps his replicas from moving to best evade detection. The results of
these simulations show that our scheme quickly detects mobile replicas with a
small number of location claims against eithe
r strategy.


[1] M. Conti, R.D. Pietro, L.V. Mancini, and A. Mei, “A Randomized,

Efficient, and Distributed Protocol for the Detection of Node

Replication Attacks in Wireless Sensor Networks,” Proc. ACM

MobiHoc, pp. 80
89, Sept. 2007.

] K. Dantu, M. Rahimi, H. Shah, S. Babel, A. Dhariwal, and G.S.

Sukhatme, “Robomote: Enabling Mobility in Sensor Networks,”

Proc. Fourth IEEE Int’l Symp. Information Processing in Sensor

Networks (IPSN), pp. 404
409, Apr. 2005.

[3] J. Ho, M. Wright, a
nd S.K. Das, “Fast Detection of Replica Node

Attacks in Mobile Sensor Networks Using Sequential Analysis,”

Proc. IEEE INFOCOM, pp. 1773
1781, Apr. 2009.

[4]J. Ho, D. Liu, M. Wright, and S.K. Das, “Distributed Detection of

Replicas with Deployment Knowledg
e in Wireless Sensor Networks,”

Ad Hoc Networks, vol. 7, no. 8, pp. 1476
1488, Nov. 2009.

[5] L. Hu and D. Evans, “Localization for Mobile Sensor Networks,”

Proc. ACM MobiCom, pp. 45
57, Sept. 2004.

[6]J. Jung, V. Paxon, A.W. Berger, and H. Balakrish
nan, “Fast

Portscan Detection Using Sequential Hypothesis Testing,” Proc.

IEEE Symp. Security and Privacy, pp. 211
225, May 2004.

[7] A. Liu and P. Ning, “TinyECC: A Configurable Library for Elliptic

Curve Cryptography in Wireless Sensor Networks,” Pro
c. Seventh

IEEE Int’l Symp. Information Processing in Sensor Networks (IPSN),

[8] B. Parno, A. Perrig, and V.D. Gligor, “Distributed Detection of

Node Replication Attacks in Sensor Networks,” Proc. IEEE Symp.

Security and Privacy, pp. 49
63, May 2005.

[9] H. Song, S. Zhu, and G. Cao, “Attack
Resilient Time Synchronization for

Wireless Sensor Networks,” Ad Hoc Networks, vol. 5, no. 1,pp. 112
125, Jan.

[10] K. Sun, P. Ning, C. Wang, A. Liu, and Y. Zhou, “TinySeRSync:

Secure and Resilient

Time Synchronization in Wireless Sensor

Networks,” Proc. 13th ACM Conf. Computer and Comm. Security

(CCS), pp. 264
271, Oct. 2006.

[11] G. Theodorakopoulos and J.S. Baras, “Game Theoretic Modeling

of Malicious Users in Collaborative Networks,” IEEE
J. Selected

Areas in Comm., vol. 26, no. 7, pp. 1317
1326, Sept. 2008.

[12] A. Wald, Sequential Analysis. Dover, 2004.

[13] Wang, B. Sheng, C.C. Tan, and Q. Li, “Comparing Symmetric

and Public
Key Based Security Schemes in Sensor Networks:

A Ca
se Study of User Access Control,” Proc. IEEE Int’l Conf.

Distributed Computing Systems (ICDCS), pp. 11
18, June 2008.

[14] K. Xing, F. Liu, X. Cheng, and H.C. Du, “Real
Time Detection of

Clone Attacks in Wireless Sensor Networks,” Proc. IEEE Int’l Con

Distributed Computing Systems (ICDCS), pp. 3
10, June 2008.

[15] C.
M. Yu, C.
S. Lu, and S.
Y. Kuo, “Efficient and Distributed

Detection of Node Replication Attacks in Mobile Sensor Net

works,” Proc. IEEE Vehicular Technology Conf. Fall (VTC Fall
), Sept.2009.