ARIADNE Journal

8/13/2019 ARIADNE Journal

1/18

Wireless Networks 11, 2138, 2005 2005 Springer Science + Business Media, Inc. Manufactured in The Netherlands.

Ariadne: A Secure On-Demand Routing Protocol for Ad Hoc

NetworksYIH-CHUN HU and ADRIAN PERRIG

Carnegie Mellon University, USA

DAVID B. JOHNSON Rice University, USA

Abstract. An ad hoc network is a group of wireless mobile computers (or nodes), in which individual nodes cooperate by forwardingpackets for each other to allow nodes to communicate beyond direct wireless transmission range. Prior research in ad hoc networkinghas generally studied the routing problem in a non-adversarial setting, assuming a trusted environment. In this paper, we present attacksagainst routing in ad hoc networks, and we present the design and performance evaluation of a new secure on-demand ad hoc network routing protocol, called Ariadne. Ariadne prevents attackers or compromised nodes from tampering with uncompromised routes consistingof uncompromised nodes, and also prevents many types of Denial-of-Service attacks. In addition, Ariadne is efcient, using only highlyefcient symmetric cryptographic primitives.

Keywords: mobile ad hoc network, ad hoc network routing, secure routing, secure ad hoc network routing, Ariadne

1. Introduction

An ad hoc network is a group of wireless mobile computers(or nodes), in which nodes cooperate by forwarding packetsfor each other to allow them to communicate beyond directwireless transmission range. Ad hoc networks require no cen-

tralized administration or xed network infrastructure such asbase stations or access points, and can be quickly and inex-pensively set up as needed. They can be used in scenariosin which no infrastructure exists, or in which the existing in-frastructure does not meet application requirements for rea-sons such as security or cost. Applications such as militaryexercises, disaster relief, and mine site operation, for exam-ple, may benet from ad hoc networking, but secure and re-liable communication is a necessary prerequisite for such ap-plications.

Ad hoc network routing protocols are challenging to de-sign, and secure ones are even more so. Wired network rout-ing protocols such as BGP [54] do not handle well the type of

rapid node mobility and network topology changes that occurin ad hoc networks; such protocols also have high communi-cation overhead because they send periodic routing messageseven when the network is not changing. So far, researchersin ad hoc networking have generally studied the routing prob-lem in a non-adversarial network setting, assuming a trustedenvironment; relatively little research has been done in a morerealistic setting in which an adversary may attempt to disruptthe communication.

We focus here on on-demand (or reactive) routing proto-cols for ad hoc networks, in which a node attempts to dis-cover a route to some destination only when it has a packet to

Corresponding author.E-mail: [email protected]

send to that destination. On-demand routing protocols havebeen demonstrated to perform better with signicantly loweroverheads than periodic (or proactive) routing protocols inmany situations [8,28,38,46], since the protocol is able to re-act quickly to the many changes that may occur in node con-nectivity, yet is able to reduce (or eliminate) routing overhead

in periods or areas of the network in which changes are lessfrequent.

In this paper, we make two contributions to the area of secure routing protocols for ad hoc networks. First, we give amodel for the types of attacks possible in such a system, andwe describe several new attacks on ad hoc network routingprotocols. Second, we present the design and performanceevaluation of a new on-demand secure ad hoc network routingprotocol, called Ariadne, that withstands node compromiseand relies only on highly efcient symmetric cryptography.Relative to previous work in securing ad hoc network routingprotocols, Ariadne is more secure, more efcient, or moregeneral (e.g., Ariadne does not require trusted hardware anddoes not require powerful processors).

Ariadne can authenticate routing messages using one of three schemes: shared secret keys between all pairs of nodes,shared secret keys between communicating nodes combinedwith broadcast authentication, or digital signatures. We pri-marily discuss here the use of Ariadne with TESLA [48,49],an efcient broadcast authentication scheme that requiresloose time synchronization. Using pairwise shared keysavoids the need for synchronization, but at the cost of higherkey setup overhead; broadcast authentication such as TESLAalso allows some additional protocol optimizations.

In section 2 of this paper, we summarize the basic opera-

tion of the Dynamic Source Routing protocol (DSR) [2931],on which we base the design of our new secure routing proto-


2/18

22 HU, PERRIG AND JOHNSON

col, Ariadne, and in section 3, we review the TESLA broad-cast authentication protocol that we use in Ariadne. In sec-tion 4, we describe our assumptions about the network, thenodes, and security and key setup. We present an attackermodel and describe types of attacks in section 5. In section 6,

we present the design of Ariadne, and in section 7, we givean initial simulation-based performance evaluation of a basicform of Ariadne. In section 8, we discuss related work, andin section 9, we present our conclusions.

2. Basic operation of DSR

We base the design of our secure on-demand ad hoc net-work routing protocol, Ariadne, on the basic operation of the Dynamic Source Routing protocol (DSR) [2931], sinceDSR operates entirely on-demand and has been well stud-ied through both simulation and real testbed implementa-tion [8,28,38,39]. Unlike periodic protocols (e.g., [4,45,52]),which exchange routing information between nodes period-ically in an attempt to always maintain routes to all desti-nations, on-demand protocols exchange routing informationonly when a new route is needed to deliver a packet to somedestination. On-demand approaches to routing in ad hoc net-works often have lower overhead than periodic protocols,since they transmit routing information only in response toactual packets to be sent or in response to topology changesaffecting routes actively in use. Lower routing overhead al-lows more of the available bandwidth and battery power to beused towards delivery of application data. In a secure routingprotocol, reduced overhead has the added benet of reducing

the number of routing packets that need to be authenticated,thereby reducing the computational overhead needed for se-curity. The operation of DSR is divided into two activities: Route Discovery and Route Maintenance . In this section, wedescribe the basic form of Route Discovery and Route Main-tenance in DSR.

In DSR, when a node has a packet to send to some destina-tion and does not currently have a route to that destination inits Route Cache , the node initiates Route Discovery to nd aroute; this node is known as the initiator of the Route Discov-ery, and the destination of the packet is known as the Discov-erys target , as illustrated in gure 1. The initiator (node A )transmits a R OUTE REQUEST packet as a local broadcast,specifying the target (node D ) and a unique identier fromthe initiator A. Each node receiving the R OUTE REQUEST ,if it has recently seen this request identier from the initia-tor or if its own address is already present in an address listin the R EQUEST , discards the R EQUEST . Otherwise, the ap-pends its own node address to the address list in the R EQUESTand rebroadcasts the R EQUEST . When the R OUTE R EQUESTreaches its target node, the target sends a R OUTE REPLY back to the initiator of the R EQUEST , including a copy of the ac-cumulated list of addresses from the R EQUEST . When theR EPLY reaches the initiator of the R EQUEST , it caches thenew route in its Route Cache.

Route Maintenance is the mechanism by which a nodesending a packet along a specied route to some destina-

Figure 1. Example of DSR Route Discovery, in which initiator node A isattempting to discover a route to target node D .

Figure 2. Example of DSR Route Maintenance, in which intermedi-ate node C detects a broken link to D when forwarding a packet fromsource node A .

tion detects if that route has broken, for example becausetwo nodes in it have moved too far apart; an example of Route Maintenance is shown in gure 2. DSR is based onsource routing : when sending a packet, the originator listsin the header of the packet the complete sequence of nodesthrough which the packet is to be forwarded. Each node alongthe route forwards the packet to the next hop indicated inthe packets header, and attempts to conrm that the packetwas received by that next node; a node may conrm this bymeans of a link-layer acknowledgment, passive acknowledg-ment [32], or network-layer acknowledgment. If, after a lim-ited number of local retransmissions of the packet, a node inthe route is unable to make this conrmation (such as node Cin gure 2), it returns a R OUTE E RROR to the original sourceof the packet (node A ), identifying the link from itself to the

next node (node D ) as broken. The sender then removes thisbroken link from its Route Cache; for subsequent packets tothis destination, the sender may use any other route to thatdestination in its Cache, or it may attempt a new Route Dis-covery for that target if necessary.

The DSR protocol also denes a number of optimiza-tions to these mechanisms (e.g., [19,20,2931,35]). Someof these optimizations, such as ow state [20], are relativelyeasy to secure (ow state requires only broadcast authentica-tion of control messages), whereas others, such as link-statecaching [19], are more difcult (link-state caching requiressome mechanism to authenticate links, but Ariadne only at-

tempts to authenticate nodes). The use of these DSR opti-mizations is beyond the scope of this paper; we secure hereonly a basic version of DSR, with a limited path cache andwithout these optimizations.

3. Overview of TESLA

In this paper, we describe Ariadne primarily using the TESLA[48,49] broadcast authentication protocol for authenticatingrouting messages, since TESLA is efcient and adds only asingle message authentication code (MAC) to a message forbroadcast authentication. Adding a MAC (computed with a

shared key) to a message can provide secure authenticationin point-to-point communication; for broadcast communica-


3/18

ARIADNE 23

tion, however, multiple receivers need to know the MAC keyfor verication, which would also allow any receiver to forgepackets and impersonate the sender. Secure broadcast au-thentication thus requires an asymmetric primitive, such thatthe sender can generate valid authentication information, but

the receivers can only verify the authentication information.TESLA differs from traditional asymmetric protocols such asRSA [55] in that TESLA achieves this asymmetry from clock synchronization and delayed key disclosure, rather than fromcomputationally expensive one-way trapdoor functions.

