BSMR: Byzantine-Resilient Secure MulticastRouting in Multi-hop Wireless Networks

Reza CurtmolaDepartment of Computer Science

The Johns Hopkins Universitycrix@cs.jhu.edu

Cristina Nita-RotaruDepartment of Computer Science and CERIAS

Purdue Universitycrisn@cs.purdue.edu

Abstract—In this work we identify vulnerabilities of on-demand multicast routing protocols for multi-hop wirelessnetworks and discuss the challenges encountered in de-signing mechanisms to defend against them. We proposeBSMR, a novel secure multicast routing protocol thatwithstands insider attacks from colluding adversaries. Ourprotocol is a software-based solution and does not requireadditional or specialized hardware. We present simulationresults which demonstrate that BSMR effectively mitigatesthe identified attacks.

I. INTRODUCTION

Multicast routing protocols deliver data from a sourceto multiple destinations organized in a multicast group.Several protocols were proposed to provide multicast ser-vices for multi-hop wireless networks. These protocolsrely on node cooperation and use flooding [1], gossip[2], geographical position [3], or dissemination structuressuch as meshes [4], [5], or trees [6], [7].

A major challenge in designing protocols for wirelessnetworks is ensuring robustness to failures and resilienceto attacks. Wireless networks provide a less robust com-munication than wired networks due to frequent brokenlinks and a higher error rate. Security is also morechallenging in multi-hop wireless networks because theopen medium is more susceptible to outside attacksand the multi-hop communication makes services morevulnerable to insider attacks coming from compromisednodes. Although an effective mechanism against outsideattacks, authentication is not sufficient to protect againstinsider attacks because an adversary that compromised anode also gained access to the cryptographic keys storedon it. Insider attacks are also known as Byzantine [8]attacks and protocols able to provide service in theirpresence are referred to as Byzantine resilient protocols.

Previous work focused mainly on the security ofunicast services. Several routing protocols [9]–[12] were

proposed to cope with outsider attacks. Methods pro-posed to address insider threats in unicast routinginclude monitoring [13], multi-path routing [14] andacknowledgment-based feedback [15], [16]. The problemof secure multicast in wireless networks was less studiedand only outside attacks were considered [17].

Security problems related to multicast routing can beclassified in routing specific security, such as the man-agement of the routing structure and data forwarding, andapplication specific security such as data confidentialityand authenticity. Solutions to the latter problem alsoreferred to as secure group communication focus mainlyon group key management [18], [19]. In this work weare concerned with multicast routing specific security.

Several aspects make the multicast communicationmodel more challenging than its unicast counterpart.First, designing secure multicast protocols for wirelessnetworks requires a more complex trust model, as nodeswhich are members of the multicast group cannot simplyorganize themselves in a dissemination structure withoutthe help of other non-member nodes acting as routers.

Second, unlike unicast protocols which establish andmaintain routes between two nodes, multicast protocolsestablish and maintain more complex structures, such astrees or meshes. For example, protocols relying on treesrequire additional operations such as route activation,tree pruning and tree merging. These actions do not havea counterpart in the unicast case and may expose therouting protocol to new vulnerabilities.

Third, multicast protocols deliver data from one senderto multiple receivers making scalability a major problemwhen designing attack-resilient protocols. In particular,solutions that offer resiliency against Byzantine attacksfor unicast are not scalable in a multicast setting. Forexample, multi-path routing affects significantly the datadissemination efficiency, while strategies based on end-to-end acknowledgments have high overhead.

In this paper we study vulnerabilities of multicastrouting protocols in multi-hop wireless networks andpropose a new protocol that provides resilience againstByzantine attacks. Our main contributions are:

We identify several aspects that make the design ofsecure multicast routing protocols more challenging thantheir unicast counterpart. They are a more complex trustmodel and underlying routing structure, and scalability.We also discuss potential attacks against such protocols.

We propose BSMR, an Byzantine-resilient on-demandmulticast protocol for multi-hop wireless networks.BSMR uses a selective data forwarding detection mech-anism based on a reliability metric capturing adversarialbehavior. Nodes determine the reliability of links bycomparing the perceived data rate with the one advertisedby the source. Adversarial links are avoided during theroute discovery phase. BSMR also deters attacks that tryto prevent or influence route establishment.

We show through simulations that the impact of sev-eral Byzantine attacks on a previously proposed securemulticast routing protocol is considerable and cannot beignored. We also demonstrate through simulations thatour protocol BSMR mitigates the attacks, while incurringa small overhead.

The remainder of the paper is organized as follows.Section II overviews related work. Section III presentsour network and system model. We discuss the at-tacks against tree-based multicast protocols in IV-B andpresent BSMR in Section V. We present experimentalresults in Section VI and conclude in Section VII.

II. RELATED WORK

Significant work addressed vulnerabilities of unicastrouting protocols in wireless networks. Several securerouting protocols resilient to outside attacks were pro-posed in the last few years such as Ariadne [11], SEAD[10], ARAN [12], and the work in [9].

Wireless specific attacks such as flood rushing andwormhole were recently identified and studied. RAP[20] prevents the rushing attack by waiting for sev-eral flood requests and then randomly selecting one toforward, rather than always forwarding only the firstone. Techniques to defend against wormhole attacksinclude Packet Leashes [21] which restricts the maxi-mum transmission distance by using either a tight timesynchronization or location information, Truelink [22]which uses MAC level acknowledgments to infer if alink exists or not between two nodes, and the techniquein [23], which relies on directional antennas.

The problem of insider threats in unicast routing wasstudied in [13]–[16]. Watchdog [13] relies on a nodemonitoring its neighbors if they forward packets to otherdestinations. If a node does not overhear a neighborforwarding more than a threshold number of packets,it concludes that the neighbor is adversarial. SDT [14]uses multi-path routing to prevent a malicious node fromselectively dropping data. ODSBR [15], [16] providesresilience to Byzantine attacks caused by individual orcolluding nodes by detecting malicious links based onan acknowledgement-based feedback technique.

