Rushing Attacks and Defense in Wireless Ad Hoc Network Routing Protocols

Transcription

1 Rushig Attacks ad Defese i Wireless Ad Hoc Network Routig Protocols Yih-Chu Hu Caregie Mello Uiversity yihchu@cs.cmu.edu Adria Perrig Caregie Mello Uiversity perrig@cmu.edu David B. Johso Rice Uiversity dbj@cs.rice.edu ABSTRACT I a ad hoc etwork, mobile computers (or odes) cooperate to forward packets for each other, allowig odes to commuicate beyod their direct wireless trasmissio rage. May proposed routig protocols for ad hoc etworks operate i a o-demad fashio, as o-demad routig protocols have bee show to ofte have lower overhead ad faster reactio time tha other types of routig based o periodic (proactive) mechaisms. Sigificat attetio recetly has bee devoted to developig secure routig protocols for ad hoc etworks, icludig a umber of secure odemad routig protocols, that defed agaist a variety of possible attacks o etwork routig. I this paper, we preset the rushig attack, a ew attack that results i deial-of-service whe used agaist all previous o-demad ad hoc etwork routig protocols. For example, DSR, AODV, ad secure protocols based o them, such as Ariade, ARAN, ad SAODV, are uable to discover routes loger tha two hops whe subject to this attack. This attack is also particularly damagig because it ca be performed by a relatively weak attacker. We aalyze why previous protocols fail uder this attack. We the develop Rushig Attack Prevetio (RAP), a geeric defese agaist the rushig attack for o-demad protocols. RAP icurs o cost uless the uderlyig protocol fails to fid a workig route, ad it provides provable security properties eve agaist the strogest rushig attackers. Categories ad Subject Descriptors: C.0 [Computer-Commuicatios Networks]: Security ad protectio; C.2.2 [Network Protocols]: Routig Protocols Geeral Terms: Security, Performace Keywords: Ad hoc etwork routig, security, routig, rushig This work was supported i part by NASA uder grat NAG3-2534, by NSF uder grat FD , by DARPA uder cotract N , by the Ceter for Computer ad Commuicatios Security at Caregie Mello uder grat DAAD from the Army Research Office, ad by a gift from Bosch ad Schlumberger. The views ad coclusios cotaied here are those of the authors ad should ot be iterpreted as ecessarily represetig the official policies or edorsemets, either express or implied, of NASA, USPS, NSF, DARPA, ARO, Bosch, Schlumberger, Caregie Mello Uiversity, Rice Uiversity, or the U.S. Govermet or ay of its agecies. Permissio to make digital or hard copies of all or part of this work for persoal or classroom use is grated without fee provided that copies are ot made or distributed for profit or commercial advatage ad that copies bear this otice ad the full citatio o the first page. To copy otherwise, to republish, to post o servers or to redistribute to lists, requires prior specific permissio ad/or a fee. WiSe 2003, September 19, 2003, Sa Diego, Califoria, USA. Copyright 2003 ACM /03/ $ INTRODUCTION A ad hoc etwork is a collectio of mobile computers (or odes) that cooperate to forward packets for each other to exted the limited trasmissio rage of each ode s wireless etwork iterface. A routig protocol i such a etwork fids routes betwee odes, allowig a packet to be forwarded through other etwork odes towards its destiatio. I cotrast to traditioal etwork routig protocols, for example for wired etworks, ad hoc etwork routig protocols must adapt more quickly, sice factors such as sigificat ode movemet ad chagig wireless coditios may result i rapid topology chage. This problem of routig i ad hoc etworks is a importat oe, ad has bee extesively studied. This study has resulted i several mature protocols [9, 20, 30, 32]. Ad hoc etworks are targeted at eviromets where commuicatig odes are mobile, or where wired etwork deploymet is ot preset or ot ecoomical. May of these applicatios may ru i utrusted eviromets ad may therefore require the use of a secure routig protocol. Furthermore, eve whe the presece of a attacker is ot forsee, a secure ad hoc etwork routig protocol ca also provide resiliece agaist miscofigured odes. I the curret Iteret, for example, miscofigured routig tables cotribute to the majority of routig istabilities [26]. Similarly, a software or hardware failure should cause oly the affected ode to fail, ad ot perturb the stability of routig i the remaider of the etwork. Missio or safety-critical etworks ca use secure ad hoc routig protocols so that cofiguratio errors, software bugs, or hardware failures do ot disturb routig at other odes. As a result, several secure ad hoc etwork routig protocols have bee proposed [6, 13, 16, 31, 36, 39, 45]. I this paper, we preset a ew attack, the rushig attack, which results i deial-of-service whe used agaist all previously published o-demad ad hoc etwork routig protocols. Specifically, the rushig attack prevets previously published secure o-demad routig protocols to fid routes loger tha two-hops (oe itermediate ode betwee the iitiator ad target). Because o-demad protocols geerally have lower overhead ad faster reactio time tha other types of routig based o periodic (proactive) mechaisms, o-demad protocols are better suited for most applicatios. To defed this importat class of protocols agaist the rushig attack, we develop a geeric secure Route Discovery compoet, called Rushig Attack Prevetio (RAP), that ca be applied to ay existig o-demad routig protocol to allow that protocol to resist the rushig attack. Our mai cotributios i this paper are the presetatio of the rushig attack, the developmet ad aalysis of our ew secure Route Discovery compoet that demostrates that it is possible to secure agaist the rushig attack, ad a geeral desig that uses this compoet to secure ay o-demad Route Discovery mechaism agaist the rushig attack. 30