To use TESLA for authentication, each sender chooses arandom initial key K N and generates a one-way key chainby repeatedly computing a one-way hash function H on thisstarting value: K N 1 = H [K N ], K N 2 = H [K N 1], . . . . Ingeneral, K i = H [K i + 1] = H N i [K N ]. To compute any pre-vious key K j from a key K i , j < i , a node uses the equationK j = H i j [K i ]. To authenticate any received value on theone-way chain, a node applies this equation to the receivedvalue to determine if the computed value matches a previousknown authentic key on the chain. Coppersmith and Jakob-sson present efcient mechanisms for storing and generatingvalues of hash chains [13].

Each sender pre-determines a schedule of the time at whichit publishes (or discloses) each key of its one-way key chain,in the reverse order from generation; that is, a sender pub-lishes its keys in the order K0 , K 1 , . . . , K N . A simple keydisclosure schedule, for example, would be to publish key K iat time T 0 + i I , where T 0 is the time at which K 0 is published,and I is the key publication interval.

TESLA relies on a receivers ability to determine which

keys a sender may have already published, based on loosetime synchronization between nodes. Let be the maxi-mum time synchronization error between any two nodes; thevalue must be known by all nodes. To send a packet, thesender uses a pessimistic upper bound on the end-to-endnetworkdelay between nodes and picks a key K i from its one-way key chain which, at the time any receiver is expected toreceive the packet, the receiver will believe has not yet beenpublished. For example, the sender could choose a key K ithat it will not publish until a time at least + 2 in the fu-ture; the value 2 is used here because the receivers clock may be ahead of the senders clock by , so at time t s at thesender, it is t s + at the receiver. In sending the packet, thesender adds a message authentication code (MAC), computedusing key K i , to the packet. When the packet reaches the re-ceiver, it will be t s + + , and the receiver will discard thepacket if the key might have been published already. Sincethe receiver knows the senders clock may be faster by , thereceiver will reject the packet unless it is received at least before the scheduled key release time, so the receiver must beable to verify that the key is released at time t s + + 2 orlater.

When a receiver receives a packet authenticated withTESLA, it rst veries the TESLA security condition that thekey K i used to authenticate the packet cannot yet have been

published. For example, if the local packet arrival time ist r, and the receiver knows that the earliest time at which the

sender will disclose the key K i is T 0 + i I , the receiver needsto verify only that t r (T 0 + i I ) , implying that K ihas not yet been published. Otherwise, the sender may havealready published K i and an attacker may have forged thepacket contents; the receiver thus discards the packet. How-

ever, if this check is successful, the receiver buffers the packetand waits for the sender to publish key K i . When the receiverthen receives K i , it authenticates K i as described above, andthen authenticates stored packets that were authenticated withany key K j , where j i . TESLA remains secure even if the end-to-end delay is larger than , although some receiversmay be required to discard the packet.

4. Assumptions

4.1. Notation

We use the following notation to describe security protocolsand cryptographic operations:

A, B are principals, such as communicating nodes.

KAB and KBA denote the secret MAC keys shared be-tween A and B (one key for each direction of commu-nication).

MAC K AB (M) denotes the computation of the message au-thentication code (MAC) of message M with the MAC keyK AB , for example, using the HMAC algorithm [3].

For notational convenience we assume hash and MACfunctions that take a variable number of arguments, simply

concatenating them in computing the function.

4.2. Network assumptions

The physical layer of a wireless network is often vulnerableto denial of service attacks such as jamming. Mechanismssuch as spread spectrum [51] have been extensively studiedas means of providing resistance to physical jamming, andwe thus disregard such physical layer attacks here.

We assume that network links are bidirectional; that is, if a node A is able to receive packets transmitted directly bysome node B , then B is able to receive packets transmitteddirectly by A . It is possible to use a network with unidirec-tional links if such links are detected and avoided; such de-tection may also otherwise be necessary, since many wirelessMedium Access Control protocols require bidirectional links,as they make use of bidirectional exchange of several link-layer frames between a source and destination to help avoidcollisions and improve reliability [6,27].

Medium Access Control protocols are also often vulner-able to attack. For example, in IEEE 802.11, an attackercan paralyze nodes in its neighborhood by sending Clear-To-Send (CTS) frames periodically, setting the Duration eldof each frame to at least the interval between such frames.Less sophisticated Medium Access Control protocols, such

as ALOHA and Slotted ALOHA [1], are not vulnerable tosuch attacks but have lower efciency, and the development


4/18


of secure Medium Access Control protocols is an active areaof research. In this paper, we disregard attacks on MediumAccess Control protocols.

We assume that the network may drop, corrupt, reorder, orduplicate packets in transmission.

When Ariadne is used with a broadcast authentication pro-tocol, we naturally inherit all of that protocols assumptions.For example, when TESLA is used, each node in the network must be able to estimate the end-to-end transmission time toany other node in the network; TESLA permits this value tobe chosen adaptively and pessimistically. When this time ischosen to be too large, authentication delay increases, reduc-ing protocol responsiveness; when it is chosen to be too small,authentic packets may be rejected, but security is not compro-mised.

4.3. Node assumptions

The resources of different ad hoc network nodes may varygreatly, from nodes with very little computational resources,to resource-rich nodes equivalent in functionality to high-performance workstations. To make our results as gen-eral as possible, we have designed Ariadne to supportnodes with few resources, such as Palm PDAs or RIMpagers.

Most previous work on secure ad hoc network routing re-lies on asymmetric cryptography such as digital signatures[64,66]. However, computing such signatures on resource-constrained nodes is expensive, and we assume that nodesin the ad hoc network may be so constrained. For exam-ple, Brown et al. analyze the computation time of digital sig-nature algorithms on various platforms [9]; on a Palm PilotPDA (16 MHz Motorola 68000 Dragonball processor) orRIM pager (10 MHz custom Intel 386 processor), a 512-bitRSA [55] signature generation takes 2.45.8seconds, and sig-nature verication takes 0.10.6 seconds, depending on thepublic exponent.

When Ariadne is used with TESLA for broadcast au-thentication, we assume that all nodes have loosely syn-chronized clocks, such that the difference between any twonodes clocks does not exceed ; the value of mustbe known by all nodes in the network. Accurate time syn-chronization can be maintained, for example, with off-the-shelf hardware based on GPS [12,61], although the timesynchronization signal itself may be subject to attack [15].We assume that nodes compensate clock drift with peri-odic re-synchronization. Microcomputer-compensated crys-tal oscillators [5] can provide sub-second accuracy for sev-eral months; if normal crystal oscillators are used, the valueof can be chosen to be as large as necessary, though acorresponding reduction in protocol responsiveness will re-sult.

We do not assume trusted hardware such as tamperproof modules. Secure routing with trusted hardware is much sim-

pler, since node compromise is assumed to be impossible(section 6.1).

4.4. Security assumptions and key setup

The security of Ariadne relies on the secrecy and authenticityof keys stored in nodes. Ariadne relies on the following keysto be set up, depending on which authentication mechanismis used:

If pairwise shared secret keys are used, we assume a mech-anism to set up the necessary n(n + 1)/ 2 keys, if n is thenumber of nodes in the network.

If TESLA is used, we assume a mechanism to set up sharedsecret keys between pairs of nodes that communicate, andto distribute one authentic public TESLA key for eachnode.

If digital signatures are used, we assume a mechanism todistribute one authentic public key for each node.

To set up shared secret keys, we can use a variety of mechanisms. For example, a key distribution center maybe used, which shares a secret key with each node andsets up shared secret keys with communicating nodes, suchas in Kerberos [36] or SPINS [50]; shared secret keyscan be bootstrapped from a Public Key Infrastructure (PKI)using protocols such as TLS [14]; or shared secret keyscan be pre-loaded at initialization, possibly through physi-cal contact [60]. Menezes et al. discuss several key setupprotocols [42].

To set up authentic public keys, we can either embed allpublic keys at initialization in each node, or assume a PKIand embed the trusted Certication Authoritys public key ineach node and then use that key to authenticate the public

keys of other nodes. Another approach proposed by Hubauxet al. [26] bootstraps trust relationships based on PGP-likecerticates.

Ariadne also requires that each node have an authentic el-ement from the Route Discovery chain (section 6.5) of everynode initiating Route Discoveries. These keys can be set upin the same way as a public key.

Key setup is an expensive operation. Setting up sharedsecret keys requires authenticity and condentiality, whereassetting up public keys only requires authenticity. Further-more, fewer public keys are generally needed, because in anetwork with n nodes, only n public keys are needed and can

potentially be broadcast, whereas n(n + 1)/ 2 secret keys needto be set up in the case of pairwise shared secret keys. In sec-tion 4.5, we describe a mechanism to set up these keys with-out relying on Ariadne, thus avoiding the circular dependencybetween key setup and the routing protocol.

4.5. Establishing authenticated keys using a trusted KDC

Although Ariadne does not require a trusted Key DistributionCenter (KDC) node in the ad hoc network, some ad hoc net-works may contain a KDC as a mechanism for authenticatedkey setup between pairs of nodes as need, as mentioned insection 4.4. A challenge to this type of key setup is the need

for routing to be established before conventional KDC proto-cols can be used. We describe here how this type of key setup


5/18

ARIADNE 25

can be done, if desired, with no established routing withinAriadne.

As described in section 4.1, we assume that each node Ashares secret MAC keys K AT and K T A between itself and thetrusted KDC T for use with a message authentication code

