Securing Quality-of-Service Route Discovery in On-Demand Routing for Ad Hoc Networks

Transcription

1 Securng Qualty-of-Servce Route Dscovery n On-Demand Routng for Ad Hoc Networks Yh-Chun Hu UC Berkeley yhchun@cs.cmu.edu Davd B. Johnson Rce Unversty dbj@cs.rce.edu ABSTRACT An ad hoc network s a collecton of computers (nodes) that cooperate to forward packets for each other over a multhop wreless network. Users of such networks may wsh to use demandng applcatons such as vdeoconferencng, Voce over IP, and streamng meda when they are connected through an ad hoc network. Because overprovsonng, a common technque n wred networks, s often mpractcal n wreless networks for reasons such as power, cost, and government regulaton, Qualty of Servce (QoS) routng s even more mportant n wreless networks than n wred networks. Though a number of QoS-routng protocols have been proposed for use n ad hoc networks, securty of such protocols has not been consdered. In ths paper, we develop SQoS, a secure form of QoS-Guded Route Dscovery for on-demand ad hoc network routng. SQoS reles entrely on symmetrc cryptography. Symmetrc cryptographc prmtves are three to four orders of magntude faster (n computaton tme) than asymmetrc cryptography. In addton, we show that n general, exstng QoS-Guded Route Dscovery can, for a sngle Route Dscovery, transmt a number of packets exponental n the number of network nodes, creatng an opportunty for Denal-of-Servce (DoS) attacks. SQoS lmts ths overhead to be lnear n the number of network nodes by provdng the source wth control over whch Route Requests are forwarded. Categores and Subject Descrptors C.2.0 [General]: Securty and protecton (e.g., frewalls); C.2.2 [Network Protocols]: Routng protocols General Terms Performance, Desgn, Securty Keywords Smulatons, Securty, Qualty-of-Servce, QoS Routng, ad hoc networks, SQoS Permsson to make dgtal or hard copes of all or part of ths work for personal or classroom use s granted wthout fee provded that copes are not made or dstrbuted for proft or commercal advantage and that copes bear ths notce and the full ctaton on the frst page. To copy otherwse, to republsh, to post on servers or to redstrbute to lsts, requres pror specfc permsson and/or a fee. SASN 04, October 25, 2004, Washngton, DC, USA. Copyrght 2004 ACM /04/00...$ INTRODUCTION An ad hoc network s a collecton of computers (nodes) that cooperate to forward packets for each other over a multhop wreless network. The nodes n the network may move and rado propagaton condtons may change at any tme, creatng a dynamc, rapdly changng network topology. An mportant applcaton of ad hoc networkng technology s to enable communcaton n envronments n whch there s no nfrastructure, where the nfrastructure has been destroyed, or when the nfrastructure cannot be used due to ssues such as cost and securty. A substantal amount of research has been proposed n the feld of ad hoc network routng, and mature protocols such as DSR [20], AODV [31], OLSR [33], and TBRPF [3] have emerged from standards dscussons n the Internet Engneerng Task Force (IETF), the prncple protocol standards development organzaton for the Internet. Users of ad hoc networks may wsh to use demandng applcatons such as vdeoconferencng, Voce over IP, and streamng meda when they are connected through an ad hoc network. Qualty of Servce (QoS) has been an mportant area of research n wred networks, as researchers have looked for solutons that provde acceptable levels of performance for these types of applcatons. When QoS routng s avalable n ad hoc networks, users wll experence better performance whle usng these types of challengng applcatons. In wreless networks, QoS routng s even more mportant. That s, n wred networks, overprovsonng can often be used to reduce the need for sophstcated QoS technques n all but the most demandng network applcatons. However, n wreless networks, overprovsonng s often mpossble or mpractcal, due to constrants on rado spectrum and power level, or because of nterference or nose wthn the rado spectrum. As a result, usng a QoS routng protocol to carefully choose routng paths wth suffcent resources may be the only way to provde suffcent resources n wreless networks for many applcatons. Ths s even more mportant n ad hoc networks due to the frequent changes n routng topology and the need to maxmze the use of the shared rado resources over multple wreless hops. In addton, recent work on route selecton [] shows that measurng lnk qualty can sgnfcantly mprove network performance even for best-effort traffc. Most work on QoS routng n ad hoc networks has focused on the Integrated Servces model [4], wth flows and reservatons, rather than on the Dfferentated Servces [30] model, where certan packets are marked as havng prorty over unmarked packets. One reason most researchers have chosen ths drecton s that, n ad hoc networks, capacty and connectvty are qute dynamc. The dynamc nature of ad hoc networks pose a sgnfcant challenge to

