Mitigating Routing Misbehavior in Mobile Ad Hoc Networks

1. http://www.stanford.edu/~giuli/publications/mobicom2000adhoc.pdfhttp://www.stanford.edu/~giuli/publications/mobicom2000adhoc.pdf Sergio Marti, T.J. Giuli, Kevin Lai, Mary Baker Stanford U. Mitigating Routing Misbehavior in Mobile Ad Hoc Networks

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

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

4. 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

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

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

7. 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)

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

9. 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

10. 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

11. 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 = 0.50 + 0.01 x (200mS segments w/ successful transmits) - 0.05 x (unreachable events) It takes >33 minutes to recover from a false error!

12. Simulation ns-2 802.11 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

13. Results (throughput)

14. 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

15. Routing Overhead • Similar overhead except SRR • Mobility only matters to SRR

16. 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)

17. 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?

18. 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

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