(MAC) algorithm such as HMAC [3] (one key for each di-rection of communication). For use with this method of es-tablishing authenticated keys using a trusted KDC, we furtherassume that each node A similarly shares secret encryptionkeys K AT and KT A between itself and the KDC T . Theseshared keys K AT , K AT , K T A , and K T A for node A could, forexample, all be derived by A and the KDC T using a singleshared a master secret key X AT = X T A (no direction infor-mation is associated with this key) using a Pseudo-RandomFunction (PRF) [16]: if F is a PRF, then let K AT = F X AT (1) ,K AT = F X AT (2) , K T A = F X AT (3) , and K T A = F X AT (4) .

We also assume here that each node can obtain an authen-tic TESLA key of the KDC; that the KDC has an authenticTESLA key for each other node; and if MW-Chains [24] areused to thwart R OUTE REQUEST oods as described in sec-tion 6.3, that each node can obtain an authentic MW-Chainhead for the KDC.

To bootstrap authenticated keys between pairs of nodes,the KDC node initiates a Route Discovery with a special, re-served address (not the address of any actual node) as the tar-get of the Discovery. The Route Discovery is processed byeach node as in Ariadne, except that each node receiving thisspecial R EQUEST for the rst time also returns a R OUTE R E -PLY . The KDC can then use each returned route to send au-thenticated keys to each node in the network. Alternatively,

this special Route Discovery procedure can be repeated pe-riodically; when a node needs a shared key with some othernode, it waits until the next such special Discovery is initi-ated by the KDC node, and at that time includes as part of its R OUTE REPLY to the KDC the list of nodes for which itneeds authenticated keys.

5. Ad hoc network routing security

In this section, we dene a taxonomy of types of attackers anddiscuss specic attacks against ad hoc network routing. Thisapproach allows us to categorize the security of an ad hocnetwork routing protocol based on the strongest attacker itwithstands.

5.1. Attacker model

We consider two main attacker classes, passive and active .The passive attacker does not send messages; it only eaves-drops on the network. Passive attackers are mainly threatsagainst the privacy or anonymity of communication, ratherthan against the functioning of the network or its routing pro-tocol, and thus we do not discuss them further here.

An active attacker injects packets into the network and

generally also eavesdrops. We characterize the attacker basedon the number of nodes it owns in the network, and based on

the number of those that are good nodes it has compromised.We assume that the attacker owns all the cryptographic keyinformation of compromised nodes and distributes it amongall its nodes. We denote such an attacker Active- n -m , where nis the number of nodes it has compromised and m is the num-

ber of nodes it owns. We propose the following attacker hier-archy (with increasing strength) to measure routing protocolsecurity: Active-0-1 (the attacker owns one node), Active-0- x(the attacker owns x nodes), Active-1- x (the attacker ownsone compromised node and distributes the cryptographickeysto its x 1 other nodes), and Active- y -x . In addition, wecall an attacker that has compromised nodes an Active-VCattacker if it owns all nodes on a vertex cut through the net-work that partitions the good nodes into multiple sets, forc-ing good nodes in different partitions to communicate onlythrough an attacker node. This attacker is particularly pow-erful, as it controls all trafc between nodes of the disjointpartitions.

Our protocol does not require a trusted Key DistributionCenter (KDC) in the network, but some ad hoc networks mayuse one for key setup, as mentioned in section 4.4. We do notconsider the case in which an attacker compromises the KDC,since the KDC is a central trust entity, and a compromisedKDC compromises the entire network.

5.2. General attacks on ad hoc network routing protocols

Attacks on ad hoc network routing protocols generally fallinto one of two categories: routing disruption attacks andresource consumption attacks. In a routing disruption at-tack, the attacker attempts to cause legitimate data packetsto be routed in dysfunctional ways. In a resource consump-tion attack, the attacker injects packets into the network inan attempt to consume valuable network resources such asbandwidth, or to consume node resources such as memory(storage) or computation power. From an application-layerperspective, both attacks are instances of a Denial-of-Service(DoS) attack.

An example of a routing disruption attack is for an attackerto send forged routing packets to create a routing loop , caus-ing packets to traverse nodes in a cycle without reaching theirdestinations, consuming energy and available bandwidth. Anattacker may similarly create a routing black hole , in whichall packets are dropped: by sending forged routing packets,the attacker could cause all packets for some destination to berouted to itself and could then discard them, or the attackercould cause the route at all nodes in an area of the network topoint into that area when in fact the destination is outsidethe area. As a special case of a black hole, an attacker couldcreate a gray hole , in which it selectively drops some pack-ets but not others, for example, forwarding routing packetsbut not data packets. An attacker may also attempt to causea node to use detours (suboptimal routes) or may attempt to partition the network by injecting forged routing packets to

prevent one set of nodes from reaching another. An attackermay attempt to make a route through itself appear longer by


6/18


adding virtual nodesto the route; we call this attack gratuitousdetour , as a shorter route exists and would otherwise havebeen used. In ad hoc network routing protocols that attemptto keep track of perceived malicious nodes in a blacklist ateach node, such as is done in watchdog and pathrater [40], an

attacker may malign a good node, causing other good nodesto add that node to their blacklists, thus avoiding that node inroutes.

A more subtle type of routing disruption attack is the cre-ation of a wormhole in the network [25], using a pair of at-tacker nodes A and B linked via a private network connec-tion. Every packet (or selected packets) that A receives fromthe ad hoc network, A forwards through the wormhole to B ,to then be rebroadcast by B ; similarly, B may send all packetsto A . Such an attack potentially disrupts routing by short cir-cuiting the normal ow of routing packets, and the attackersmay also create a virtual vertex cut that they control.

The rushing attack is a malicious attack that is targetedagainst on-demand routing protocols that nd routes througha Route Discovery protocol and use duplicate suppressionof the R OUTE REQUEST messages in that protocol at eachnode [23]. An attacker disseminates R OUTE REQUEST squickly throughout the network, suppressing any later legit-imate R OUTE REQUEST s when nodes drop them due to theduplicate suppression.

An example of a resource consumption attack is for an at-tacker to inject extra data packets into the network, whichwill consume bandwidth resources when forwarded, espe-cially over detours or routing loops. Similarly, an attackercan inject extra control packets into the network, which mayconsume even more bandwidth or computational resourcesas other nodes process and forward such packets. With ei-ther of these attacks, an Active-VC attacker can try to ex-tract maximum resources from the nodes on both sides of the vertex cut; for example, it might forward only routingpackets and not data packets, such that the nodes waste en-ergy forwarding packets to the vertex cut, only to have themdropped.

If a routing protocol can prevent an attacker from insertingrouting loops, and if a maximum route length can be enforced,

then an attacker that can inject extra data packets has limitedattack power. In particular, if routes are limited to hops,then each data packet transmitted by the attacker causes onlyat most a xed number of additional transmissions; more gen-erally, if at most one control packet can be sent in response toeach data packet (e.g., a R OUTE ERROR ), and that controlpacket is limited to hops, then an individual data packetcan cause only 2 individual transmissions. We consider anattack a DoS attack only if the ratio between the total work performed by nodes in the network and the work performedby the attacker is on the order of the number of nodes in thenetwork. An example of a DoS attack is for the attacker to

send a single packet that results in a packet ood throughoutthe network.

6. Ariadne

6.1. Design goals

We aim for resilience against Active-1- x and Active- y -x at-

tackers. Ideally, the probability that the routing protocol de-livers messages degrades gracefully when nodes fail or arecompromised. Our goal is to design simple and efcientmechanisms achieving high attack robustness. These mecha-nisms should be sufciently general to allow application to awide range of routing protocols.

Defending against an Active-0- x attacker is relatively easy.A network-wide shared secret key limits the attacker to re-playing messages. Thus the main attacks remaining arethe wormhole and rushing attacks (section 5.2). Packet leashes [25] can prevent both attacks because they preventan Active-0- x attacker from retransmitting packets. Theseapproaches also trivially secure a network routing protocolthat uses tamperproof hardware, since the strongest attackerin such an environment is an Active-0- x attacker, assuming allrouting and security functionality (including packet leashes)is implemented in the secure hardware.

Most routing disruption attacks we present in section 5.2are caused by malicious injection or altering of routing data.To prevent these attacks, each node that interprets routing in-formation must verify the origin and integrity of that data;that is, it must authenticate the data. Ideally, the initiator of the Route Discovery can verify the origin of each individualdata eld in the R OUTE R EPLY .

We need an authentication mechanism with low computa-

tion and communication overhead. An inefcient authentica-tion mechanism could be exploited by an attacker to performa Denial-of-Service (DoS) attack by ooding nodes with ma-licious messages, overwhelming them with the cost of veri-fying authentication. Thus, for point-to-point authenticationof a message, we use a message authentication code (MAC)(e.g., HMAC [3]) and a shared key between the two parties.However, setting up the shared keys between the initiator andall the nodes on the path to the target may be expensive. Wethus also propose using the TESLA broadcast authenticationprotocol (section 3) for authentication of nodes on the rout-ing path. However, we also discuss MAC authentication withpairwise shared keys, for networks capable of inexpensive keysetup, and we discuss digital signatures for authentication, fornetworks with extremely powerful nodes.

As a general design principle, a node trusts only itself for acquiring information about which nodes in the network are malicious. This approach helps avoid blackmail attacks,where an attacker constructs information to make a legitimatenode appear malicious. In our design, we assume that a sendertrusts the destination with which it communicates, for authen-ticating nodes on the path between them. This assumption isstraightforward, as the destination node can control all com-munication with the sender anyway. However, the destina-tion node can potentially blackmail nodes on the path to the

sender. The sender thus needs to keep a separate blacklist foreach destination.


7/18

ARIADNE 27

