Ariadne: A Secure On-Demand RoutingProtocol for Ad Hoc Networks

Yih-Chun HuCarnegie Mellon University

yihchun@cs.cmu.edu

Adrian PerrigCarnegie Mellon University

perrig@cmu.edu

David B. JohnsonRice Universitydbj@cs.rice.edu

December 16, 2002

AbstractAn ad hoc network is a group of wireless mobile computers (or nodes), in which individual nodes cooperate by

forwarding packets for each other to allow nodes to communicate beyond direct wireless transmission range. Priorresearch in ad hoc networking has generally studied the routing problem in a non-adversarial setting, assuming atrusted environment. In this paper, we present attacks against routing in ad hoc networks, and we present the designand performance evaluation of a new secure on-demand ad hoc network routing protocol, called Ariadne. Ariadneprevents attackers or compromised nodes from tampering with uncompromised routes consisting of uncompromisednodes, and also prevents many types of Denial-of-Service attacks. In addition, Ariadne is efficient, using only highlyefficient symmetric cryptographic primitives.

1. Introduction

An ad hoc network is a group of wireless mobile computers (or nodes), in which nodes cooperate by forwardingpackets for each other to allow them to communicate beyond direct wireless transmission range. Ad hoc networksrequire no centralized administration or fixed network infrastructure such as base stations or access points, and can bequickly and inexpensively set up as needed. They can be used in scenarios in which no infrastructure exists, or in whichthe existing infrastructure does not meet application requirements for reasons such as security or cost. Applicationssuch as military exercises, disaster relief, and mine site operation, for example, may benefit from ad hoc networking,but secure and reliable communication is a necessary prerequisite for such applications.

Ad hoc network routing protocols are challenging to design, and secure ones are even more so. Wired networkrouting protocols such as BGP [53] do not handle well the type of rapid node mobility and network topology changesthat occur in ad hoc networks; such protocols also have high communication overhead because they send periodicrouting messages even when the network is not changing. So far, researchers in ad hoc networking have generallystudied the routing problem in a non-adversarial network setting, assuming a trusted environment; relatively littleresearch has been done in a more realistic setting in which an adversary may attempt to disrupt the communication.

We focus here on on-demand (or reactive) routing protocols for ad hoc networks, in which a node attempts todiscover a route to some destination only when it has a packet to send to that destination. On-demand routing protocolshave been demonstrated to perform better with significantly lower overheads than periodic (or proactive) routingprotocols in many situations [8, 27, 37, 45], since the protocol is able to react quickly to the many changes that mayoccur in node connectivity, yet is able to reduce (or eliminate) routing overhead in periods or areas of the network inwhich changes are less frequent.

In this paper, we make two contributions to the area of secure routing protocols for ad hoc networks. First,we give a model for the types of attacks possible in such a system, and we describe several new attacks on ad hocnetwork routing protocols. Second, we present the design and performance evaluation of a new on-demand securead hoc network routing protocol, called Ariadne, that withstands node compromise and relies only on highly efficient

This work was supported in part by NSF under grant CCR-0209204, by NASA under grant NAG3-2534, by the United States Postal Service undercontract USPS 102592-01-Z-0236, by DARPA under contract N66001-99-2-8913, and by gifts from Schlumberger and Bosch. The views and con-clusions contained here are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, eitherexpress or implied, of NSF, NASA, USPS, DARPA, Schlumberger, Bosch, Rice University, Carnegie Mellon University, or the U.S. Governmentor any of its agencies.

"A" "A,B" "A,B,C"DCBA

id=2 id=2id=2

Figure 1: Example of DSR Route Discovery, in which initiator node A is attempting to discover a route totarget node D.

symmetric cryptography. Relative to previous work in securing ad hoc network routing protocols, Ariadne is moresecure, more efficient, or more general (e.g., Ariadne does not require trusted hardware and does not require powerfulprocessors).

Ariadne can authenticate routing messages using one of three schemes: shared secret keys between all pairs ofnodes, shared secret keys between communicating nodes combined with broadcast authentication, or digital signatures.We primarily discuss here the use of Ariadne with TESLA [47, 48], an efficient broadcast authentication scheme thatrequires loose time synchronization. Using pairwise shared keys avoids the need for synchronization, but at thecost of higher key setup overhead; broadcast authentication such as TESLA also allows some additional protocoloptimizations.

In Section 2 of this paper, we summarize the basic operation of the Dynamic Source Routing protocol (DSR) [28,29, 30], on which we base the design of our new secure routing protocol, Ariadne, and in Section 3, we review theTESLA broadcast authentication protocol that we use in Ariadne. In Section 4, we describe our assumptions aboutthe network, the nodes, and security and key setup. We present an attacker model and describe types of attacks inSection 5. In Section 6, we present the design of Ariadne, and in Section 7, we give an initial simulation-basedperformance evaluation of a basic form of Ariadne. In Section 8, we discuss related work, and in Section 9, we presentour conclusions.

2. Basic Operation of DSR

We base the design of our secure on-demand ad hoc network routing protocol, Ariadne, on the basic operation ofthe Dynamic Source Routing protocol (DSR) [28, 29, 30], since DSR operates entirely on-demand and has been wellstudied through both simulation and real testbed implementation [8, 27, 37, 38]. Unlike periodic protocols (e.g., [4,44, 51]), which exchange routing information between nodes periodically in an attempt to always maintain routesto all destinations, on-demand protocols exchange routing information only when a new route is needed to deliver apacket to some destination. On-demand approaches to routing in ad hoc networks often have lower overhead thanperiodic protocols, since they transmit routing information only in response to actual packets to be sent or in responseto topology changes affecting routes actively in use. Lower routing overhead allows more of the available bandwidthand battery power to be used towards delivery of application data. In a secure routing protocol, reduced overheadhas the added benefit of reducing the number of routing packets that need to be authenticated, thereby reducing thecomputational overhead needed for security. The operation of DSR is divided into two activities: Route Discovery andRoute Maintenance. In this section, we describe the basic form of Route Discovery and Route Maintenance in DSR.

In DSR, when a node has a packet to send to some destination and does not currently have a route to that destinationin its Route Cache, the node initiates Route Discovery to find a route; this node is known as the initiator of the RouteDiscovery, and the destination of the packet is known as the Discovery’s target, as illustrated in Figure 1. The initiator(node A) transmits a ROUTE REQUEST packet as a local broadcast, specifying the target (node D) and a uniqueidentifier from the initiator A. Each node receiving the ROUTE REQUEST, if it has recently seen this request identifierfrom the initiator or if its own address is already present in an address list in the REQUEST, discards the REQUEST.Otherwise, the appends its own node address to the address list in the REQUEST and rebroadcasts the REQUEST. Whenthe ROUTE REQUEST reaches its target node, the target sends a ROUTE REPLY back to the initiator of the REQUEST,including a copy of the accumulated list of addresses from the REQUEST. When the REPLY reaches the initiator of theREQUEST, it caches the new route in its Route Cache.

Route Maintenance is the mechanism by which a node sending a packet along a specified route to some destinationdetects if that route has broken, for example because two nodes in it have moved too far apart; an example of RouteMaintenance is shown in Figure 2. DSR is based on source routing: when sending a packet, the originator lists inthe header of the packet the complete sequence of nodes through which the packet is to be forwarded. Each node

2

D C B A

Figure 2: Example of DSR Route Maintenance, in which intermediate node C detects a broken link to D whenforwarding a packet from source node A.

along the route forwards the packet to the next hop indicated in the packet’s header, and attempts to confirm that thepacket was received by that next node; a node may confirm this by means of a link-layer acknowledgment, passiveacknowledgment [31], or network-layer acknowledgment. If, after a limited number of local retransmissions of thepacket, a node in the route is unable to make this confirmation (such as node C in Figure 2), it returns a ROUTE ERROR

to the original source of the packet (node A), identifying the link from itself to the next node (node D) as broken. Thesender then removes this broken link from its Route Cache; for subsequent packets to this destination, the sender mayuse any other route to that destination in its Cache, or it may attempt a new Route Discovery for that target if necessary.

The DSR protocol also defines a number of optimizations to these mechanisms (e.g., [19, 20, 28, 29, 30, 34]).Some of these optimizations, such as flow state [20], are relatively easy to secure (flow state requires only broadcastauthentication of control messages), whereas others, such as link-state caching [19], are more difficult (link-statecaching requires some mechanism to authenticate links, but Ariadne only attempts to authenticate nodes). The use ofthese DSR optimizations is beyond the scope of this paper; we secure here only a basic version of DSR, with a limitedpath cache and without these optimizations.

3. Overview of TESLA

In this paper, we describe Ariadne primarily using the TESLA [47, 48] broadcast authentication protocol for authen-ticating routing messages, since TESLA is efficient and adds only a single message authentication code (MAC) to amessage for broadcast authentication. Adding a MAC (computed with a shared key) to a message can provide se-cure authentication in point-to-point communication; for broadcast communication, however, multiple receivers needto know the MAC key for verification, which would also allow any receiver to forge packets and impersonate thesender. Secure broadcast authentication thus requires an asymmetric primitive, such that the sender can generate validauthentication information, but the receivers can only verify the authentication information. TESLA differs from tra-ditional asymmetric protocols such as RSA [54] in that TESLA achieves this asymmetry from clock synchronizationand delayed key disclosure, rather than from computationally expensive one-way trapdoor functions.

To use TESLA for authentication, each sender chooses a random initial key KN and generates a one-waykey chain by repeatedly computing a one-way hash function H on this starting value: KN−1 = H [KN ],KN−2 = H [KN−1], . . . . In general, Ki = H [Ki+1] = HN−i[KN ]. To compute any previous key Kj from akey Ki, j < i, a node uses the equation Kj = H i−j [Ki]. To authenticate any received value on the one-way chain,a node applies this equation to the received value to determine if the computed value matches a previous known au-thentic key on the chain. Coppersmith and Jakobsson present efficient mechanisms for storing and generating valuesof hash chains [13].

Each sender pre-determines a schedule of the time at which it publishes (or discloses) each key of its one-way keychain, in the reverse order from generation; that is, a sender publishes its keys in the order K0, K1, . . . , KN . A simplekey disclosure schedule, for example, would be to publish key Ki at time T0 + i × I , where T0 is the time at whichK0 is published, and I is the key publication interval.