2 the negotaton of Servce Level Agreements (SLA), whch lmt the amount of marked traffc that any node can ntroduce. Routng protocols for ad hoc networks can generally be dvded nto two categores. A proactve (or perodc) routng protocol attempts to allow each node usng t to always mantan an up-todate route to each possble destnaton n the network; the protocol perodcally exchanges routng nformaton wth other nodes n order to allow new routes to be dscovered and exstng routes to be modfed f they break due to factors such as node moblty and envronmental changes. A reactve (or on-demand) routng protocol only attempts to a dscover a route to some destnaton when t has a packet to route to that destnaton and does not already know a route there; the protocol caches known routes and uses a floodngbased dscovery protocol when a needed route s not found n the cache. For dynamcally moble ad hoc networks, reactve or ondemand routng protocols often outperform proactve or perodc ones, due to ther ablty to adjust the amount of network overhead created to track the moblty n the network affectng current communcaton [6, 19]. A number of protocols have been proposed for QoS routng n ad hoc networks [5, 7, 8, 24, 25, 32, 38]. As desgned, these protocols are ntended for operaton n a trusted envronment n whch all nodes are honest, and they do not consder the dsruptons that can be caused by a malcous attacker sendng arbtrary (e.g., forged) routng packets. In ths paper, we dscuss general mechansms for securng QoS routng n on-demand routng protocols for ad hoc networks, and we apply these mechansms to create a new secure QoS routng protocol that we call SQoS. The operaton of SQoS s based on DSR s QoS-guded Route Dscovery [25, 5] technque. We also show how our mechansms can be appled to the proposed AODV QoS extensons [32]. The rest of ths paper s organzed as follows. In Secton 2, we descrbe exstng work on QoS-Guded Route Dscovery. In Secton 3, we then present an overvew of the cryptographc mechansms that we use for securng QoS-Guded Route Dscovery, and Secton 4 descrbes mechansms for securng QoS-Guded Route Dscovery, ncludng one mechansm (ROUTE REQUEST authentcaton) that s generally applcable to all secure on-demand routng protocols. In Secton 5, we then compare our SQoS protocol wth a protocol for securng QoS-Guded Route Dscovery usng publc key cryptography. We revew related work n Secton 6 and conclude n Secton QOS-GUIDED ROUTE DISCOVERY In an on-demand ad hoc network routng protocol, such as DSR [22, 21] or AODV [31, 32], a node (whch we call the ntator) can fnd a route to a destnaton node (whch we call the target) by performng a controlled flood of the network. In ths Route Dscovery procedure, the ntator transmts a ROUTE REQUEST packet, dentfyng the target to whch the route s needed. Each node recevng the ROUTE REQUEST n general retransmts the REQUEST f t has not already forwarded a copy of t; when the target node receves the REQUEST, t returns a ROUTE REPLY to the ntator, lstng the route taken by the REQUEST, rather than forwardng the REQUEST. Many optmzatons have been defned for ths basc Route Dscovery scheme to reduce the frequency of performng Route Dscovery and to lmt the porton of the network over whch the ROUTE REQUEST flood must be forwarded. For each ndvdual Route Dscovery attempt, each node that forwards the ROUTE REQUEST does so only for the frst REQUEST t receves as part of that Route Dscovery, n order to lmt the overhead of the floodng operaton. In AODV, ths technque n effect fnds the path whch forwards the REQUEST to the target wth the lowest latency; n DSR, ths technque returns a set of paths such that each strct prefx P of each path s the path that forwarded the REQUEST to the last node of P wth lowest latency (the target node n DSR returns a ROUTE REPLY for each copy of the ROUTE REQUEST that t receves). In both cases, a node wshng to fnd a route wth certan QoS parameters (e.g., wth a gven maxmum latency or a gven avalable bandwdth) may not be able to fnd a route wth suffcent qualty. In partcular, because low-latency paths are preferred, a node searchng for a path along whch to route a hgh-bandwdth flow may not fnd an approprate route wth ether DSR or AODV, even f a route wth suffcent bandwdth exsts. To allow Route Dscovery to dscover paths satsfyng QoS constrants, Maltz ntroduced QoS-Guded Route Dscovery [5, 25], whch allows a node to specfy QoS metrcs that must be satsfed by a dscovered path. (The QoS-Guded Route Dscovery technque was specfed n verson 3 of the DSR Internet-Draft [5] n the IETF but was removed n later drafts [22] to smplfy the standard DSR protocol specfcaton n accordance wth the consensus of the MANET Workng Group.) In ths secton, we revew the prevous work n QoS-Guded Route Dscovery. In QoS-Guded Route Dscovery, ROUTE REQUEST packets are constraned to paths fulfllng certan requrements. Often, a node may already have a preexstng route to the destnaton; for example, n DSR, a node may have a cached route, or n AODV, a node may already have the destnaton n ts routng table. When a node has a preexstng route, t may ether perform a QoS-Guded Route Dscovery, or t may attempt to establsh a new flow along the preexstng route. If the node chooses to use the preexstng route and the flow establshment s successful, t s not necessary to perform a QoS-Guded Route Dscovery, although one may be performed n an attempt to fnd a better route. The decson about whether or not to perform such a Dscovery may be made based on resources avalable along a preexstng route or the node s estmate of the probablty of successful flow setup along that route. Alternatvely, a node may choose to always perform a second search requestng a slghtly hgher level of resources than s avalable along the preexstng route. To use ths QoS-Guded Route Dscovery mechansm, a node sendng a ROUTE REQUEST also nserts n the REQUEST an optonal QoS Request Header for each type of resource requred. Each QoS Request Header ndcates the type of resource, the mnmum acceptable resource level, and the resource level of the current path. The resource level of the current path s ntalzed to the desred resource level, but may be reduced as the ROUTE REQUEST traverses the network. For example, an audo flow may requre at least 2.4 kbps of bandwdth but desre up to 128 kbps. In ths case, when t ntates the Route Dscovery, the ntator node specfes a mnmum acceptable level of 2.4 kbps and a current resource level of 128 kbps. A node recevng a ROUTE REQUEST contanng one or more QoS Request Headers processes each QoS Request Header to determne whether or not the node can support a new flow wth resources at a level at least equal to the mnmum requested. If t s unable to support the mnmum requested resource level for any requested resource, the node slently dscards the ROUTE REQUEST. If t s unable to support the current level specfed n any QoS Request Header n the packet, the node modfes the header by