In general, ad hoc network routing protocols do not needsecrecy or condentiality . These properties are required toachieve privacy or anonymity for the sender of messages.Even in the Internet, it is challenging to achieve senderanonymity, and this area is still the subject of active research.

Our protocol does not prevent an attacker from injectingdata packets. As we described in section 5.2, injecting apacket results in a DoS attack only if it oods the network.Since data packets cannot ood the network, we do not ex-plicitly protect against packet injection. However, maliciousROUTE REQUEST messages that ood the network do clas-sify as a DoS attack, and we thus prevent this attack with aseparate mechanism that we describe in section 6.5.

6.2. Basic Ariadne Route Discovery

In this section, we describe the basic operation of Route Dis-covery in Ariadne. We rst overview the features of theprotocol in three stages: we present a mechanism that en-ables the target of a Route Discovery to verify the authentic-ity of the R OUTE REQUEST ; we then present three alternativemechanisms for authenticatingdata in R OUTE REQUEST s andROUTE R EPLY s; and we present an efcient per-hop hashingtechnique to verify that no node is missing from the node listin the R EQUEST . After this overview, we present in detailthe operation of Route Discovery in Ariadne when TESLAis used as the authentication mechanism. In the followingdiscussion, we assume that some initiator node S performs aRoute Discovery for a target node D , and that they share thesecret keys K SD and K DS , respectively, for message authen-

tication in each direction.

Target authenticates ROUTE REQUEST s. To convince thetarget of the legitimacy of each eld in a R OUTE RE -QUEST , the initiator simply includes in the R EQUEST a MACcomputed with key KSD over unique data, for example atimestamp. The target can easily verify the authenticity andfreshness of the R OUTE REQUEST using the shared key K SD .

Three techniques for route data authentication. In a RouteDiscovery, the initiator wants to authenticate each individualnode in the node list of the R OUTE REPLY . A secondaryrequirement is that the target can authenticate each node inthe node list of the R OUTE R EQUEST , so that it will return aROUTE REPLY only along paths that contain only legitimatenodes. In this section, we present three alternative techniquesto achieve node list authentication: the TESLA protocol, dig-ital signatures, and standard MACs.

When Ariadne Route Discovery is used with TESLA, eachhop authenticates the new information in the R EQUEST . Thetarget buffers and does not send the R EPLY until intermedi-ate nodes can release the corresponding TESLA keys. TheTESLA security condition is veried at the target, and the tar-get includes a MAC in the R EPLY to certify that the securitycondition was met. TESLA requires each packet sender to

choose a a pessimistic upper bound on the end-to-end net-work delay between nodes for sending this packet, in order to

select the TESLA key it will use to authenticate it. Choicesof do not affect the security of the protocol, although val-ues that are too small may cause the Route Discovery to fail.Ariadne can choose adaptively, by increasing when a Dis-covery fails. In addition, the target of the Discovery could

provide feedback in the R OUTE REPLY when was chosentoo large.If Ariadne Route Discovery is used with digital signa-

tures , instead, the authentication differs in that no Route Dis-covery chain element is required (section 6.5). In addition,the MAC list in the R OUTE R EQUEST (described below) be-comes a signature list, where the data used to compute theMAC is instead used to compute a signature. Rather thancomputing the target MAC using a Message AuthenticationCode, a signature is used. Finally, no key list (also describedbelow) is required in the R EPLY .

Ariadne Route Discovery using MACs is the most efcientof the three alternative authentication mechanisms, but it re-quires pairwise shared keys between all nodes. When Ariadneis used in this way, the MAC list in the R OUTE REQUEST iscomputed using a key shared between the target and the cur-rent node, rather than using the TESLA key of the currentnode. The MACs are veried at the target and are not re-turned in the R OUTE REPLY . As a result, the target MAC isnot computed over the MAC list in the R EQUEST . In addition,no key list is required in the R EPLY .

Per-hop hashing. Authentication of data in routing mes-sages is not sufcient, as an attacker could remove a nodefrom the node list in a R OUTE REQUEST . We use one-wayhash functions to verify that no hop was omitted, and we callthis approach per-hop hashing . To change or remove a pre-vious hop, an attacker must either hear a R OUTE REQUESTwithout that node listed, or it must be able to invert the one-way hash function.

Ariadne Route Discovery with TESLA. We now describe indetail the version of Ariadne Route Discovery using TESLAbroadcast authentication. We assume that every end-to-endcommunicating sourcedestination pair of nodes A and Bshare the MAC keys KAB and KBA . We also assume thatevery node has a TESLA one-way key chain, and that allnodes know an authentic key of the TESLA one-way keychain of each other node (for authentication of subsequentkeys, as described in section 3). Route Discovery has twostages: the initiator oods the network with a R OUTE RE -QUEST , and the target returns a R OUTE REPLY . To securethe R OUTE REQUEST packet, Ariadne provides the followingproperties: (1) the target node can authenticate the initiator(using a MAC with a key shared between the initiator andthe target); (2) the initiator can authenticate each entry of thepath in the R OUTE REPLY (each intermediate node appendsa MAC with its TESLA key); and (3) no intermediate nodecan remove a previous node in the node list in the R EQUESTor R EPLY (a one-way function prevents a compromised nodefrom removing a node from the node list).

A ROUTE REQUEST packet in Ariadne contains eightelds: ROUTE R EQUEST , initiator , target , id , time interval ,


8/18


S : h0 = MAC K SD (REQUEST ,S ,D , id , ti)S : REQUEST ,S ,D , id , ti, h 0 ,(),()A : h1 = H [A, h 0]

M A = MAC K Ati (R EQUEST ,S ,D , id , ti, h 1 , (A),())A : REQUEST ,S ,D , id , ti, h 1 , ( A ), ( M A )

B : h2 = H [B, h 1 ]M B = MAC K Bti (R EQUEST ,S ,D , id , ti, h 2 ,(A,B),(M A ))B : REQUEST ,S ,D , id , ti, h 2 ,(A, B ),(M A , M B )C : h3 = H [C, h 2 ]

M C = MAC K Cti (R EQUEST ,S ,D, id , ti, h 3 , (A,B,C),(M A , M B ))C : REQUEST ,S ,D , id , ti, h 3 , (A,B, C ),(M A , M B , M C )D : M D = MAC K DS (R EPLY ,D ,S , ti ,(A,B,C),(M A , M B , M C ))D C : REPLY ,D ,S , ti,(A,B,C),(M A , M B , M C ), M D , ()C B : REPLY ,D ,S , ti,(A,B,C),(M A , M B , M C ), M D , ( K C ti )B A : REPLY ,D ,S , ti,(A,B,C),(M A , M B , M C ), M D , (K C ti , K B ti )A S : REPLY ,D ,S , ti,(A,B,C),(M A , M B , M C ), M D , (K C ti , K B ti , K A ti )

Figure 3. Route Discovery example in Ariadne. The initiator node S is attempting to discover a route to the target node D . The bold underlined font indicateschanged message elds, relative to the previous message of that type.

hash chain , node list , MAC list . The initiator and target areset to the address of the initiator and target nodes, respec-tively. As in DSR, the initiator sets the id to an identier thatit has not recently used in initiating a Route Discovery. Thetime interval is the TESLA time interval at the pessimisticexpected arrival time of the R EQUEST at the target, account-ing for clock skew; specically, given , a pessimistic transittime, the time interval could be set to any time interval forwhich the key is not released within the next + 2 time.The initiator of the R EQUEST then initializes the hash chain

to MAC K SD ( initiator , target , id , time interval ) and the nodelist and MAC list to empty lists.

When any node A receives a R OUTE R EQUEST for whichit is not the target, the node checks its local table of initiator , id values from recent R EQUEST s it has received,

to determine if it has already seen a R EQUEST from this sameRoute Discovery. If it has, the node discards the packet, as inDSR. The node also checks whether the time interval in theR EQUEST is valid: that time interval must not be too far in thefuture, and the key corresponding to it must not have been dis-closed yet. If the time interval is not valid, the node discardsthe packet. Otherwise, the nodemodies the R EQUEST by ap-

pending its own address, A , to the node list in the R EQUEST ,replacing the hash chain eld with H [A, hash chain ], and ap-pending a MAC of the entire R EQUEST to the MAC list . Thenode uses the TESLA key K A i to compute the MAC, wherei is the index for the time interval specied in the R EQUEST .Finally, the node rebroadcasts the modied R EQUEST , as inDSR.

When the target node receives the R OUTE REQUEST , itchecks the validity of the R EQUEST by determining that thekeys from the time interval specied have not been disclosedyet, and that the hash chain eld is equal to

H n , H n 1 , H . . . , H 1 , MAC K SD (initiator , target , id ,time interval ) . . . ,

where i is the node address at position i of the node list inthe R EQUEST , and where n is the number of nodes in thenode list . If the target node determines that the R EQUEST isvalid, it returns a R OUTE REPLY to the initiator, containingeight elds: ROUTE R EPLY , target , initiator , time interval ,node list , MAC list , target MAC , key list . The target , initia-tor , time interval , node list , and MAC list elds are set tothe corresponding values from the R OUTE REQUEST , the tar-get MAC is set to a MAC computed on the preceding elds inthe R EPLY with the key K DS , and the key list is initialized to

the empty list. The R OUTE R EPLY is then returned to the ini-tiator of the R EQUEST along the source route obtained by re-versing the sequence of hops in the node list of the R EQUEST .

