Secure Reporting of Traffic Forwarding Activity in Mobile Ad Hoc Networks
Heesook Choi, William Enck, Jaesheung Shin, Patrick McDaniel, Thomas F. La Porta
Department of Computer Science and Engineering
Pennsylvania State University, University Park, PA 16802
Nodes forward data on behalf of each other in mobile
ad hoc networks. In a civilian application, nodes are as-
sumed to be selfish and rational, i.e., they pursue their own
self-interest. Hence,theabilityto accuratelymeasuretraffic
forwarding is critical to ensure proper network operation.
These measurements are often used to credit nodes based
on their level of participation, or to detect loss. Past solu-
tions employ neighbor monitoring and reporting on node
forwarding traffic. These methods are not applicable in
civilian networks where neighbor nodes lack the desire or
ability to perform the monitoring function. Such environ-
constrained, or in networks where directional antennas are
used and reliable monitoring is difficult or impossible.
In this paper, we propose a protocol that uses nodes on
the data path to securely produce packet forwarding re-
ports. Reporting nodes are chosen randomly and secretly
so that malicious nodes cannot modify their behavior based
uponthe monitoring point. The integrity and authenticity of
reports are preserved through the use of secure link layer
acknowledgments and monitoring reports. The robustness
of the reporting mechanism is strengthened by forwarding
the report to multiple destinations (source and destination).
We explore the security, cost, and accuracy of our protocol.
The establishment of a wireless infrastructure is non-
trivial, especially in volatile environments where node mo-
bility dominates. Occasionally, erecting xed infrastruc-
tures is not feasible due to location or temporal validity.
For example, it is not possible to build a wireless tower in
the middle of a hostile battleeld. Furthermore, the tower
cannot be moved as an attack progresses. In other mission-
oriented scenarios such as search and rescue, terrestrial ob-
stacles, e.g. avalancheprone mountains, inhibit the creation
of xed access points.
In the absence of a xed infrastructure, mobile ad hoc
networks (MANETs) can be used.
xed infrastructure or centralized control for communica-
tion, MANETs are well suited for the aforementioned sce-
narios. Within the network, multi-hop paths are created
between nodes that formerly could not communicate. Ide-
ally, each node selessly forwards each packet to the next
node in the path. As nodes move, they leave and join vari-
ous communication links, thus promoting many ephemeral
Reliable operation in a MANET requires explicit coop-
eration between nodes. While this is feasible to assume for
mission-oriented scenarios, careful consideration needs to
take place when applyingMANETs to civilian applications.
In a civilian mobile ad hoc network, communicating nodes
will use any relay points present. It is conceivable that self-
ish or malicious nodes exist in these networks. Addition-
ally, reliability can be severely impacted by network con-
gestion and mobility. Ergo, there is a need to detect self-
ish or malevolent behavior, promote cooperation between
nodes, and route around network congestion.
One method for detecting malicious behavior is to gen-
erate reports on trafc ow between nodes. This informa-
tion can be used to not only detect misbehavior, but also to
indicate good network citizens. By identifying nodes that
play fairly, a payment scheme can be implemented in order
to further promote cooperation. Trafc reports can also be
used to detect bottlenecks.
to eavesdrop on data transmissions in order to generate re-
ports. While this may work well in networks with trusted
nodes, i.e. military settings, it is not feasible for civilian ad
hoc networks. Furthermore, such techniques may also fail
in military settings if directional antennas are used, since
nodes cannot reliably monitor data transmissions.
In this paper, we propose a secure random reportingpro-
tocol for a civilian ad hoc network, in which the source and
destination collect reports from intermediate nodes on the
routing path. Every data packet delivered initiates a re-
port from one intermediate node that is randomly chosen
By not requiring a
by a source node. The chosen node then integrates its self-
report into the packet before forwarding the transmission.
The symmetric-keyconstructionefciently prevents disclo-
sure of the selected node’s identity from all adversaries ex-
ceptthose that can mountlargescale trafc analysis attacks.
Note that reports may become lost due to mobility and con-
gestion. In order to provide robustness in the face of loss,
the report is sent to the source, the destination, or both.
While the secure random reporting protocol provides se-
cret node selection, as well as integrity and authenticity of
reports, it does not guarantee that the self-report is accu-
rate. Although nodes cannot manipulate others’ reports,
theymay not be trusted to generateaccurate reports. To rec-
tify this inadequacy,we propose a forgerydetection scheme
that provides proofs of delivery implementedby secure net-
work layer acknowledgments.
We have simulated these schemes using ns-2 . Our
results show that we accurately monitor packet forwarding
activity even in lossy networks. We further simulate ma-
licious packet dropping to look at the effectiveness of our
secure random reporting protocol.
The rest of this paper is organized as follows. Section 2
reviews previous research in malicious node detection and
cooperation in ad hoc networks. Section 3 describes possi-
overview of the proposed random reporting protocol. This
scheme is then strengthened in Section 5 as we extend it
to provide report integrity, node selection condentiality,
and preventionof falsied reports. Next, Section 6 provides
simulationresults andcomputationaloverheadofthe secure
random reporting protocol. Finally, Section 7 concludes.
2. Related Work
Detection of malicious behavior and collection of coop-
eration history for crediting are two motivating factors for
monitoring nodes. This section discusses previous research
in these areas.
2.1. Detection of Malicious Behavior
The Watchdog/Pathrater  scheme proposes the use
of a watchdog for detecting misbehaving nodes, and a
pathrater to help the routing protocol avoid detected misbe-
having nodes. The design utilizes intermediate nodes along
the routing path, wherein a node sends a packet to an in-
termediate downstream node and veries the node that for-
wards it. If the node does not send the packet within a pre-
dened period, it is declared as misbehaving, and the moni-
toringnode noties the source. Pioneering the area of intru-
sion detection in ad hoc networks, Zhang and Lee [16, 17]
propose a general architecture, in which all nodes partic-
ipate in the monitoring of data transmission. Each node
is responsible for monitoring a transmission range and co-
operating with neighboring nodes in order to detect intru-
sions. Zhang and Lee later proposed a second scheme to
reduce the number of nodes involved in monitoring . In
this cluster-based scheme, a cluster head (CH) is elected
for monitoring data trafc within the transmission range.
The elected CH is responsible for monitoring all neighbor-
ing nodes and checking statistics. AODVSTAT  im-
plements an intrusion detection system (IDS) within the
AODV  routingprotocol. The system monitorsforrout-
ing message drops, data-packet drops, MAC/IP spoong,
and resource depletion attacks. In AODVSTAT, an IDS
monitorsall observabletransmissionsfromneighbors. Note
that all of the above schemes require some level of commu-
nication eavesdropping. These solutions are not feasible in
our target environments because reliable eavesdropping is
Awerbuchet al. proposeanalternateschemethat uses
intermediate nodes on the data path. If a source does not re-
ceive an ACK from a destination, the source begins probing
all intermediate nodes. This causes each node along the
path to send an ACK back to the source. Unfortunately,due
to the dynamic characteristics of MANETs, data paths can
change frequently, possibly before the failed link is found.
Many times, cooperation between nodes cannot be
expected without incentives.
been proposed that use payment schemes. A node may
be paid via a credit for behaving cooperatively or ex-
cluded/penalized for misbehaving.
Sprite  proposes an incentive system where selsh
nodes are encouraged to cooperate. In Sprite, each node is
motivatedtohonestlyreportits actions,evenin thepresence
of selsh node collusion. Intermediatenodes retain receipts
of received messages. The receipt is then sent to the CCS
(Credit Clearance Service) as proof of forwarding, and the
CCS then charges/credits based on the received reports.
CORE , another cooperation algorithm, uses a col-
laborative reputation mechanism to encourage nodes to co-
operate. The reputation is calculated via both direct and
indirect observation by a node and its neighboring nodes,
respectively, within the transmission range.
scheme, CONFIDANT , each node monitors nodes ex-
isting one hop away. If a node detects and concludes mal-
ice, it generates an ALARM message to either a source or
a friend. This, in turn, causes misbehaving nodes to be ex-
cluded from the community.
All of the aforementioned detection and cooperation
schemes require the observation of neighboring nodes. Ad-
ditionally, these schemes deal only with detection or coop-
eration. Our reporting protocol targets more general appli-
Several algorithms have
cations, including both detection of malicious behavior and
crediting for cooperation. The information provided by the
reportingscheme is also vital for detectingdatabottlenecks.
3. Threat Model
tential for anomalous behavior. Inconsistencies arise from
self-interest, maliciousness, network congestion, and mo-
bility. This section discusses these threats and how they
pertain to packet forwarding activity and report collection.
The discussion illuminates the set of threats to which we
aim to be resilient.
It is important to note that the high loss and delay preva-
lent in wireless and mobile networks exacerbates the prob-
lem of detecting selsh/malicious nodes. If a node drops
packets and moves, it is difcult to detect whether the
packet loss is from mobility or selshness/maliciousness.
Likewise, in a congested network, packets are dropped be-
cause of packet buffer overows. Distinguishing between
selsh/malicious drops and congestion is difcult. Regard-
less of the reasons for packet loss, a source node may wish
to avoid particular nodes due to the mere occurrence of lost
packets, whether it be the result of selsh/malicious behav-
ior or simply network congestion.
Most formsofnon-cooperationresult indenialofservice
(DoS). In the extreme case, an ill-performing node would
simply refrain in participating in routing, and hence would
never be placed on a path. Possibly more damaging, a sim-
ilar attack would allow the node to accept a position on the
path, but it would not forward data packets. Our protocol
does nothing to prevent or detect attacks on the routing pro-
tocol, but ratherfocuses on accurate reportingof packet for-
Nodes may also drop packets selectively. For example,
a selsh node may choose not to forward packets for a spe-
cic source or destination, or conversely, simply favor a
source or destination by dropping trafc for others when
they are in competition. Similarly, the node can choose par-
ticular applications to drop or show preferential treatment.
Finally, a node may randomly drop packets in order to sim-
ply save energy.
Note that only a few well-selected drops are necessary
to vastly reduce the throughput between a source and des-
tination: each drop causes the congestion control algorithm
to aggressively throttle trafc . Connection recovery is
slow, and the attacker gains advantagewith little effort.
Moresubtleattacksexist. Increditbasedsystems, anode
benets from forwarding more packets than its neighbors.
To gainan advantage,a maliciousnodeinjects fakepackets.
This expends the energy of all forwarding nodes, thereby
rendering them incapable of forwarding future legitimate
packets. The known defense for this attack is to use inter-
leaved hop-by-hop authentication schemes [19, 20], where
fake packets are ltered mid-transmission. This paper does
not address this type of attack.
Existing proposed cooperation schemes for civilian ad
hoc networks use rewards or penalties to encourage coop-
eration. Rewards and penalties are dictated by reports of
mobile node behavior. The credit for relaying other trafc
The policy motivates mobile nodes to cheat, manipulate, or
dropthe reports so that they get more credit and avoid being
penalized. Defending against potential forwarding and re-
play attacks on the reporting data is a challenging issue for
monitoring the packet forwarding activity.
4. Overview of Random Reporting Protocol
Forthe purposesofthis paper,it is assumedthat dynamic
source routing (DSR)  is used. The DSR routing proto-
col provides a full path between the source and destination.
This is advantageouswhen choosing a random intermediate
node. It is reasonable to assume that the source and desti-
nation nodes are trusted, as they are the entities responsible
for the data trafc. The protocol focuses on the secure re-
porting of forwarding activities for the data transmission.
Each intermediate node only needs to keep track of its
own contribution, instead of observing the actions of other
nodes. Using intermediate nodes in this manner is rational
when dealing with a civilian ad hoc network. The rest of
this section provides an overview of the Random Report-
ing Protocol. While alone the Random Reporting Protocol
is not secure, Section 5 introduces the Secure Random Re-
4.1. Basic Periodic Reporting
Basic Periodic Reportingis a simplistic methodin which
intermediate nodes periodically send reports to the destina-
tion. These reportsare collected by the destination andused
to analyze network paths. The compiled report is then used
for future path engineering, crediting, and determination of
This simple periodic reporting scheme functions well
for static networks, but it does not work well for dynamic
networks, or networks with malicious nodes.
scheme’s quality is highly dependent on report transmis-
sion frequency. Additionally, rapid changes due to mobility
or congestion quickly degrade its effectiveness, because re-
ports may be lost or paths may change before reports are
gathered. Since reliable transmission is not guaranteed, the
disappearance of a node’s report may cause it to be viewed
as an anomalous or congested point, even if it has correctly
forwarded all data packets. The report data is transmitted
via the same path as normal data. This allows a selsh or
c) Random Bidirectional Reporting: At node 2, report is transmitted to both S and D
b) Random Node and Direction Selection: Node 2 sends a report to the source S
a) Random Node Selection: Node 2 is chosen.
Figure 1. Random Reporting Protocol: source S and destination D
malicious node to know the source of any report. The node
can then drop or change particular reports for their own self
4.2. Random Reporting Node Selection (RRNS)
In order to address the aforementioned problems with
packet manipulation and dynamic networks, we propose a
Random Reporting Node Selection (RRNS) method. For
every packet, the source randomly chooses one intermedi-
ate node to send a report to the destination. This is accom-
plished by coupling each data packet with a report, so that
when the report is received by the destination, the relaying
In RRNS, if the path consists of n intermediate nodes,
any node can be chosen with probability 1/n. Figure 1-(a)
illustrates RRNS where node 2 has been randomly chosen.
1. For all packets p, source S randomlychooses (uniform
distribution) intermediate node nito send a report. S
attaches a report request RR to p, identifying nias the
2. For a packet p with RR for ni, niattaches report R to
p before forwarding to destination D.
3. Destination D receives p, including R from all inter-
mediate nodes, and periodically analyzes the reports,
looking for trafc deviations.
The idea of choosing a random node is motivated by
micro-payment [7, 11], in which a randomly chosen trans-
action is used for a merchant to deposit some amount of
money. Applied to RRNS, the randomly chosen intermedi-
ate node should add to the forwarding packet the number of
packets it has forwarded since joining the path.
Since the intermediate node is selected randomly, other
nodesare unableto predict the selection schedule. This pre-
vents nodes from timing their attacks to maximize their du-
ration. While the randomness provides better reports, the
described scheme is vulnerable to attack. Without taking
precautions, reports may be manipulated by downstream
nodes with selsh intentions. Section 5 addresses this by
introducing secret node selection. In summary, RRNS is
advantageous, because it gathers reports from nodes in real
time and has very low communication overhead, due to the
couplingof reportswith everydata packet. We quantifythis
overhead in Section 6.
4.3. Random Reporting Node and Direction Selec-
In RRNS, if packets are lost due to congestion or mobil-
ity, the destination will only receive the reports sent before
the anomaly occurred. Thus, the destination may misinter-
pret the location of the problem.
Random Reporting Node and Direction Selection
(RRNDS) is proposedto makeRRNS morerobust. RRNDS
extendsStep 2 of RRNS byrandomlydecidingthedirection
to send the report at the chosen node. If the report is sent
towards the destination, it is attached to the data packets,
just as in RRNS. On the other hand, if a source-bound di-
rection is chosen, a separate report message is transmitted.
Figure 1-(b) shows this scheme.
4.4. Random Bidirectional Reporting (RBR)
The report in RRNDS is transmitted to either the source
or the destination. Unfortunately, the amount of report in-
formation received by the destination or source is reduced
in RRNDS. Due to this shortage of reports, the source or
destination may not precisely analyze the relaying activity
of intermediate nodes.
We address this problem by modifying Step 2 of RRNS
to transmit the report to both the source and destination.
This technique, shown in Figure 1-(c), is referred to as
Random Bidirectional Reporting (RBR). In the gure, node
2 sends a report to the destination and source node. Simu-
lation results reported in Section 6 show that bidirectional
reporting improves effectiveness in the face of mobility.
Additionally, for both RRNDS and RBR, if the com-
munication between source and destination is bidirectional,
source-bound reports are attached to data packets destined
for the source. This reduces communication overhead.
5. Secure Reporting Protocol
The random reporting protocols discussed in Section 4
are based upon random node selection.
nodes (selsh or malicious) discover a packet including a
report and the selected node, the information may be ma-
nipulated or dropped.
This section proposes an efcient construction that con-
ceals the node selection from other intermediate nodes. In
civilian mobile ad hoc networks, the intermediate nodes
cannot be assumed to be honest; lying may provide more
credit. Thus, in order to assure the validity of node reports,
a chain of HMACs on the link layer acknowledgments is
proposed. This addition provides forgery detection.
The following notations are used in the secure reporting
protocol and forged report detection schemes.
• IDi: Identier of node ni.
• Kij: a pair-wise key between node niand nj.
• hash(x): Cryptographic hash function computation
• σ: HMAC(KSD,DATA|IDi) computation result
for the data and IDi.
• DATA: Data transmitted between the source and des-
Mobile devices are less powerful in computation and
have a battery of limited lifetime. Therefore, symmetric
cryptography is often more appropriate for mobile devices
in ad hoc networks. The secure random reporting protocol
requires three pairs of symmetric keys: source and destina-
tion, source and intermediate nodes, and destination and in-
termediate nodes. Key management schemes for distribut-
ing symmetric keys in ad hoc networks have been proposed
[9, 4], and thus will not be discussed. Any efcient sym-
metric keymanagementscheme can be used fordistributing
symmetric keys to mobile nodes; its choice does not impact
5.1. Secure and Random Reporting Protocol
DSR allows the source node to know the full routing
path. The source node chooses one intermediate node ni
uniformlyat random,and computes Token, which is added
to the data packet. The Token contains the node selection
information which is not disclosed. The use of an HMAC
in the computation of the Token provides randomness and
secrecy in the node selection.
- Choose one intermediate node ni
- Compute σ = HMAC(KSD,DATA|IDi),
- Compute Hi= hash(KSi|σ)
- Generate Token = σ ⊕ Hi
→ rst intermediate node: [DATA,σ,Token]
When a node receives a packet, it needs to determine if
it is the randomly selected node. At the same time, no other
nodes can be allowed to know which node has been chosen.
Upon receiving a data packet(DATA,σ,Token), an inter-
mediate node njcomputes Hj= hash(KjS|σ) and XORs
it with the received Token. If the result of the XOR opera-
tion is equal to the received σ, the node knows it was cho-
sen. This is only satised at node nisince the source used a
pairwisekeyKSi. Sincethe abovetest inotherintermediate
nodes is not satised, they do not generate reports.
The chosen intermediate node nisends its report by at-
taching it to the data packet. The report R includes the
number of packets the node forwarded for the source and
destination. For integrity purposes, the chosen intermedi-
ate node computes hash with its report R and its pair-wise
symmetric key shared with the destination.
Table 1. Random and Secure Reporting
- Choose one intermediate node ni
- Compute σ = HMAC(KSD,DATA|IDi)
- Compute Hi= hash(KSi|σ)
- Compute Token = σ ⊕ Hi
- Send the packet (DATA,σ,Token)
Intermediate Node ni:
- Compute Hi= hash(KiS|σ)
- XOR Hiwith Token → Hi⊕ Token = Hi⊕ σ ⊕ H?i, where H?iis received
- Check if XOR(Token,Hi) == σ
- If niis chosen,
o Compute HD= hash(KiD|R)
o Generate Report = [R,HD] and attach it to the data packet
- Evaluate if hash(KDi|R) = HDto nd out the chosen node.
- Save the report and check whether there exists a misbehavior.
- If the report is not valid, ignore the report.
This scheme is resilient to another node nk replacing
Token = σ ⊕ Hi with σ ⊕ Hk, because the result-
ing HMAC(KSD,DATA|IDk) is not equal to the re-
ceived σ = HMAC(KSD,DATA|IDi). Without know-
ing KSD, the node nk cannot change σ to masquer-
ade as a selected node. When receiving a data packet,
the destination checks that σ and the received report R
are valid, i.e. if hash(KDi|R)
HMAC(KDS,DATA|IDi) are satised.
In RRNDS and RBR, reports are transmitted to the
source node. The only difference is that the chosen inter-
mediate node uses the symmetric key KiSto generate the
source-bound report. The report generation is the same as
described above. The key idea of node selection is to con-
ceal the node selection from other nodes. Table 1 summa-
rizes the secure random reporting protocol.
While the secret random reporting protocol protects the
identity of the selected node from in-path adversaries, it is
susceptible to trafc analysis. If an adversary can overhear
trafc going in and out of node ni, determining whether or
not niwas selected is trivial. If the incoming and outgoing
data does not match, nihas attached a report. Therefore, if
this adversary is downstream from ni, it can selshly strip
out the report. However, we expect this to be limited to the
direct neighbors of the selected nodes in most cases.
HD and σ
5.2. Report Forgery Detection Scheme
Even if the report transmission is secure, we still need
a way to validate the information provided by the selected
node. To address this, a report forgery detection scheme is
In wireless networks,thelink layerprovidesan acknowl-
edgment (ACK) by which a receiving node conrms to a
sending node that it received the packet successfully. The
sending node waits for an ACK from the receiver. If it does
not receive an ACK after retransmitting a packet several
times, it considers the link to the receiving node broken and
sends a ROUTE ERROR message back to the source node.
If this occurs, the source node will change the data path.
This property of the link layer protocol is used to pro-
vide forgery detection of reports. Each data packet is sent
in a link layer frame. For each data packet i, successfully
received in frame jf, the receiver sends an ACK(jf, seqi)
and αi, which is an HMAC of αi−1and seqi. Intermedi-
ate nodes generate self-reports for each ow dened by the
source and destination addresses. Intermediate nodes may
relay data packets for multiple ows. They generate ACKs
ing to the ow.
For the HMAC’s symmetric key, the receiver R uses the
pair-wise KRD shared with the destination. The forgery
detection scheme does not use a key shared between two
neighboringnodes in order to preventthese nodes from col-
luding and allowing one node to manipulate the HMAC.
report forgery detection scheme. Data transfer begins with
initial packet DATA0. For this first packet, node B com-
putes α0= HMAC(KBD,seq0|0). Node B then sends to
A both a link layer ACK and the computed α0. After the
initial packet, node B uses the previous HMAC, αi−1, in
= HMAC( , Seq_0 | 0)
= HMAC( , Seq_1 | )
DATA, Rep(k, )
Flow (S,D) Table
= HMAC( , Seq_k | )
Reported Chained HMACs
= HMAC( , Seq_k | )
= HMAC( , Seq_k | )
= HMAC( , Seq_k | )
Figure 2. Chained HMACs to Detect Report Forgery
the computation of αi.
When node A is randomly chosen to send a report for data
packet k, both k and αkare transmitted. In the case of Fig-
ure 2, since the report direction is towards the destination,
the report is attached to a DATA transmission.
Mobility is fundamental to MANETs.
changes, the destination may not have the initial sequence
number for a particular path. Therefore, for the first re-
port in a path, node A must include α0, the initial sequence
number, αi, the sequence number map, and the number of
packets it has forwarded. Since the destination knows the
symmetrickey,KBD, it canverifyα0was createdcorrectly.
The most recent HMAC, αi, can then be veried by com-
puting the HMAC chain from α0.
The chained HMACs are intended to detect if nodes
forge their reports. The forgery detection scheme protects
against two types of misbehavior. In Figure 2, node A may
try to cheat by sending a report saying it forwarded 100
packets when it really only forwarded 50 packets. In or-
der for A to cheat under the described scheme, it must pro-
vide α100. Since generation of α100requires knowledge of
KBD, only known by node B and D, A cannot fake the re-
port. The only way for A to learn α100is for node B to tell
it. This only occurs after A forwards B 100 packets.
The forgerydetectionscheme also protects against a ma-
licious node B. In one case, node B may purposefully
choose to not send an ACK to node A. If this occurs, node
A will send a ROUTE ERROR to the source node, and a
new data path will be chosen. If, on the other hand, node
B sends A an ACK, but purposefully generates the wrong
HMAC, for the initial α0or the intermediate αi, node A
will report the wrong α0or αito the destination.
Fortunately, the destination can determine if α0 or
αi is incorrect.Since the destination can compute
HMAC(KBD,seq0|0) = α0, if the resulting α0does not
match the received α?0, it can detect that node B is mis-
behaving. Similarly, the destination can compute αkand
When a path
compare it to the received α?k. As shown in Figure 2, the
destination retains knowledge of the state by keeping a ta-
ble consisting of the node identier and the most recently
received HMAC, αi. The destination determines the ex-
pected αkby calculating the HMAC chain.
If the received α?kdoes not match the computed αk, the
destination can determine if B is behaving maliciously.
The chained HMACs scheme prevents nodes from lying.
Additionally, it prevents nodes in collusion from dropping
packets. Nearby colluding nodes may exchange informa-
tion to determine the random node selection. If a packet
selects a downstream cooperative node that is not in col-
lusion to generate a report, the colluding nodes drop the
packet and generatefalse reportthat they all transmit. How-
ever,theyneedto haveproofsthat thecooperativenodesuc-
cessfully received these packets. In this case, malicious be-
havior can be detected since the colluders do not have the
chained HMACs generated by the cooperative node. Sec-
tion 6 examines the resulting computational overhead.
6. Reliability and Computational Overhead
In order to analyze the reliability of the proposed report-
ing schemes, we simulated our protocols using ns-2. These
simulations illustrate the robustness of the RBR and other
related schemes. Additionally, we explore the cost of the
underlying cryptographic constructions based on empirical
6.1. Simulation Environments
The experimental testbed is as follows. Table 2 shows
bile nodesuse IEEE802.11MAC with a transmissionrange
of 250m. Additionally, the CMU scenario generation tool
was used to create a network consisting of 50 mobile nodes
in an 1100X1100 range. The model used random waypoint
mobility with speeds of 15 m/sec. For simulating network
congestion, 10 burst ows exponentially distributed were
used between other nodes. Finally, a CBR trafc ow was
used between the specic source and destination.
Table 2. Simulation Parameters
Simulation Time1000 seconds
Number of nodes50
Packet Size512 bytes
Mobility 15 meter/second
Random waypoint mobility model
Routing Protocol Dynamic Source Routing (DSR)
The observation period is a xed time that the destina-
tion and source observe the reports to analyze the network
properly. For cases of high CBR trafc rates (28.57 pack-
ets per second), a basic observation period of ve seconds
was used. For low trafc rates, the period was extended
inversely proportional to the trafc rate in order to gather
enoughinformationforanalysis. For example,if onepacket
is generated per second, a ve second observation time is
not long enough to collect reports from intermediate nodes.
Therefore, the observation time was extended.
Trafc ows are dened by the source and destination
addresses. In order to adapt to the dynamic characteristic of
path changes, the reports were collected based on the ow
and path. This is required, because a ow may change its
path due to a link failure caused by mobility or congestion.
As the path changes, the source and destination keep track
of the ow state, the current path state, and the active path
list that consists of paths transmitting the ow trafc during
the observation period.
When a node encounters a link failure and sends a
ROUTE ERROR message to the source, the appropriate se-
quence number is included in the notication. Until the
source receives the ROUTE ERROR, it continues to use the
currentpathtotransmitdata. Therefore,all packetscontain-
ing sequencenumbershigherthan the notied packet on the
path causing the ROUTE ERROR are lost.
6.2. Simulation Results and Discussions
Packet loss occurs due to mobility, congestion, and ma-
licious dropping. Identifying the source of packet loss is
difcult due to the random nature of its occurrence. In or-
der to determine the effectiveness of the secure reporting
protocol, we measured the average packet loss rate over the
simulation time, excluding malicious nodes. This results in
12% average packet loss (caused by congestion and mobil-
ity) from this baseline test.
0 2 4 6 8 10 12 14 16
Max Speed (m/seconds)
Figure 3. Effectiveness vs. Mobility
The following experiments assess the accuracy of mon-
itored reports. Using the measured average packet loss,
12%, as a guideline, a second battery of experiments simu-
lated an adversary that dropped 17% of the received pack-
ets. We designatedany nodethat the reports showedto have
a loss rate greater than 12% as anomalous. The efciency
of the protocol (shown in the following gures) is the per-
centage of experiments that correctly identify the malicious
nodes as anomalous. In this conservative model, the ad-
versary behaves only slightly different than well behaved
nodes: nodes that more aggressively drop packets will be
detected more easily, and the protocols will be more effec-
In the secure random reporting protocol, a report is em-
bedded in the data packet towards the source and destina-
tion. Packet loss occurs either before or after a report is
attached. In both cases, the report does not reach to the des-
tination or source. As mobility increases or more trafc is
injected, packet loss increases, which results in lost reports.
Figure 3 shows the impact of mobility on the effectiveness
of the three protocols. This simulation used the high bit rate
CBR trafc between the source and destination, a fteen-
second attack period, and no other trafc ows. In the static
case, all three protocols showed an almost 100% detection
rate. However, as mobility is introduced, the effectiveness
of RRNS decreases sharply since the reports embedded in
datat packets are lost. By contrast, the RBR protocol re-
mains highly effective in all experiments. In RBR, the re-
port is transmitted to both the source and destination. The
redundant transmission improves the robustness of reports
in the presence of mobility.
We further simulated adversaries mounting attacks of
variable length. As shown in Figure 4, RRNS was the least
effective. Most of the undetected drops in RRNS occurred
0 5 10 15 20 25 30 35
Attack Period (Seconds)
Figure 4. Effectiveness in Random Reporting
where the source changes to a new path, one intermediate
node on the new path drops packets, and then the data path
changes due to the following link failure. This does not al-
low any reports to reach the destination, and the forwarding
activity cannot be discovered. The results also show that
RRNDS improves RRNS’s effectiveness by 1.5. The RBR
RBR was also tested under different trafc rates. Again,
as the trafc rate decreases, the observation time needed to
be extendedin order to collect enoughreports and probethe
relaying by intermediate nodes. Not shown in these graphs
is the performance of RBR under the different trafc rates,
which was essentially constant. From these experiments,
we can conclude that the secure reporting protocol is fea-
sible for collecting the relaying activities of intermediate
nodes in civilian ad hoc networks.
The secure randomreportingprotocolrequiresthree new
elds: Token, Report, and HMAC. Both the Token and
HMAC are the same size as the cryprographic hash output
(16 bytes for MD5). The Report is composedof the number
of forwarded packets (4 bytes) and its cryptographic hash
output (16 bytes). The total overhead incurred by the se-
cure random reporting protocol is 52 bytes which is only
3% of maximum data packet size. On the other hand, the
existing eavesdropping schemes require a separate packet
transmission to informing other nodes of the reports. This
separate packet transmission incurs additional transmission
delay and energy consumption. Our reporting protocol re-
moves all these extra costs by embedding a report in data
packet with small overhead in packet size.
6.3. Computational Overhead
One possible concern of the Secure Random Reporting
Protocol is the computational overhead of the HMAC cal-
culation. Depending on the chosen cryptographic digest
function, the overhead will vary. To test the HMAC perfor-
mance, we wrote a module for the Linux 2.6 kernel, using
the available cryptographic API. Tests were performed on
a Pentium 3 800MHz, 512MB RAM system using a stock
Linux 2.6.10 kernel compiled by GCC 3.3. The tests cov-
ered MD5, SHA1, and SHA256 digest functions with vary-
ing key sizes (64bit, 128bit, 160bit, and 256bit). All ob-
tained results were the average raw cycle count over 1000
test runs. The high number of tests runs was chosen to en-
sure more accurate results.
Table 3 shows the computation time for individual cal-
culations, which emulated the actual data used by the pro-
tocol. As described earlier, the input data for each stage of
put of a previous HMAC. Thus, the total input data size for
the HMAC chain is four bytes for the sequence number and
the number of bytes outputted by each cryptographicdigest
function (MD5 = 16 bytes, SHA1 = 20 bytes, SHA256 =
32 bytes). The HMAC data column in the table represents
the overhead for performing the HMAC on the Maximum
Transmission Unit (MTU), 1500 bytes. As expected, there
was no performance difference for varied key sizes, there-
fore, the average raw cycle count for the four key sizes was
used. Finally, using the cpu_khz value of 797556, actual
time latencies were calculated.
Table 3. HMAC Computational Overhead
MD5 4.985 µs
In our simulation, the longest path has ten intermediate
nodes. For this longest path, we estimate the computational
overheadof the secure reportingprotocol. The total compu-
tation consists of three factors: two HMACs of data packets
at the source and destination, chained HMACs at each in-
termediate node, and a hash computation at each of the in-
termediate nodes and the destination. According to the re-
sults of HMAC computationaloverhead,the secure random
reporting protocol and forgery detection scheme have less
than 600 µseconds overhead as Table 3 shows. Under opti-
mal circumstances, it takes 65 milliseconds to transmit data
from the source to the destination (10 intermediate nodes).
The total HMAC and hash computation takes only 0.8% of
the total time (577.06µs/65.577ms = 0.57706/65.577).
A mobile ad hoc network does not require a xed in-
frastructureand a centralized control to enable communica-
tion between mobile nodes. Most applications target mis-
sion oriented scenarios such as battle elds and emergency
rescue. In these scenarios, mobile nodes actively cooper-
ate with each other to achieve a goal. This is different than
civilian mobile ad hoc networks, where nodes are not nec-
In this paper, we propose a secure randomreporting pro-
tocol for a civilian ad hoc network, in which the source
and destination collect reports from intermediate nodes on
the routing path. Every data packet initiates a report from
one intermediate node that is randomly chosen by a source
node. Through a symmetric cryptographicconstruction, we
ensure that the node selection is not disclosed to other inter-
Although the report is securely transmitted to the desti-
nation, we cannot assure that it is accurate, since nodes may
cheat in order to get credit. We devise a chained HMAC
scheme on the link layer acknowledgmentsto verify the va-
lidity of the received report.
cure random reporting protocol is advantageous for gath-
ering the forwarding activities of mobile nodes in civilian
ad hoc networks. The protocol has a small communication
overhead due to the increase in packet size caused by in-
cluding the real time reports with data transmission. Our
simulation results demonstrate the promising possibility of
the reporting protocol.
Many applications require a secure and accurate report
of trafc forwarding. The report can be used for determin-
ing whether congestion exists in network, engineering the
trafc, crediting nodes with how many packet they relayed,
and detecting that nodes maliciously drop packets.
 Y. an Huang and W. Lee. A Cooperative Intrusion Detection