TESLA relies on a receiver’s ability to determine which keys a sender may have already published, based on loosetime synchronization between nodes. Let ∆ be the maximum time synchronization error between any two nodes; thevalue ∆ must be known by all nodes. To send a packet, the sender uses a pessimistic upper bound τ on the end-to-end network delay between nodes and picks a key Ki from its one-way key chain which, at the time any receiver isexpected to receive the packet, the receiver will believe has not yet been published. For example, the sender couldchoose a key Ki that it will not publish until a time at least τ + 2∆ in the future; the value 2∆ is used here becausethe receiver’s clock may be ahead of the sender’s clock by ∆, so at time ts at the sender, it is ts + ∆ at the receiver.In sending the packet, the sender adds a message authentication code (MAC), computed using key Ki, to the packet.When the packet reaches the receiver, it will be ts + τ + ∆, and the receiver will discard the packet if the key mighthave been published already. Since the receiver knows the sender’s clock may be faster by ∆, the receiver will rejectthe packet unless it is received at least ∆ before the scheduled key release time, so the receiver must be able to verifythat the key is released at time ts + τ + 2∆ or later.

3

When a receiver receives a packet authenticated with TESLA, it first verifies the TESLA security condition thatthe key Ki used to authenticate the packet cannot yet have been published. For example, if the local packet arrivaltime is tr, and the receiver knows that the earliest time at which the sender will disclose the key Ki is T0 + i × I , thereceiver needs to verify only that tr ≤ (T0 + i× I −∆), implying that Ki has not yet been published. Otherwise, thesender may have already published Ki and an attacker may have forged the packet contents; the receiver thus discardsthe packet. However, if this check is successful, the receiver buffers the packet and waits for the sender to publish keyKi. When the receiver then receives Ki, it authenticates Ki as described above, and then authenticates stored packetsthat were authenticated with any key Kj , where j ≤ i. TESLA remains secure even if the end-to-end delay is largerthan τ , although some receivers may be required to discard the packet.

4. Assumptions

4.1. Notation

We use the following notation to describe security protocols and cryptographic operations:

• A, B are principals, such as communicating nodes.

• KAB and KBA denote the secret MAC keys shared between A and B (one key for each direction of communi-cation).

• MACKAB(M) denotes the computation of the message authentication code (MAC) of message M with the

MAC key KAB, for example using the HMAC algorithm [3].

For notational convenience we assume hash and MAC functions that take a variable number of arguments, simplyconcatenating them in computing the function.

4.2. Network Assumptions

The physical layer of a wireless network is often vulnerable to denial of service attacks such as jamming. Mechanismssuch as spread spectrum [50] have been extensively studied as 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 directlyby some node B, then B is able to receive packets transmitted directly by A. It is possible to use a network withunidirectional links if such links are detected and avoided; such detection may also otherwise be necessary, since manywireless Medium Access Control protocols require bidirectional links, as they make use of bidirectional exchange ofseveral link-layer frames between a source and destination to help avoid collisions and improve reliability [6, 26].

Medium Access Control protocols are also often vulnerable to attack. For example, in IEEE 802.11, an attacker canparalyze nodes in its neighborhood by sending Clear-To-Send (CTS) frames periodically, setting the “Duration” fieldof each frame to at least the interval between such frames. Less sophisticated Medium Access Control protocols, suchas ALOHA and Slotted ALOHA [1], are not vulnerable to such attacks but have lower efficiency, and the developmentof secure Medium Access Control protocols is an active area of research. In this paper, we disregard attacks onMedium Access Control protocols.

We assume that the network may drop, corrupt, reorder, or duplicate packets in transmission.When Ariadne is used with a broadcast authentication protocol, we naturally inherit all of that protocol’s as-

sumptions. For example, when TESLA is used, each node in the network must be able to estimate the end-to-endtransmission time to any other node in the network; TESLA permits this value to be chosen adaptively and pessimisti-cally. When this time is chosen to be too large, authentication delay increases, reducing protocol responsiveness; whenit is chosen to be too small, authentic packets may be rejected, but security is not compromised.

4.3. Node Assumptions

The resources of different ad hoc network nodes may vary greatly, from nodes with very little computational resources,to resource-rich nodes equivalent in functionality to high-performance workstations. To make our results as general aspossible, we have designed Ariadne to support nodes with few resources, such as Palm PDAs or RIM pagers.

Most previous work on secure ad hoc network routing relies on asymmetric cryptography such as digital signa-tures [63, 65]. However, computing such signatures on resource-constrained nodes is expensive, and we assume thatnodes in the ad hoc network may be so constrained. For example, Brown et al analyze the computation time of digital

4

signature algorithms on various platforms [9]; on a Palm Pilot PDA (16 MHz Motorola 68000 “Dragonball” processor)or RIM pager (10 MHz custom Intel 386 processor), a 512-bit RSA [54] signature generation takes 2.4–5.8 seconds,and signature verification takes 0.1–0.6 seconds, depending on the public exponent.

When Ariadne is used with TESLA for broadcast authentication, we assume that all nodes have loosely synchro-nized clocks, such that the difference between any two nodes’ clocks does not exceed ∆; the value of ∆ must beknown by all nodes in the network. Accurate time synchronization can be maintained, for example, with off-the-shelfhardware based on GPS [12, 60], although the time synchronization signal itself may be subject to attack [15]. Weassume that nodes compensate clock drift with periodic re-synchronization. Microcomputer-compensated crystal os-cillators [5] can provide sub-second accuracy for several months; if normal crystal oscillators are used, the value of ∆can be chosen to be as large as necessary, though a corresponding reduction in protocol responsiveness will result.

We do not assume trusted hardware such as tamperproof modules. Secure routing with trusted hardware is muchsimpler, 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 authenticity of keys stored in nodes. Ariadne relies on the followingkeys to be set up, depending on which authentication mechanism is used:

• If pairwise shared secret keys are used, we assume a mechanism to set up the necessary n(n + 1)/2 keys, if nis the number of nodes in the network.

• If TESLA is used, we assume a mechanism to set up shared secret keys between pairs of nodes that communicate,and to distribute one authentic public TESLA key for each node.

• If digital signatures are used, we assume a mechanism to distribute 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 and sets up shared secret keys with communicating nodes, suchas in Kerberos [35] or SPINS [49]; shared secret keys can be bootstrapped from a Public Key Infrastructure (PKI)using protocols such as TLS [14]; or shared secret keys can be pre-loaded at initialization, possibly through physicalcontact [59]. Menezes et al discuss several key setup protocols [41].

To set up authentic public keys, we can either embed all public keys at initialization in each node, or assume aPKI and embed the trusted Certification Authority’s public key in each node and then use that key to authenticate thepublic keys of other nodes. Another approach proposed by Hubaux et al [25] bootstraps trust relationships based onPGP-like certificates.

Ariadne also requires that each node have an authentic element from the Route Discovery chain (Section 6.5) ofevery node initiating Route Discoveries. These keys can be set up in the same way as a public key.

Key setup is an expensive operation. Setting up shared secret keys requires authenticity and confidentiality,whereas setting up public keys only requires authenticity. Furthermore, fewer public keys are generally needed, be-cause in a network with n nodes, only n public keys are needed and can potentially be broadcast, whereas n(n + 1)/2secret keys need to be set up in the case of pairwise shared secret keys. In Section 4.5, we describe a mechanism to setup these keys without relying on Ariadne, thus avoiding the circular dependency between key setup and the routingprotocol.

4.5. Establishing Authenticated Keys using a Trusted KDC

Although Ariadne does not require a trusted Key Distribution Center (KDC) node in the ad hoc network, some ad hocnetworks may contain a KDC as a mechanism for authenticated key setup between pairs of nodes as need, as mentionedin Section 4.4. A challenge to this type of key setup is the need for routing to be established before conventional KDCprotocols can be used. We describe here how this type of key setup can be done, if desired, with no established routingwithin Ariadne.

As described in Section 4.1, we assume that each node A shares secret MAC keys KAT and KTA between itselfand the trusted KDC T for use with a message authentication code (MAC) algorithm such as HMAC [3] (one keyfor each direction of communication). For use with this method of establishing authenticated keys using a trustedKDC, we further assume that each node A similarly shares secret encryption keys K ′

AT and K ′

TA between itself andthe KDC T . These shared keys KAT , K ′

AT , KTA, and K ′

TA for node A could, for example, all be derived by Aand the KDC T using a single shared a master secret key XAT = XTA (no direction information is associated withthis key) using a Pseudo-Random Function (PRF) [16]: if F is a PRF, then let KAT = FXAT

(1), K ′

AT = FXAT(2),

KTA = FXAT(3), and K ′

TA = FXAT(4).

5

We also assume here that each node can obtain an authentic TESLA key of the KDC; that the KDC has an authenticTESLA key for each other node; and if MW-Chains [23] are used to thwart ROUTE REQUEST floods as described inSection 6.3, that each node can obtain an authentic MW-Chain head for the KDC.

To bootstrap authenticated keys between pairs of nodes, the KDC node initiates a Route Discovery with a special,reserved address (not the address of any actual node) as the target of the Discovery. The Route Discovery is processedby each node as in Ariadne, except that each node receiving this special REQUEST for the first time also returns aROUTE REPLY. The KDC can then use each returned route to send authenticated keys to each node in the network.Alternatively, this special Route Discovery procedure can be repeated periodically; when a node needs a shared keywith some other node, it waits until the next such special Discovery is initiated by the KDC node, and at that timeincludes as part of its ROUTE REPLY to the KDC the list of nodes for which it needs authenticated keys.

5. Ad Hoc Network Routing Security

In this section, we define a taxonomy of types of attackers and discuss specific attacks against ad hoc network routing.This approach allows us to categorize the security of an ad hoc network routing protocol based on the strongest attackerit withstands.

5.1. Attacker Model

We consider two main attacker classes, passive and active. The passive attacker does not send messages; it onlyeavesdrops on the network. Passive attackers are mainly threats against the privacy or anonymity of communication,rather than against the functioning of the network or its routing protocol, and thus we do not discuss them further here.

An active attacker injects packets into the network and generally also eavesdrops. We characterize the attackerbased on the number of nodes it owns in the network, and based on the number of those that are good nodes it hascompromised. We assume that the attacker owns all the cryptographic key information of compromised nodes anddistributes it among all its nodes. We denote such an attacker Active-n-m, where n is the number of nodes it hascompromised and m is the number of nodes it owns. We propose the following attacker hierarchy (with increasingstrength) to measure routing protocol security: Active-0-1 (the attacker owns one node), Active-0-x (the attacker ownsx nodes), Active-1-x (the attacker owns one compromised node and distributes the cryptographic keys to its x − 1other nodes), and Active-y-x. In addition, we call an attacker that has compromised nodes an Active-VC attacker ifit owns all nodes on a vertex cut through the network that partitions the good nodes into multiple sets, forcing goodnodes in different partitions to communicate only through an attacker node. This attacker is particularly powerful, asit controls all traffic between nodes of the disjoint partitions.