2 iitiator target Figure 1: Example etwork illustratig the rushig attack. I Sectio 2 of this paper, we itroduce the rushig attack. Sectio 3 details our assumptios. Sectio 4 describes our Secure Neighbor Detectio ad Secure Route Discovery procedures, ad Sectio 5 presets two evaluatios of our Route Discovery compoet: a simulatio study of the performace of our mechaisms, ad a aalytical evaluatio that gives a coservative lower boud o the probability that our protocols discover a workig route whe subject to this attack. I Sectio 6, we discuss related work, ad i Sectio 7, we preset coclusios. 2. THE RUSHING ATTACK AGAINST AD HOC NETWORK ROUTING PROTOCOLS We itroduce here a ew attack, which we call the rushig attack, that acts as a effective deial-of-service attack agaist all curretly proposed o-demad ad hoc etwork routig protocols, icludig protocols that were desiged to be secure. I a o-demad protocol, a ode eedig a route to a destiatio floods the etwork with ROUTE REQUEST packets i a attempt to fid a route to the destiatio. To limit the overhead of this flood, each ode typically forwards oly oe ROUTE REQUEST origiatig from ay Route Discovery. I particular, existig o-demad routig protocols, such as AODV [32], DSR [20], LAR [23], Ariade [16], SAODV [45], ARAN [39], AODV secured with SUCV [6], ad SRP [31], oly forward the REQUEST that arrives first from each Route Discovery. I the rushig attack, the attacker exploits this property of the operatio of Route Discovery. We ow describe the rushig attack i terms of its effect o the operatio of DSR Route Discovery [18, 19, 20]; other protocols such as AODV [33], Ariade [16], SAODV [45], ad ARAN [39] are vulerable i the same way. I the etwork show i Figure 1, the iitiator ode iitiates a Route Discovery for the target ode. If the ROUTE REQUESTs for this Discovery forwarded by the attacker are the first to reach each eighbor of the target (show i gray i the figure), the ay route discovered by this Route Discovery will iclude a hop through the attacker. That is, whe a eighbor of the target receives the rushed REQUEST from the attacker, it forwards that REQUEST, ad will ot forward ay further REQUESTs from this Route Discovery. Whe o-attackig REQUESTs arrive later at these odes, they will discard those legitimate REQUESTs. As a result, the iitiator will be uable to discover ay usable routes (i.e., routes that do ot iclude the attacker) cotaiig at least two hops (three odes). I geeral terms, a attacker that ca forward ROUTE REQUESTs more quickly tha legitimate odes ca do so, ca icrease the probability that routes that iclude the attacker will be discovered rather tha other valid routes. Whereas the discussio above has used the case of odes that forward oly the first ROUTE REQUEST from ay Route Discovery, the rushig attack ca also be used agaist ay protocol that predictably forwards ay particular RE- QUEST for each Route Discovery. A rushig attacker eed ot have access to vast resources. Odemad routig protocols delay ROUTE REQUEST forwardig i two ways. First, Medium Access Cotrol (MAC) protocols geerally impose delays betwee whe the packet is haded to the etwork iterface for trasmissio ad whe the packet is actually trasmitted. I a MAC usig time divisio, for example, a ode must wait util its time slot to trasmit, whereas i a MAC usig carrier-sese multiple access, a ode geerally performs some type of backoff to avoid collisios; protocols like IEEE also impose a iterframe spacig time before trasmissio actually begis. Secod, eve if the MAC layer does ot specify a delay, o-demad protocols geerally specify a delay betwee receivig arequest ad forwardig it, i order to avoid collisios of the REQUEST packets. I particular, because REQUEST packets are broadcast, ad collisio detectio for broadcast packets is difficult, routig protocols ofte impose a radomized delay i RE- QUEST forwardig. A attacker igorig delays at either the MAC or routig layers will geerally be preferred to similarly situated o-attackig odes. Oe way to thwart a attacker that rushes i this way is to remove these delays at both the MAC ad routig layers, but this approach does ot work agaist all types of rushig attackers ad is ot geeral. For example, i a dese etwork usig a CSMA MAC layer, if a ode A iitiates a Route Discovery, ad B is two hops away from A,adC ad D are eighbors of both A ad B, the the B will likely ot receive the ROUTE REQUEST due to a collisio betwee REQUESTs forwarded by C ad D. I a dese etwork, such collisios may ofte prevet the discovery of ay otrivial routes (routes loger tha a direct lik), which is eve more severe tha the rushig attack, which prevets the discovery of routes loger tha two hops. Aother way that a relatively weak attacker ca obtai a advatage i forwardig speed is to keep the etwork iterface trasmissio queues of earby odes full. For example, if each ode processes the packets it receives i order, ad a iefficiet RE- QUEST autheticatio mechaism is used, the attacker ca keep other odes busy autheticatig REQUESTs cotaiig bogus autheticatio, thus slowig their ability to forward legitimate RE- QUESTs. Protocols employig public key techiques are particularly susceptible to these attacks, sice they require substatial computatio to validate each received REQUEST. A relatively weak attacker ca also achieve faster trasit of its REQUEST packets by trasmittig them at a higher wireless trasmissio power level, thus reducig the umber of odes that must forward that REQUEST to arrive at the target. Sice packet trasit time at each hop is domiated by the processig time at the forwardig ode, reducig the path to the target by just oe hop is likely to provide a sigificat latecy advatage, thus stregtheig the attackers positio. A more powerful rushig attacker may employ a wormhole [14] to rush packets. I this case, the attacker simply forwards all cotrol packets (but ot data packets) received at oe ode (the attacker) to aother ode i the etwork (e.g., a secod attacker). This forms a tuel i the etwork, where packets reachig oe ed of the tuel are broadcast out the other ed. If the tuel provides sigificatly faster trasit tha legitimate forwarders, odes ear oe ed of the tuel geerally will be uable to discover workig routes to the other ed of the tuel, sice it will geerally discover routes through the tuel. I geeral, a wired tuel (i which the two attackers have a wired coectio betwee themselves) will provide faster trasit tha ative wireless (multihop) forwardig, sice 31