System for Ad Hoc Networks. Proceedings of the 1st ACM
workshop on Security of ad hoc and sensor networks(SASN),
 B. Awerbuch, D. Holmer, C. Nita-Rotaru, and H. Rubens.
An On-Demand Secure Routing Protocol Resilient to
Byzantine Failures . ACM WiSe, 2002.
 S. Buchegger and J.-Y. L. Boudec. Performance Analysis of
the CONFIDANTProtocol(Cooperation Of Nodes: Fairness
in Dynamic Ad-hoc NeTworks). MOBIHOC, 2002.
 L. Eschenauer and V. Gligor. A key-management scheme for
distributed sensor networks. ACM Conference on Computer
and Communication Security, 2002.
 http://www.isi.edu. The Network Simulator - ns-2, 2000.
 P. J. Transmission Control Protocol - DARPA Internet Pro-
tocol Program Specication. IETF, Sep. 1981. RFC 793.
 M. Jakobsson, J.-P. Hubaux, and L. Buttyan.
Payment Scheme Encouraging Collaboration in Multi-Hop
Cellular Networks. In Proceedings of Financial Cryptogra-
 D. B. Johnson, D. A. Maltz, Y.-C. Hu, and J. G. Jetcheva.
The Dynamic Source Routing Protocol for Mobile Ad Hoc
Networks (DSR). http://www.ietf.org/internet-drafts/draft-
ietf-manet-drIETF draft, 2004.
 D. Liu and P. Ning. Establishing Pairwise Keys in Dis-