Most of the work addressing application security is-sues related to multicast in wireless networks focused onthe problem of group key management in order to ensuredata confidentiality and authenticity [24]–[28]. Workstudying multicast routing specific security problems inwireless networks is scarce with the exception of theauthentication framework in [17]. The framework allowsMAODV to withstand several external attacks against thecreation and maintenance of the multicast tree. However,it does not provide resilience against Byzantine attacks.

Multicast routing specific security was also studied inoverlay networks [29]–[31]. Solutions proposed exploitoverlay specific properties, which do not hold in multi-hop wireless networks, such as: existence of networkconnectivity between each pair of nodes, allowing directprobing of non-neighboring nodes, and highly redundantconnectivity, ensuring that many disjoint paths exist.

III. NETWORK AND SYSTEM MODEL

A. Network Model

We consider a multi-hop wireless network wherenodes participate in the data forwarding process for othernodes. We assume that the wireless channel is symmet-ric. All nodes have the same transmitting power andconsequently the same transmission range. The receivingrange of a node is identical to its transmission range.

Nodes are not required to be tamper resistant, nor to beequipped with additional hardware such as GPS receiversor tightly synchronized clocks.

B. Multicast Protocol

We assume a tree-based on-demand multicast proto-col such as [6]. The protocol maintains bi-directionalshared multicast trees connecting multicast sources andreceivers. Each multicast group has a correspondingmulticast tree. The multicast source is a special node, thegroup leader, whose role is to eliminate stale routes andcoordinate group merges. Route freshness is indicated bya group sequence number updated by the group leader

and broadcast periodically in the entire network. Highergroup sequence numbers denote fresher routes.

The main operations of the protocol are route dis-covery, route activation and tree maintenance. Duringroute discovery a node discovers a path to a node thatis part of the multicast tree. A requester first broadcastsa route request message (RREQ) that includes the latestknown group sequence number. The RREQ message isflooded in the network using a basic flood suppressionmechanism and establishes reverse routes to the source ofthe request. Upon receiving the RREQ, a node that is partof the multicast tree and has a group sequence number atleast as large as the one in the RREQ, generates a routereply (RREP) message and unicasts it on the reverseroute. The RREP message includes the last known groupsequence number and the number of hops to the nodethat originated the RREP.

During route activation, the requester selects the fresh-est and shortest route (i.e., with the smallest number ofhops to the multicast tree) from the routes returned by theroute discovery operation. The requester activates thatroute by unicasting a multicast activation message.

Three main operations ensure the tree maintenance:tree pruning, broken link repair and tree merging. Treepruning occurs when a group member that is a leaf in themulticast tree decides to leave the group. A node initiatesthe pruning from the tree by sending a message to itsparent. The pruning message travels up the tree causingleaf nodes that are not members of the multicast groupto prune themselves from the tree, until it reaches eithera non-leaf node or a group member. A non-leaf groupmember must continue to act as a router and cannotprune itself from the multicast tree.

A node initiates a link repair procedure when theupstream link in the multicast tree breaks. If the nodecannot reconnect to the tree, it means the tree is parti-tioned. In this case the node runs a special procedure toprune non-member leaf nodes and elect a group leaderfor the partition. When two partitions of the same treereconnect, the leader of one of the partitions coordinatesthe merge of the partitions, suppressing the other leader.

IV. ATTACKS AGAINST MULTICAST ROUTING

A. Adversarial Model

We assume that nodes may exhibit Byzantine behav-ior, either alone or colluding with other nodes. Exam-ples of such behavior include: not forwarding packets,injecting, modifying or replaying packets. We refer toany arbitrary action by authenticated nodes resulting in

disruption of the routing service as Byzantine behavior,and to such an adversary as a Byzantine adversary.

We consider a three-level trust model that captures theinteractions between nodes in a wireless multicast settingand defines a node’s privileges: a first level includes thesource which must be continually available and assumednot to be compromised; a second level consists of themulticast group member nodes, which are allowed toinitiate requests for joining multicast groups; and a thirdlevel consists of non-member nodes which participatein the routing but are not entitled to initiate group joinrequests. In order to cope with Byzantine attacks, evengroup members cannot be fully trusted.

We do not consider general attacks such as Sybiland node replication attacks. Techniques such as [32],[33] or [34], complementary to our routing protocolcan be used to address these attacks. This work onlyconsiders attacks targeted against the network level.Also, preventing traffic analysis is not the goal of thiswork, which focuses instead on survivable routing.

B. Attacks in Multicast in Multi-Hop Wireless Networks

An adversary can attack control messages correspond-ing to the route discovery, route activation and treemanagement components of the routing protocol, or canattack data messages.

The route discovery can be disrupted by outsideattackers by injecting, replaying, or modifying controlpackets. Malicious nodes that are not in the tree can mis-lead correct nodes into believing that they found and areconnected to the tree. Nodes can flood the network withbogus requests for joining multicast groups. A Byzantinenode can prevent a route from being established bydropping the request and/or response, or can influencethe route selection by using wireless specific attackssuch as wormhole and flood rushing. A Byzantine nodecan also modify the packets carrying the route selectionmetric such as hop count or node identifiers.

Outsider nodes can inject bogus route activation mes-sages, while Byzantine nodes can prevent correct routeactivation messages to reach correct nodes.

Nodes can maliciously report that other links arebroken or generate incorrect pruning messages resultingin correct nodes being disconnected from the networkor tree partitioning. In the absence of authentication,any node can pretend to be the group leader. Althoughmany routing protocols do not describe how to select anew group leader when needed, we note that the leaderelection protocol can also be influenced by attackers.