3 settng the current level equal to the maxmum resource level t can support, and then forwards the ROUTE REQUEST normally. A node able to support the current level specfed n all QoS Request Headers contaned n the packet forwards the ROUTE REQUEST packet normally wthout modfyng the QoS Request Header. We now consder the three common QoS metrcs of bandwdth, latency, and jtter. Wth the bandwdth metrc, a node forwardng a packet places n the current resource level the lesser of the resource level that t receved and ts own resource level. When a node wth 240 kbps of avalable bandwdth receves a REQUEST wth a current resource level of 640 kbps, t reduces the bandwdth level n the REQUEST before forwardng t. For the metrcs of latency and jtter, each node actually ncreases the latency and jtter specfed n the REQUEST, and therefore adds the local latency or jtter to the receved value. For example, f a node receves a REQUEST reflectng 20 ms of latency and 5 ms of jtter, and the node tself mposes ms of latency wth 3 ms of jtter, the REQUEST packet t forwards wll show 30 ms of latency and 8 ms of jtter. The QoS Request Headers n a ROUTE REQUEST only determne f the requested resources are avalable along the path, lmtng the Route Dscovery to return only paths that meet at least the mnmum levels of resources requested. A node that propagates a ROUTE REQUEST contanng QoS Request Headers may also temporarly reserve the resources specfed n the REQUEST n order to mprove the lkelhood that the resources wll stll be avalable when the flow begns usng ths route. One mportant problem n QoS-Guded Route Dscovery s determnng the resources avalable at any partcular node. These technques are beyond the scope of ths paper, but some earler work has addressed ths problem. For example, Maltz descrbes technques for measurng latency and avalable bandwdth [25]. Any technque used to measure avalable performance may themselves be manpulated by an attacker. In ths paper, we assume that such attacks can only reduce the measured avalable resources, and, n dong so, reduce actual avalable resources. For example, an attacker may reduce apparent bandwdth by unnecessarly reservng the medum through the use of excessve RTS and CTS packets [18, 2]; however, ths attack actually does reduce avalable bandwdth. A routng protocol usng QoS-Guded Route Dscovery can fnd sutable routes through the network. Once such a route s found, the routng protocol ether must reserve those resources for a flow, or t wll use that route on a best effort bass. For example, when the route s used on a best effort bass, a source mght use the route untl performance degrades to an unacceptable level, at whch pont t would re-ntate QoS-Guded Route Dscovery. Alternatvely, a protocol may allow a path establshment and resource reservaton protocol, n whch a source establshes a flow along that path by sendng an ESTABLISH FLOW packet along that path [16]. Each node along the path recevng the ESTABLISH FLOW packet reserves the resources needed by the flow and forwards the ESTABLISH FLOW packet to the next node on the path. When a node that has been forwardng traffc for a flow s no longer able to meet the QoS requrements of the flow, t sends a FLOW ERROR packet to the source of the flow. Though flow establshment requres two addtonal packet types, they are specfc to the routng protocol n use. In general, ESTABLISH FLOW packets can be authentcated ether through broadcast authentcaton (e.g., as descrbed n Secton 4.1), or through the use of parwse authentcaton usng shared keys between the source and each forwardng node. One of these two types of authentcaton s generally requred to secure other routng protocol messages. When each forwardng node can authentcate the source, t can use polcy to determne whether or not that source s authorzed to reserve these resources. In addton, FLOW ERROR packets can be authentcated n the same way as ROUTE ERROR packets used by on-demand routng protocols. For example, when used wth Aradne usng dgtal sgnatures, the ESTABLISH FLOW packet can be dgtally sgned by the source, so each forwardng node can ensure that the source s authorzed to make that reservaton; lkewse, each FLOW ERROR packet s dgtally sgned by the node orgnatng the ERROR, so the source can ensure that the ERROR was n fact sent by a node on the route. Because each routng protocol has dfferent key setup requrements and secures routng messages dfferently, we leave the securty of these control messages to the routng protocol; n the rest of the paper, we focus on securng the QoS-Guded Route Dscovery mechansm tself. 3. CRYPTOGRAPHIC MECHANISMS We desgn SQoS, our secure QoS routng protocol, by buldng on exstng securty mechansms. Specfcally, SQoS bulds on hash chans and MW-chans, whch we revew n ths secton. 3.1 HASH CHAINS One-way hash chans are a wdely used cryptographc prmtve. One of the frst uses of one-way chans was n one-tme password protocols [23, 14]. These chans are also used n other applcatons, such as effcent one-tme sgnature algorthms [12, 28, 27, 35]. Coppersmth and Jakobsson present effcent mechansms for storng and generatng values of hash chans [9]. We create a one-way chan by selectng the fnal value v n at random, and by repeatedly applyng a one-way hash functon H, such that v = H[v +1 ]. The last value generated n ths way s called the anchor; generally, an authentc anchor s publshed to allow verfcaton of hash chan elements. One-way chans have two man propertes (assumng H s a cryptographcally secure oneway hash functon): Anybody can authentcate that a value v j really belongs to the one-way chan, by usng an earler value v of the chan by checkng that H j (v j ) equals v. Gven the latest released value v of a one-way chan, an adversary cannot fnd a later value v j such that H j (v j ) equals v. Even when value v +1 s released, a second pre-mage collson resstant hash functon prevents an adversary from fndng v +1 dfferent from v +1 such that H[v +1 ] equals v. These two propertes result n authentcaton of one-way chan values: f the current value v belongs to the one-way chan, and we see another value v j wth the property that H j (v j ) equals v, then v j also orgnates from the same chan and was released by the creator of the chan. 3.2 THE MW CHAINS MECHANISM In ths secton, we revew the MW-chan mechansm [15], whch provdes nstant authentcaton and low storage overhead. Frst, we descrbe the one-tme sgnature, on whch MW-chans are based. In a sgnature, a node chooses a prvate key K, and from that prvate key generates a verfcaton key V. Gven a message m, the node can use K to form a sgnature s such that a node wth V can