3 ode processig delay i forwardig is much loger tha the propagatio time. The rushig attack applies to all proposed o-demad protocols because such protocols must limit the umber of packets that ay ode will trasmit i respose to a sigle Route Discovery. Curretly proposed protocols choose to forward at most oe REQUEST for each Discovery; ay protocol that allows a attacker to predict which ROUTE REQUEST(s) will be chose for forwardig at each hop will be vulerable to some variat of the rushig attack. 3. ASSUMPTIONS 3.1. Network Assumptios We make the commo assumptio that most etwork liks are bidirectioal. More specifically, we require that the etwork remai coected whe uidirectioal liks are igored. Our Secure Neighbor Detectio protocol rejects uidirectioal liks, so uderlyig routig protocols ca assume that the etwork is free of uidirectioal liks. If aother Secure Neighbor Detectio techique is used, ad that techique supports uidirectioal liks, the the ability of our Secure Route Discovery mechaism to discover ad use uidirectioal liks is limited oly by the uderlyig routig protocol. Wireless physical layers for sedig data from oe ode to aother are ofte vulerable to jammig. Mechaisms such as spread spectrum modulatio [37], or directioal ateas have bee extesively studied as meas of improvig resistace to physical jammig. I additio, a effective jammig attack usually requires additioal hardware; i cotrast, a rushig attack is much simpler to do because the attacker ca use the same hardware as legitimate odes. A attacker ca eve remotely break ito a legitimate ode ad perform these attacks. Moreover, the rushig attack allows for far more selective deial-of-service, ad is thus harder to detect. Jammig attacks are relatively broad (they dey service to a large umber of participats) ad are thus also easier to detect. Though a jammig attack is also a importat deial-of-service attack, we preset mechaisms to defed agaist the rushig attack because we believe that the rushig attack is more easily performed. Medium Access Cotrol protocols are also ofte vulerable to attack. For example, i IEEE , a attacker ca paralyze odes i its eighborhood by sedig Clear-To-Sed (CTS) frames periodically, settig the Duratio field of each frame equal to the iterval betwee such frames [16]. Less sophisticated Medium Access Cotrol protocols, such as ALOHA ad Slotted ALOHA [1], are ot vulerable to such attacks but have lower efficiecy. I this paper, we disregard attacks o Medium Access Cotrol protocols. Prior work has show that ad hoc etwork routig i geeral does ot scale well [10]. Most existig simulatio of ad hoc etwork routig protocols cosider scearios of 50 to 500 odes. I this work, we focus o such medium-sized etworks, ad will ot cosider scalability issues; however, we believe that mechaisms such as clusterig, which improve the scalability of other o-demad ad hoc etwork routig protocols, ca also improve the scalability of our approach Security Assumptios ad Key Setup The protocols discussed i this paper require a istatly-verifiable broadcast autheticatio protocol, for which we use a digital sigature. However, ay sigature used should be able to keep up with verificatio at lie speed, to avoid a deial-of-service attack where a attacker overwhelms the victim by floodig it with bogus messages. Oe example of a protocol which should be fast eough o may odes is the the HORS oe-time sigature by Reyzi ad Reyzi [38]. We use the costructios of the BiBa [35] oe-time sigature i cojuctio with the HORS oe-time sigature to desig a efficiet istatly-verifiable broadcast autheticatio protocol. We also use a Merkle hash tree [28] to geerate oe sigature over multiple messages, such that each message is idepedetly verifiable. As used i our simulatio evaluatio, HORS requires a average of 156,760 hashes per secod to sig ad verify all messages i a 100 ode etwork, a rate easily achievable eve by PDAs. We assume that the keys ecessary for broadcast autheticatio are distributed i advace; a umber of techiques for distributig such iformatio have bee proposed [2, 16, 17, 24, 42, 46]. To escape the circular depedecy of secure routig ad key distributio, Hu et al propose a simple routig protocol that discovers a route to a trusted third party, which ca i tur bootstrap the iitial keys [16]. If a wormhole attack, i which a attacker selectively tuels packets from oe place i the etwork to aother, is cosidered a possible threat, our Secure Neighbor Detectio requires a mechaism to detect such a tuel betwee ay two legitimate odes. A umber of mechaisms for prevetig the wormhole attack, such as TIK, geographical leashes ad RF watermarkig, have bee proposed. Depedig o the mechaism used to implemet packet leashes, this requiremet beefit other parts of the protocol: TIK [14], for example, autheticates each packet i a lightweight maer, thus protectig the more expesive sigature verificatio from a deial-of-service attack. I particular, if a ode A receives a autheticated packet cotaiig a bogus sigature from ode B, the A ca lower the priority with which it checks sigatures set by B. As a result, a attacker ca oly cause each ode to verify oe bogus sigature for each ode compromised by that attacker. We do ot assume tamper-proof hardware; the attacker ca thus compromise odes ad steal their cryptographic keys. We assume a powerful attacker, which we call coordiated attacker. Thisisa attacker that compromised multiple odes (ad thus kows all their cryptographic keys), with a fast chael to route packets amogst themselves. 4. SECURE ROUTING REQUIREMENTS AND PROTOCOL I this sectio, we describe a set of geeric mechaisms that together defed agaist the rushig attack: secure Neighbor Detectio, secure route delegatio, adradomized ROUTE REQUEST forwardig. We also describe a techique to secure ay protocol usig a o-demad Route Discovery protocol. I previous o-demad protocols, ode B cosiders ode A to be a eighbor whe B receives a broadcast message from A. Secure Neighbor Detectio, which replaces stadard Neighbor Detectio, allows each eighbor to verify that the other is withi a give maximum trasmissio rage. Oce a ode A forwardig a ROUTE REQUEST determies that ode B is a eighbor (that is, is withi the allowable rage), it sigs a Route Delegatio message, allowig ode B to forward the ROUTE REQUEST. Whe ode B determies that ode A is withi the allowable rage, it sigs a Accept Delegatio message. Radomized selectio of the ROUTE REQUEST message to forward, which replaces traditioal duplicate suppressio i o-demad route discovery, esures that paths that forward REQUESTs with low latecy are oly slightly more likely to be selected tha other paths. Figure 2 shows the basic desig of our complete rushig attack prevetio mechaism. 32