Our protocol does not require a trusted Key Distribution Center (KDC) in the network, but some ad hoc networksmay use one for key setup, as mentioned in Section 4.4. We do not consider the case in which an attacker compromisesthe KDC, since the KDC is a central trust entity, and a compromised KDC compromises the entire network.

5.2. General Attacks on Ad Hoc Network Routing Protocols

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

An example of a routing disruption attack is for an attacker to send forged routing packets to create a routingloop, causing packets to traverse nodes in a cycle without reaching their destinations, consuming energy and availablebandwidth. An attacker may similarly create a routing black hole, in which all packets are dropped: by sending forgedrouting packets, the attacker could cause all packets for some destination to be routed to itself and could then discardthem, or the attacker could cause the route at all nodes in an area of the network to point “into” that area when in factthe destination is outside the area. As a special case of a black hole, an attacker could create a gray hole, in whichit selectively drops some packets but not others, for example, forwarding routing packets but not data packets. Anattacker may also attempt to cause a node to use detours (suboptimal routes) or may attempt to partition the networkby injecting forged routing packets to prevent one set of nodes from reaching another. An attacker may attempt tomake a route through itself appear longer by adding virtual nodes to the route; we call this attack gratuitous detour, as

6

a shorter route exists and would otherwise have been used. In ad hoc network routing protocols that attempt to keeptrack of perceived malicious nodes in a “blacklist” at each node, such as is done in watchdog and pathrater [39], anattacker may blackmail a good node, causing other good nodes to add that node to their blacklists, thus avoiding thatnode in routes.

A more subtle type of routing disruption attack is the creation of a wormhole in the network [24], using a pair ofattacker nodes A and B linked via a private network connection. Every packet (or selected packets) that A receivesfrom the ad hoc network, A forwards through the wormhole to B, to then be rebroadcast by B; similarly, B may sendall ad hoc network packets to A. Such an attack potentially disrupts routing by short circuiting the normal flow ofrouting packets, and the attackers may also create a virtual vertex cut that they control.

The rushing attack is a malicious attack that is targeted against on-demand routing protocols that find routesthrough a Route Discovery protocol and use duplicate suppression of the ROUTE REQUEST messages in that protocolat each node [22]. An attacker disseminates ROUTE REQUESTs quickly throughout the network, suppressing any laterlegitimate ROUTE REQUESTs when nodes drop them due to the duplicate suppression.

An example of a resource consumption attack is for an attacker to inject extra data packets into the network,which will consume bandwidth resources when forwarded, especially over detours or routing loops. Similarly, anattacker can inject extra control packets into the network, which may consume even more bandwidth or computationalresources as other nodes process and forward such packets. With either of these attacks, an Active-VC attacker cantry to extract maximum resources from the nodes on both sides of the vertex cut; for example, it might forward onlyrouting packets and not data packets, such that the nodes waste energy forwarding packets to the vertex cut, only tohave them dropped.

If a routing protocol can prevent an attacker from inserting routing loops, and if a maximum route length canbe enforced, then an attacker that can inject extra data packets has limited attack power. In particular, if routes arelimited to ν hops, then each data packet transmitted by the attacker causes only at most a fixed number of additionaltransmissions; more generally, if at most one control packet can be sent in response to each data packet (e.g., a ROUTE

ERROR), and that control packet is limited to ν hops, then an individual data packet can cause only 2ν individualtransmissions. We consider an attack a DoS attack only if the ratio between the total work performed by nodes in thenetwork and the work performed by the attacker is on the order of the number of nodes in the network. An exampleof a DoS attack is for the attacker to send a single packet that results in a packet flood throughout the network.

6. Ariadne

6.1. Design Goals

We aim for resilience against Active-1-x and Active-y-x attackers. Ideally, the probability that the routing protocoldelivers messages degrades gracefully when nodes fail or are compromised. Our goal is to design simple and efficientmechanisms achieving high attack robustness. These mechanisms should be sufficiently general to allow applicationto a wide range of routing protocols.

Defending against an Active-0-x attacker is relatively easy. A network-wide shared secret key limits the attackerto replaying messages. Thus the main attacks remaining are the wormhole and rushing attacks (Section 5.2). Packetleashes [24] can prevent both attacks because they prevent an Active-0-x attacker from retransmitting packets. Theseapproaches also trivially secure a network routing protocol that uses tamperproof hardware, since the strongest attackerin such an environment is an Active-0-x attacker, assuming all routing and security functionality (including packetleashes) is implemented in the secure hardware.

Most routing disruption attacks we present in Section 5.2 are caused by malicious injection or altering of routingdata. To prevent these attacks, each node that interprets routing information must verify the origin and integrity of thatdata; that is, it must authenticate the data. Ideally, the initiator of the Route Discovery can verify the origin of eachindividual data field in the ROUTE REPLY.

We need an authentication mechanism with low computation and communication overhead. An inefficient au-thentication mechanism could be exploited by an attacker to perform a Denial-of-Service (DoS) attack by floodingnodes with malicious messages, overwhelming them with the cost of verifying authentication. Thus, for point-to-pointauthentication of a message, we use a message authentication code (MAC) (e.g., HMAC [3]) and a shared key be-tween the two parties. However, setting up the shared keys between the initiator and all the nodes on the path to thetarget may be expensive. We thus also propose using the TESLA broadcast authentication protocol (Section 3) forauthentication of nodes on the routing path. However, we also discuss MAC authentication with pairwise shared keys,

7

for networks capable of inexpensive key setup, and we discuss digital signatures for authentication, for networks withextremely powerful nodes.

As a general design principle, a node trusts only itself for acquiring information about which nodes in the networkare malicious. This approach helps avoid blackmail attacks, where an attacker constructs information to make a legiti-mate node appear malicious. In our design, we assume that a sender trusts the destination with which it communicates,for authenticating nodes on the path between them. This assumption is straightforward, as the destination node cancontrol all communication with the sender anyway. However, the destination node can potentially blackmail nodes onthe path to the sender. The sender thus needs to keep a separate blacklist for each destination.

In general, ad hoc network routing protocols do not need secrecy or confidentiality. These properties are requiredto achieve 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 injecting data packets. As we described in Section 5.2, injectinga packet results in a DoS attack only if it floods the network. Since data packets cannot flood the network, we do notexplicitly protect against packet injection. However, malicious ROUTE REQUEST messages that flood the network doclassify as a DoS attack, and we thus prevent this attack with a separate mechanism that we describe in Section 6.5.

6.2. Basic Ariadne Route Discovery

In this section, we describe the basic operation of Route Discovery in Ariadne. We first overview the features of theprotocol in three stages: we present a mechanism that enables the target of a Route Discovery to verify the authenticityof the ROUTE REQUEST; we then present three alternative mechanisms for authenticating data in ROUTE REQUESTsand ROUTE REPLYs; and we present an efficient per-hop hashing technique to verify that no node is missing from thenode list in the REQUEST. After this overview, we present in detail the operation of Route Discovery in Araidne whenTESLA is used as the authentication mechanism. In the following discussion, we assume that some initiator node Sperforms a Route Discovery for a target node D, and that they share the secret keys KSD and KDS , respectively, formessage authentication in each direction.

Target Authenticates ROUTE REQUESTs. To convince the target of the legitimacy of each field in a ROUTE

REQUEST, the initiator simply includes in the REQUEST a MAC computed with key KSD over unique data, forexample a timestamp. The target can easily verify the authenticity and freshness of the ROUTE REQUEST using theshared key KSD.

Three Techniques for Route Data Authentication. In a Route Discovery, the initiator wants to authenticate eachindividual node in the node list of the ROUTE REPLY. A secondary requirement is that the target can authenticate eachnode in the node list of the ROUTE REQUEST, so that it will return a ROUTE REPLY only along paths that containonly legitimate nodes. In this section, we present three alternative techniques to achieve node list authentication: theTESLA protocol, digital signatures, and standard MACs.

When Ariadne Route Discovery is used with TESLA, each hop authenticates the new information in the REQUEST.The target buffers and does not send the REPLY until intermediate nodes can release the corresponding TESLA keys.The TESLA security condition is verified at the target, and the target includes a MAC in the REPLY to certify thatthe security condition was met. TESLA requires each packet sender to choose a a pessimistic upper bound τ onthe end-to-end network delay between nodes for sending this packet, in order to select the TESLA key it will use toauthenticate it. Choices of τ do not affect the security of the protocol, although values that are too small may causethe Route Discovery to fail. Ariadne can choose τ adaptively, by increasing τ when a Discovery fails. In addition, thetarget of the Discovery could provide feedback in the ROUTE REPLY when τ was chosen too large.

If Ariadne Route Discovery is used with digital signatures, instead, the authentication differs in that no RouteDiscovery chain element is required (Section 6.5). In addition, the MAC list in the ROUTE REQUEST (describedbelow) becomes a signature list, where the data used to compute the MAC is instead used to compute a signature.Rather than computing the target MAC using a Message Authentication Code, a signature is used. Finally, no key list(also described below) is required in the REPLY.

Ariadne Route Discovery using MACs is the most efficient of the three alternative authentication mechanisms, butit requires pairwise shared keys between all nodes. When Ariadne is used in this way, the MAC list in the ROUTE

REQUEST is computed using a key shared between the target and the current node, rather than using the TESLA keyof the current node. The MACs are verified at the target and are not returned in the ROUTE REPLY. As a result, thetarget MAC is not computed over the MAC list in the REQUEST. In addition, no key list is required in the REPLY.

8

Per-Hop Hashing. Authentication of data in routing messages is not sufficient, as an attacker could remove a nodefrom the node list in a ROUTE REQUEST. We use one-way hash functions to verify that no hop was omitted, andwe call this approach per-hop hashing. To change or remove a previous hop, an attacker must either hear a ROUTE

REQUEST without that node listed, or it must be able to invert the one-way hash function.