A node forwarding a R OUTE REPLY waits until it is ableto disclose its key from the time interval specied; it thenappends its key from that time interval to the key list eld inthe R EPLY and forwards the packet according to the sourceroute indicated in the packet. Waiting delays the return of the R OUTE REPLY but does not consume extra computationalpower.

When the initiator receivesa R OUTE REPLY , it veries thateach key in the key list is valid, that the target MAC is valid,and that each MAC in the MAC list is valid. If all of thesetests succeed, the node accepts the R OUTE REPLY ; otherwise,it discards it. Figure 3 shows an example of Route Discoveryin Ariadne.

6.3. Basic Ariadne Route Maintenance

Route Maintenance in Ariadne is based on DSR as describedin section 2. A node forwarding a packet to the next hopalong the source route returns a R OUTE ERROR to the orig-inal sender of the packet if it is unable to deliver the packetto the next hop after a limited number of retransmission at-tempts. In this section, we discuss mechanisms for securing

ROUTE E RROR s, but we do not consider the case of attackersnot sending E RROR s (section 6.4).


9/18

ARIADNE 29

To prevent unauthorized nodes from sending E RROR s, werequire that an E RROR be authenticated by the sender. Eachnode on the return path to the source forwards the E RROR . If the authentication is delayed, for example, when TESLA isused, each node that will be able to authenticate the E RROR

buffers it until it can be authenticated.When using broadcast authentication, such as TESLA,a ROUTE ERROR packet in Ariadne contains six elds:ROUTE E RROR , sending address , receiving address , time

interval , error MAC , recent TESLA key . The sending addressis set to the address of the intermediate node encountering theerror, and the receiving address is set to the intended next hopdestination of the packet it was attempting to forward. Forexample, if node B is attempting to forward a packet to thenext hop node C , if B is unable to deliver the packet to C ,node B sends a R OUTE ERROR to the original sender of thepacket; the the sending address in this example is set to B ,and the receiving address is set to C . The time interval inthe R OUTE ERROR is set to the TESLA time interval at thepessimistic expected arrival time of the E RROR at the des-tination, and the error MAC eld is set to the MAC of thepreceding elds of the R OUTE ERROR , computed using thesender of the R OUTE ERROR s TESLA key for the time inter-val specied in the E RROR . The recent TESLA key eld in theROUTE E RROR is set to the most recent TESLA key that canbe disclosed for the sender of the E RROR . We use TESLA forauthenticating R OUTE E RROR s so that forwarding nodes canalso authenticate and process the R OUTE E RROR .

When sending a R OUTE ERROR , the destination of thepacket is set to the source address of the original packet trig-

gering the E RROR , and the R OUTE ERROR is forwarded to-ward this node in the same way as a normal data packet;the source route used in sending the R OUTE ERROR packetis obtained by reversing the source route from the headerof the packet triggering the E RROR . Each node that is ei-ther the destination of the E RROR or forwards the E RRORsearches its Route Cache for all routes it has stored that usethe sending address , receiving address link indicated by theE RROR . If the node has no such routes in its Cache, it doesnot process the R OUTE ERROR further (other than forwardingthe packet, if it is not the destination of the E RROR ). Other-wise, the node checks whether the time interval in the E RRORis valid: that time interval must not be too far into the future,and the key corresponding to it must not have been disclosedyet; if the time interval is not valid, the node similarly doesnot process the R OUTE E RROR further.

If all of the tests above for the R OUTE ERROR succeed, thenode checks the authentication on the E RROR , based on thesending nodes TESLA key for the time interval indicated inthe E RROR . To do so, the node saves the information from theE RROR in memory until it receives a disclosed TESLA keyfrom the sender that allows this. During this time, the nodecontinues to use the routes in its Route Cache without modi-cation from this E RROR . If the sender stops using that route,there will be no need to complete the authentication of the

E RROR . Otherwise, each subsequent packet sent along thisroute by this node will trigger an additional R OUTE ERROR ,

and once the TESLA time interval used in the rst E RRORends, the recent TESLA key eld in the next E RROR returnedwill allow authentication of this rst E RROR ; alternatively,the node could also explicitly request the needed TESLA keyfrom the sender once the interval ends. Once the R OUTE E R -

ROR has been authenticated, the node removes from its RouteCache all routes using the indicated link, and also discardsany saved information for other E RROR s for which, as a re-sult of removing these routes, it then has no correspondingroutes in its Route Cache.

To handle the possible memory consumption attack of needing to save information from many pending R OUTE E R -ROR s, the following technique is quite effective: each nodekeeps in memory a table containing the information fromeachROUTE ERROR awaiting authentication. We manage this ta-ble such that the probability that the information from an E R -ROR is in the table is independent of the time that this nodereceived that R OUTE E RROR .

When the wireless link capacity is nite, an attacker can inject only a nite number of R OUTE E RROR s within a TESLAtime interval plus 2 + . As a result, the probability of success for our defense against memory consumption attacksfor received R OUTE E RROR s in any time interval is given byp s = 1 (y/(x + y )) N , where N is the number of R OUTEE RROR s that can be held in the nodes table, x is the numberof authentic R OUTE E RROR s received, and y is the number of E RROR s sent by the attacker. The maintenance of a link there-fore follows a geometric distribution, and the expected num-ber of time intervals before success is (1 (y/(x + y)) N ) 1 .For example, in a network using a 1-second TESLA time in-

terval and an 11 Mbps wireless link, if the size of a R OUTEE RROR packet is 60 bytes, then a node with a 5000-elementtable receiving just one authentic R OUTE E RROR per secondcan successfully authenticate and process one of the authen-tic R OUTE ERROR s within 5.1 seconds on the average, evenwhen an attacker is otherwise ooding the node with mali-cious R OUTE ERROR s. This 5.1 second recovery time rep-resents a worst-case scenario, and minimal node resourcesare consumed while the node waits to validate one of theseROUTE R EQUEST s.

When digital signatures or pairwise shared keys are used,this memory consumption attack is not possible, and the au-thentication is more straightforward. A R OUTE E RROR neednot include a time interval or recent TESLA key . Furthermore,the error MAC is changed to a digital signature when digitalsignatures are used. When pairwise shared keys are used, theerror MAC is computed based on the key shared between theoriginal sender of the packet and the sender of the R OUTEE RROR , rather than on the TESLA key of the sender of theE RROR .

6.4. Thwarting the effects of routing misbehavior

The protocol described so far is vulnerable to an Active-1-1attacker that happens to be along the discovered route. In

particular, we have not presented a means of determiningwhether intermediate nodes are, in fact, forwarding packets


10/18


that they have been requested to forward. Watchdog andpathrater [40] attempt to solve this problem by identifyingthe attacking nodes and avoiding them in the routes used.Instead, we choose routes based on their prior performancein packet delivery. Introducing mechanisms that penalize

specic nodes for routing misbehavior (such as is done inwatchdog and pathrater) is subject to a blackmail attack (sec-tion 5.1), where a sufcient number of attackers may be ableto penalize a well-behaved node.

Our scheme relies on feedback about which packets weresuccessfully delivered. The feedback can be received eitherthrough an extra end-to-end network layer message, or byexploiting properties of transport layers, such as TCP withSACK [41]; this feedback approach is somewhat similar thatused in IPv6 for Neighbor Unreachability Detection [43].Stronger properties are obtained when the routing protocolsends such feedback packets along a route equal to the re-versed route of the triggering packet; otherwise, a maliciousnode along one route may drop the acknowledgment for apacket transmitted along a functioning route.

A node with multiple routes to a single destination can as-sign a fraction of packets that it originates to be sent alongeach route. When a substantially smaller fraction of packetssent along any particular route are successfully delivered, thenode can begin sending a smaller fraction of its overall pack-ets to that destination along that route. However, if the frac-tion of packets chosen to be sent along a route that appearsto be misbehaving were to reach zero, a short-lived jammingattack that is now over could still prevent the future use of that route. To avoid this possible DoS attack, we choose the

fraction of packets sent along such a route to be some smallbut nonzero amount, to allow the occasional monitoring of the route. A packet sent for this purpose can be a normal datapacket, or, if all packets are secured using end-to-end encryp-tion, a padded probe packet can be used.

Because DSR often returns multiple R OUTE R EPLY pack-ets in response to a Route Discovery, the presence of multipleroutes to some destination in a nodes Route Cache is quitecommon. Tsirigos and Haas [62] also discuss the use of mul-tiple routes for increasing reliability, although they do not dis-cuss this technique with respect to secure routing protocols.

Malicious nodes can also be avoided during Route Dis-covery. Each R OUTE R EQUEST can include a list of nodes toavoid, and the MAC that forms the initial hash chain element(h 0 ) is then also computed over that list of nodes. Maliciousnodes cannot add or remove nodes from this list without be-ing detected by the target. Choosing which nodes to avoid inthis way is beyond the scope of this paper.

6.5. Thwarting malicious route request oods

An active attacker can attempt to degrade the performanceof DSR or other on-demand routing protocols by repeat-edly initiating Route Discovery. In this attack, an attackersends R OUTE REQUEST packets, which the routing proto-

col oods throughout the network. In basic Ariadne (sec-tions 6.2 and 6.3), a R OUTE REQUEST is not authenticated

until it reaches its target, thus allowing an Active-1-1 attackerto cause such network-wide oods. (An Active-0-1 can bethwarted by using a network-wide authentication key, as de-scribed in section 7.2.)

To protect Ariadne from a ood of R OUTE REQUEST

packets, we need a mechanism that enables nodes to instantlyauthenticate R OUTE REQUEST s, so nodes can lter out forgedor excessive R EQUEST packets. We introduce Route Discov-ery chains , a mechanism for authenticating Route Discover-ies, allowing each node to rate-limit Discoveries initiated byany node.