4 Yes Sigle-Hop? No Gather REQUESTs; radomly choose 1 Secure Neighbor Detectio Origial Routig Protocol Figure 2: Our combied mechaisms to secure a o-demad route discovery protocol agaist the rushig attack Notatio We use the followig otatio: A or B deote commuicatig odes. A : η R {0,1} l deotes that ode A radomly selects a l-bit log oce η. A B : M,H(A η) meas that ode A seds B the message M ad the hash of A s idetifier cocateated with the oce η. A : M,Σ M meas that ode A broadcasts message M with its sigature Σ M Secure Neighbor Detectio Oe simple istace of the rushig attack is whe a attacker forwards a ROUTE REQUEST beyod the ormal radio trasmissio rage (for example by usig a higher gai atea or a higher power level), thus suppressig subsequet REQUESTs from this Route Discovery. I this sectio, we preset a secure Neighbor Detectio protocol that allows both the seder ad the receiver of a ROUTE REQUEST to verify that the other party is withi the ormal direct wireless commuicatio rage. The fuctioality of Neighbor Detectio, i which two odes detect a bidirectioal lik betwee themselves, is preset i some form i almost every routig protocol. For example, a ode participatig i a periodic protocol geerally broadcasts advertisemets, allowig its eighbors to detect it. Most o-demad routig protocols, o the other had, perform Neighbor Detectio implicitly. I those protocols, a ode receivig a ROUTE REQUEST cosiders itself to be a eighbor of the previous-hop ode that trasmitted the REQUEST. Whe that ode propagates the REQUEST, it claims a lik betwee the trasmitter ad the recipiet. Ufortuately, this implicit Neighbor Detectio does ot prevet a attacker ode receivig a REQUEST from simply replayig it. I additio, if the address of the previous-hop ode is uautheticated, a attacker ca claim to be ay ode propagatig a REQUEST, ad the ext hop will trust that iformatio (we call this the repeater attack). This repeater attack is serious, because two odes that are ot withi commuicatio rage believe that the other is is its eighbor, givig the attacker the ability to selectively forward packets betwee the two odes. The repeater attack is a istace of a wormhole attack [15]. Requiremets for Secure Neighbor Detectio. Two odes detect each other as eighbors oly if they ca commuicate ad they are withi some maximum trasmissio rage. The secure Neighbor Detectio protocol thus prevets a attacker from: (1) itroducig two odes that are ot withi the maximum trasmissio rage as eighbors; ad (2) claimig that it is a eighbor of aother ode without beig able to hear packets directly from that ode. From the first requiremet, it follows that a attacker should ot be able to tuel a eighbor solicitatio from oe compromised ode to aother ucompromised ode. The secod requiremet demads that a ode (or a accomplice of that ode) eeds to hear the eighbor solicitatio, sice otherwise it caot claim to be a eighbor. Fially, the protocol should ot itroduce a deial-of-service opportuity; for example, floodig a ode with eighbor requests should ot cosume all CPU resources of that ode. Our Secure Neighbor Detectio Protocol. We preset a secure Neighbor Detectio protocol that allows both the iitiator ad the respoder to check that the other is withi a maximum commuicatio rage. Assumig egligible MAC protocol delays, we desig a simple three-roud mutual autheticatio protocol that uses tight delay timig to esure that the other party is withi commuicatio rage. I the first roud, the iitiatig ode seds a Neighbor Solicitatio packet, either by uicastig that packet to a specific eighbor, or by broadcastig the packet. Next, a ode receivig the Neighbor Solicitatio packet seds a Neighbor Reply packet. Fially, the iitiator seds a Neighbor Verificatio, which icludes broadcast autheticatio of a timestamp ad the lik from the source to the destiatio. Figure 3 shows a example of the protocol. If a ode wishes to detect multiple eighbors, it must request a respose from each eighbor, ad must iitiate Neighbor Detectio with each eighbor separately, i order to avoid a implosio of Neighbor Reply packets. To esure freshess of the reply messages, we use oces η 1 ad η 2. The iitiator picks η 1 at radom (of sufficiet legth that a attacker has a egligible probability of guessig it) ad is thus certai that the reply message is fresh if the received oce matches η 1. The measured delay betwee sedig the first message ad receivig the secod message provides a upper boud o the distace of the eighbor: give delay, the eighbor ode is o farther away tha /2 c, wherec is the speed of light. This is accurate if a ode ca quickly process the first message ad retur a autheticated secod message; for example, if HORS is used for autheticatio, a ode eed oly perform oe hash fuctio to autheticate the reply. The autheticatio o message M 2 esures to the iitiator that the respose ideed comes from the correct respoder. I the geeral case, we use the same digital sigature for autheticatio, but if the two odes share a secret key, we ca also use a message autheticatio code for this purpose, for example HMAC [4]. Similarly, the oce η 2 ad the sigature o message M 3 esure to the respoder that the iitiator is withi trasmissio rage if message M 3 arrives after a sufficietly short delay. Fially, we rate-limit New Neighbor Solicitatios to prevet a attacker from floodig its eighbors. Figure 3 shows the full protocol. Itegratio with a O-Demad Protocol. I a o-demad protocol, eighbor verificatio is performed durig each Route Discovery. As a result, we ca defed agaist New Neighbor Solicitatio floods, by relyig o the uderlyig protocol to defed agaist ROUTE REQUEST floods; a ode respods to ay New Neighbor Solicitatio preseted with a valid REQUEST. If desired, REQUEST flood prevetio ca be achieved through the use of a hash chai, 33