Ariadne Route Discovery with TESLA. We now describe in detail the version of Ariadne Route Discovery usingTESLA broadcast authentication. We assume that every end-to-end communicating source-destination pair of nodes Aand B share the MAC keys KAB and KBA. We also assume that every node has a TESLA one-way key chain, andthat all nodes know an authentic key of the TESLA one-way key chain of each other node (for authentication ofsubsequent keys, as described in Section 3). Route Discovery has two stages: the initiator floods the network with aROUTE REQUEST, and the target returns a ROUTE REPLY. To secure the ROUTE REQUEST packet, Ariadne providesthe following properties: (1) the target node can authenticate the initiator (using a MAC with a key shared between theinitiator and the target); (2) the initiator can authenticate each entry of the path in the ROUTE REPLY (each intermediatenode appends a MAC with its TESLA key); and (3) no intermediate node can remove a previous node in the node listin the REQUEST or REPLY (a one-way function prevents a compromised node from removing a node from the nodelist).

A ROUTE REQUEST packet in Ariadne contains eight fields: 〈ROUTE REQUEST, initiator, target, id, time interval,hash chain, node list, MAC list〉. The initiator and target are set to the address of the initiator and target nodes,respectively. As in DSR, the initiator sets the id to an identifier that it has not recently used in initiating a RouteDiscovery. The time interval is the TESLA time interval at the pessimistic expected arrival time of the REQUEST atthe target, accounting for clock skew; specifically, given τ , a pessimistic transit time, the time interval could be set toany time interval for which the key is not released within the next τ + 2∆ time. The initiator of the REQUEST theninitializes the hash chain to MACKSD

(initiator, target, id, time interval) and the node list and MAC list to empty lists.When any node A receives a ROUTE REQUEST for which it is not the target, the node checks its local table of

〈initiator, id〉 values from recent REQUESTs it has received, to determine if it has already seen a REQUEST fromthis same Route Discovery. If it has, the node discards the packet, as in DSR. The node also checks whether thetime interval in the REQUEST is valid: that time interval must not be too far in the future, and the key corresponding toit must not have been disclosed yet. If the time interval is not valid, the node discards the packet. Otherwise, the nodemodifies the REQUEST by appending its own address, A, to the node list in the REQUEST, replacing the hash chainfield with H [A, hash chain], and appending a MAC of the entire REQUEST to the MAC list. The node uses the TESLAkey KAi

to compute the MAC, where i is the index for the time interval specified in the REQUEST. Finally, the noderebroadcasts the modified REQUEST, as in DSR.

When the target node receives the ROUTE REQUEST, it checks the validity of the REQUEST by determining thatthe keys from the time interval specified have not been disclosed yet, and that the hash chain field is equal to

H [ηn, H [ηn−1, H [ . . . , H [η1, MACKSD(initiator, target, id, time interval) ] . . . ] ] ]

where ηi is the node address at position i of the node list in the REQUEST, and where n is the number of nodes inthe node list. If the target node determines that the REQUEST is valid, it returns a ROUTE REPLY to the initiator,containing eight fields: 〈ROUTE REPLY, target, initiator, time interval, node list, MAC list, target MAC, key list〉. Thetarget, initiator, time interval, node list, and MAC list fields are set to the corresponding values from the ROUTE

REQUEST, the target MAC is set to a MAC computed on the preceding fields in the REPLY with the key KDS , and thekey list is initialized to the empty list. The ROUTE REPLY is then returned to the initiator of the REQUEST along thesource route obtained by reversing the sequence of hops in the node list of the REQUEST.

A node forwarding a ROUTE REPLY waits until it is able to disclose its key from the time interval specified; itthen appends its key from that time interval to the key list field in the REPLY and forwards the packet according tothe source route indicated in the packet. Waiting delays the return of the ROUTE REPLY but does not consume extracomputational power.

When the initiator receives a ROUTE REPLY, it verifies that each key in the key list is valid, that the target MAC isvalid, and that each MAC in the MAC list is valid. If all of these tests succeed, the node accepts the ROUTE REPLY;otherwise, it discards it. Figure 3 shows an example of Route Discovery in Ariadne.

6.3. Basic Ariadne Route Maintenance

Route Maintenance in Ariadne is based on DSR as described in Section 2. A node forwarding a packet to the next hopalong the source route returns a ROUTE ERROR to the original sender of the packet if it is unable to deliver the packet

9

S : h0 = MACKSD(REQUEST, S,D, id, ti)

S → ∗ : 〈REQUEST, S,D, id, ti, h0, (), ()〉

A : h1 = H [A,h0]MA = MACKAti

(REQUEST, S,D, id, ti, h1, (A), ())

A → ∗ : 〈REQUEST, S,D, id, ti, h1, (A), (MA)〉

B : h2 = H [B, h1]MB = MACKBti

(REQUEST, S,D, id, ti, h2, (A, B), (MA))

B → ∗ : 〈REQUEST, S,D, id, ti, h2, (A, B), (MA, MB)〉

C : h3 = H [C,h2]MC = MACKCti

(REQUEST, S,D, id, ti, h3, (A, B, C), (MA,MB))

C → ∗ : 〈REQUEST, S,D, id, ti, h3, (A, B, C), (MA, MB , MC)〉

D : MD = MACKDS(REPLY, D, S, ti, (A, B,C), (MA,MB , MC))

D → C : 〈REPLY,D, S, ti, (A, B, C), (MA,MB ,MC),MD , ()〉

C → B : 〈REPLY,D, S, ti, (A, B, C), (MA,MB ,MC),MD , (KCti)〉

B → A : 〈REPLY,D, S, ti, (A, B, C), (MA,MB ,MC),MD , (KCti,KBti

)〉

A → S : 〈REPLY,D, S, ti, (A, B, C), (MA,MB ,MC),MD , (KCti,KBti

,KAti)〉

Figure 3: Route Discovery example in Ariadne. The initiator node S is attempting to discover a route to the targetnode D. The bold underlined font indicates changed message fields, relative to the previous message of that type.

to the next hop after a limited number of retransmission attempts. In this section, we discuss mechanisms for securingROUTE ERRORs, but we do not consider the case of attackers not sending ERRORs (Section 6.4).

To prevent unauthorized nodes from sending ERRORs, we require that an ERROR be authenticated by the sender.Each node on the return path to the source forwards the ERROR. If the authentication is delayed, for example whenTESLA is used, each node that will be able to authenticate the ERROR buffers it until it can be authenticated.

When using broadcast authentication, such as TESLA, a ROUTE ERROR packet in Ariadne contains sixfields: 〈ROUTE ERROR, sending address, receiving address, time interval, error MAC, recent TESLA key〉. Thesending address is set to the address of the intermediate node encountering the error, and the receiving address is setto the intended next hop destination of the packet it was attempting to forward. For example, if node B is attemptingto forward a packet to the next hop node C, if B is unable to deliver the packet to C, node B sends a ROUTE ERROR

to the original sender of the packet; the the sending address in this example is set to B, and the receiving addressis set to C. The time interval in the ROUTE ERROR is set to the TESLA time interval at the pessimistic expectedarrival time of the ERROR at the destination, and the error MAC field is set to the MAC of the preceding fields of theROUTE ERROR, computed using the sender of the ROUTE ERROR’s TESLA key for the time interval specified in theERROR. The recent TESLA key field in the ROUTE ERROR is set to the most recent TESLA key that can be disclosedfor the sender of the ERROR. We use TESLA for authenticating ROUTE ERRORs so that forwarding nodes can alsoauthenticate and process the ROUTE ERROR.

When sending a ROUTE ERROR, the destination of the packet is set to the source address of the original packettriggering the ERROR, and the ROUTE ERROR is forwarded toward this node in the same way as a normal data packet;the source route used in sending the ROUTE ERROR packet is obtained by reversing the source route from the headerof the packet triggering the ERROR. Each node that is either the destination of the ERROR or forwards the ERROR

searches its Route Cache for all routes it has stored that use the 〈sending address, receiving address〉 link indicatedby the ERROR. If the node has no such routes in its Cache, it does not process the ROUTE ERROR further (other thanforwarding the packet, if it is not the destination of the ERROR). Otherwise, the node checks whether the time intervalin the ERROR is valid: that time interval must not be too far into the future, and the key corresponding to it mustnot have been disclosed yet; if the time interval is not valid, the node similarly does not process the ROUTE ERROR

further.If all of the tests above for the ROUTE ERROR succeed, the node checks the authentication on the ERROR, based on

the sending node’s TESLA key for the time interval indicated in the ERROR. To do so, the node saves the informationfrom the ERROR in memory until it receives a disclosed TESLA key from the sender that allows this. During thistime, the node continues to use the routes in its Route Cache without modification from this ERROR. If the senderstops using that route, there will be no need to complete the authentication of the ERROR. Otherwise, each subsequentpacket sent along this route by this node will trigger an additional ROUTE ERROR, and once the TESLA time interval

10

used in the first ERROR ends, the recent TESLA key field in the next ERROR returned will allow authentication of thisfirst ERROR; alternatively, the node could also explicitly request the needed TESLA key from the sender once theinterval ends. Once the ROUTE ERROR has been authenticated, the node removes from its Route Cache all routesusing the indicated link, and also discards any saved information for other ERRORs for which, as a result of removingthese routes, it then has no corresponding routes in its Route Cache.

To handle the possible memory consumption attack of needing to save information from many pending ROUTE

ERRORs, the following technique is quite effective: each node keeps in memory a table containing the informationfrom each ROUTE ERROR awaiting authentication. We manage this table such that the probability that the informationfrom an ERROR is in the table is independent of the time that this node received that ROUTE ERROR.

When the wireless link capacity is finite, an attacker can inject only a finite number of ROUTE ERRORs within aTESLA time interval plus 2∆+τ . As a result, the probability of success for our defense against memory consumptionattacks for received ROUTE ERRORs in any time interval is given by ps = 1 − (y/(x + y))N , where N is the numberof ROUTE ERRORs that can be held in the node’s table, x is the number of authentic ROUTE ERRORs received, and yis the number of ERRORs sent by the attacker. The maintenance of a link therefore follows a geometric distribution,and the expected number of time intervals before success is (1− (y/(x + y))N )−1. For example, in a network using a1-second TESLA time interval and an 11 Mbps wireless link, if the size of a ROUTE ERROR packet is 60 bytes, then anode with a 5000-element table receiving just one authentic ROUTE ERROR per second can successfully authenticateand process one of the authentic ROUTE ERRORs within 5.1 seconds on the average, even when an attacker is otherwiseflooding the node with malicious ROUTE ERRORs. This 5.1 second recovery time represents a worst-case scenario,and minimal node resources are consumed while the node waits to validate one of these ROUTE REQUESTs.