Route Discovery chains are one-way chains generated,as in TESLA (section 3), by choosing a random KN , andrepeatedly computing a one-way hash function H to giveK i = H N i [K N ]. These chains can be used in one of twoways. One approach is to release one key for each Route Dis-covery. Each R OUTE REQUEST from that Discovery wouldcarry a key from this Route Discovery chain, and duplicatescould be suppressed using this value. Because of the ood-ing nature of Route Discovery, a node that is not partitionedfrom the network will generally hear each chain element thatis used, preventing an attacker from reusing that value in thefuture. An alternative approach, similar to TESLA, is to dic-tate a schedule at which Route Discovery chain elements canbe used, and to use loosely synchronized clocks to preventeven partitioned nodes from propagating an old R OUTE RE -QUEST . The latter approach is computationally slightly moreexpensive, but it is secure against an attacker replaying anold chain element to a formerly partitioned node, causing thatnode to ignore R EQUEST s from the spoofed source for some

period of time.Route Discovery chains can also be constructed from a

chain-based one-time signature, such as the MerkleWinter-nitz construction [24,56,65]. The chain can then be usedto sign any set of immutable elds in the initial R OUTEREQUEST , and the signature distributed with the R EQUEST .In our design, the only immutable eld is the target address,since the identier is the chain element used for the currentRoute Discovery, and the time interval can also be derivedfrom that chain element. As a result, the one-time signaturescheme needs to sign very few bits, and steps in the RouteDiscovery chain can be very inexpensive. For example, ina network with 50 nodes, it sufces to represent 49 possibletargets (since the initiator is never the target). If the MerkleWinternitz construction is used with two signature chains of length 7 and a checksum chain of length 13, each R OUTEREQUEST is just 20 bytes longer, and one step in the hashchain costs just 27 hash operations. If each node is permit-ted to initiate one Route Discovery per second, the amortizedcost of using MerkleWinternitz chains in this network is just1350 hash operations per second.

6.6. Optimizations for Ariadne

Caching improvements. When Ariadne is used with broad-

cast authentication such as TESLA, additional route cachingis possible. In the basic Route Discovery mechanism de-


11/18

ARIADNE 31

scribed in section 6.2, only the initiator of the Discovery canuse the route in the R OUTE REPLY , since the target MAC eldof the R EPLY can only be veried by the initiator. However, if the appropriate data is also broadcast authenticated, any nodealong a path returned in a R EPLY can use that route to reach

the target. For example, if TESLA is used as the broadcastauthentication protocol, a target authenticator is placed thepacket in addition to the target MAC , and is computed using aTESLA key that is not expected to be disclosed until afterthe last R EPLY reaches the initiator (where is the maximumtime difference between two nodes). That TESLA key is thendisclosed, after appropriate delay, by sending it to the initiatoralong each path traversed by a R EPLY .

Reduced overhead. When Ariadne is used with symmet-ric authentication (such as TESLA or pairwise shared keys),some elds can be calculated by the receiver rather than in-cluded in the packet [24]. In particular, the MAC list in boththe R OUTE R EQUEST and R OUTE R EPLY can be eliminated,and h i can be computed using

MAC K Ai REQUEST ,S ,D , id , ti, h i 1 , (A 1 , . . . , A i ) .

The verier (initiator with delayed broadcast authentication,and target with pairwise shared keys) can then recomputeeach h i given the disclosed (or known) symmetric keys.

7. Ariadne evaluation

7.1. Simulation-based performance evaluation

To evaluate the Ariadne without attackers, we used the ns-2simulator, with our mobility extensions [8]. The ns-2 simula-tor has been used extensively in evaluating the performance of ad hoc network routing protocols. These simulations modelradio propagation using the realistic two-ray ground reec-tion model [53] and account for physical phenomena such assignal strength, propagation delay, capture effect, and inter-ference. The Medium Access Control protocol used is theIEEE 802.11 Distributed Coordination Function (DCF) [27].The parameters used for our simulation are given in table 1.

We evaluated the version of Ariadne that uses TESLA forbroadcast authentication and shared keys only between com-municating pairs of nodes. We also simulate the effect of adding the Reduced Overhead optimization in Ariadne de-scribed in section 6.6; we refer to the unoptimized versionof Ariadne as Ariadne-HiOvd and the optimized version asAriadne-LoOvd.

We modeled these versions of Ariadne by modifying ourns-2 DSR model in several ways: we increased the packetsizes to reect the additional elds necessary for authen-ticating the packets, and modied the handling of RouteDiscovery and Route Maintenance for the additional authen-tication processing dened in Ariadne; we adjusted retrans-mission timeouts for R OUTE REQUEST s to compensate for

the delay necessary for the disclosure of TESLA keys; andwe treated routes learned from Route Discovery in an atomic

Table 1Parameters for Ariadne simulations.

Scenario parameters

Number of nodes 50Maximum velocity ( vmax ) 20 m/sDimensions of space 1500 m 300 mNominal radio range 250 mSourcedestination pairs 20Source data pattern (each) 4 packets/secondApplication data payload size 512 bytes/packetTotal application data load 327 kbpsRaw physical link bandwidth 2 Mbps

DSR parameters

Initial R OUTE R EQUEST timeout 2 secondsMaximum R OUTE R EQUEST timeout 40 secondsCache size 32 routesCache replacement policy FIFO

TESLA parameters

TESLA time interval 1 secondPessimistic end-to-end propagation time ( ) 0.2 secondsMaximum time synchronization error ( ) 0.1 secondsHash length ( ) 80 bits

fashion that did not allow the use of prexes of routes in theRoute Cache. We compare Ariadne with the current versionof DSR [19], which we call simply DSR, and with an un-optimized version of DSR, which we call DSR-NoOpt. InDSR-NoOpt, we disabled all DSR protocol optimizations notpresent in Ariadne. By comparing Ariadne with this unopti-mized version of DSR, we can examine the performance im-pact of adding security, independent of the performance im-pact of the DSR optimizations removed to allow the securityfunctionality.

Each node in our simulation moves according to the ran-dom waypoint mobility model [30]. In the random waypointmodel, each node starts at a random position, waits for a du-ration called the pause time , and then independently choosesa new random location and moves there with a velocity uni-formly chosen between 0 and vmax . When it arrives, it waitsfor the pause time and repeats the process. Like much previ-ous work in evaluating ad hoc network routing protocols (e.g.,[8,19,28]), we use a rectangular space of size 1500 m 300 m

to increase the average number of hops in routes used relativeto a square space of equal area, creating a more challengingenvironment for the routing protocol in this respect. All pro-tocols were run on identical movement and communicationscenarios. We computed six metrics for each simulation run:

Packet Delivery Ratio (PDR) . The fraction of application-level data packets sent that are actually received at the re-spective destination node.

Packet Overhead . The number of transmissions of rout-ing packets; for example, a R OUTE R EPLY sent over threehops would count as three overhead packets in this metric.

Byte Overhead . The number of transmissions of overhead(non-data) bytes, counting each hop as above.


12/18


Mean Latency . The average time elapsed from when adata packet is rst sent to when it is rst received at itsdestination.

99.99th Percentile Latency . Computed as the 99.99th per-centile of the packet delivery latency.

Path Optimality . Compares the length of routes used tothe optimal (minimum possible) hop length as determinedby an off-line omniscient algorithm, based on the nominalwireless transmission range of 250 m per hop.

Figure 4(a) shows the Packet Delivery Ratio (PDR) foreach protocol. Removing the optimizations from DSR to pro-duce DSR-NoOpt reduces the PDR by an average of 12.7%;adding Ariadne-HiOvd security further reduces the PDR by just an additional 1.12% on average, and does not reducePDR by more than an additional 2.8% at any pause time. Ari-adne with reduced overhead (Ariadne-LoOvd) recovers mostof this PDR loss; it has PDR just 0.015% lower (on aver-age) than DSR-NoOpt. Ariadne with reduced overhead out-performs DSR-NoOpt at low mobility, but has lower PDR athigh mobility.

Surprisingly, Ariadne outperforms DSR-NoOpt at lowerlevels of mobility. This improved performance results fromthe average half-second delay (one half the TESLA time in-terval) that Ariadne introduces between the target receivinga ROUTE REQUEST and sending a R OUTE REPLY . Speci-cally, when a R OUTE REQUEST traverses a short-lived link,DSR-NoOpt immediately returns the R OUTE R EPLY , but thenew route can be used for only its brief lifetime, contributingadditional overhead for forwarding the R EPLY and for send-

ing and forwarding the resulting R OUTE E RROR . In Ariadne,links are in effect tested twice: once when the R OUTE RE -QUEST traverses the network, and once when the R OUTE RE -PLY is sent along the reverse path. If one of the links alongthis path breaksbetween these tests, the R EPLY with this routeis not received by the initiator. It is this additional route con-rmation that allows Ariadne to nd more stable routes thanDSR-NoOpt.

From examining the PDR achieved by the different proto-cols, we draw three conclusions. First, Ariadnes Route Dis-covery operates more slowly but also nds better routes, sincethose routes must exist for long enough to successfully returna ROUTE REPLY . Second, these better routes offset the dis-advantage that Ariadne R OUTE E RROR s cannot be processeduntil the TESLA key used is disclosed, causing additionaldata packets to continue to be sent along the broken route foron average half of the TESLA time interval after the E RROR isreceived. Finally, the increased overhead of Ariadne-HiOvdis almost fully responsible for its lower PDR relative to DSR-NoOpt.