5 R S : η 1 {0,1} l M 1 = NEIGHBOR SOLICITATION,S,η 1 Σ M1 = Sig(H(M 1 )) S : M 1,Σ M1 R R : η 2 {0,1} ( l) M 2 = NEIGHBOR REPLY,S,R,η 1,η 2 ) Σ M2 = Sig(H(M 2 )) R S : M 2,Σ M2 S : M 3 = NEIGHBOR VERIFICATION,S,R,η 1,η 2 Σ M3 = Sig(H(M 3 )) S R : M 3,Σ M3 Figure 3: Neighbor Detectio betwee iitiator S ad respoder R. as i Ariade [16]. I particular, i Ariade, each ode maitais a hash chai, ad uses elemets of the hash chai to autheticate the flooded REQUEST. These hash chai values provide cheap autheticatio, ad a victim receivig too may Route Discoveries from a attacker ca rate-limit forwardig of that attacker s RE- QUESTs. I RAP, we ca istead use HORS or ay other efficiet autheticatio mechaism with this rate limitig, to prevet excessive floodig. Whe a ode A forwards a REQUEST, it icludes i that RE- QUEST a broadcast Neighbor Solicitatio. Each ode B forwardig that REQUEST returs a Neighbor Reply, ad piggybacks o the Neighbor Reply a uicast Neighbor Solicitatio for A. IfA decides that B is a eighbor based o the wormhole prevetio mechaism used, A returs a siged Neighbor Verificatio that verifies the lik from A to B. A also icludes i packet a Neighbor Reply to the uicast Neighbor Solicitatio set by B. If B decides that A is a eighbor based o the wormhole prevetio mechaism used, B forwards the REQUEST, icludig the Neighbor Verificatio for the A B lik siged by A, ad also icludig a Neighbor Verificatio for the B A lik siged by itself. B eed ot retur a Neighbor Verificatio, sice A is likely to hear the forwarded REQUEST, which icludes the B A Neighbor Verificatio. Figure 4 shows how B forwards a REQUEST from A Secure Route Delegatio I our ROUTE REQUEST propagatio, we wat to eable each ode to verify that all the secure Neighbor Detectio steps were performed betwee ay adjacet pair of odes i the REQUEST, i.e., verify that both odes of each adjacet ode pair ideed believes to be a eighbor. We achieve this property through a Secure Route Delegatio mechaism, which is ispired by the work of Ket et al. i S-BGP [21, 22]. S-BGP uses Route Attestatios to esure that each Autoomous System (AS) listed i the BGP AS path is ideed a valid AS. I S-BGP, before sedig a route update to its eighbor, the AS sigs a route attestatio delegatig it the right to further propagate the update. We use this mechaism to eable the odes to verify that all the secure eighbor detectio protocols were executed ad that both eighbors believe that they are withi trasmissio rage. We describe the protocol based o a example. Cosider two eighborig odes A ad B, where A received the curret ROUTE RE- QUEST origiatig from ode S destied for ode R with the sequece umber id. Node A egages i the secure eighborig detectio protocol ad fids after the secod message that B is ideed withi rage, so it delegates the ROUTE REQUEST to B as follows: M A = ROUTE DELEGATION,A,B,S,R,id Σ MA = Sig(H(M A )) A B : Σ MA Node A does ot eed to sed the message to B, as B ca recostruct all the fields of the message ad verify the sigature. The ROUTE DELEGATION message ca be budled together with the last message of the secure Neighbor Detectio protocol. If B believes that A is ideed a eighbor withi rage, B will accept the ROUTE DELEGATION, cotiue the protocol, ad sig aother ROUTE DELEGATION with the ext eighbor Radomized Message Forwardig The secure Neighbor Detectio ad secure Route Delegatio techiques are ot sufficiet to thwart the rushig attack, sice a adversary ca still get a advatage by forwardig ROUTE REQUESTs very rapidly. We use a radom selectio techique to miimize the chace that a rushig adversary ca domiate all retured routes. I traditioal ROUTE REQUEST forwardig, the receivig ode immediately forwards the REQUEST ad suppresses all subsequet REQUESTs. I our modified floodig, a ode first collects a umber of REQUESTs, ad selects a REQUEST at radom to forward. There are thus two parameters to our radomized forwardig techique: first, the umber of REQUEST packets to be collected, ad secod, the algorithm by which timeouts are chose. Give perfect iformatio, each forwardig ode would collect the maximum possible umber of REQUESTs before forwardig oe, sice this approach provides the most effective defese agaist a rushig attack. However, whe the umber of REQUESTs is chose to be too large, radomized forwardig will heavily rely o the timeout totrigger REQUEST forwardig, icreasig latecy ad possibly reducig security. I a real etwork, perfect iformatio is geerally ot available; as a result, iitiators ca iclude i each Route Discovery the umber of REQUESTs to buffer before forwardig oe, ad ca adjust this parameter adaptively, based o the REPLY latecy ad o the parameters chose by other odes. Alteratively, this umber ca be chose as a global parameter, or locally usig a adaptive algorithm, though a adaptive algorithm may allow certai ew attacks. Whe perfect topology iformatio is available, the choice of timeout should be based o the umber of legitimate hops betwee the iitiator ad the ode forwardig the REQUEST; closer odes should choose shorter timeouts tha far-away odes. This topological iformatio ca be approximated by locatio iformatio; that is, odes that are geographically closer should choose smaller timeouts tha odes that are geographically farther away. Whe geographic iformatio is ot available, odes ca radomly choose timeouts; sroutig.tex however, this approach reduces security by favorig odes choosig shorter timeouts. ======= however, this approach reduces security by favorig odes choosig shorter timeouts Secure Route Discovery I this sectio, we describe our secure route discovery protocol. We use three techiques i cocert to prevet the rushig attack: our secure Neighbor Discovery protocol, our secure Route Delegatio ad delegatio acceptace protocol, ad radomized selectio of which ROUTE REQUEST will be forwarded. The ituitio behid Secure Route Discovery is to make the forwardig of REQUEST packets less predictable by bufferig the first REQUESTs received, the radomly choosig oe of those RE- QUESTs. However, we eed to prevet a attacker from fillig too may of these REQUESTs, sice otherwise the attacker could simply rush copies of a REQUEST, rather tha a sigle REQUEST,ad 34