When digital signatures or pairwise shared keys are used, this memory consumption attack is not possible, andthe authentication is more straightforward. A ROUTE ERROR need not include a time interval or recent TESLA key.Furthermore, the error MAC is changed to a digital signature when digital signatures are used. When pairwise sharedkeys are used, the error MAC is computed based on the key shared between the original sender of the packet and thesender of the ROUTE ERROR, rather than on the TESLA key of the sender of the ERROR.

6.4. Thwarting Effects of Routing Misbehavior

The protocol described so far is vulnerable to an Active-1-1 attacker that happens to be along the discovered route. Inparticular, we have not presented a means of determining whether intermediate nodes are in fact forwarding packetsthat they have been requested to forward. Watchdog and pathrater [39] 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 specific nodes for routing misbehavior (such as is done inwatchdog and pathrater) is subject to a blackmail attack (Section 5.1), where a sufficient number of attackers may beable to penalize a well-behaved node.

Our scheme relies on feedback about which packets were successfully delivered. The feedback can be receivedeither through an extra end-to-end network layer message, or by exploiting properties of transport layers, such asTCP with SACK [40]; this feedback approach is somewhat similar that used in IPv6 for Neighbor UnreachabilityDetection [42]. Stronger properties are obtained when the routing protocol sends such feedback packets along aroute equal to the reversed route of the triggering packet; otherwise, a malicious node along one route may drop theacknowledgment for a packet transmitted along a functioning route.

A node with multiple routes to a single destination can assign a fraction of packets that it originates to be sent alongeach route. When a substantially smaller fraction of packets sent along any particular route are successfully delivered,the node can begin sending a smaller fraction of its overall packets to that destination along that route. However, ifthe fraction of packets chosen to be sent along a route that appears to be misbehaving were to reach zero, a short-livedjamming attack that is now over could still prevent the future use of that route. To avoid this possible DoS attack, wechoose the fraction of packets sent along such a route to be some small but nonzero amount, to allow the occasionalmonitoring of the route. A packet sent for this purpose can be a normal data packet, or, if all packets are secured usingend-to-end encryption, a padded “probe” packet can be used.

Because DSR often returns multiple ROUTE REPLY packets in response to a Route Discovery, the presence ofmultiple routes to some destination in a node’s Route Cache is quite common. Tsirigos and Haas [61] also discussthe use of multiple routes for increasing reliability, although they do not discuss this technique with respect to securerouting protocols.

Malicious nodes can also be avoided during Route Discovery. Each ROUTE REQUEST can include a list of nodesto avoid, and the MAC that forms the initial hash chain element (h0) is then also computed over that list of nodes.

11

Malicious nodes cannot add or remove nodes from this list without being detected by the target. Choosing whichnodes to avoid in this way is beyond the scope of this paper.

6.5. Thwarting Malicious Route Request Floods

An active attacker can attempt to degrade the performance of DSR or other on-demand routing protocols by repeatedlyinitiating Route Discovery. In this attack, an attacker sends ROUTE REQUEST packets, which the routing protocolfloods throughout the network. In basic Ariadne (Sections 6.2 and 6.3), a ROUTE REQUEST is not authenticated untilit reaches its target, thus allowing an Active-1-1 attacker to cause such network-wide floods. (An Active-0-1 can bethwarted by using a network-wide authentication key, as described in Section 7.2.)

To protect Ariadne from a flood of ROUTE REQUEST packets, we need a mechanism that enables nodes to instantlyauthenticate ROUTE REQUESTs, so nodes can filter out forged or excessive REQUEST packets. We introduce RouteDiscovery chains, a mechanism for authenticating Route Discoveries, allowing each node to rate-limit Discoveriesinitiated by any 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 give Ki = HN−i[KN ]. These chains can be used in one of twoways. One approach is to release one key for each Route Discovery. Each ROUTE REQUEST from that Discoverywould carry a key from this Route Discovery chain, and duplicates could be suppressed using this value. Becauseof the flooding nature of Route Discovery, a node that is not partitioned from the network will generally hear eachchain element that is used, preventing an attacker from reusing that value in the future. An alternative approach,similar to TESLA, is to dictate a schedule at which Route Discovery chain elements can be used, and to use looselysynchronized clocks to prevent even partitioned nodes from propagating an old ROUTE REQUEST. The latter approachis computationally slightly more expensive, but it is secure against an attacker replaying an old chain element to aformerly partitioned node, causing that node to ignore REQUESTs 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 Merkle-Winternitz construction [23, 55, 64]. The chain can then be used to sign any set of immutable fields in the initialROUTE REQUEST, and the signature distributed with the REQUEST. In our design, the only immutable field is thetarget address, since the identifier is the chain element used for the current Route Discovery, and the time interval canalso be derived from that chain element. As a result, the one-time signature scheme needs to sign very few bits, andsteps in the Route Discovery chain can be very inexpensive. For example, in a network with 50 nodes, it suffices torepresent 49 possible targets (since the initiator is never the target). If the Merkle-Winternitz construction is used withtwo signature chains of length 7 and a checksum chain of length 13, each REQUEST is just 20 bytes longer, and onestep in the hash chain costs just 27 hash operations. If each node is permitted to initiate one Route Discovery persecond, the amortized cost of using Merkle-Winternitz chains in this network is just 1350 hash operations per second.

6.6. Optimizations for Ariadne

Caching Improvements. When Ariadne is used with broadcast authentication such as TESLA, additional routecaching is possible. In the basic Route Discovery mechanism described in Section 6.2, only the initiator of theDiscovery can use the route in the REPLY, since the target MAC field of the REPLY can only be verified by theinitiator. However, if the appropriate data is also broadcast authenticated, any node along a path returned in a REPLY

can use that route to reach the target. For example, if TESLA is used as the broadcast authentication protocol, a targetauthenticator is placed the packet in addition to the target MAC, and is computed using a TESLA key that is notexpected to be disclosed until ∆ after the last REPLY reaches the initiator (where ∆ is the maximum time differencebetween two nodes). That TESLA key is then disclosed, after appropriate delay, by sending it to the initiator alongeach path traversed by a REPLY.

Reduced Overhead. When Ariadne is used with symmetric authentication (such as TESLA or pairwise sharedkeys), some fields can be calculated by the receiver rather than included in the packet [23]. In particular, the MAC listin both the REQUEST and REPLY can be eliminated, and hi can be computed using

MACKAi(REQUEST, S, D, id, ti, hi−1, (A1, . . . , Ai)) .

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

12

Table 1: Parameters for Ariadne Simulations

Scenario ParametersNumber of Nodes 50Maximum Velocity (vmax) 20 m/sDimensions of Space 1500 m × 300 mNominal Radio Range 250 mSource-Destination 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 ParametersInitial ROUTE REQUEST Timeout 2 secondsMaximum ROUTE REQUEST Timeout 40 secondsCache Size 32 routesCache Replacement Policy FIFO

TESLA ParametersTESLA Time Interval 1 secondPessimistic End-to-End Propagation Time (τ ) 0.2 secondsMaximum Time Synchronization Error (∆) 0.1 secondsHash Length (ρ) 80 bits

7. Ariadne Evaluation

7.1. Simulation-Based Performance Evaluation

To evaluate the Ariadne without attackers, we used the ns-2 simulator, with our mobility extensions [8]. The ns-2 sim-ulator has been used extensively in evaluating the performance of ad hoc network routing protocols. These simulationsmodel radio propagation using the realistic two-ray ground reflection model [52] and account for physical phenomenasuch as signal strength, propagation delay, capture effect, and interference. The Medium Access Control protocol usedis the IEEE 802.11 Distributed Coordination Function (DCF) [26]. The parameters used for our simulation are givenin Table 1.

We evaluated the version of Ariadne that uses TESLA for broadcast authentication and shared keys only be-tween communicating nodes. We also simulate the effect of adding the Reduced Overhead optimization described inSection 6.6; we refer to the unoptimized version as “Ariadne-HiOvd” and the optimized version as “Ariadne-LoOvd.”

We modeled these versions of Ariadne by modifying our ns-2 DSR model in several ways: we increased the packetsizes to reflect the additional fields necessary for authenticating the packets, and modified the handling of Route Dis-covery and Maintenance for the additional authentication processing defined in Ariadne; we adjusted retransmissiontimeouts for ROUTE REQUESTs to compensate for the delay necessary for the disclosure of TESLA keys; and wetreated routes learned from Route Discovery in an atomic fashion that did not allow the use of prefixes of routes inthe Route Cache. We compare this version of Ariadne versus the current version of DSR [19], which we call simply“DSR,” and with an unoptimized version of DSR, which we call “DSR-NoOpt.” In DSR-NoOpt, we disabled allprotocol optimizations not present in Ariadne. By comparing Ariadne with this unoptimized version of DSR, we canexamine the performance impact of adding security, independent of the performance impact of the DSR optimizationsremoved to allow the security changes.

Each node in our simulation moves according to the random waypoint model [29]: a node starts at a randomposition, waits for a duration called the pause time, and then chooses a new random location and moves there with avelocity uniformly chosen between 0 and vmax. When it arrives, it waits for the pause time and repeats the process.Like much previous work in evaluating ad hoc network routing protocols (e.g., [8, 19, 27]), we use a rectangular spaceof size 1500 m× 300 m to increase the average number of hops in routes used relative to a square space of equal area,creating a more challenging environment for the routing protocol in this respect. All protocols were run on identicalmovement and communication scenarios. We computed six metrics for each simulation run:

13

0 100 200 300 400 500 600 700 800 9000.5

0.6

0.7

0.8

0.9

1

1.1

Pause Time

DSR−NoOptPSfrag replacements

DSR

DSR-NoOptAriadne-LoOvdAriadne-HiOvd

Pac

ketD

eliv

ery

Rat

io

(a) Packet Delivery Ratio

0 1 2 3 40

0.1

0.2

0.3

0.4

0.5

0.6

0.7

Number of Hops More Than Optimal

DSR−NoOpt

PSfrag replacements

DSR

DSR-NoOpt

Ariadne-LoOvdAriadne-HiOvd

Frac

tion

ofD

eliv

ered

Pac

kets

≥5

(b) Path Optimality

0 100 200 300 400 500 600 700 800 9000

20

40

60

80

100

120

140

160

180

Pause Time

DSR−NoOpt

PSfrag replacements

DSR

DSR-NoOpt

Ariadne-LoOvdAriadne-HiOvd

Pac

ketO

verh

ead

(Pac

kets×

10

3)

(c) Packet Overhead