Figure 4(b) shows the path optimality results for each pro-tocol. In DSR, the average number of hops along a route usedby a packet is 0.700 hops more than the minimum possible,based on the nominal wireless transmission range of 250 mper hop. In DSR-NoOpt, routes used are on average 0.264

hops longer than in DSR, and in both versions of Ariadne,routes used average 0.011 hops longer than in DSR-NoOpt.

DSR-NoOpt performs slightly better than Ariadne becauseit initiates more Route Discoveries and thus tends to morequickly nd shorter routes when they become available thandoes Ariadne.

Figures 4(c) and 4(d) show the the results for packet over-

head and byte overhead, respectively. Ariadne has consis-tently lower packet overhead than does DSR-NoOpt, becauseAriadne tends to nd more stable routes than DSR-NoOpt,reducing the number of Route Discoveries as well as thenumber of R OUTE ERROR s that are sent. This advantageis somewhat reduced since R OUTE ERROR processing is de-layed in Ariadne, causing more redundant E RROR s to be sentfor each broken route. Byte overhead in Ariadne-HiOvd issignicantly worse than in either DSR or DSR-NoOpt, dueto the authentication overhead in R OUTE R EQUEST , REPLY ,and E RROR packets. Surprisingly, Ariadne-LoOvd has loweroverhead than DSR-NoOpt, because the extra packets sent byDSR-NoOpt outweigh the additional authentication informa-tion in each Ariadne-LoOvd routing control packet.

Figures 4(e) and 4(f) show the results for average latencyand 99.99th percentile latency, respectively. Because of thereduced number of broken links that Ariadne uses relativeto DSR-NoOpt, Ariadne generally has better latency thandoes DSR-NoOpt. Ariadne-LoOvd shows signicantly lowermean latency than Ariadne-HiOvd, because it has lower byteoverhead and thus creates less congestion in the network. Thedifference is also present in the 99.99th percentile latency, butthere, channel contention is a smaller fraction of the overalllatency.

7.2. Security analysis

In this section, we discuss how Ariadne resists attacks by cer-tain attacker types, according to the taxonomy we presentedin section 5.1.

Intuitively, Ariadne Route Discovery is successful when atleast one of the R EPLY s returned by the target is a workingroute. Since the target of a Route Discovery returns a routefor each of its neighbors, if the rst R EQUEST from a partic-ular Discovery to reach any neighbor of the target has passedthrough no malicious nodes, that Discovery will succeed.

To more formally characterize the security offered by Ari-

adne, we dene a minimum broadcast latency path

between asource and a destination to be any path that forwards a RouteDiscovery most quickly from the source to the destination.We call a route that only consists of uncompromised nodes anuncompromised route . Ariadne prevents compromised nodesfrom disturbing uncompromised routes. In particular, Ari-adne provides two properties assuming reliable broadcast:

If there exists an uncompromisedneighbor of a destinationsuch that the minimum latency path between the initia-tor of the Discovery and that neighbor is uncompromised,then an uncompromised route from the initiator to the tar-get will be returned in a R OUTE R EPLY .

If at least one R EPLY returned as a result of the rst prop-erty represents a shortest route from the initiator to the tar-


13/18

ARIADNE 33

Figure 4. Performance results comparing Ariadne with the standard DSR protocol and with a version of DSR with all DSR optimizations not present inAriadne disabled. Results are based on simulation over 50 runs, and the error bars represent the 95% condence interval of the mean.


14/18


get, Ariadne may route packets along one such uncompro-mised route.

To argue for the correctness of the rst property, we notethat if the minimum latency path between the initiator and aneighbor of the destination is uncompromised, then the rstR EQUEST to reach that neighbor comes over an uncompro-mised route. Since it is the rst R EQUEST , it will not be l-tered by duplicate R EQUEST detection, so it will be rebroad-cast, and heard by the target. Since the target returns a R EPLYfor each R EQUEST it receives, without performing duplicatedetection, a R EPLY will be returned. The second propertytrivially follows from the use of shortest paths and the rstproperty.

Although it may not be possible to achieve reliable broad-cast securely or efciently, we assume that most broadcastpackets are received, and hence the properties listed abovegenerally hold.

We now consider Ariadne using our taxonomy of attackertypes from section 5.1. We list different attacker congura-tions in increasing strength, and discuss how Ariadne resistssome possible attacks. Ariadne resists many more attacks, butonly a representative sample are discussed here.

Since Ariadne does not attempt to provide anonymousrouting, passive attackers can eavesdrop on all routing traf-c sent by nodes within range of those attackers. They canalso perform trafc analysis on any packets sent or forwardedby nodes within range of the attackers.

When replay protection and a global MAC key are used, anActive-0- x attacker (for x 1) can at most perform worm-

hole and rushing attacks. Packet leashes can prevent theseattacks [25].An Active-1-1 attacker may attempt the following attacks:

Create a gray hole or black hole by removing nodes in aROUTE R EQUEST ; however, the per-hop hash mechanismin each R EQUEST prevents such tampering. An attackermay fabricate nodes to insert in the accumulated route listof a R EQUEST packet, such fabricated nodes would nothave known keys at the source, and the R EPLY would thusnot be authenticated. If the attacker tries to replace theMAC and keys in the reply, such tampering will be de-tected as a result of the target MAC eld in the R EPLY .

Create routing loops. Intuitively, the use of source routesprevents loops, since a packet passing through only legiti-mate nodes will not be forwarded into a loop. An attackercan create a routing loop by modifying the source routeeach time around the loop; this behavior, however, is noworse than if the attacker were to source packets with pe-riod equal to the propagation time around the loop. In par-ticular, if there are n nodes in the routing loop, and a singlepacket is forwarded around the loop m times, the attackerparticipates in m forwards, and the total expended effortis mn forwards. Had the attacker instead sourced m pack-ets along n-hop routes, the total attacker effort is m trans-

missions, and the total network effort is mn forwards, anidentical result.

Flood network with many R OUTE REQUEST s. Since thesource address of each R EQUEST is authenticated, andsince each new Route Discovery needs to carry a new one-way Route Discovery chain value, the compromised nodecan only produce R OUTE REQUEST s with its own source

address. An upper bound on the sending rate can be en-forced either by rate limiting of R EQUEST s at each node orsynchronizing Route Discovery chain elements with time(section 6.5).

Perform a rushing attack (section 5.2). Rushing attackscan be probabilistically prevented by slightly modifyingthe Route Discovery protocol [23].

Multiple attackers that have compromised one node (Act-ive-1- x , for x > 1) may attempt to construct a wormhole, butappend the address and key of the compromised node in eachREQUEST forwarded across this wormhole. Packet leashesalone cannot prevent this attack, but packet leashes and GPS

can be used in conjunction to ensure that an Active-1- x worm-hole attack can be no worse than an Active-1-1 attacker po-sitioned correctly. In particular, if each node forwarding aROUTE REQUEST includes its alleged GPS coordinates inthat R EQUEST , then a node can detect if it should be reach-able from the previous hop, and if the hop before the previoushop should be able to reach the previous hop. If both of thesechecks succeed, then the attacker could have placed the com-promised node at the position it specied in the packet, andthat node would have been able to hear the original R EQUEST ,append its address, and forward it to the next hop.

Multiple attackers that know all the keys of multiple nodes(an Active- y -x attacker conguration, where 1 < y x ) mayperform the following attacks:

Lengthen the route in the R EQUEST by adding other com-promised nodes to the route. If the source nds a shorterroute, it will likely prefer that route, so the protocol be-haves as if the attacker were not there.

Attempt to force the initiator to repeatedly initiate RouteDiscoveries. Suppose an Active- y -x attacker had the keysof multiple compromised nodes, and that one such attackerwere on the shortest path from the source to the destina-tion. When the attacker receives its rst R OUTE REQUESTpacket as part of some Discovery, it adds its address andMAC, as normal, but also adds the address of another nodeit has compromised. When data packets are sent along thatroute, the attacker replies with a R OUTE ERROR from itsrst hop to its second hop. In subsequent Route Discov-eries, the attacker can use different addresses for the addi-tional address. Since other routes may have been returnedas part of any of these Route Discoveries, this attack is notguaranteed to be successful.To prevent such starvation, the initiator may include datain the R OUTE REQUEST . To be part of the path, the at-tacker must forward routing messages, so the initiator cansend data to the target. If the attacker alters the data inthe R OUTE REQUEST , the destination will detect the al-

teration (using the shared key and a MAC on the data) andreject that route.


15/18

ARIADNE 35

A set of attackers that control a vertex cut of the net-work (an Active-VC attacker) may perform the following ad-ditional attacks:

Make nodes on one side of the vertex cut believe that anynode on the other side is attempting to ood the network.By holding and not propagating R OUTE REQUEST s froma certain node for some time, then initiating many RouteDiscoveries with the chain values from the old Discover-ies, an Active-VC attacker can make that node appear tobe ooding the network. When the use of individual ele-ments of a Route Discovery chain are time-synchronized,this attack simply causes the R EQUEST s associated withthe stale chain elements to be discarded.

Only forward R OUTE REQUEST and R OUTE REPLY pack-ets. A sender is then unable to successfully deliver pack-ets. This attack is only marginally different from not par-ticipating in the protocol at all, differing only in that the

sender and some intermediate nodes continue to spendpower to send packets, but none of those packets are suc-cessfully received.

8. Related work