6 R A : η A {0,1} l M 1a = ROUTE REQUEST,id,... M 1b = NEIGHBOR SOLICITATION,A,η A Σ M1 = Sig(H(M 1a M 1b )) A : M 1a,M 1b,Σ M1 R B : η B {0,1} l M 2a = NEIGHBOR REPLY,A,B,η A,η B Σ M2 = Sig(H(M 2a )) B A : M 2a,M 2b,Σ M2 A : M 3a = NEIGHBOR VERIFICATION,A,B,η A,η B Σ M3a = Sig(H(M 3a )) M 3b = ROUTE DELEGATION,A,B,S,R,id Σ M3b = Sig(H(M 3b )) A B : M 3a,Σ M3a,M 3b,Σ M3b B : η R B {0,1} l M 4a = ROUTE REQUEST,id,...,Σ M3b,Σ M4a... M 4b = NEIGHBOR SOLICITATION,B,η B Σ M4 = Sig(H(M 4a ) H(M 4b )) B : M 4a,M 4b,Σ M4 Figure 4: B forwardig the REQUEST from A. Σ M2 ca be geerated usig a shared key, if available. The ROUTE REQUEST i M 4a icludes the bidirectioal Neighbor Verificatio messages M 3a ad M 4c, together with the ecessary autheticators (H(M 3b ) ad Σ M3 ). The use of H(M 3b ) i Σ M3 allows the verificatio of M 3a without eedig M 3b, which decreases the overhead caused by the REQUEST packet. The same techique is used i creatig Σ M4. our scheme would oce agai be vulerable to the rushig attack. To limit the umber of REQUESTs that traverse a attacker, we exploit the fact that legitimate odes forward oly oe REQUEST i ay Discovery. First, we require that each REQUEST carry a list of odes traversed by this REQUEST. Secod, we require a bidirectioal Neighbor Verificatio for each lik represeted by this list of odes, for a total of two siged Neighbor Verificatios per hop. Third, to autheticate the ode list, we require each ode to autheticate the REQUEST it forwards, though it ca piggyback this autheticatio together with the Neighbor Verificatio that it sigs. Fially, we require buffered REQUESTs be duplicate-suppressiouique: that is, if the route record of ay two REQUESTs cotai ay ode A, the route prefix leadig up to (ad icludig) A must be the same. These three requiremets costrai a attacker to the extet that a attacker that has compromised m odes ca rush at most m REQUESTs. To prevet replay of old Neighbor Verificatio messages, each message is tied to a specific Route Discovery. Specifically, whe a ode S seds a Neighbor Verificatio for the lik from S to R, S sigs ot just S ad R (as i Figure 3), but also ties a uique Route Discovery idetifier to the Neighbor Verificatio. For example, i AODV, the RREQ ID ad Origiator IP Address i a RREQ form a uique idetifier; i DSR, the Target Address ad Idetifier fields from a ROUTE REQUEST, together with the IP Source Address, form a uique idetifier. To address wraparoud i these Idetifier fields, if the odes i the etwork have very loosely sychroized clocks (withi a few days), the ode ca iclude a timeout i additio to this uique idetifier. If etwork odes have more tightly sychroized clocks (withi a few secods), the ode ca iclude a timeout i place of ay uique idetifier. I some areas of some etworks, a ode will ot have distict paths to the source of the REQUEST. To eable the Discovery of routes to or through such odes, we allow a ode to forward a REQUEST after some time, eve if it has ot yet received REQUESTs. I certai cases, however, a fixed timeout allows a attacker to prevet the discovery of a correct route. Oe way to avoid such a attack is to choose a radom timeout betwee t mi ad t max. Alteratively, we ca prefer early release whe a ode has buffered more REQUESTs, for example by choosig a radom timeout betwee t mi +( j)t add ad t max +( j)t add, where j is the umber of REQUESTs buffered so far. Choosig a timeout whe locatio iformatio is available ca provide better properties. If the iitiator of each REQUEST icludes a timestamp t ad its locatio, itermediate odes ca choose a timeout of t +fixed timeout+propagatio speed distace to iitiator. After a ode chooses a timeout, either radomly or based o optioal locatio iformatio, the ode radomly chooses oe received RE- QUEST for forwardig. We implemet two additioal security optimizatios to this basic scheme. I geeral, these optimizatios are based o usig the property of orepudiatio to spread iformatio about malicious odes. First, we require that each REQUEST be siged by the forwardig ode. A ode detectig a attacker forwardig more tha oe REQUEST ca expose the attacker by floodig the two RE- QUESTs. Secod, if locatio iformatio is available, ad used for example to implemet geographic packet leashes, a attacker claimig to be i two places at the same time ca be blacklisted i the same way. For example, if each REQUEST icludes i the ode list locatio iformatio ad time iformatio for each forwardig ode, a ode ca keep a database of previous locatio iformatio, ad fid two locatio claims that sigificatly exceed the maximum speed achievable by legitimate odes. I particular, if locatio iformatio is accurate to δ, ad time iformatio is cosistet to, ad maximum speed is ν, the two locatios claimed t time apart is maliciously claimed if the distace betwee the two locatios is greater tha 2δ + ν(t + 2 ). Our blacklist mechaisms do ot eed autheticatio, sice the orepudiatio of cotradictig iformatio ca be ca be verified by ay odes. We route blacklist iformatio by floodig: cotradictory iformatio is rebroadcast by ay ode that verifies the orepudiatio ad did ot have this malicious ode o its blacklist. This approach is similar to the blacklist mechaism used by Ariade [16] Itegratig Secure Route Discovery with DSR To itegrate rushig prevetio with DSR [18] or other secure protocols based o DSR, we limit Route Discovery frequecy as i Ariade [16]. Each time a ode forwards a ROUTE REQUEST, it first performs a Secure Neighbor Detectio exchage with the previous hop. Whe it forwards the REQUEST, it icludes i the RE- QUEST a bidirectioal Neighbor Verificatio for the previous hop. As i DSR, the target of a Route Discovery returs a ROUTE REPLY for each distict ROUTE REQUEST it receives. Each such ROUTE REPLY is set with a source route selected by reversig the route i the ROUTE REQUEST. This route is likely to work if there are o attackers o the route, sice Neighbor Detectio oly fids bidirectioal eighbors Itegratig Secure Route Discovery with AODV I AODV [33], as well as other secure protocols based o AODV [6, 39, 45], Route Request (RREQ) packets do ot carry a ode list. However, i order to filter excessive malicious RREQs, we require each RREQ to carry a ode list. Istead of forwardig the first RREQ received, odes usig our Secure Route Discovery radomly select oe of the first RREQs it receives ad treats it as the RREQ 35