4 verfy the sgnature; however, a node wth V but not K cannot generate a sgnature. A one-tme sgnature s a type of sgnature such that only one message m can be sgned wth a sngle key. For example, n the Merkle-Wnterntz one-tme sgnature, two sgnatures usng the same key provde an attacker enough nformaton to forge certan other sgnatures. The MW-chan s bult on a certan type of one-tme sgnature, whch we call a chanable sgnature. In a chanable sgnature, a sgnature s on message m can be verfed by comparng f (s,m) to verfcaton key V, and any verfcaton key can be used as a sgnature key. One such one-tme sgnature s the Merkle-Wnterntz sgnature. To buld an MW-chan of length l from a chanable sgnature, we pck a sgnng key K l. We then derve each sgnng key K as the publc key correspondng to sgnng key K +1. In partcular, f functon G generates a verfcaton key from a sgnature key, then K = G[K +1 ]. Snce G must be a secure one-way hash functon, an MW-chan has the same propertes of a hash chan, and has the addtonal property that a sgnature s usng key K +1 can be used to generate K usng the equaton K = f (s,m), but cannot be used to derve K MECHANISMS FOR SECURING QOS ROUTING Our key observaton for securng QoS routng s that propertes of nterest n the route dscovery and selecton are generally monotone; that s, the desrablty of a path decreases as more nodes are added. For example, the resources of bandwdth, latency, and jtter all are monotone. In ths paper, we desgn SQoS, a secure QoS routng protocol that enforces monotoncty and strct monotoncty n QoS metrcs, preventng an attacker from subvertng the correct operaton of the QoS routng. 4.1 BROADCAST AUTHENTICATION FOR ROUTE REQUEST PACKETS Our mechansms for secure QoS Route Dscovery requre the network to provde some form of broadcast authentcaton for the mmutable felds of ROUTE REQUEST packets; that s, any node that receves a ROUTE REQUEST packet must be able to ascertan that t was sent by the clamed ntator. Though ths authentcaton can be provded by a dgtal sgnature, the cost of verfyng a dgtal sgnature creates the possblty of a Denal-of-Servce (DoS) attack; n ths attack, an attacker floods a vctm node wth nvald ROUTE REQUEST packets, forcng the vctm to consume all of ts CPU tme attemptng to check the sgnatures on the REQUESTs. An alternatve to the use of dgtal sgnatures s to provde ths authentcaton usng an effcent, nstant broadcast authentcaton mechansm such as HORS [34]. In SQoS, however, ths authentcaton s ntegrated wth a mechansm that prevents excessve floodng. In partcular, snce QoS- Guded Route Dscovery requres a flood of the network and hence provdes a means for an attacker to perform a Denal-of-Servce attack (consumng all network resources), a secure ad hoc network routng protocol must enforce lmts on the frequency at whch each node can ntate such floodng. For example, Aradne [18] uses a hash chan to provde ths rate-lmt. Ths technque has two advantages. Frst, t allows any node to authentcate that a ROUTE REQUEST dd n fact orgnate from the ntator. Second, t uses only effcent symmetrc cryptography. However, ths technque does not prevent modfcaton of the felds of the REQUEST. We replace ths hash chan wth an MW-chan to prevent the modfcaton of the mmutable felds of the REQUEST. A node uses one MW-chan step for each Route Dscovery, and uses the sgnature from that MW-chan step to authentcate the mmutable felds of the ROUTE REQUEST. For example, f the MW-chan allows the authentcaton of 2 80 dfferent values, then an 80-bt one-way hash of the mmutable felds of the packet can be encoded as a sngle value authentcated usng ths MW-chan. An attacker attemptng to change any or all of these mmutable felds, then, wll have a 2 80 probablty of preservng the correctness of the sgnature. 4.2 ENFORCING MONOTONICITY To ensure monotoncty, the ntator of a QoS-Guded Route Dscovery creates a vrtual hash chan for each QoS metrc requested. Ths vrtual hash chan can be a tradtonal hash chan, as descrbed n Secton 3.1, a skpchan [15] (whch allows for more effcent authentcaton of large changes n metrc), or a hash tree chan [15] (whch enforce strct monotoncty, effectvely requrng each forwarder to change the QoS metrc). In the rest of ths secton, for smplcty, we wll descrbe SQoS usng a tradtonal hash chan; however, SQoS can also be used wth these other types of one-way chans. To generate ths hash chan, the ntal value (value farthest from the anchor) s chosen to authentcate the maxmum level of servce requested by ths QoS-Guded Route Dscovery for ths metrc. Each step n the hash chan authentcates one quanta, whch s the smallest dfference that can be represented for the authentcaton for that metrc. The hash chan s generated to represent each value between the maxmum level of servce (the ntally generated value) and the mnmum level of servce (the anchor) requested by the QoS-Guded Route Dscovery. For example, f an ntator s nterested n a range of bandwdth between 2.4 kbps and 56 kbps, and bandwdth s specfed n bts per second, the node generates a hash chan of length = Each step n ths chan represents 1 bps, such that the ntally chosen seed represents the 56 kbps level and the anchor represents the 2.4 kbps level. A ROUTE REQUEST packet ncludes the authentcator for the metrc currently clamed n that ROUTE REQUEST. When a node forwardng the REQUEST reduces the metrc clamed n the REQUEST, t hashes the authentcator accordngly; for example, f a node reduces the clamed bandwdth by 5 kbps, t apples the one-way hash functon 5000 tmes. Each anchor s ncluded n the Route Dscovery, sent wth broadcast authentcaton (as descrbed n Secton 4.1), allowng each recpent to authentcate each clamed QoS metrc. The quantzaton of nteger or fxed pont values s smpler than for floatng pont values. For example, the smallest step representable wth an nteger s 1, and the range of a 32-bt sgned nteger value s 2 32, whereas a 32-bt sgned floatng pont value n the IEEE 754 standard can represent a step as small as wth a range of We can overcome ths dffculty by usng a varable step sze; snce n bts can represent at most 2 n values, we conceptually sort all representable values, and correlate one step n a vrtual hash chan wth one element n ths conceptually sorted lst. Ths sortng can be acheved at low computatonal cost wth proper data representaton; for example, fnte postve numerc floatng pont values n the IEEE 754 standard can be converted nto ther nteger ranks by takng the 32-bt (or 64-bt) bnary representaton and