Attacks against data messages consist of eavesdrop-ping, modifying, replaying, injecting data, or selectivelyforwarding data after being selected on a route. A specialform of packet delivery disruption is a denial of serviceattack, in which the attacker overwhelms the computa-tional, sending or receiving capabilities of a node. Ingeneral, data source authentication, integrity and encryp-tion can solve the first attacks and are usually consideredapplication specific security. Defending against selectivedata forwarding and denial of service cannot be doneexclusively by using cryptographic mechanisms.

V. SECURE MULTICAST ROUTING PROTOCOL

A. BSMR Overview

Our protocol ensures that multicast data is deliv-ered from the source to the members of the multicastgroup, even in the presence of Byzantine attackers,as long as the group members are reachable throughnon-adversarial paths and a non-adversarial path existsbetween a new member and a node in the multicast tree.

We use an authentication framework to eliminateoutside adversaries and ensure that only authorized nodesperform certain operations (e.g., only tree nodes can per-form tree operations and only group nodes can connectto the corresponding multicast tree).

BSMR mitigates inside attacks that try to preventa node from establishing a route to the multicast treeby flooding both route request and route reply, unlikethe basic multicast protocol presented in Sec. III-Bwhich unicasts the route reply. This ensures that if anadversarial-free route exists, then a route is established.

BSMR ensures resilience to selective data forward-ing attacks by using a reliability metric that capturesadversarial behavior. The metric consists of a list oflink weights in which high weights correspond to lowreliability. Each node in the network maintains its ownweight list and includes it in each route request to ensurethat a new route to the tree avoids adversarial links.

A link’s reliability is determined based on the numberof packets successfully delivered on that link over time.Tree nodes monitor the rate of receiving data packetsand compare it with the transmission rate indicated bythe source in the form of an MRATE message. If theperceived transmission rate falls below the rate indicatedin the MRATE message by more than a threshold, anhonest node that is a direct descendant of an adversarialnode updates its weight list by penalizing the link to itsparent and then tries to discover a new route to the tree.

We note that a strategy based on end-to-end acknowl-edgments, although shown effective in unicast [14], [16],

is not scalable: As the size of the multicast groupincreases, ACK implosion occurs at the source, whichmay cause a drastic decrease in data delivery [35].Solutions that address the problem of feedback implo-sion in multicast protocols (e.g., feedback aggregationor a combination of ACK/NACK messages [36]) weredesigned to operate under non-adversarial conditions; Itis questionable if they will work in adversarial networks.

Without loss of generality, we limit our description toone multicast group. Below we describe the previouslymentioned authentication framework, the route discov-ery, the route activation, multicast tree maintenance andthe selective data forwarding detection mechanisms.

B. Authentication Framework

In order to protect from external attacks against thecreation and maintenance of the multicast tree BSMRuses a framework similar with the one in [17]. Theframework prevents unauthorized nodes to be part of thenetwork, of a multicast group, or of a multicast tree.These forms of authentication correspond to the trustmodel described in Section IV-A. Each node authorizedto join the network has a pair of public/private keys and anode certificate that binds its public key to its IP address.Each node authorized to join a multicast group has anadditional group certificate that binds its public key andIP address to the IP address of the multicast group.

Nodes in the multicast tree are authenticated using atree token, which is periodically refreshed and dissemi-nated by the group leader in the multicast tree with thehelp of pairwise shared keys established between everydirect tree neighbors. Thus, only nodes that are currentlyon the tree will have a valid tree token. To allow any nodein the network to check that a tree node possesses a validtree token, the group leader periodically broadcasts in theentire network a tree token authenticator f(tree token),where f is a collision resistant one-way function. Nodescan check the validity of a given tree token by applyingthe function f to it and comparing the result with thelatest received tree token authenticator.

To prevent tree nodes from claiming to be at a smallerhop distance from the group leader than they actually are,we use a technique based on a one-way hash chain. Thelast element of this hash chain, referred to as hop countanchor, is broadcast periodically by the group leader.

We assume that nodes have a method to determinethe source authenticity of the received data (e.g., TESLA[37]). This allows a node to correctly determine the rateat which it receives multicast data.

C. Route Discovery

BSMR’s route discovery allows a node that wants tojoin a multicast group to find a route to the multicast tree.The protocol follows the typical route request/route replyprocedure used by on-demand routing protocols withseveral differences. To prevent outsiders from interfering,all route discovery messages are authenticated using thepublic key corresponding to the network certificate. Onlygroup authenticated nodes can initiate route requests andthe group certificate is required in each request. Treenodes use the tree token to prove their current tree status.

Several mechanisms are used to address internal at-tackers: (a) both route request and route reply are floodedin order to ensure that, if an adversarial-free path exists,it will be found; (b) the path selection relies on theweights list carried in the response flood and allows therequester to select a non-adversarial path; (c) the prop-agation of weights and path accumulation is performedusing an onion-like signing to prevent forwarding nodesfrom modifying the path carried in the response.

The requesting node broadcasts a route request(RREQ) message that includes the node identifier and itsweight list, the multicast group identifier, the last knowngroup sequence number, and a request sequence number.The RREQ message is flooded in the network until itreaches a tree node that has a group sequence numberat least as great as that in the RREQ. Only new requestsare processed by intermediate nodes.

When a tree node receives for the first time a RREQfrom a requester and the node’s group sequence numberis at least as great as that contained in the RREQ, itinitiates a response. The node broadcasts a route reply(RREP) message that includes that node identifier, itsrecorded group sequence number, the requester’s iden-tifier, a response sequence number, the group identifierand the weight list from the request message. To proveits current tree node status, the node also includes inthe response the current tree token, encrypted with therequester’s public key. The RREP message is floodedin the network until it reaches the requester, using thefollowing weighted flood suppression mechanism. Treenodes with a group sequence number at least as greatas that in the RREP ignore RREP messages. Otherwise,a node computes the total path weight by summing theweight of all the links on the specified path from themulticast tree to itself. If the total weight is less thanany previously forwarded matching response (same re-quester, multicast group and response sequence number),and all the signatures accumulated on the reply are valid,