0 100 200 300 400 500 600 700 800 9000

5

10

15

20

25

Pause Time

DSR−NoOpt

PSfrag replacements

DSR

DSR-NoOpt

Ariadne-LoOvdAriadne-HiOvd

Byt

eO

verh

ead

(Byt

es×

10

6)

(d) Byte Overhead

0 100 200 300 400 500 600 700 800 9000

100

200

300

400

500

600

700

800

900

1000

1100

Pause Time

DSR−NoOpt

PSfrag replacements

Ariadne-LoOvdAriadne-HiOvd

Late

ncy

(ms)

DSR

DSR-NoOpt

(e) Average Latency

0 100 200 300 400 500 600 700 800 9000

10

20

30

40

50

60

Pause Time

DSR−NoOpt

PSfrag replacements

Late

ncy

(s)

DSR

DSR-NoOpt

Ariadne-LoOvdAriadne-HiOvd

(f) 99.99th Percentile Latency

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

14

• Packet Delivery Ratio (PDR): The fraction of application-level data packets sent that are actually received at therespective destination node.

• Packet Overhead: The number of transmissions of routing packets; for example, a ROUTE REPLY sent overthree hops would count as three packets in this metric.

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

• Mean Latency: The average time elapsed from when a data packet is first sent to when it is first received at itsdestination.

• 99.99th Percentile Latency: Computed as the 99.99th percentile of the packet delivery latency.

• Path Optimality: Compares the length of routes used to the optimal (minimum possible) hop length as deter-mined by an off-line omniscient algorithm.

Figure 4(a) shows the Packet Delivery Ratio (PDR) for each protocol. Removing the optimizations from DSRto produce DSR-NoOpt reduces PDR by an average of 12.7%; adding Ariadne-HiOvd security further reduces PDRby just an additional 1.12% on average, and does not reduce PDR by more than an additional 2.8% at any pausetime. Ariadne with reduced overhead recovers most of this PDR loss; it has PDR just 0.015% lower (on average) thanDSR-NoOpt. Ariadne with reduced overhead outperforms DSR-NoOpt at low mobility, but has lower PDR at highmobility.

Surprisingly, Ariadne outperforms DSR-NoOpt at lower levels of mobility. This improved performance resultsfrom the average half-second delay (one half the TESLA time interval) that Ariadne introduces between the targetreceiving a ROUTE REQUEST and sending a ROUTE REPLY. Specifically, when a REQUEST traverses a short-livedlink, DSR-NoOpt immediately returns the REPLY, but the new route can be used for only its brief lifetime, contributingadditional overhead for forwarding the REPLY and for sending and forwarding the ERROR. In Ariadne, links are testedtwice: once when the REQUEST traverses the network, and once when the REPLY is sent along the reverse path. If oneof these links breaks between these tests, the REPLY with this route is not received by the initiator. It is this additionalroute confirmation that allows Ariadne to find more stable routes than DSR-NoOpt.

From examining PDR across these protocols, we draw three conclusions. First, Ariadne Route Discovery operatesmore slowly but also finds better routes, since those routes must exist for long enough to return a ROUTE REPLY.Second, these better routes offset the disadvantage that Ariadne ROUTE ERRORs cannot be processed until the TESLAkey used is disclosed, causing additional data packets continue to be sent along the broken route for on average halfof the TESLA time interval after the ERROR is received. Finally, the increased overhead of Ariadne-HiOvd is almostfully responsible for its lower PDR relative to DSR-NoOpt.

Figure 4(b) shows Path Optimality. In DSR, the average number of hops along a route used by a packet is 0.700hops more than the minimum possible, based on the nominal wireless transmission range of 250 m per hop. InDSR-NoOpt, routes used are on average 0.264 hops longer than in DSR, and in both versions of Ariadne, routes usedaverage 0.011 hops longer than in DSR-NoOpt. DSR-NoOpt performs slightly better than Ariadne because it initiatesmore Route Discoveries and thus tends to more quickly find shorter routes when they become available than doesAriadne.

Figures 4(c) and 4(d) show the packet and byte overhead, respectively. Ariadne has consistently lower packetoverhead than DSR-NoOpt, because Ariadne tends to find more stable routes than DSR-NoOpt, reducing the num-ber of ROUTE ERRORs that are sent. This advantage is somewhat countered by the increase in number of ROUTE

ERRORs used by Ariadne: since ERROR processing is delayed, more redundant ERRORs are sent. Byte overhead inAriadne-HiOvd is significantly worse than in either DSR or DSR-NoOpt, due to the authentication overhead in ROUTE

REQUEST, REPLY, and ERROR packets. Suprisingly, Ariadne-LoOvd has lower overhead than DSR-NoOpt, becausethe extra packets sent by DSR-NoOpt outweigh the additional authentication information in each Ariadne-LoOvdrouting control packet.

Figures 4(e) and 4(f) show the average and 99.99th percentile latency for the protocols, respectively. Because ofthe reduced number of broken links that Ariadne uses relative to DSR-NoOpt, Ariadne generally has better latencythan DSR-NoOpt. Ariadne-LoOvd shows significantly lower mean latency than Ariadne-HiOvd, because it has lowerbyte overhead and thus creates less congestion. The difference is also present in the 99.99th percentile latency, butthere, channel contention is a smaller fraction of the overall latency.

7.2. Security Analysis

In this section, we discuss how Ariadne resists attacks by certain attacker types, according to the taxonomy we presentin Section 5.1.

15

Intuitively, Ariadne Route Discovery is successful when at least one of the REPLYs returned by the target is aworking route. Since the target of a Route Discovery returns a route for each of its neighbors, if the first REQUEST

from a particular Discovery to reach any neighbor of the target has passed through no malicious nodes, that Discoverywill succeed.

To more formally characterize the security offered by Ariadne, we define a minimum broadcast latency pathbetween a source and a destination to be any path that forwards a Route Discovery most quickly from the source to thedestination. We call a route that only consists of uncompromised nodes an uncompromised route. Ariadne preventscompromised nodes from disturbing uncompromised routes. In particular, Ariadne provides two properties assumingreliable broadcast:

• If there exists an uncompromised neighbor of a destination such that the minimum latency path between theinitiator of the Discovery and that neighbor is uncompromised, then an uncompromised route from the initiatorto the target will be returned in a ROUTE REPLY.

• If at least one REPLY returned as a result of the first property represents a shortest route from the initiator to thetarget, Ariadne may route packets along one such uncompromised route.

To argue for the correctness of the first property, we note that if the minimum latency path between the initiatorand a neighbor of the destination is uncompromised, then the first REQUEST to reach that neighbor comes over anuncompromised route. Since it is the first REQUEST, it will not be filtered by duplicate REQUEST detection, so itwill be rebroadcast, and heard by the target. Since the target returns a REPLY for each REQUEST it receives, withoutperforming duplicate detection, a REPLY will be returned. The second property trivially follows from the use ofshortest paths and the first property.

Although it may not be possible to achieve reliable broadcast securely or efficiently, we assume that most broadcastpackets are received, and hence the properties listed above generally hold.

We now consider Ariadne using our taxonomy of attacks that we present in Section 5.1. We list different attackerconfigurations in increasing strength, and discuss how Ariadne resists some possible attacks. Ariadne resists manymore attacks, but only a representative sample are discussed here.

Since Ariadne does not attempt to provide anonymous routing, passive attackers can eavesdrop on all routing trafficsent by nodes within range of those attackers. They can also perform traffic analysis on any packets sent or forwardedby nodes within range of the attackers.

When replay protection and a global MAC key are used, an Active-0-x attacker (for x ≥ 1) can at most performwormhole and rushing attacks. Packet leashes can prevent these attacks [24].

An Active-1-1 attacker may attempt the following attacks:

• Create a gray hole or black hole by removing nodes in a ROUTE REQUEST; however, the per-hop hash mecha-nism in each REQUEST prevents such tampering. An attacker may fabricate nodes to insert in the accumulatedroute list of a REQUEST packet, such fabricated nodes would not have known keys at the source, and the REPLY

would thus not be authenticated. If the attacker tries to replace the MAC and keys in the reply, such tamperingwill be detected as a result of the target MAC field in the REPLY.

• Create routing loops. Intuitively, the use of source routes prevents loops, since a packet passing through onlylegitimate nodes will not be forwarded into a loop. An attacker can create a routing loop by modifying thesource route each time around the loop; this behavior, however, is no worse than if the attacker were to sourcepackets with period equal to the propagation time around the loop. In particular, if there are n nodes in therouting loop, and a single packet is forwarded around the loop m times, the attacker participates in m forwards,and the total expended effort is mn forwards. Had the attacker instead sourced m packets along n-hop routes,the total attacker effort is m transmissions, and the total network effort is mn forwards, an identical result.

• Flood network with many ROUTE REQUESTs. Since the source address of each REQUEST is authenticated, andsince each new Route Discovery needs to carry a new one-way Route Discovery chain value, the compromisednode can only produce ROUTE REQUESTs with its own source address. An upper bound on the sending rate canbe enforced either by rate limiting of REQUESTs at each node or synchronizing Route Discovery chain elementswith time (Section 6.5).

• Perform a rushing attack (Section 5.2). Rushing attacks can be probabilistically prevented by slightly modifyingthe Route Discovery protocol [22].

Multiple attackers that have compromised one node (Active-1-x, for x > 1) may attempt to construct a wormhole,but append the address and key of the compromised node in each REQUEST forwarded across this wormhole. Packetleashes alone cannot prevent this attack, but packet leashes and GPS can be used in conjunction to ensure that anActive-1-x wormhole attack can be no worse than an Active-1-1 attacker positioned correctly. In particular, if each

16

node forwarding a ROUTE REQUEST includes its alleged GPS coordinates in that REQUEST, then a node can detect if itshould be reachable from the previous hop, and if the hop before the previous hop should be able to reach the previoushop. If both of these checks succeed, then the attacker could have placed the compromised node at the position itspecified in the packet, and that node would have been able to hear the original REQUEST, append its address, andforward it to the next hop.

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

• Lengthen the route in the REQUEST by adding other compromised nodes to the route. If the source finds ashorter route, it will likely prefer that route, so the protocol behaves as if the attacker were not there.