5 nterpretng the opaque bt values as f those bts represented an unsgned nteger. Even though hash functons are relatvely fast to compute, followng a hash chan of length 2 32 for each ROUTE REQUEST packet would provde an opportunty for Denal of Servce attacks based on floodng REQUESTs wth nvald metrc authentcators. To reduce the maxmum amount of effort needed to verfy any sngle metrc, SQoS uses a network-wde maxmum number of steps between the mnmum level of servce requred and the maxmum level that can be used. Instead of authentcatng the exact level of servce, only the current step s authentcated, though a more precse measurement s ncluded n the forwarded REQUEST. Snce SQoS authentcates only the step (as opposed to the exact metrc value), an attacker can change the metrc to any value wthn the same step. For example, for the metrc of bandwdth, the span from mnmum acceptable to maxmum usable could be as great as from 2.4 kbps to 2.4 Mbps for a conferencng applcaton. Dvded logarthmcally nto 200 steps, each step represents a factor of ncrease, and a node clamng a bandwdth of 125 kbps would nclude an authentcator vald for any bandwdth between kbps and 128 kbps. In general, for each metrc, the ntator specfes a mnmum level acceptable, a maxmum level usable, the number of steps between those two levels, and whether those steps are calculated lnearly or logarthmcally. To prevent an attack where a node uses maxmum-length chans for each of a number of metrcs, the network-wde maxmum can provde the maxmum number of steps summed across all metrcs. For example, f a total of 300 steps were allowed, a node may wsh to use 200 steps to represent bandwdth wth logarthmc steps and 0 steps to represent latency wth lnear steps. 4.3 LIMITING OVERHEAD OF QOS-GUIDED ROUTE DISCOVERY In QoS-Guded Route Dscovery, a forwardng node does not perform duplcate suppresson as standard Route Dscovery does. In standard Route Dscovery, nodes havng already forwarded a ROUTE REQUEST from a Route Dscovery gnore further REQUESTs from the same Dscovery. In QoS-Guded Route Dscovery, a node should only gnore a REQUEST f t has forwarded a better REQUEST. Ths rases three problems: An ntermedate node may not know whch tradeoffs between QoS metrcs are preferred by the source (e.g., does the source prefer 1 Mbps and 50 ms latency, or 2 Mbps and 75 ms latency?) An attacker can force a node to forward a large number of ROUTE REQUESTs by broadcastng a sngle REQUEST multple tmes, usng progressvely better metrcs. If a node forwards each better REQUEST, an exponental number of forwarded packets can result from a sngle Route Dscovery. The frst problem exsts because dfferent types of traffc demand dfferent lnk qualtes. For example, voce traffc may be very jtter-senstve, somewhat latency-senstve, and relatvely bandwdth nsenstve, whereas a bulk data transfer may be hghly bandwdth-senstve. A strct prorty amongst the QoS parameters may be mpractcal, snce vdeoconferencng software may be able to code vdeo and audo at several qualty (and hence bandwdth) levels but also desre low latency and jtter; preferrng bandwdth (and hence vdeo qualty) over the latency and jtter metrcs may result n a path wth suboptmal latency and jtter characterstcs, whereas optmzng latency and jtter may result n a bandwdth level that requres the use of a lower-qualty vdeo codec. Dependng on how ntermedate nodes n the node lst are authentcated, the second problem may or may not exst. In partcular, f a dgtal sgnature or other nstantly verfable broadcast authentcaton s used for node authentcaton, then each forwardng node can verfy that the ROUTE REQUEST has traversed the sequence of nodes lsted n the node lst. In ths case, an attacker can only play as many REQUESTs as t receves, because otherwse the authentcated REQUEST proves that the attacker s behavng malcously. However, f the node authentcaton s performed at the target, as n Aradne [18], an attacker can perform ths attack at wll. The thrd problem, however, s fundamental when forwardng latency of a ROUTE REQUEST packet at a node s not exactly correlated wth the ntator s route preference. For example, suppose there are n nodes n addton to the ntator and the target, arranged n n/2 groups of 2 nodes as shown n Fgure 1. Let group 0 represent the target and group n/2 + 1 represent the ntator. If these groups are arranged such that both nodes n group are neghbors of all nodes n groups 1, and + 1, of the other node n group, and of no other nodes. Then each node n group 1 would forward 1 REQUEST, for a total of 2 REQUESTs forwarded. If the node n group 1 wth the lowest level of resources was the frst to forward the REQUEST, then each node n group 2 would forward both REQUESTs, for a total of 4 REQUESTs forwarded. Agan, n the worst case, each node n group 3 would forward all 4 REQUESTs, for a total of 8 REQUESTs forwarded. In general, group would forward 2 REQUEST packets, for a total number of ROUTE REQUEST packet transmssons of n/2 2 = 2 n =0 SQoS solves all three problems by provdng the source wth control over whch ROUTE REQUESTs are re-forwarded. For example, a node can nclude an evaluaton functon n each REQUEST. Ths evaluaton functon can take the form of a functon selected from a lst, or can be more general, such as actve code, as has been proposed for Actve Networks [37]. Each evaluaton functon should take as nput the metrcs of nterest and a maxmum value, and should return an nteger between 0 and a maxmum value specfed n the REQUEST. A node then can forward an addtonal REQUEST only when the evaluaton functon returns a larger value than t dd the prevous tme, thus allowng each node to bound the number of tmes t forwards a REQUEST from any sngle Dscovery. To prevent a DoS attack where the attacker allows a REQUEST to be forwarded a large number of tmes, we can specfy as a network-wde parameter the maxmum number of REQUESTs that can be forwarded by a sngle node from a sngle Route Dscovery. Alternatvely, we can lmt the rate at whch REQUESTs can be forwarded for any partcular node; snce the maxmum return value of the evaluaton functon s authentcated, a node can gnore REQUESTs beyond a certan lmt. To prevent an attacker from specfyng extremely CPU ntensve programs, SQoS uses a language wth no loop or subroutne constructs, so that runtme s proportonal to program length. Other technques that can acheve the same result nclude the use of a sandbox that