Several researchers have proposed secure routing protocols.For example, Perlman [47] proposed ooding NPBR , an on-demand protocol designed for wired networks that oods eachpacket through the network. Flooding NPBR allocates a frac-tion of the bandwidth along each link to each node, and usesdigital signatures to authenticate all packets. Unfortunately,

this protocol has high overhead in terms of the computationalresources necessary for digital signature verication and interms of its bandwidth requirements. Furthermore, estimatingand guaranteeing available bandwidth in a wireless environ-ment is difcult [34].

Other wired network protocols have secured periodic rout-ing protocols with asymmetric cryptography, such as Kentet al. [33], Perlmans link-state NPBR , Kumars secure link-state protocol [37], and Smith et al. [58,59]. However, nodesin an ad hoc network may not have sufcient resources to ver-ify an asymmetricsignature; in particular, an attacker can triv-ially ood a victim with packets containing invalid signatures,but verication can be prohibitively expensive for the victim.In addition, these protocols may suffer in some scenarios be-cause periodic protocols may not be able to cope with highrates of mobility in an ad hoc network. Kumar also discussesthreats to both distance-vector protocols and link-state pro-tocols, and describes techniques for securing distance-vectorprotocols. However, these techniques are vulnerable to thecompromise of a single node.

Zhou and Haas [66], Zapata [64], and Sanzgiri et al. [57]propose the use of asymmetric cryptography to secure on-demand ad hoc network routing protocols. However, asabove, when the nodes in an ad hoc network are generally un-able to verify asymmetric signatures quickly enough, or when

network bandwidth is insufcient, these protocols may not besuitable.

Cheung [10], Hauser et al. [17], and Zhang [65] describesymmetric -key approaches to the authentication of link-stateupdates, but they do not discuss mechanisms for detectingthe status of these links. In wired networks, a common tech-nique for authenticating HELLO packets is to verify that the

the incoming network interface is the expected interface andthat the IP TTL of the packet is 255. In a wireless ad hocnetwork, this technique cannot be used. Furthermore, theseprotocols assume the use of periodic routing protocols, whichare not always suitable in ad hoc networks. Cheung [10] usescryptographic mechanisms similar to those used in Ariadnewith TESLA, but optimistically integrates routing data beforeit is authenticated, adversely affecting security.

A number of other researchers have also proposed theuse of symmetric schemes for authenticating routing con-trol packets. Heffernan [18] proposes a mechanism requiringshared keys between all communicating routers. This schememay not scale to large ad hoc networks, and may be vulnera-ble to single-node compromise. Perrig et al. [50] use symmet-ric primitives to secure routing between nodes and a trustedbase station. Basagni et al. [2] use a network-wide symmetrickey to secure routing communication, which is vulnerable to asingle node compromise, although they specify the use of se-cure hardware to limit the damage that can be done by a com-promised node. Papadimitratos and Haas [44] present work that secures against non-colluding adversaries, and they donot authenticate intermediate nodes that forward R OUTE R E -QUEST s, and thus do not handle authorization. Yi et al. [63]discuss authorization issues. Our previous work, SEAD [21],uses hash chains to authenticate routing updates sent by a

distance-vector protocol; however, that approach builds ona periodic protocol, and such protocols tend to have higheroverhead than on-demand protocols and may not be suitablein highly mobile networks. An earlier version of the Ariadneprotocol was presented in [22].

Routing protocol intrusion detection has also been studiedas a mechanism for detecting misbehaving routers [7,11,40].

9. Conclusions

This paper has presented the design and evaluation of Ari-adne, a new secure ad hoc network routing protocol. Ariadneprovides security against one compromised node and arbi-trary active attackers, and relies only on efcient symmetriccryptographic operations. Ariadne operates on-demand, dy-namically discovering routes between nodes only as needed;the design is based on the basic operation of the DSR pro-tocol. Rather than generously applying cryptography to anexisting protocol to achieve security, however, we carefullyre-designed each protocol message and its processing. Thesecurity mechanisms we designed are highly efcient andgeneral, so that they should be applicable to securing a widevariety of routing protocols.

Because we did not secure the optimizations of DSR in

Ariadne, the resulting protocol is less efcient than the highlyoptimized version of DSR that runs in a trusted environment.


16/18


However, we also compared Ariadne to a version of DSR inwhich we disabled all protocol optimizations not present inAriadne, allowing us to evaluate and analyze the effect of theoptimizations and the security separately. As explained in ourresults, however, Ariadne actually performs better on some

metrics (e.g., 41.7% lower packet overhead) than for unop-timized DSR, and about the same on all other metrics, eventhough Ariadne must bear the added costs for security notpresent in unoptimized DSR.

We found that source-routing facilitates securing ad hocnetwork routing protocols. Source routing empowers thesender to circumvent potentially malicious nodes, and enablesthe sender to authenticate every node in a R OUTE REPLY .Such ne-grained path control is absent in most distance-vector routing protocols, which makes such protocols morechallenging to fully secure.

Acknowledgements

This work was supported in part by NSF under grant CCR-0209204, by NASA under grant NAG3-2534, by the UnitedStates Postal Service under contract USPS 102592-01-Z-0236, by DARPA under contract N66001-99-2-8913, and bygifts from Schlumberger and Bosch. The views and conclu-sions contained here are those of the authors and should notbe interpreted as necessarily representing the ofcial poli-cies or endorsements, either express or implied, of NSF,NASA, USPS, DARPA, Schlumberger, Bosch, Rice Univer-sity, Carnegie Mellon University, or the U.S. Government or

any of its agencies.

References

[1] N. Abramson, The ALOHA system another alternative for computercommunications, in: Proceedings of the Fall 1970 AFIPS Computer Conference (November 1970) pp. 281285.

[2] S. Basagni, K. Herrin, E. Rosti and D. Bruschi, Secure pebblenets, in:Proceedings of the 2nd Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc 2001) (October 2001) pp. 156163.

[3] M. Bellare, R. Canetti and H. Krawczyk, Keying hash functions formessage authentication, in: Advances in Cryptology Crypto96 , Lec-ture Notes in Computer Science, Vol. 1109, ed. N. Koblitz (Springer,1996) pp. 115.

[4] B. Bellur and R.G. Ogier, A reliable, efcient topology broadcast pro-tocol for dynamic networks, in: Proceedings of the 18th Annual Joint Conference of the IEEE Computer and Communications Societies (IN-FOCOM99) (March 1999) pp. 178186.

[5] A. Benjaminson and S.C. Stallings, A microcomputer-compensatedcrystal oscillator using a dual-mode resonator, in: Proceedings of the43rd Annual Symposium on Frequency Control (May 1989) pp. 2026.

[6] V. Bharghavan, A. Demers, S. Shenker and L. Zhang, MACAW: A Me-dia Access Protocol for Wireless LANs, in: Proceedings of the SIG-COMM94 Conference on Communications Architectures, Protocolsand Applications (August 1994) pp. 212225.

[7] K.A. Bradley, S. Cheung, N. Puketza, B. Mukherjee and R.A. Ols-son, Detecting disruptive routers: a distributed network monitoring ap-proach, in: Proceedings of the IEEE Symposium on Research in Secu-rity and Privacy (May 1998) pp. 115124.

[8] J. Broch, D.A. Maltz, D.B. Johnson, Y.-C. Hu and J.G. Jetcheva, A per-formance comparison of multi-hop wireless ad hoc network routing

protocols, in: Proceedings of the 4th ACM/IEEE International Confer-ence on Mobile Computing and Networking (MobiCom98) (October1998) pp. 8597.

[9] M. Brown, D. Cheung, D. Hankerson, J.L. Hernandez, M. Kirkup andA. Menezes, PGP in constrained wireless devices, in: Proceedings of the 9th USENIX Security Symposium (August 2000) pp. 247261.

[10] S. Cheung, An efcient message authentication scheme for link staterouting, in: Proceedings of the 13th Annual Computer Security Appli-cations Conference (1997) pp. 9098.

[11] S. Cheung and K. Levitt, Protecting routing infrastructures from denialof service using cooperative intrusion detection, in: Proceedings of the1997 New Security Paradigms Workshop (September 1998) pp. 94106.

[12] T. Clark, Tom Clarks totally accurate clock FTP site, Greenbelt, MA,available at ftp://aleph.gsfc.nasa.gov/GPS/totally.accurate.clock/

[13] D. Coppersmith and M. Jakobsson, Almost optimal hash sequence tra-versal, in: Proceedings of the 4th Conference on Financial Cryptogra- phy (FC02) , Lecture Notes in Computer Science (2002) pp. 102119.

[14] T. Dierks and C. Allen, The TLS protocol, version 1.0, RFC 2246 (Jan-uary 1999).

[15] E. Gabber and A. Wool, How to prove where you are: tracking the

location of customer equipment, in: Proceedings of the 5th ACM Con- ference on Computer and Communications Security (November 1998)pp. 142149.

[16] O. Goldreich, S. Goldwasser and S. Micali, How to construct randomfunctions, Journal of the ACM 33(4) (1986) 792807.

[17] R. Hauser, A. Przygienda and G. Tsudik, Reducing the cost of secu-rity in link state routing, in: Proceedings of the Symposium on Net-work and Distributed Systems Security (NDSS97) (February 1997)pp. 9399.

[18] A. Heffernan, Protection of BGP sessions via the TCP MD5 signatureoption, RFC 2385 (August 1998).

[19] Y.-C. Hu and D.B. Johnson, Caching strategies in on-demand routingprotocols for wireless ad hoc networks, in: Proceedings of the 6th Annual IEEE/ACM International

Documents

ARIADNE Journal