7 to forward. More specifically, it places the iitiator of the Route Discovery i its routig table usig the previous hop of the RREQ selected as the ext-hop destiatio. It the appeds its address ad autheticatio iformatio to the ode list, ad forwards it as i DSR. Sice AODV is a distace-vector protocol, it caot make use of multiple routes. As a result, the target of a Route Discovery also waits for RREQ packets before returig a sigle RREP. The target sigs the RREP, ad icludes i the RREP eighbor autheticatio for each hop i the chose path. This autheticatio allows odes forwardig the RREP to autheticate the etire path back to the source of the RREP. Each ode autheticatig this iformatio establishes a route back to the source of the RREP (the target of the RREQ). Whe this RREP reaches the destiatio, it will have established a bidirectioal route betwee the iitiator ad target of theroutediscovery. Because AODV does ot support multiple routes, the security properties of AODV usig Secure Neighbor Discovery will be somewhat worse tha the properties of DSR usig Secure Neighbor Discovery Itegratig Secure Route Discovery with Secure Ad Hoc Network Routig Protocols Whe usig our rushig attack prevetio together with a secure o-demad routig protocol, a ode ca first attempt Route Discovery usig that secure protocol. If a rushig attacker prevets the discovery of ay workig routes, the ode ca the set a flag idicatig that it wats to use rushig attack prevetio, though it must also autheticate that flag to prevet modificatio. This approach is similar to the priciple of expadig rig search: first, a ode uses a cheaper, but sometimes usuccessful, search. The ode oly uses a more expesive search whe the cheaper search does ot fid a route. This optimizatio provides beefits i two cases: first, whe there are o rushig attackers, existig secure routig protocols should be able to fid a route. Secodly, a rushig attacker does ot have ay advatage i oe- ad two-hop routes. 5. EVALUATION To evaluate our techiques, we aalyzed the cost ad effectiveess through simulatio ad aalysis. Our simulatio was desiged to show the cost of our techiques i a o-adversarial eviromet, whereas our aalytical evaluatio shows provable bouds o the extet to which a attacker ca disrupt a protocol usig our techiques Simulatio Evaluatio To evaluate the overhead of usig our secure eighbor discovery mechaism i a o-adversarial eviromet, we simulated our scheme usig the s-2 simulator, usig Ariade [16] as our uderlyig routig protocol. We call this modified protocol RAP (Rushig Attack Prevetio). We did ot implemet the optimizatios described i Sectio 4.8, because our simulatios did ot iclude a attacker, so our results would be equivalet to just usig Ariade. We used the origial Ariade source code [29], ad modified it to use digital sigatures based o HORS ad geographical leashes for wormhole protectio [14]. We compared our results with Ariade ad DSR i order to determie the added costs of RAP whe there are o attackers. However, whe a rushig attacker is preset, existig o-demad ad hoc etwork routig protocol would i geeral be uable to deliver packets over paths loger tha two hops (Sectio 2). RAP, o the other had, would be able to discover workig paths much of the time, ad as a result, would geerally outperform existig o-demad routig protocols. We chose HORS as our broadcast sigature, usig a time iterval of 5 secods ad allowig each ode to autheticate up to 20 messages per time iterval. We assumed a time sychroizatio error of 1 secod, ad used 180 byte sigatures. As a result, each public key is bytes, ad each ode has a amortized workload of hash operatios per secod at each ode for geeratig sigatures, as well as verifyig all sigatures from all odes. (This level is well withi the capability of moder PDAs, ad represets aroud 10% CPU utilizatio o moder workstatios). Our parameters were chose to provide a 80 bit security level; that is, a attacker must guess 2 80 sigatures to forge oe sigature i expectatio. Whe sigatures were eeded at a faster rate tha permitted by HORS, we used a multi-sigature scheme based o Merkle hash trees [28]. We simulated packet leashes based o optioal locatio iformatio, ad waited for 2 REQUEST packets, or a 0.2 secods fixed timeout plus the distace to the iitiator times a propagatio speed of 1500 meters per secod. Because a square area is more likely to support multiple routes betwee a source a a destiatio, our simulatios used 100 odes i a 1000 m 1000 m space movig accordig to the radom waypoit model [19]. I this model, each ode is radomly placed; at the begiig of the simulatio, it waits for a pause time, the chooses a velocity uiformly betwee 0 ad 20 meters per secod. It the proceeds to a radom locatio at that velocity, ad upo arrivig, waits for the pause time ad repeats. We simulated pause times of 0, 30, 60, 120, 300, 600, ad 900 secods. We chose a workload of 5 flows, each producig 4 packets per secod, usig 64-byte packets. This workload was sufficiet to cause sigificat cogestio with our scheme, eve though ormal ad hoc etwork routig protocols ca deliver four or more times the load at lower loss rate; however, secure eighbor discovery icurs sigificatly higher overhead due to the four-way hadshake ad speed-of-light delays associated with it. We simulated a lik-layer data rate of 2 Mbps. RAP has sigificatly worse performace tha both Ariade ad DSR because of the added load of the Secure Neighbor Discovery. Figure 5(a) shows the Packet Delivery Ratio of the three protocols. DSR delivers betwee 99.8% ad 100% of offered traffic. Ariade delivers betwee 95.0% ad 100% of offered traffic; a sigificat improvemet over previous simulatio results [16]. This suggests that previous simulatios used too high a traffic load to fairly evaluate Ariade i the absece of cogestio. Eve with this light traffic load, RAP was able to deliver just 7.6% to 47.7% of offered load. This performace is primarily due to cogestio. At higher movemet speeds (lower pause time), the lower packet delivery ratio is caused by a eve higher packet overhead, which results from the o-demad ature of the protocol. We also simulated RAP carryig a lower load of just oe flow. At higher pause times, Ariade with RAP has sufficietly low overhead to deliver betwee 73.7% ad 74.5% of traffic. Eve with these pause times, 92.1% of drops were due to MAC-layer cogestio, compared to just 4.15% due to the ode s iability to fid a route. This MAC-layer cogestio severely hampers our protocol s ability to deliver applicatio-layer packets. Figure 5(b) shows the media latecy of delivered packets. DSR ad Ariade appear to have zero mea latecy, sice their media latecies of 4.3ms ad 3.8ms respectively are sigificatly lower tha the 1050ms media latecy of RAP. Two factors cotribute to the higher latecy of RAP: first, cogestio icreases the time each ode must wait to acquire the medium, ad secod, if a ode receives just oe ROUTE REQUEST packet from a Route Discovery, 36

8 DSR Ariade RAP RAP 1 Flow Packet Delivery Ratio DSR Ariade RAP RAP 1 Flow Pause Time (a) Packet Delivery Ratio Media Latecy (secods) Pause Time (b) Media Latecy Packet Overhead (Packets 10 3 ) DSR Ariade RAP RAP 1 Flow Byte Overhead (Bytes 10 6 ) DSR Ariade RAP RAP 1 Flow Pause Time (c) Packet Overhead Pause Time (d) Byte Overhead Figure 5: Uoptimized RAP performace evaluatio results i o-adversarial eviromet. Optimized RAP would have same results as Ariade, except that it would perform better whe uder attack. Uder attack, optimized RAP ad Ariade would perform idetically for oe- ad two-hop routes, but i fidig loger routes, RAP should sigificatly outperform Ariade, sice RAP fids workig routes with moderate probability, but Ariade ad DSR ca ever fid routes. RAP 1 Flow refers to RAP with the lighter commuicatios patter of oe CBR source. Results based o averages over 50 simulatio rus; the error bars represet the 95% cofidece iterval of the mea. it waits a sigificat amout of time before forwardig that RE- QUEST i a attempt to collect eough REQUESTs ad choose oe at radom. Figures 5(c) ad 5(d) show the Packet Overhead ad Byte Overhead of the three protocols. At higher pause times, RAP has more tha five times as much overhead whe it uses five flows. This idicates that the cogestio caused by the protocol sigificatly reduces the usefuless of the routig protocol packets. Whe cogestio is ot a issue, we actually expect that overhead should be less tha a factor of five, because odes ca cache iformatio they overhear, thus improvig efficiecy. Our performace evaluatio shows that i o-adversarial eviromets, RAP adds sigificat costs relative to other secure routig protocols. May of these costs are due to the cogestio created at lower bit rates. However, RAP is desiged to be used oly whe ecessary (Sectio 4.8), so these higher costs are oly icurred whe the uderlyig protocol is otherwise uable to discover a workig route. Specifically, RAP icurs o cost util the uderlyig protocol is completely preveted from fidig a workig route. It the allows that protocol to use a higher cost approach to successfully deliver packets eve agaist a rushig attacker. I the ext sectio, we show how RAP performs uder a rushig attack, i which DSR ad Ariade would be uable to fid routes cotaiig more tha three odes (two hops) Security Aalysis This sectio discusses the security properties achieved with RAP whe distict routes (both legitimate ad attackig) exist betwee the origiator ad each other ode i the etwork. (As i Sectio 4.5, two routes are cosidered distict if they ed i differet odes.) Sice routes are required to ed i differet odes, a attacker with access to the keys of m compromised odes ca geerate at most m distict, maliciously ijected ROUTE REQUESTs for the purpose of deial-of-service. To aalyze the probability of a ode subvertig a Route Discovery, we assume that the attacker rushes m distict REQUESTs to 37