6 Group 2 Group 4 Intator PSfrag replacements Target Group 1 Group 3 Fgure 1: Network topology used n countng ROUTE REQUESTs forwarded by each node lmts resource consumpton, or Proof Carryng Code [29] that ensures bounded runtme. 4.4 APPLICATION TO DSR To perform secure QoS-Guded Route Dscovery n on-demand source routed protocols such as DSR [20], and n secure versons of DSR such as Aradne [18], an ntator usng SQoS specfes a lst of metrcs of nterest, such as latency and bandwdth. For each metrc, the ntator ndcates the maxmum necessary level and mnmum desrable level, the length of the hash chan, and whether steps are to be dvded lnearly or logarthmcally. To authentcate these levels, hash chan anchors, and other felds of the ROUTE REQUEST, we add an authentcaton header to the REQUEST based on an MW-chan; a node s th Route Dscovery s sgned usng prvate key K, and snce Route Dscoveres flood the entre network, most nodes wll have already heard a sgnature usng the prevous key K 1. As a result, they need only follow one step n the MW-chan to verfy the sgnature, whch results n very effcent verfcaton. For example, n the topology shown n Fgure 2, a node S may ntate a ROUTE REQUEST to node D for a route to be used for a vdeoconference. Node S may want bandwdth between 64 kbps and 1.28 Mbps and may want latency between 0 ms and 200 ms. Node S may allocate 200 logarthmcally-dvded steps to bandwdth and 0 lnearly-dvded steps to latency, so each step of bandwdth represents a factor of 1.015, and each step of latency represents an addtonal 2 ms. It then bulds the hash chans for authentcatng bandwdth (h B ) and for authentcatng latency (hl ). For bandwdth authentcators, ntator S chooses h B 200 and the hash chan usng h B = H[h B +1 ]; t then chooses latency authentcator h L 0 and computes the hash chan hl = H[h L +1 ], as descrbed n Secton 4.2. The two anchors h B 0 and hl 0 are ncluded n the REQUEST packet. In addton, the ntator specfes some lmt to the number of REQUEST packets forwarded by any node as descrbed n Secton 4.3; for example, the ntator may want each node to forward at most 5 REQUESTs from ths Route Dscovery, and t may equally weght the 200 bandwdth and 0 latency steps. A smple postfx program that would acheve ths s 1 LOADSTEP 2 LOADSTEP 2 * + 5 * 400 /, where LOADSTEP s a unary operator that loads current step number of the th metrc, where s the nput value. For example, 1 LOADSTEP loads the step that the bandwdth s on; f the bandwdth level s 1.28 Mbps, whch corresponds to bandwdth step 200, 1 LOADSTEP results n the value 200 on the stack. The program above adds the bandwdth step number to twce the latency step number (snce there are a maxmum of 0) and scales the result to a value between 0 and 5. The ntator then sgns the REQUEST usng ts next MW-chan element. It then adds the current path bandwdth (1.28 Mbps) and latency (0 ms) and the authentcators for those values. It also adds a path lst, whch starts empty. Fnally, t broadcasts the resultng ROUTE REQUEST: S : [ROUTE REQUEST,D,, (Bandwdth,64000, ,200,Log,h B 0 ), (Latency,0,200,0,Lnear,h L 0 ), 5,(1 LOADSTEP 2 LOADSTEP 2 * + 5 * 400 /)] K, ,h B 200,0,hL 0,() As n DSR, each node keeps a table of ROUTE REQUEST packets t has prevously heard. However, unlke n DSR, MW-chan poston must be hard state to ensure securty; that s, f a node forgets ts MW-chan poston, the correct operaton of the protocol s jeopardzed. As a result, each node need store only nformaton from the most recent REQUEST ntated by each other node n the network. In addton to the MW-chan poston (whch replaces the dentfer) and ntator, the node stores three addtonal values: the maxmum output of the evaluaton functon (n ths case, 5), the output of the evaluaton functon for the REQUEST last forwarded from ths Route Dscovery, and a hash of the mmutable (sgned) felds of the header. Ths hash prevents an attacker from forgng multple REQUESTs usng an old MW-chan poston once the new MW-chan sgnature has been revealed. It also speeds up the verfcaton of the sgnature. When a node receves a REQUEST, t checks f t has receved a REQUEST wth ths or newer MW-chan poston and authentcates the sgnature. If the node has not prevously seen a REQUEST wth ths or newer MW-chan poston, t forwards the REQUEST and updates ts table of prevously heard REQUESTs. If a more recent REQUEST has been heard, ths REQUEST s dscarded; f a REQUEST from the same Route Dscovery has been heard, the node evaluates the new REQUEST accordng to the evaluaton functon n the packet. If the evaluaton functon returns a hgher value for ths new REQUEST than for the prevously forwarded REQUEST, t forwards ths REQUEST and also updates the table of prevously forwarded REQUESTs. For example, a node hearng the REQUEST above would check f t had heard REQUEST or larger. If t had not, t would authentcate the sgnature and evaluate the evaluaton functon, whch would return 5. The node would then

7 S A B C D Fgure 2: A Smple Example Ad Hoc Network Topology note that for ntator S t had forwarded REQUEST wth value 5 of a maxmum of 5. When forwardng a ROUTE REQUEST, a node reduces the QoS levels n the REQUEST to the levels that t can provde. For example, a node A whch adds 20 ms of latency and has 640 kbps of avalable bandwdth would reduce the above REQUEST to reflect a 640 kbps bandwdth (based on the maxmum of 640 kbps and 1.28 Mbps) and 20 ms latency (based on the sum of 0 ms plus 20 ms), as descrbed n Secton 2. It then computes the authentcators for bandwdth and latency h B 154 and hl 90, and forwards the ROUTE REQUEST: A : [ROUTE REQUEST,D,, (Bandwdth,64000, ,200,Log,h B 0 ), (Latency,0,200,0,Lnear,h L 0 ), 5,(1 LOADSTEP 2 LOADSTEP 2 * + 5 * 400 /)] K, ,h B 154,20,hL 90,(A) If node B, whch adds ms of latency and has 960 kbps of bandwdth capacty, forwards ths ROUTE REQUEST, t does not reduce bandwdth, snce t can support ths flow. However, t ncreases latency to 30 ms and computes authentcator h L 85. It also computes the evaluaton functon, for whch t receves a result of 4. It stores ths result n the table of forwarded REQUESTS, and forwards the ROUTE REQUEST: B : [ROUTE REQUEST,D,, (Bandwdth,64000, ,200,Log,h B 0 ), (Latency,0,200,0,Lnear,h L 0 ), 5,(1 LOADSTEP 2 LOADSTEP 2 * + 5 * 400 /)] K, ,h B 154,30,hL 85,(A,B) If node C, whch adds 15 ms of latency and has 240 kbps of capacty, forwards ths ROUTE REQUEST, t reduces bandwdth to 240 kbps and ncreases latency to 45 ms. The authentcators for bandwdth and latency become h B 89 and hl 78. Node C also computes the evaluaton functon, for whch t receves a result of 4. It stores ths result n the table of forwarded REQUESTS, and forwards the ROUTE REQUEST: C : [ROUTE REQUEST,D,, (Bandwdth,64000, ,200,Log,h B 0 ), (Latency,0,200,0,Lnear,h L 0 ), 5,(1 LOADSTEP 2 LOADSTEP 2 * + 5 * 400 /)] K, ,h B 89,45,hL 78,(A,B,C) Fnally, for each ROUTE REQUEST the target receves, t returns a ROUTE REPLY. Ths REPLY can be authentcated wth a key shared between the ntator and the target, or, f no such key exsts, the ntator and target can use Dffe-Hellman key exchange (or other key exchange that does not requre communcaton) to establsh a key. Snce we use MW-chan authentcaton to ratelmt the number of Route Dscoveres ntated by any node, an attacker would need to compromse a large number of nodes to overwhelm a vctm wth many legtmate REQUESTs for whch the vctm needs to establsh keys. In partcular, for the ROUTE REQUEST above, node D returns a ROUTE REPLY: D C : MAC KSD [ROUTE REPLY,,240000,45,(A,B,C)] Each node forwards the ROUTE REPLY towards the source. A complete executon of the secure QoS-Guded Route Dscovery protocol s shown n Fgure APPLICATION TO AODV The applcaton of secure QoS-Guded Route Dscovery to AODV [31], and to secure versons of AODV such as ARAN [36] and SAODV [39], s smlar to the applcaton to DSR and Aradne. We hghlght the dfferences here. Snce AODV does not mantan a source route n ts ROUTE REQUEST packets (called RREQs n AODV), secure QoS-Guded Route Dscovery also does not requre the source route. As a result, durng Route Dscovery, downstream nodes do not know the complete route that the RREQ followed, but nstead only know the address of the last node to forward the RREQ. Each node forwardng an RREQ keeps a table of the prevous hop for each RREQ that t has forwarded. We can use ths property to mprove routes even after an RREQ s forwarded, by modfyng the evaluaton functon to allow the return of fractonal values. An addtonal RREQ s forwarded for a Route Dscovery f the evaluaton functon appled to the new RREQ s at least 1 greater than for the prevously forwarded RREQ. If t s greater but not suffcently mproved, the prevous hop can be updated to reflect the new path, but only f each metrc of the new RREQ s at least as good as the forwarded RREQ. When AODV s used as the underlyng routng protocol, the ntator of the Route Dscovery s not provded wth the addresses of each forwardng node. As a result, authentcaton of a ESTABLISH FLOW packet must be performed usng broadcast authentcaton. Fortunately, the two proposed schemes for securng AODV [39, 36] both use broadcast authentcaton to secure other protocol messages, so our secure QoS-Guded Route Dscovery protocol can be used wthout any addtonal key setup. 5. EVALUATION To evaluate our protocol, we frst analyze the securty propertes t provdes. Then, to quantfy the costs of our scheme, we defne a publc-key based secure QoS-Guded Route Dscovery mechansm based on pror work n the related area of secure ad hoc network routng. We then compare SQoS to ths publckey system, whch we call the Publc Key Secure QoS Route Dscovery (PK-Squared), and show that SQoS sgnfcantly outperforms PK-Squared. 5.1 SECURITY ANALYSIS To analyze the securty acheved by our secure QoS-Guded Route Dscovery scheme, we examne the taxonomy of attacks

