Mitigating Routing Misbehavior in Mobile Ad Hoc Networks Sergio Marti, T.J. Giuli, Kevin Lai, Mary Baker Stanford U.

Appeared at MOBICOM in 2000 Authors: Kevin Lai, Mary Baker – faculty, now at HP Labs Authors: Sergio Marti, TJ Giuli are still PhD students.

The Problem A node may agree to forward data but fail to do so when required Reasons: Overloaded machine Broken hardware / buggy code malicious

The Problem How to Identify Misbehaving nodes? What to do about them? Only forward through trusted nodes Kick miscreants out of the routing network Add intelligence to end stations to learn & route around them

Assumptions Bidirectional communication (though not necessarily symmetric) Promiscuous mode is available (no per- hop encryption)

DSR route discovery (a)Sender broadcasts route request (b)Intermediate nodes stamp & forward request (c)Destination sends a (source routed) reply containing path

DSR route maintenance End station selects shortest known path to destination If a requested link is broken, the neighbor link sends an alert to the source, which must restart route discovery (unless it has another route in cache)

Proposed Solution 2 new programs: Watchdog – listens for connection status Pathrater – avoids broken paths

Watchdog Each node runs in promiscuous mode. Uses path knowledge from source routing Save relayed packets in cache Listens to its neighbors forwarding its packets if packets not relayed by next hop, increment error counter if error count exceeds threshold, mark node as misbehaving

Watchdog Weaknesses Ambiguous collisions – collision at “A” keeps “A” from knowing whether “B” relayed the frame Rx collisions -- “A” can't detect collisions at “C” limited power -- “A” can't tell if signal too weak to reach “C” False misbehavior -- “B” could spoof or incorrectly send error notifications Collusion -- “B” and “C” could appear to function, but not forward packets from each other Partial dropping -- “B” drops packets at a rate lower than “A”'s thresholds

PathRater Each node in network is rated based on feedback from Watchdog Path metric = MEAN{ all nodes in path } ┌ Node metric = │ -100 (misbehaving nodes), │ 0 <= N <= 0.80 └ N = x (200mS segments w/ successful transmits) x (unreachable events) It takes >33 minutes to recover from a false error!

Simulation ns MAC model 50 wireless nodes Communications pattern found in previous paper (Random waypoint model) Source nodes moving at <20 m/s (FAST! -- 72kph/45Mph) small number of CBR traffic streams 200 second simulation length (no error recovery) varying percentage of misbehaving nodes

Results (throughput)

Result analysis DSR mods do not help throughput w/o misbehaving nodes? (95% thruput) All mods enabled has best throughput Pathrater alone does not help throughput

Routing Overhead Similar overhead except SRR Mobility only matters to SRR

False Positives No throughput impact detected Not clear how many false positives detected, relation w/ # of miscreants Some false positives are due to genuine error cases (high drop/collision rates)

Open Questions Is there benefit to any DSR mods w/o misbehaving nodes? (95% thruput) How is throughput measured --- does it only include data? What is network loading? Probably too low to be significant. Simulations 200 seconds, false error recovery 2000 seconds Effect of # of nodes? Active talkers?

Future Work Optimise watchdog thresholds for errors Include explicitly trusted nodes Integrate pathrater with TCP feedback TCP/FTP load testing Does pathrater/watchdog impact latency

Conclusions Passive detection of misbehaving nodes increases throughput in the presense of miscreants with manageable overhead Battery usage still a concern w/ overhead