the node appends its identifier to the end of the message,signs the entire message and rebroadcasts it. As theRREP message propagates across the network, nodesestablish the forward route by setting pointers to the nodefrom which the RREP was received. Although severaltree nodes may initiate the response flood, the weightedflood suppression mechanism insures the communicationoverhead is equivalent to only one flood.

When the requester receives a response, it performsthe same computation as an intermediate node duringthe response propagation. The requester updates its in-formation upon receipt of a valid response that containsa better path according to our reliability metric.

D. Multicast Route Activation

The requester signs and unicasts on the selected routea multicast activation (MACT) message that includes itsidentifier, the group identifier and the sequence numberused in the route request phase. An intermediate nodeon the route checks if the signature on MACT is validand if MACT contains the same sequence number asthe one in the original RREQ message. The node thenadds to its list of tree neighbors the previous node andthe next node on the route as downstream and upstreamneighbors, respectively, and sends the MACT messagealong the forward route.

The requester and the nodes that received the MACTmessage could be prevented from being grafted to thetree by an adversarial node, selected on the forwardroute, which drops the MACT message. To mitigate theattack, these nodes will start a waiting to connect timer(WTC Timer) upon whose expiration nodes isolate afaulty link and initiate Route Discovery (Fig. 3). Thetimer expires after a value proportional to a node’s hopdistance to the tree, in the hope that the nodes closer tothe tree will succeed in avoiding the adversarial node andwill manage to connect to the tree. After a node becomesaware of its expected receiving data rate, it cancels itsWTC Timer and behaves as described in Sec. V-F.

E. Multicast Tree Maintenance

The tree maintenance phase ensures the correct oper-ation of the protocol when confronted with events suchas pruning, link breakage and node partitioning. Routingmessages exchanged by tree neighbors, such as pruningmessages (described in Sec. III-B) are authenticatedusing the pairwise keys shared between tree neighbors.If a malicious node prunes itself even if it has a subtreebelow it, the honest nodes in this subtree will reconnectto the tree following the procedure described in Sec. V-F.

The link repair procedure is initiated by nodes that detecta broken link and is similar with Route Discovery.

The group leader periodically broadcast in the entirenetwork a signed Group Hello message that contains thecurrent group sequence number, the tree token authenti-cator and the hop count anchor (described in Sec. V-B).

F. Selective Data Forwarding Detection

The source periodically signs and sends in the tree amulticast rate (MRATE) message that contains its datatransmission rate ρ0. As this message propagates in themulticast tree, nodes may add their perceived transmis-sion rate to it. The information in the MRATE messageallows nodes to detect if tree ancestors perform selectivedata forwarding attacks. Depending on whether their per-ceived rate is within acceptable limits of the rate in theMRATE message, nodes alternate between two states.The initial state of a node is Disconnected; After it joinsthe multicast group and becomes aware of its expectedreceiving data rate, the node switches to the Connectedstate. Upon detecting a selective data forwarding attack,the node switches back to the Disconnected state.

A network operating normally exhibits some amountof natural “loss”, which may cause the rate perceivedby a node to be smaller than the rate perceived by itstree parent. This natural rate decrease is cumulative asdata travels further away from the source. We define athreshold δ as the upper bound for the tolerable loss rateon a single link. If a node’s perceived rate is smaller thanthe last recorded rate in MRATE by more than δ, thenode concatenates its identifier and its rate to MRATEand signs the entire message before forwarding it. Theseadded rates serve as proofs that nodes which previouslyforwarded the MRATE message did not perceive lossesmuch larger than natural losses.

In order to prevent a malicious node from introducinga rate decrease significantly larger than δ, we use anotherthreshold ∆ > δ. Upon receiving an MRATE message,each node first checks if the difference between the lastrate in MRATE and the node’s perceived rate is greaterthan ∆. If so, this indicates that there exists at least anadversarial node in between this node and the node thatadded the last rate to MRATE. The first honest node thatnotices a difference larger than ∆ incriminates the link toits tree parent as faulty (by using an exponential weightincrease scheme) and assumes responsibility for findinga new route to the tree. The nodes in the subtree belowthis node will notice there is a “gap” greater than ∆between the rates included in MRATE; They will defertaking any action to isolate the faulty link for an amount

1. if this is the first MRATE message received then2. switch to Connected state3. cancel WTC Timer4. store MRATE message and cancel MRATE Timer5. if state = Connected and WTC Timer 6= PENDING then6. if MRATE contains a “gap” larger than ∆ then7. start WTC Timer timer8. forward MRATE9. return

10. else if WTC Timer = PENDING then11. if MRATE contains a “gap” larger than ∆ then12. MRATE = cat and sign(MRATE, (idnode, ρnode))13. forward MRATE14. return15. else16. cancel WTC Timer17. switch to Connected state18. if ρk − ρnode > ∆ then19. MRATE = cat and sign(MRATE, (idnode, ρnode))20. if WTC Timer = PENDING then21. cancel WTC timer22. switch to Disconnected state23. increase weight of the link to the parent24. initiate Route Discovery25. else if ρk − ρnode > δ then26. MRATE = cat and sign(MRATE, (idnode, ρnode))27. forward MRATE message28. start MRATE Timer

Fig. 1: receipt of MRATE = (ρ0, (id1, ρ1), . . . , (idk, ρk))

1. if state = Connected and WTC Timer 6= PENDING then2. retrieve stored MRATE = (ρ0, (id1, ρ1), . . . , (idk, ρk))3. if ρk − ρnode > ∆ then4. MRATE = cat and sign(MRATE, (idnode, ρnode))5. switch to Disconnected state6. increase weight of the link to the parent7. initiate Route Discovery8. else if ρk − ρnode > δ then9. MRATE = cat and sign(MRATE, (idnode, ρnode))