8 S : [ROUTE REQUEST,D,,(Bandwdth,64000, ,200,Log,h B 0 ),(Latency,0,200,0,Lnear,hL 0 ), 5,(1 LOADSTEP 2 LOADSTEP 2 * + 5 * 400 /)] K, ,h B 200,0,hL 0,() A : [ROUTE REQUEST,D,,(Bandwdth,64000, ,200,Log,h B 0 ),(Latency,0,200,0,Lnear,hL 0 ), 5,(1 LOADSTEP 2 LOADSTEP 2 * + 5 * 400 /)] K,640000,h B 154,20,hL 90,(A) B : [ROUTE REQUEST,D,,(Bandwdth,64000, ,200,Log,h B 0 ),(Latency,0,200,0,Lnear,hL 0 ), 5,(1 LOADSTEP 2 LOADSTEP 2 * + 5 * 400 /)] K,640000,h B 154,30,hL 85,(A,B) C : [ROUTE REQUEST,D,,(Bandwdth,64000, ,200,Log,h B 0 ),(Latency,0,200,0,Lnear,hL 0 ), 5,(1 LOADSTEP 2 LOADSTEP 2 * + 5 * 400 /)] K,240000,h B 89,45,hL 78,(A,B,C) D C : C B : B A : A S : MAC KSD [ROUTE REPLY,,240000,45,(A,B,C)] MAC KSD [ROUTE REPLY,,240000,45,(A,B,C)] MAC KSD [ROUTE REPLY,,240000,45,(A,B,C)] MAC KSD [ROUTE REPLY,,240000,45,(A,B,C)] Fgure 3: Secured QoS-Guded Route Dscovery provded by Hu et al [18] and Dahll et al [36]. In our analyss, we consder only the addtonal rsks posed by QoS-Guded Route Dscovery, and not those caused by the underlyng ad hoc network routng protocol. In partcular, because QoS-Guded Route Dscovery can be mplemented wth only one addtonal packet type (ESTABLISH FLOW), and because the authentcaton of that packet can generally be performed n the same way as for ROUTE REQUESTs, we gnore general routng attacks such as corrupted node lsts, wormhole attacks, routng message replay, spoofed sgnalng, fabrcated routng messages, routng loop formaton, and the partcpaton of unauthorzed nodes. We focus nstead on attacks specfc to the QoS-Guded Route Dscovery, and n partcular on unauthorzed modfcaton of QoS parameters. An attacker can attempt to be chosen as the preferred route by clamng more resources on paths that traverse the attacker. However, wth SQoS, an attacker s unable to clam sgnfcantly hgher resources than the path to the attacker; at most, an attacker can clam the maxmum amount of resources that are authentcated wth the step authentcator the attacker receved. For example, f an attacker receves an authentcator for bandwdth that can represent between and 128 kbps, and the actual bandwdth up to the attacker s 125 kbps, the attacker can at most clam slghtly less than 128 kbps. As a result, the dscovered resource level wll be the same as the actual resource level, plus or mnus the granularty of a step sze, except that any resource lmts at the attacker wll not be dscovered. Cryptographc mechansms generally cannot force the correct measurement of resources lmts at the attacker, snce the attacker can ntentonally measure resource lmts ncorrectly. Multple colludng attackers can forward metrc authentcaton data from the frst attacker on the path to the last attacker on the path, thus allowng the attackers to pretend that there s a drect lnk wth nfnte resources between each par of attackers. In general, an attacker can tunnel packets between nodes controlled by the attacker; SQoS does not defend aganst ths attack. 5.2 SECURING QOS-GUIDED ROUTE DISCOVERY USING PUBLIC KEY CRYPTOGRAPHY Awerbuch et al [1] proposed a secure routng protocol that uses dgtal sgnatures at each hop to ensure that the proper metrcs are added. In ther scheme, each node sgns ther address and updates the metrcs. Snce the metrc of each lnk s known to all nodes, any node can verfy the correct path metrc, assumng that all nodes on the path are correctly lsted. In ther protocol, a node forwards any ROUTE REQUEST packet reflectng a better path than the prevously forwarded REQUEST packets, whch, as descrbed n Secton 4.3, can n worst case result n an exponental number of ROUTE REPLY packets n response to a sngle Route Dscovery. We chose to use Awerbuch s scheme n our comparson because t s the only publshed secure ad hoc network routng protocol that fnds paths based on metrcs other than hop count and latency, and s thus readly modfed to ft the requrements of QoS-Guded Route Dscovery. We modfy Awerbuch et al s scheme to create PK-Squared, our publc-key based secure QoS-Guded Route Dscovery mechansm. In PK-Squared, each node sgns the current QoS metrc up to and ncludng tself. That s, each node specfes the cumulatve metrc for the subpath endng at that node. When forwardng a ROUTE REQUEST, the node retans the sgnatures of all the other hops on the path, and appends ts own sgnature. Snce our QoS metrcs are monotone, each node must clam a metrc not better than the prevous node s sgnature. A REQUEST not satsfyng ths property can be dscarded as malcous. When a node usng PK-Squared receves a ROUTE REQUEST, t checks to see f t has prevously heard a REQUEST from ths Route Dscovery wth a better path. If t has, then t slently dscards the REQUEST; otherwse, t authentcates each sgnature on the REQUEST (possbly consultng a cache to speed up the verfcaton of the ntator s sgnature). It then reduces the QoS parameters n the REQUEST, sgns the resultng REQUEST, and forwards t. 5.3 COMPARISON METHODOLOGY To compare the effcency of SQoS and PK-Squared, we tmed the operaton of the prmtves of SQoS and PK-Squared on a Moble Pentum 4 CPU runnng at 1.6 GHz, a processor commonly used n current laptop computers. Our PK-Squared operatons were based on 24-bt RSA, as mplemented n the Crypto++ lbrary. For a hash functon, SQoS uses the Rjndael block cpher [11] n the constructon standardzed by ISO/IEC 118-2, whch was orgnally proposed by Matyas, Meyer, and Oseas [26]. For our purposes, ths constructon results n the hash functon