9 iitiator target Figure 6: Example etwork topology used i RAP security aalysis. iitiator X x = 1 x = 2 x = 3 x = 4 target Figure 7: A example of a successful Route Discovery. Each gray ode chose a valid REQUEST ad beloged to a route for which a REPLY was set. Each lie represets a hop i a path chose by a legitimate REQUEST; the etwork topology is show i Figure 6. each ode i the etwork. As a result, each ode eeds oly m additioal distict REQUESTs. We also suppose that the etwork topology of these legitimate requests is represeted by Figure 6, such that the l hops from the source to the target form a sequece of tiers, such that the m eighbors of the source form the first tier, the m eighbors of the target form the last tier, ad ay two adjacet tiers form a complete, bipartite graph. We deote the probability of successfully fidig a route at tier x give y odes at that tier to be S x,y. I particular, we seek the probability S l, m. Sice oe-hop eighbors caot be subverted, S 1,y = 1forally > 0. At ay other level (that is, whe x 1), the probability that i of the y eighbors will choose oe of the m bogus ROUTE REQUESTs is give by the biomial PDF ( y)( m ) y i ( m ) i.for i example, i Figure 7, at x = 4, y = 3 odes received a valid ROUTE REPLY, but oly i = 2 of them forwarded a valid REQUEST. Each of the i odes that do ot choose bogus REQUESTs chooses oe of the REQUESTs it received. Some of these REQUESTsmay overlap; the probability of choosig exactly j distict previous hops is give by p m j ( m,i),wherep r j (r,i) is the probability that whe i balls are throw ito r boxes, exactly r j boxes are empty (that is, exactly j boxes are full). The solutio to the classical occupacy problem [43] gives p r j (r,i) = ( r ) j r j ( 1) k( j) ( ) j k i. k r k=0 For example, i Figure 7, at x = 4, i = 2 odes chose j = 2distict previous hops, ad at x = 3, i = 2 odes chose j = 1 distict previous hops. Whe, at a level x 1, i odes do ot choose bogus REQUESTs but istead choose a total of j distict, legitimate REQUESTs, the probability that the Route Discovery will be successful is S x 1, j by defiitio. The S x,y is give by the equatio i Figure 5.2. For example, whe = 6, m = 2adl = 5, the probability of a successful Route Discovery is 46%. We ow argue that the case above reflects a worst case aalysis by aalyzig some potetial variatios. First, the m additioal icomig odes could come from earlier tiers (e.g., tiers with lower x). However, sice S x,y is mootoe decreasig with icreasig x ad fixed y, the opportuity to choose odes from earlier tiers oly provides a beefit. Secod, there may ot be as much overlap betwee the predecessors of the odes i a sigle tier; however, this oly reduces the umber of collisios at the previous tier. Fewer collisios at the previous tier improves performace, sice S x,y is mootoe icreasig with fixed x ad icreasig y. Third, a attacker ca choose to reduce the umber of bogus REQUESTsit seds to each ode; this has the effect of reducig m, which agai icreases the probability of success. A fial attack allows a powerful attacker to moitor the REQUESTs forwarded by each ode legitimate ode. Some of these legitimate odes will have radomly chose REQUESTs that represet compromised routes. The attacker ca the attempt to forward such REQUESTs to odes that did ot hear that REQUEST directly from that ode. This attack will be preveted by wormhole detectio. As metioed i Sectio 4.7, if oly oe ROUTE REPLY is retured with ay discovery, security is somewhat lower. I particular, oly oe route is retured, ad each hop after the first has a m probability of choosig a oattackig ode uder the attacker model used i this sectio. I a workig route, all odes must forward a oattackig REQUEST. As a result, the probability of choosig a workig route is ( ) m l,wherel is the umber of itermediate odes (excludig the iitator ad target). This sectio preseted a extremely coservative security aalysis. I particular, a attacker as aggressive as the oe described here would eed to propagate the ROUTE REQUEST from each Route Discovery from may differet locatios, possibly subjectig it to a itrusio detectio mechaism. A real attacker cosiderig the tradeoff betwee a improved probability of subversio ad a icreased probability of beig caught is ulikely to use such a powerful attack. 6. RELATED WORK We have already discussed the vulerability of curret secure odemad ad hoc etwork routig protocols [6, 39, 16, 31, 45] to the rushig attack i Sectio 2. Perlma s Floodig NPBR [34] routig protocol for wired etworks does ot suffer from this attack, sice the protocol does ot deped o the actual path of the flood for routig; rather, it requires that each packet be flooded through the the etwork. Other secure routig protocols have bee proposed based o periodic (proactive) mechaisms, for wired etworks [7, 11, 12, 21, 25, 40, 41] as well as for wireless ad hoc etworks [13, 36]. Although these protocols typically are ot vulerable to rushig attacks, such periodic protocols are ofte less desirable for ad hoc etwork routig due to their higher overhead ad slower adaptivity. Other areas i secure ad hoc etwork routig have bee explored, such as trust establishmet [2, 16, 17, 42], key geeratio [3], odes that maliciously do ot forward packets [27], ad security requiremets for forwardig odes [44]. These areas are beyod the scope of this paper. Routig protocol itrusio detectio has bee studied i wired etworks as a mechaism for detectig misbehavig routers. Cheug ad Levitt [8] ad Bradley et al [5] propose itrusio detectio techiques for detectig ad idetifyig routers that sed bogus routig update messages. I this paper, we describe oe ivariat of legitimate ode behavior, ad itroduce a distributed mechaism to exclude odes that have bee caught violatig that ivariat. 7. CONCLUSION I this paper, we have described the rushig attack, a ovel ad powerful attack agaist o-demad ad hoc etwork routig proto- 38