• Attempt to force the initiator to repeatedly initiate Route Discoveries. Suppose an Active-y-x attacker had thekeys of multiple compromised nodes, and that one such attacker were on the shortest path from the source tothe destination. When the attacker receives its first ROUTE REQUEST packet as part of some Discovery, it addsits address and MAC, as normal, but also adds the address of another node it has compromised. When datapackets are sent along that route, the attacker replies with a ROUTE ERROR from its first hop to its second hop.In subsequent Route Discoveries, the attacker can use different addresses for the additional address. Since otherroutes may have been returned as part of any of these Route Discoveries, this attack is not guaranteed to besuccessful.To prevent such starvation, the initiator may include data in the ROUTE REQUEST. To be part of the path, theattacker must forward routing messages, so the initiator can send data to the target. If the attacker alters the datain the ROUTE REQUEST, the destination will detect the alteration (using the shared key and a MAC on the data)and reject that route.

A set of attackers that control a vertex cut of the network (an Active-VC attacker) may perform the followingadditional attacks:

• Make nodes on one side of the vertex cut believe that any node on the other side is attempting to flood thenetwork. By holding and not propagating ROUTE REQUESTs from a certain node for some time, then initiatingmany Route Discoveries with the chain values from the old Discoveries, an Active-VC attacker can make thatnode appear to be flooding the network. When the use of individual elements of a Route Discovery chainare time-synchronized, this attack simply causes the REQUESTs associated with the stale chain elements to bediscarded.

• Only forward ROUTE REQUEST and ROUTE REPLY packets. A sender is then unable to successfully deliverpackets. This attack is only marginally different from not participating in the protocol at all, differing only inthat the sender and some intermediate nodes continue to spend power to send packets, but none of those packetsare successfully received.

8. Related Work

Several researchers have proposed secure routing protocols. For example, Perlman [46] proposed flooding NPBR,an on-demand protocol designed for wired networks that floods each packet through the network. Flooding NPBRallocates a fraction of the bandwidth along each link to each node, and uses digital signatures to authenticate allpackets. Unfortunately, this protocol has high overhead in terms of the computational resources necessary for digitalsignature verification and in terms of its bandwidth requirements. Furthermore, estimating and guaranteeing availablebandwidth in a wireless environment is difficult [33].

Other wired network protocols have secured periodic routing protocols with asymmetric cryptography, such asKent et al [32], Perlman’s link-state NPBR, Kumar’s secure link-state protocol [36], and Smith et al [57, 58]. However,nodes in an ad hoc network may not have sufficient resources to verify an asymmetric signature; in particular, anattacker can trivially flood a victim with packets containing invalid signatures, but verification can be prohibitivelyexpensive for the victim. In addition, these protocols may suffer in some scenarios because periodic protocols may notbe able to cope with high rates of mobility in an ad hoc network. Kumar also discusses threats to both distance-vectorprotocols and link-state protocols, and describes techniques for securing distance-vector protocols. However, thesetechniques are vulnerable to the compromise of a single node.

Zhou and Haas [65], Zapata [63], and Sanzgiri et al [56] propose the use of asymmetric cryptography to secureon-demand ad hoc network routing protocols. However, as above, when the nodes in an ad hoc network are generallyunable to verify asymmetric signatures quickly enough, or when network bandwidth is insufficient, these protocolsmay not be suitable.

17

Cheung [10], Hauser et al [17], and Zhang [64] describe symmetric-key approaches to the authentication of link-state updates, but they do not discuss mechanisms for detecting the status of these links. In wired networks, a commontechnique for authenticating HELLO packets is to verify that the the incoming network interface is the expectedinterface and that the IP TTL of the packet is 255. In a wireless ad hoc network, this technique cannot be used.Furthermore, these protocols assume the use of periodic routing protocols, which are not always suitable in ad hocnetworks. Cheung [10] uses cryptographic mechanisms similar to those used in Ariadne with TESLA, but optimisti-cally integrates routing data before it is authenticated, adversely affecting security.

A number of other researchers have also proposed the use of symmetric schemes for authenticating routing controlpackets. Heffernan [18] proposes a mechanism requiring shared keys between all communicating routers. This schememay not scale to large ad hoc networks, and may be vulnerable to single-node compromise. Perrig et al [49] usesymmetric primitives to secure routing between nodes and a trusted base station. Basagni et al [2] use a network-widesymmetric key to secure routing communication, which is vulnerable to a single node compromise, although theyspecify the use of secure hardware to limit the damage that can be done by a compromised node. Papadimitratosand Haas [43] present work that secures against non-colluding adversaries, and they do not authenticate intermediatenodes that forward ROUTE REQUESTs, and thus do not handle authorization. Yi et al [62] 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 on a periodic protocol, and such protocols tend to have higher overhead than on-demandprotocols and may not be suitable in highly mobile networks.

Routing protocol intrusion detection has also been studied as a mechanism for detecting misbehaving routers [7,11, 39].

9. Conclusions

This paper has presented the design and evaluation of Ariadne, a new ad hoc network routing protocol that providessecurity against one compromised node and arbitrary active attackers, and relies only on efficient symmetric cryp-tography. Ariadne operates on-demand, dynamically discovering routes between nodes only as needed; the design isbased on the basic operation of the DSR protocol. Rather than generously applying cryptography to an existing pro-tocol to achieve security, however, we carefully re-designed each protocol message and its processing. The securitymechanisms we designed are highly efficient and general, so that they should be applicable to securing a wide varietyof routing protocols.

Because we did not secure the optimizations of DSR in Ariadne, the resulting protocol is less efficient than thehighly optimized version of DSR that runs in a trusted environment. However, we also compared Ariadne to a versionof DSR in which we disabled all protocol optimizations not present in Ariadne, allowing us to evaluate and analyzethe effect of the optimizations and the security separately. The byte overhead of Ariadne was 26.19% higher than forunoptimized DSR, due to the overhead of the authentication information in Ariadne’s routing packets. As explainedin our results, however, Ariadne actually performs better on some metrics (e.g., 41.7% lower packet overhead) thanfor unoptimized DSR, and about the same on all other metrics, even though Ariadne must bear the added costs forsecurity not present in unoptimized DSR.

We found that source-routing facilitates securing ad hoc network routing protocols. Source routing empowersthe sender to circumvent potentially malicious nodes, and enables the sender to authenticate every node in a ROUTE

REPLY. Such fine-grained path control is absent in most distance-vector routing protocols, which makes such protocolsmore challenging to fully secure.

References

[1] Norman Abramson. The ALOHA System—Another Alternative for Computer Communications. In Proceedingsof the Fall 1970 AFIPS Computer Conference, pages 281–285, November 1970.

[2] Stefano Basagni, Kris Herrin, Emilia Rosti, and Danilo Bruschi. Secure Pebblenets. In Proceedings of the SecondSymposium on Mobile Ad Hoc Networking and Computing (MobiHoc 2001), pages 156–163, October 2001.

[3] Mihir Bellare, Ran Canetti, and Hugo Krawczyk. Keying Hash Functions for Message Authentication. InAdvances in Cryptology - Crypto ’96, edited by Neal Koblitz, pages 1–15. Springer-Verlag, 1996. Lecture Notesin Computer Science Volume 1109.

18

[4] Bhargav Bellur and Richard G. Ogier. A reliable, efficient topology broadcast protocol for dynamic networks.In Proceedings of the Eighteenth Annual Joint Conference of the IEEE Computer and Communications Societies(INFOCOM ’99), pages 178–186, March 1999.

[5] A. Benjaminson and S. C. Stallings. A Microcomputer-Compensated Crystal Oscillator Using a Dual-ModeResonator. In Proceedings of the 43rd Annual Symposium on Frequency Control, pages 20–26, May 1989.

[6] Vaduvur Bharghavan, Alan Demers, Scott Shenker, and Lixia Zhang. MACAW: A Media Access Protocol forWireless LANs. In Proceedings of the SIGCOMM ’94 Conference on Communications Architectures, Protocolsand Applications, pages 212–225, August 1994.

[7] Kirk A. Bradley, Steven Cheung, Nick Puketza, Biswanath Mukherjee, and Ronald A. Olsson. Detecting Dis-ruptive Routers: A Distributed Network Monitoring Approach. pages 115–124, May 1998.

[8] Josh Broch, David A. Maltz, David B. Johnson, Yih-Chun Hu, and Jorjeta G. Jetcheva. A Performance Com-parison of Multi-Hop Wireless Ad Hoc Network Routing Protocols. In Proceedings of the Fourth ACM/IEEEInternational Conference on Mobile Computing and Networking (MobiCom’98), pages 85–97, October 1998.

[9] Michael Brown, Donny Cheung, Darrel Hankerson, Julio Lopez Hernandez, Michael Kirkup, and AlfredMenezes. PGP in Constrained Wireless Devices. In 9th USENIX Security Symposium, pages 247–261, Au-gust 2000.

[10] Steven Cheung. An Efficient Message Authentication Scheme for Link State Routing. In 13th Annual ComputerSecurity Applications Conference, pages 90–98, 1997.

[11] Steven Cheung and Karl Levitt. Protecting Routing Infrastructures from Denial of Service Using CooperativeIntrusion Detection. In The 1997 New Security Paradigms Workshop, pages 94–106, September 1998.

[12] Tom Clark. Tom Clark’s Totally Accurate Clock FTP Site. Greenbelt, Maryland. Available atftp://aleph.gsfc.nasa.gov/GPS/totally.accurate.clock/.

[13] Don Coppersmith and Markus Jakobsson. Almost Optimal Hash Sequence Traversal. In Proceedings of theFourth Conference on Financial Cryptography (FC ’02), 2002.

[14] T. Dierks and C. Allen. The TLS protocol version 1.0. RFC 2246, January 1999.

[15] Eran Gabber and Avishai Wool. How to Prove Where You Are: Tracking the Location of Customer Equipment. InProceedings of the 5th ACM Conference on Computer and Communications Security, pages 142–149, November1998.

[16] Oded Goldreich, Shafi Goldwasser, and Silvio Micali. How to Construct Random Functions. Journal of theACM, 33(4):792–807, October 1986.

[17] Ralf Hauser, Antoni Przygienda, and Gene Tsudik. Reducing the Cost of Security in Link State Routing. InSymposium on Network and Distributed Systems Security (NDSS ’97), pages 93–99, February 1997.

[18] Andy Heffernan. Protection of BGP Sessions via the TCP MD5 Signature Option. RFC 2385, August 1998.

[19] Yih-Chun Hu and David B. Johnson. Caching Strategies in On-Demand Routing Protocols for Wireless Ad HocNetworks. In Proceedings of the Sixth Annual IEEE/ACM International Conference on Mobile Computing andNetworking (MobiCom 2000), pages 231–242, August 2000.