tributed Sensor Networks. ACM Conference on Computer
and Communication Security, 2003.
 S. Marti, T. Giuli, K. Lai, and M. Baker. Mitigating Routing
Misbehavior in Mobile Ad Hoc Networks. Proc. of ACM
 S. Micali and R. Rivest. Micropayments Revisited. CT-RSA,
 P. Michiardi and R. Molva. CORE: A Collaborative Reputa-
tion Mechanism to enforce node cooperation in Mobile Ad
Hoc Networks. In Proceedings of The 6th IFIP, 2002.
 C. E. Perkins and E. Belding-Royer. Ad hoc On-Demand
Distance Vector (AODV) Routing. IETF RFC3561, 2003.
 G. Vigna, S. Gwalani, K. Srinivasan, E. Belding-Royer, and
R. Kemmerer. An Intrusion Detection Tool for AODV-based
Ad hoc Wireless Networks. 20th Annual Computer Security
Applications Conference, 2004.
 X. Zhang, S. Wu, Z. Fu, and T.-L. Wu. Malicious Packet
Dropping: How It Might Impact the TCP Performance and
How We Can Detect It. In Proceedings of ICNP 2000, Nov.
 Y. Zhang and W. Lee. Intrusion Detection in Wireless Ad
Hoc Networks. 6th International Conference Mobile Com-
puting and Networks, 2000.
 Y. Zhang and W. Lee. Intrusion Detection in Wireless Ad
Hoc Networks. Proc. of ACM Mobicom, 2000.
 S. Zhone, J. Chen, and Y. R. Yang. Sprite: A Simpe, Cheat-
Proof, Credit-Based System for Mobile Ad-Hoc Networks.
Proc. of IEEE INFOCOM, 2003.
 S. Zhu, S. Setia, S. Jajodia, and P. Ning. An Interleaved
Hop-by-Hop Authentication Scheme for Filtering of In-
jected False Data in Sensor Networks. In Proc. of IEEE
Symposium on Security and Privacy, 2004.
 S. Zhu, S. Xu, S. Setia, and S. Jajodia.
Lightweight Hop-by-Hop Authentication Protocol For Ad-
Hoc Networks. In Proc. of the 23rd International Confer-
ence on Distributed Computing Systems Workshops, 2003.