10. forward MRATE messageFig. 2: timeout of MRATE Timer

1. switch to Disconnected state2. increase weight of the link to the parent3. initiate Route Discovery

Fig. 3: timeout of WTC Timer

of time proportional to the distance from the node thatalready started the repair procedure, in the hope that thenodes closer to the faulty link will succeed in isolatingit. Upon detecting that the expected data packet rate hasbeen restored, nodes cancel the repair procedure.

Figures 1, 2 and 3 describe how a Connected nodereacts to the following events, respectively: (1) receipt ofan MRATE message, (2) timeout of the MRATE Timer,and (3) timeout of the WTC Timer. ρnode denotes the rateat which the node receives packets from its tree parent.

Tree nodes expect to periodically receive MRATEmessages, otherwise the MRATE Timer will expire. Notethat each tree node stores the latest received MRATE

message and uses it to re-initiate the propagation ofMRATE if MRATE Timer expires. When MRATE Timerexpires, a node compares its perceived rate with theexpected rate from the stored MRATE message.

VI. EXPERIMENTAL RESULTS

To the best of our knowledge, the only previous secureon-demand multicast protocol is the one in [17], towhich we refer as A-MAODV. Although A-MAODVwithstands several external attacks against the creationand maintenance of the multicast tree, it does not provideresilience against Byzantine attacks. In this section, westudy the effect of several Byzantine attacks on theperformance of A-MAODV and demonstrate the effec-tiveness of BSMR in mitigating the attacks.

We implemented BSMR using the ns2 [38]net-work simulator, starting from an MAODV implementa-tion [39]. We assumed the protocol uses RSA [40] with1024-bit keys for public key operations, AES [41] with128-bit keys for symmetric encryptions and HMAC [42]with SHA1 as the message authentication code.

The values used for δ and ∆ were 10% and 20% ofthe source’s rate, respectively. We developed a protocol-independent Byzantine attack simulation module for ns2.

A. Experimental Methodology

To capture a protocol’s effectiveness in delivering datato the multicast group, we used as a performance metricthe packet delivery ratio (PDR), defined as:

PDR =Pr

Ps · Nwhere Pr is the number of data packets received bymulticast group members, Ps is the number of datapackets sent by the source and N is the size of the group.

Because external attacks can be prevented using theauthentication framework described in Sec. V-B, in thispaper we focus on the following two Byzantine attacks:

black hole attack: This is a selective data forwardingattack, in which adversaries only forward routing controlpackets, while dropping all data packets.

flood rushing attack: The attack exploits the floodduplicate suppression technique used by many wirelessrouting protocols. By “rushing” an authenticated floodthrough the network before the flood traveling througha legitimate route, a Byzantine adversary ends up con-trolling many routes. The attack was implemented bysimply ignoring the small randomized delays which arenormally required to reduce the number of collisions.

In order to quantify the impact of adversarial position-ing, we consider the following scenarios:

random placement: Adversaries are placed randomlyin the simulation area;

strategic placement: Adversaries are placed strategi-cally around the multicast source, equidistant on a circlewith radius of 200 meters.

To study the influence of whether the adversariesexplicitly join the multicast group and the order ofjoining, we consider two scenarios:

NJOIN: Adversarial nodes do not join the group;JOIN: Adversarial nodes explicitly join the group

before any of the honest members join. The adversariesare considered group members in the formula for PDR.

We chose these test case scenarios in order to studythe impact of the attacks under a light set of conditions(adversaries are placed randomly, or they do not explic-itly join the multicast group) and under a more extremeset of conditions (adversaries are placed strategically, orthey join the group before honest nodes do).

B. Simulation Setup

We performed simulations using the ns2 networksimulator [38]. Nodes were set to use 802.11 radios with2 Mbps bandwidth and 250 meters nominal range. Thesimulated time was 600 seconds. We randomly placed100 nodes within a 1500 by 1500 meter area and themulticast source in the center of the area at coordinates(750,750). We experimented with different values forgroup size, number of adversaries and speed. Due tolack of space, we only include results for medium-sizedgroups (30 and 50), for adversaries between 14% - 66%of the group size and for “max” speeds of 0 and 5 m/s.

Group members join the group sequentially in thebeginning of the simulation, at 3-second intervals. Thenthe source transmits multicast data for 600 seconds at arate of 5 packets per second, each packet of 256 bytes.The members stay in the group until the end of thesimulation. Adversaries added to the network replacehonest nodes, thus modeling the capture of honest nodes.

Node movement pattern is defined by the random way-point model. Data points are averaged over 30 differentrandom environments and over all group members.

C. Attack Resilience

We evaluate the PDR as a function of the numberof adversaries, for different group sizes and levels ofmobility. Each graph illustrates the effect of the blackhole attack with and without flood rushing.

a) Impact of Adversarial Placement: When ad-versaries are randomly placed (Fig. 4), for the samegroup size, the PDR of A-MAODV decreases as the

A-MAODV A-MAODV-rush BSMR BSMR-rush

0

10

20

30

40

50

60

70

80

90

100

0 5 10 20

Adversaries

Pac

ket

Del

iver

y R

atio

(%

)

(a) 30 members; 0 m/s

0

10

20

30

40

50

60

70

80

90

100

0 5 10 20

Adversaries

Pac

ket

Del

iver

y R

atio

(%

)

(b) 30 members; 5 m/s

0

10

20

30

40

50

60

70

80

90

100

0 10 20 30

Adversaries

Pac

ket

Del

iver

y R

atio

(%

)

(c) 50 members; 0 m/s

0

10

20

30

40

50

60

70

80

90

100

0 10 20 30

Adversaries

Pac

ket

Del

iver

y R

atio

(%

)

(d) 50 members; 5 m/s

Fig. 4: Black hole attack and flood rushing combined with black hole:Random placement (NJOIN)