9 Table 1: CPU Costs of SQoS Compared to PK-Squared on a 1.6 GHz Pentum 4 SQoS PK-Squared Intate Route Dscovery 885 µs 7669 µs Sgnature Overhead (bytes) Accept ntator sgnature 645 µs 401 µs Reject nvald sgnature 34 µs 401 µs Addtonal cost to accept l-hop REQUEST 573 µs (l 1) 401 µs Packet forward after verfcaton 0 µs 7669 µs Bytes added at each step Number of packets per dscovery 5n 2 n/2+1 Hop-Drop Attack Helps Attacker No Yes Metrc granularty 300 Steps Infnte H(x) = E K (x) x, where K s a well-known key. For tmng ths constructon, we bult our hash functon mplementaton on top of Gladman s mplementaton of Rjndael [13]. 5.4 RESULTS In SQoS, a node ntatng a Route Dscovery must sgn a REQUEST usng ts MW-chan. Ths sgnature requres 172 hash functons on average, or 322 µs on the 1.6 GHz Pentum 4, and the sgnature s 230 bytes. We also need to compute hash chans totalng at most 300 steps, whch takes up to 563 µs, for a total ntalzaton cost of 885 µs. By comparson, the sngle RSA sgnature requred by PK-Squared takes 7669 µs, and takes 128 bytes. Each node needs to verfy a Route Dscovery only once, after whch t can cache the hash of the mmutable felds of the REQUEST, whch makes verfcaton much faster. To verfy the ntator s sgnature n In SQoS, ths verfcaton takes 645 µs on average, whereas n PK-Squared, ths verfcaton s a 24-bt RSA verfy, whch takes 401 µs. However, rejectng an nvald sgnature n SQoS s much faster, snce SQoS uses 19 separate hash chans, any one of whch can be used to dscard the sgnature. As a result, an nvald sgnature takes only 34 µs (amortzed) to reject. In partcular, snce a correctly verfed hash chan element from an nvald sgnature can be cached, t speeds up the verfcaton of the next vald sgnature, and represents a cost whch would otherwse be a part of the next successful verfcaton. Once the frst REQUEST from a Route Dscovery has been verfed, SQoS requres only that a recever verfy up to 300 hash chan steps at a cost of up to 563 µs, and compute the evaluaton functon, whch we assume has bounded cost of µs. By contrast, PK-Squared requres the node verfy each sgnature on the path, for a total cost of (l 1) 401 µs when the path s of length l. When actually forwardng a REQUEST, a node usng SQoS has already followed all hash chans to ther anchors, and thus can use that precomputaton to generate the authentcators at no cost. By comparson, when forwardng a REQUEST n PK-Squared, a node must perform an RSA sgnature, at a cost of 7669 µs. Furthermore, a node forwardng a REQUEST usng SQoS ncreases the packet length by only the length of an address, whch n IPv4 s 4 bytes. In PK-Squared, the node must add ts address and ts sgnature, whch together are 132 bytes, n addton to any QoS metrc values whch t has changed, whch are needed to verfy prevous sgnatures. For example, f a node usng PK-Squared ncreases path latency from 20 ms to 30 ms, t must place the new 30 ms tme n the packet, but must also nclude the old 20 ms value, whch s needed to verfy prevous sgnatures. One type of attack aganst ad hoc network routng protocols s the hop drop attack, n whch a forwardng node removes a prevous node from the source route. In SQoS, ths hop drop attack s not prevented (although our scheme can be used together wth a protocol lke Aradne, whch does prevent hop drop), but t does not allow the attacker to clam a better metrc than t has. In partcular, snce the metrc authentcators are not ted to the node lst, droppng nodes from the node lst does not affect what metrcs the attacker can clam. By contrast, n PK-Squared, an attacker that drops a hop, partcularly a slow hop, can clam sgnfcantly better routes than a legtmate node that does not drop a hop. One beneft that the publc key scheme does have, however, s that t s capable of authentcatng unlmted metrc granularty, whereas our scheme allows only 300 steps. However, we beleve that 300 steps provdes a good tradeoff between performance and step granularty; n our example, we bounded bandwdth to wthn 1.5% and latency to wthn 2 ms. Table 1 summarzes our results. Fgure 4 shows the worst-case total CPU tme used for a Route Dscovery n a network where the topology s the topology descrbed n Secton 4.3 and llustrated n Fgure 1. In ths evaluaton, we have focused on the cost of the mechansm rather than on the performance of a system usng such a mechansm. The man reason for not performng ths evaluaton s that determnng the avalable resources at a node remans an open research challenge. In addton, Route Dscovery s relatvely rare, and we can mpose a lmt on the number of Route Dscoveres ntated by any node durng any tme perod, whch lmts the mpact of the addtonal overhead wthn each ROUTE REQUEST packet. Fnally, the addtonal overhead s qute small. In partcular, for each QoS metrc, we add a step count, step dvson (log or lnear) and authentcator, whch s at most 12 bytes. The postfx evaluaton functon language can be represented very compactly; f each operaton or small lteral (under 200) can be represented n one byte, then the evaluaton functon from Secton 4.4 can be represented wthn 13 bytes.