[20] Yih-Chun Hu and David B. Johnson. Implicit Source Routing in On-Demand Ad Hoc Network Routing. InProceedings of the Second Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc 2001), pages1–10, October 2001.

[21] Yih-Chun Hu, David B. Johnson, and Adrian Perrig. Secure Efficient Distance Vector Routing in Mobile WirelessAd Hoc Networks. In Fourth IEEE Workshop on Mobile Computing Systems and Applications (WMCSA ’02),pages 3–13, June 2002.

[22] Yih-Chun Hu, Adrian Perrig, and David B. Johnson. Rushing Attacks and Defense in Wireless Ad Hoc NetworkRouting Protocols. Technical Report TR01-384, Department of Computer Science, Rice University, June 2002.

[23] Yih-Chun Hu, Adrian Perrig, and David B. Johnson. Efficient Security Mechanisms for Routing Protocols. InProceedings of the Tenth Annual Network and Distributed System Security Symposium (NDSS 2003), February2003. To appear.

[24] Yih-Chun Hu, Adrian Perrig, and David B. Johnson. Packet Leashes: A Defense against Wormhole Attacksin Wireless Ad Hoc Networks. In Proceedings of the Twenty-Second Annual Joint Conference of the IEEEComputer and Communications Societies (INFOCOM 2003), April 2003. To appear.

19

[25] Jean-Pierre Hubaux, Levente Buttyan, and Srdjan Capkun. The Quest for Security in Mobile Ad Hoc Networks.In Proceedings of the Second Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc 2001), pages146–155, October 2001.

[26] IEEE Computer Society LAN MAN Standards Committee. Wireless LAN Medium Access Control (MAC) andPhysical Layer (PHY) Specifications, IEEE Std 802.11-1997. The Institute of Electrical and Electronics Engi-neers, 1997.

[27] Per Johansson, Tony Larsson, Nicklas Hedman, Bartosz Mielczarek, and Mikael Degermark. Scenario-basedPerformance Analysis of Routing Protocols for Mobile Ad-hoc Networks. In Proceedings of the Fifth AnnualACM/IEEE International Conference on Mobile Computing and Networking (MobiCom’99), pages 195–206,August 1999.

[28] David B. Johnson. Routing in Ad Hoc Networks of Mobile Hosts. In Proceedings of the IEEE Workshop onMobile Computing Systems and Applications (WMCSA’94), pages 158–163, December 1994.

[29] David B. Johnson and David A. Maltz. Dynamic Source Routing in Ad Hoc Wireless Networks. In Mobile Com-puting, edited by Tomasz Imielinski and Hank Korth, chapter 5, pages 153–181. Kluwer Academic Publishers,1996.

[30] David B. Johnson, David A. Maltz, Yih-Chun Hu, and Jorjeta G. Jetcheva. The Dynamic Source Routing Protocolfor Mobile Ad Hoc Networks. Internet-Draft, draft-ietf-manet-dsr-07.txt, February 2002. Work in progress.

[31] John Jubin and Janet D. Tornow. The DARPA Packet Radio Network Protocols. Proceedings of the IEEE,75(1):21–32, January 1987.

[32] Stephen Kent, Charles Lynn, Joanne Mikkelson, and Karen Seo. Secure Border Gateway Protocol (S-BGP) —Real World Performance and Deployment Issues. In Symposium on Network and Distributed Systems Security(NDSS ’00), pages 103–116, February 2000.

[33] Minkyong Kim and Brian Noble. Mobile Network Estimation. In Proceedings of the Seventh Annual Interna-tional Conference on Mobile Computing and Networking (MobiCom 2001), pages 298–309, July 2001.

[34] Young-Bae Ko and Nitin Vaidya. Location-Aided Routing (LAR) in Mobile Ad Hoc Networks. In Proceedingsof the Fourth ACM/IEEE International Conference on Mobile Computing and Networking (MobiCom’98), pages66–75, October 1998.

[35] John Kohl and B. Clifford Neuman. The Kerberos Network Authentication Service (V5). RFC 1510, September1993.

[36] B. Kumar. Integration of Security in Network Routing Protocols. SIGSAC Review, 11(2):18–25, 1993.

[37] David A. Maltz, Josh Broch, Jorjeta Jetcheva, and David B. Johnson. The Effects of On-Demand Behavior inRouting Protocols for Multi-Hop Wireless Ad Hoc Networks. IEEE Journal on Selected Areas in Communica-tions, 17(8):1439–1453, August 1999.

[38] David A. Maltz, Josh Broch, and David B. Johnson. Quantitative Lessons From a Full-Scale Multi-Hop WirelessAd Hoc Network Testbed. In Proceedings of the IEEE Wireless Communications and Networking Conference,pages 992–997, September 2000.

[39] Sergio Marti, T.J. Giuli, Kevin Lai, and Mary Baker. Mitigating Routing Misbehaviour in Mobile Ad HocNetworks. In Proceedings of the Sixth Annual IEEE/ACM International Conference on Mobile Computing andNetworking (MobiCom 2000), pages 255–265, August 2000.

[40] Matt Mathis, Jamshid Mahdavi, Sally Floyd, and Allyn Romanow. TCP Selective Acknowledgment Options.RFC 2018, October 1996.

[41] Alfred J. Menezes, Paul C. van Oorschot, and Scott A. Vanstone. Handbook of Applied Cryptography. CRCPress Series on Discrete Mathematics and its Applications. CRC Press, 1997.

[42] Thomas Narten, Erik Nordmark, and William Allen Simpson. Neighbor Discovery for IP Version 6 (IPv6).RFC 2461, December 1998.

[43] Panagiotis Papadimitratos and Zygmunt J. Haas. Secure Routing for Mobile Ad Hoc Networks. In SCS Commu-nication Networks and Distributed Systems Modeling and Simulation Conference (CNDS 2002), January 2002.

[44] Charles E. Perkins and Pravin Bhagwat. Highly Dynamic Destination-Sequenced Distance-Vector Routing(DSDV) for Mobile Computers. In Proceedings of the SIGCOMM ’94 Conference on Communications Ar-chitectures, Protocols and Applications, pages 234–244, August 1994.

[45] Charles E. Perkins and Elizabeth M. Royer. Ad-Hoc On-Demand Distance Vector Routing. In Second IEEEWorkshop on Mobile Computing Systems and Applications (WMCSA’99), pages 90–100, February 1999.

20

[46] Radia Perlman. Interconnections: Bridges and Routers. 1992.

[47] Adrian Perrig, Ran Canetti, Dawn Song, and J. D. Tygar. Efficient and Secure Source Authentication for Multi-cast. In Network and Distributed System Security Symposium, NDSS ’01, pages 35–46, February 2001.

[48] Adrian Perrig, Ran Canetti, J.D. Tygar, and Dawn Song. Efficient Authentication and Signing of MulticastStreams over Lossy Channels. In IEEE Symposium on Security and Privacy, pages 56–73, May 2000.

[49] Adrian Perrig, Robert Szewczyk, Victor Wen, David Culler, and J. D. Tygar. SPINS: Security Protocols forSensor Networks. In Proceedings of the Seventh Annual International Conference on Mobile Computing andNetworking (MobiCom 2001), pages 189–199, July 2001.

[50] Raymond L. Pickholtz, Donald L. Schilling, and Laurence B. Milstein. Theory of Spread Spectrum Communi-cations — A Tutorial. IEEE Transactions on Communications, 30(5):855–884, May 1982.

[51] Amir Qayyum, Laurent Viennot, and Anis Laouiti. Multipoint Relaying: An Efficient Technique for flooding inMobile Wireless Networks. Technical Report Research Report RR-3898, INRIA, February 2000.

[52] Theodore S. Rappaport. Wireless Communications: Principles and Practice. Prentice Hall, 1996.

[53] Yakov Rekhter and Tony Li. A Border Gateway Protocol 4 (BGP-4). RFC 1771, March 1995.

[54] Ronald L. Rivest, Adi Shamir, and Leonard M. Adleman. A Method for Obtaining Digital Signatures and Public-Key Cryptosystems. Communications of the ACM, 21(2):120–126, 1978.

[55] Pankaj Rohatgi. A Compact and Fast Hybrid Signature Scheme for Multicast Packet Authentication. In 6th ACMConference on Computer and Communications Security, November 1999.

[56] Kimaya Sanzgiri, Bridget Dahill, Brian Neil Levine, , Clay Shields, and Elizabeth Belding-Royer. A SecureRouting Protocol for Ad hoc Networks. In Proceedings of the 10th IEEE International Conference on NetworkProtocols (ICNP ’02), November 2002.

[57] Bradley R. Smith and J.J. Garcia-Luna-Aceves. Securing the Border Gateway Routing Protocol. In GlobalInternet’96, pages 81–85, November 1996.

[58] Bradley R. Smith, Shree Murthy, and J.J. Garcia-Luna-Aceves. Securing Distance Vector Routing Protocols. InSymposium on Network and Distributed Systems Security (NDSS ’97), pages 85–92, February 1997.

[59] Frank Stajano and Ross Anderson. The Resurrecting Duckling: Security Issues for Ad-hoc Wireless Networks.In Security Protocols, 7th International Workshop, volume 1796. Springer Verlag, 1999.

[60] Trimble Navigation Limited. Data Sheet and Specifications for Trimble Thunderbolt GPS Disciplined Clock.Sunnyvale, California. Available at http://www.trimble.com/thunderbolt.html.

[61] Aristotelis Tsirigos and Zygmunt J. Haas. Multipath Routing in Mobile Ad Hoc Networks or How to Route inthe Presence of Topological Changes. In Proceedings of IEEE MILCOM 2001, pages 878–883, October 2001.

[62] Seung Yi, Prasad Naldurg, and Robin Kravets. Security-Aware Ad hoc Routing for Wireless Networks. TechnicalReport UIUCDCS-R-2001-2241, Department of Computer Science, University of Illinois at Urbana-Champaign,August 2001.

[63] Manel Guerrero Zapata and N. Asokan. Securing Ad Hoc Routing Protocols. In Proceedings of the ACMWorkshop on Wireless Security (WiSe 2002), September 2002.

[64] Kan Zhang. Efficient Protocols for Signing Routing Messages. In Proceedings of the Symposium on Networkand Distributed Systems Security (NDSS ’98), March 1998.

[65] Lidong Zhou and Zygmunt J. Haas. Securing Ad Hoc Networks. IEEE Network Magazine, 13(6):24–30, Novem-ber/December 1999.

21