A-MAODV A-MAODV-rush BSMR BSMR-rush

0

10

20

30

40

50

60

70

80

90

100

0 5 10 20

Adversaries

Pac

ket

Del

iver

y R

atio

(%

)

(a) 30 members; 0 m/s

0

10

20

30

40

50

60

70

80

90

100

0 5 10 20

Adversaries

Pac

ket

Del

iver

y R

atio

(%

)

(b) 30 members; 5 m/s

0

10

20

30

40

50

60

70

80

90

100

0 10 20 30

Adversaries

Pac

ket

Del

iver

y R

atio

(%

)

(c) 50 members; 0 m/s

0

10

20

30

40

50

60

70

80

90

100

0 10 20 30

Adversaries

Pac

ket

Del

iver

y R

atio

(%

)

(d) 50 members; 5 m/s

Fig. 5: Black hole attack and flood rushing combined with black hole:Strategic placement (NJOIN)

number of adversaries increases. For the same numberof adversaries, it also decreases as we increase the groupsize. However, random adversarial placement causes thenumber of group members in the subtree below anadversary to be low; Thus a relatively large number ofadversaries is needed to cause a significant disruption(e.g., 30 adversaries for a group of size 50 cause a PDRdrop below 50%). In the presence of flood rushing, the

PDR decreases further because adversaries actively tryto get selected themselves as part of the tree.

We notice that, for A-MAODV, increasing the nodalspeed does not have a negative effect on the PDR; On thecontrary, at higher speeds we even see a slight increasein PDR. The effect of link breaks due to mobility iscompensated by the fact that group members get achance to reconnect to the multicast tree in a differentposition, possibly connected to the source through anadversarial-free path. For the same reason, the effect offlood rushing is diminished as the nodal speed increases.

BSMR is almost unaffected by the black hole attack(Fig. 4). The PDR drops by less than 10% even in thepresence of 20 adversaries. In addition, the influence offlood rushing is unnoticeable. This shows that BSMR’sstrategy that includes the processing of all responseflood duplicates and the metric capturing past behaviorof adversarial nodes, is effective against flood rushing.Mobility causes a slight PDR decrease, which is naturalbecause higher speeds will cause more link breaks.

In the previous experiments, the adversaries were ran-domly placed. Fig. 5 shows the results when adversariesare strategically positioned as described in Section VI-A.

When adversaries are strategically positioned (Fig. 5)as described in Sec. VI-A, we notice for A-MAODV adrastic drop in the PDR. For example, at 0 m/s, when thegroup size is 30, only 5 adversaries (representing 16%of the group size) are able to reduce the PDR to 25% byexecuting the black hole attack with flood rushing. Thisis a direct consequence of the fact that an adversary isnow selected in the tree closer to the root and the subtreebelow it may potentially contain many group members.For the same reason, the negative effect of the floodrushing attack is now emphasized when compared tothe random placement case. We conclude that strategicadversarial positioning has a crippling effect on theperformance of A-MAODV.

On the contrary, the effect of strategic adversarialpositioning on BSMR is minor (Fig. 5). Like for randomplacement, the PDR drops by less than 10% even in thepresence of 20 adversaries, at low nodal speeds. Whenmore adversaries are present, we see a slightly largerPDR decrease because there are less available honestnodes left in the network to serve as intermediaries forthe group members. The resilience of BSMR to attacksthat otherwise have a devastating effect on A-MAODVvalidates the effectiveness of BSMR’s approach.

b) Impact of Explicit Join and Join Order: Toanalyze the impact of explicit join of adversaries to themulticast group (JOIN), as compared to the NJOIN

A-MAODV A-MAODV-rush BSMR BSMR-rush ideal

0

10

20

30

40

50

60

70

80

90

100

0 5 10 20

Adversaries

Pac

ket

Del

iver

y R

atio

(%

)

(a) 30 honest members; 0 m/s

0

10

20

30

40

50

60

70

80

90

100

0 5 10 20

Adversaries

Pac

ket

Del

iver

y R

atio

(%

)

(b) 30 honest members; 5 m/s

0

10

20

30

40

50

60

70

80

90

100

0 10 20 30

Adversaries

Pac

ket

Del

iver

y R

atio

(%

)

(c) 50 honest members; 0 m/s

0

10

20

30

40

50

60

70

80

90

100

0 10 20 30

Adversaries

Pac

ket

Del

iver

y R

atio

(%

)

(d) 50 honest members; 5 m/s

Fig. 6: Black hole attack and flood rushing combined with black hole:Random placement (JOIN)

A-MAODV A-MAODV-rush BSMR BSMR-rush ideal

0

10

20

30

40

50

60

70

80

90

100

0 5 10 20

Adversaries

Pac

ket

Del

iver

y R

atio

(%

)

(a) 30 honest members; 0 m/s

0

10

20

30

40

50

60

70

80

90

100

0 5 10 20

Adversaries

Pac

ket

Del

iver

y R

atio

(%

)

(b) 30 honest members; 5 m/s

0

10

20

30

40

50

60

70

80

90

100

0 10 20 30

Adversaries

Pac

ket

Del

iver

y R

atio

(%

)

(c) 50 honest members; 0 m/s

0

10

20

30

40

50

60

70

80

90

100

0 10 20 30

Adversaries

Pac

ket

Del

iver

y R

atio

(%

)

(d) 50 honest members; 5 m/s

Fig. 7: Black hole attack and flood rushing combined with black hole:Strategic placement (JOIN)

case, we look again at the cases where adversaries arerandomly and strategically placed (Fig. 6 and 7). Figuresinclude the ideal PDR (labeled ideal), which wouldbe obtained if every honest group member receives allpackets sent by the source. Attack effectiveness shouldbe read as the difference between the ideal line and aprotocol’s PDR line; Thus, attack resilience will appearas a protocol line that stays parallel to the ideal line.

For random adversarial placement in Fig. 6, just like inthe NJOIN case, the PDR decreases as the number of ad-versaries increases. However, we see a major differencefrom the NJOIN case: When the adversaries explicitlyjoin the group before the honest nodes join, the impactof flood rushing is minimal because the adversaries arealready part of the group and rushing control packetsdoes not provide any additional benefit. On the contrary,in this case flood rushing may actually improve the PDRbecause, by rushing control packets, adversaries mayhelp legitimate nodes to find routes faster.

A drastic drop in the PDR is observed for A-MAODVwhen adversaries are placed strategically (Fig. 7). Weconclude that strategic positioning has a more cripplingeffect on the performance of A-MAODV even whenadversaries explicitly join the multicast group. For bothrandom and strategic adversarial placement, BSMR isbarely affected by the attacks: In most cases the PDR lineremains almost parallel to the ideal line, which showslittle degradation occurs as the number of adversariesincreases. The impact of the attacks on BSMR increasesslightly when a large number of adversaries have joinedthe group, because there are less available honest nodesleft in the network to serve as intermediaries for honestgroup members. We conclude that BSMR’s strategy iseffective in the JOIN case as well.

D. Protocol Overhead

In a non-adversarial scenario (Fig. 8(a)), BSMR hashigher overhead than A-MAODV because the route replyis flooded, and because of the extra MRATE packetsbroadcast periodically. BSMR’s overhead becomes morenoticeable especially at higher levels of mobility.

For an adversarial setting (Fig. 8(b)), we focus ona strong attack configuration: Black hole with strategicadversarial placement. For the NJOIN case, BSMR’s ad-ditional overhead compared to A-MAODV grows slowlyas the number of adversaries increases (from 40 morepackets/sec. for 0 adversaries to 55 more packets/sec.for 20 adversaries). For the JOIN case, the additionaloverhead does not grow as we increase the numberof adversaries, indicating that BSMR incurs little extraoverhead over the non-adversarial case.

VII. CONCLUSION

In this paper we have discussed several aspects thatmake designing attack-resilient multicast routing proto-cols for multi-hop wireless networks more challengingwhen compared to their unicast counterpart. A morecomplex trust model and underlying structure for the

0

50

100

150

200

250

0 1 2 5 10

Speed (m/s)

Ove

rhea

d (p

acke

ts /

seco

nd)

A-MAODV-10 A-MAODV-30BSMR-10 BSMR-30

(a) Non-adversarial scenario(group size ∈ {10, 30})

0

20

40

60

80

100

120

140

160

0 2 5 10 20

Adversaries

Ove

rhea

d (p

acke

ts /

seco

nd)

A-MAODV-NJOIN A-MAODV-JOINBSMR-NJOIN BSMR-JOIN

(b) Attack Scenario (group size= 30, 2m/s, strategic placement)

Fig. 8: BSMR overhead

routing protocol make solutions tailored for unicast set-tings not applicable for multicast protocols.

We have proposed BSMR, a routing protocol whichrelies on novel general mechanisms to mitigate Byzan-tine attacks. BSMR identifies and avoids adversariallinks based on a reliability metric that captures adversar-ial behavior. Our experimental results show that BSMR’sstrategy is effective against strong insider attacks such asblack holes and flood rushing.

ACKNOWLEDGEMENTS

The first author would like to thank Razvan Musaloiu-E. for fruitful “copy-room” discussions in the earlystages of this work. This work is supported by NationalScience Foundation CyberTrust Award No. 0545949.The views expressed in this research are not endorsedby the National Science Foundation.

REFERENCES[1] Y. B. Ko and N. H. Vaidya, “Flooding-based geocasting pro-

tocols for mobile ad hoc networks,” Mob. Netw. Appl., vol. 7,no. 6, pp. 471–480, 2002.

[2] R. Chandra, V. Ramasubramanian, and K. Birman, “Anonymousgossip: Improving multicast reliability in mobile ad-hoc net-works,” in Proc. of ICDCS, 2001.

[3] Y.-B. Ko and N. H. Vaidya, “GeoTORA: a protocol for geo-casting in mobile ad hoc networks,” in Proc. of ICNP. IEEEComputer Society, 2000, p. 240.

[4] E. L. Madruga and J. J. Garcia-Luna-Aceves, “Scalable mul-ticasting: the core-assisted mesh protocol,” Mob. Netw. Appl.,vol. 6, no. 2, pp. 151–165, 2001.

[5] S. J. Lee, W. Su, and M. Gerla, “On-demand multicast routingprotocol in multihop wireless mobile networks,” Mob. Netw.Appl., vol. 7, no. 6, pp. 441–453, 2002.

[6] E. Royer and C. Perkins, “Multicast ad-hoc on-demand distancevector (MAODV) routing,” in Internet Draft, July 2000.

[7] J. G. Jetcheva and D. B. Johnson, “Adaptive demand-drivenmulticast routing in multi-hop wireless ad hoc networks.” inProc. of MobiHoc, 2001, pp. 33–44.

[8] L. Lamport, R. Shostak, and M. Pease, “The Byzantine gen-erals problem,” in Advances in Ultra-Dependable DistributedSystems. IEEE Computer Society Press, 1995.

[9] P. Papadimitratos and Z. Haas, “Secure routing for mobile adhoc networks,” in Proc. of CNDS, January 2002, pp. 27–31.

[10] Y.-C. Hu, D. B. Johnson, and A. Perrig, “SEAD: Secure efficientdistance vector routing for mobile wireless ad hoc networks,”in Proc. of WMCSA, June 2002.

[11] Y.-C. Hu, A. Perrig, and D. B. Johnson, “Ariadne: A secureon-demand routing protocol for ad hoc networks,” in Proc. ofMOBICOM, September 2002.

[12] K. Sanzgiri, B. Dahill, B. N. Levine, C. Shields, and E. Belding-Royer, “A secure routing protocol for ad hoc networks,” in Proc.of ICNP, November 2002.

[13] S. Marti, T. Giuli, K. Lai, and M. Baker, “Mitigating routingmisbehavior in mobile ad hoc networks,” in Proc. of MOBI-COM, August 2000.

[14] P. Papadimitratos and Z. Haas, “Secure data transmission inmobile ad hoc networks,” in Proc. of WiSe, 2003, pp. 41–50.

[15] B. Awerbuch, D. Holmer, C. Nita-Rotaru, and H. Rubens,“An on-demand secure routing protocol resilient to byzantinefailures,” in Proc. of WiSe’02. ACM Press, 2002.

[16] B. Awerbuch, R. Curtmola, D. Holmer, C. Nita-Rotaru, andH. Rubens, “On the survivability of routing protocols in ad hocwireless networks,” in Proc. of SecureComm’05. IEEE, 2005.

[17] S. Roy, V. G. Addada, S. Setia, and S. Jajodia, “SecuringMAODV: Attacks and countermeasures,” in Proc. 2nd IEEEInt’l. Conf. SECON. IEEE, 2005.

[18] C. Zhang, B. DeCleene, J. Kurose, and D. Towsley, “Compari-son of inter-area rekeying algorithms for secure wireless groupcommunications,” Perform. Eval., vol. 49, no. 1-4, 2002.

[19] K. H. Rhee, Y. H. Park, and G. Tsudik, “An architecture for keymanagement in hierarchical mobile ad hoc networks,” Journalof Communication and Networks, vol. 6, no. 2, June 2004.

[20] Y.-C. Hu, A. Perrig, and D. B. Johnson, “Rushing attacks anddefense in wireless ad hoc network routing protocols,” in Proc.of WiSe. ACM, 2003.

[21] ——, “Packet leashes: A defense against wormhole attacks inwireless ad hoc networks,” in Proc. of INFOCOM, April 2003.

[22] J. Eriksson, S. Krishnamurthy, and M. Faloutsos, “Truelink: Apractical countermeasure to the wormhole attack in wirelessnetworks,” in Proc. of ICNP’06. IEEE, 2006.

[23] L. Hu and D. Evans, “Using directional antennas to preventwormhole attacks,” in Proc. of NDSS, 2004.

[24] D. Bruschi and E. Rosti, “Secure multicast in wireless networksof mobile hosts: protocols and issues,” Mobile Networks andApplications, vol. 7, no. 6, pp. 503–511, 2002.

[25] T. Kaya, G. Lin, G. Noubir, and A. Yilmaz, “Secure multicastgroups on ad hoc networks,” in Proc. of SASN’03. ACM Press,2003, pp. 94–102.

[26] S. Zhu, S. Setia, S. Xu, and S. Jajodia, “Gkmpan: An effi-cient group rekeying scheme for secure multicast in ad-hocnetworks,” in Proc. of Mobiquitos’04. IEEE, 2004, pp. 42–51.

[27] L. Lazos and R. Poovendran, “Power proximity based keymanagement for secure multicast in ad hoc networks,” 2005,aCM Journal on Wireless Networks (WINET).

[28] R. Balachandran, B. Ramamurthy, X. Zou, and N. Vinodchan-dran, “CRTDH: an efficient key agreement scheme for securegroup communications in wireless ad hoc networks,” in Proc.of ICC 2005, vol. 2, 2005, pp. 1123– 1127.

[29] S. Banerjee, S. Lee, B. Bhattacharjee, and A. Srinivasan,“Resilient multicast using overlays,” SIGMETRICS Perform.Eval. Rev., vol. 31, no. 1, pp. 102–113, 2003.

[30] V. Pappas, B. Zhang, A. Terzis, and L. Zhang, “Fault-tolerantdata delivery for multicast overlay networks,” in Proc. of ICDCS’04, 2004, pp. 670–679.

[31] L. Xie and S. Zhu, “Message dropping attacks in overlaynetworks: Attack detection and attacker identification,” in Proc.SecureComm ’06. IEEE and Create-NET, 2006.

[32] J. Newsome, E. Shi, D. Song, and A. Perrig, “The Sybil attackin sensor networks: analysis & defenses,” in Proc. of IPSN ’04.New York, NY, USA: ACM Press, 2004, pp. 259–268.

[33] C. Piro, C. Shields, and B. N. Levine, “Detecting the Sybilattack in mobile ad hoc networks,” in Proc. SecureComm, 2006.

[34] B. Parno, A. Perrig, and V. D. Gligor, “Distributed detection ofnode replication attacks in sensor networks.” in IEEE Sympo-sium on Security and Privacy, 2005, pp. 49–63.

[35] R. Curtmola and C. Nita-Rotaru, “Secure multicast routing inwireless networks,” to be published in ACM MC2R, 2006.

[36] K. Tang, K. Obraczka, S.-J. Lee, and M. Gerla, “A reliable,congestion-controlled multicast transport protocol in multime-dia multi-hop networks,” in Proc. of IEEE WPMC’02, 2002.

[37] A. Perrig, R. Canetti, D. Song, and J. D. Tygar, “Efficientand secure source authentication for multicast,” in Proc. ofNDSS’01, 2001.

[38] “The network simulator - ns2,” http://www.isi.edu/nsnam/ns/.[39] Y. Zhu and T. Kunz, “MAODV implementation for NS-2.26,”

Carleton University, Technical Report SCE-04-01.[40] R. L. Rivest, A. Shamir, and L. M. Adleman, “A method

for obtaining digital signatures and public-key cryptosystems,”Communications of the ACM, vol. 21, no. 2, pp. 120–126, 1978.

[41] Advanced Encryption Standard (AES). National Institute forStandards and Technology (NIST), 2001, no. FIPS 197.

[42] The Keyed-Hash Message Authentication Code (HMAC).NIST, 2002, no. FIPS 198.