1 Protocols for the Wireless Paranoid Nitin Vaidya University of Illinois Slightly revised version of slides used for a 2005 INFOCOM (Miami) panel on Paranoid Protocol Design for Wireless Networks March 16, 2005 Other panelists: Jean-Pierre Hubaux (Moderator), Bill Arbaugh, Ed Knightly, Adrian Perrig

2 Disclaimer If you review my research proposals, ignore everything I say here

3 Panel’s Premise  Wireless networks need more paranoid protocols than wired networks

4 Wireless Networks  Greater paranoia may be desirable in wireless networks  Easier to “tap” into  Limited resources  Incentive to cheat  Programmable devices provide means to cheat  But …

5 What are Paranoid Protocols Anyway?

6 Department of NetLand Security (DNS) Low Severe High Elevated Guarded Paranoid Threat Assessment Characterized by extreme and irrational distrust

7 Paranoid Design Principles  Everything that can go wrong, will - Murphy’s Law  Protect against everything

8 Research Community’s Response  Enumerate all possible ways things can go wrong  Separate solution for each of the ills Not quite the right approach   Proof by Example  3 Mistakes often made

9 Mistake 1: Assuming Extreme Scenario as the Common Case Ad hoc network are coming ! Ad hoc networks are coming !!

10 “Extreme” Ad Hoc Networking Large Isolated Networks  No infrastructure A B C E

11 Extreme Scenario  “Extreme” ad hoc networks: No infrastructure  No certification authority  No DHCP server  Long-lived partitions Why build networks this way, if you don’t have to? Not all networks are for the battlefield !!

12 Extreme Ad Hoc Networks  Model acceptable when exploring design space for MAC and routing  Assuming same model for “security” can lead to unnecessary complexity

13 More Likely Ad Hoc Networks Access to Infrastructure or Small A B C E internet

14 More Likely Ad Hoc Networks Access to Infrastructure or Small

15 More Realistic Multi-Hop Wireless Mesh Networks Wireless channel Mesh node A Wireless channel Mesh node B C Wireless “backbone” internet

16 More Realistic Multi-Hop Wireless Hybrid Networks Wireless channel Access Point A Wireless channel Access Point B C D E internet

17 Even Vehicles Can Have Intermittent Infrastructure Access Picture courtesy Prof. Jean-Pierre Hubaux (somewhat modified from Prof. Hubaux’s version)

18 Multi-Hop Wireless is Here (Summary)  Multi-hop wireless, but “infrastructure” can be accessed selectively  Not all enumerable scenarios are relevant  Design protocols for the likely scenarios

19 Mistake 2: “In-Band” Solutions  “In-band” solutions  Solution tied closely to attack

20 Mistake 2: “In-Band” Solutions  Example attack: Node refuses to forward packets  In-band solution: Watch each other for the misbehavior A B C Discard P

21 Out-of-Band Solutions Often More Practical 1. Disincentives for not forwarding packets 2. Misbehavior translates to poor performance  Re-route around “bad” parts of the network Single out-of-band solution can help with many attacks

22 Mistake 2: “In-Band” Solutions  Example Attack: MAC Layer selfish misbehavior for performance gains  In-band solution: Detect whether a node follows protocol faithfully  Out-of-band solution: Determine whether a node receives unfair share Wireless channel Access Point

23 Out-of-Band Solutions (Summary)  Out-of-band solutions often superior, and easier to implement

24 Mistake 3 Wireless = Wired Equivalent  Many protocols work correctly only when nodes see identical wireless channel status

25 Mistake 3 Wireless = Wired Equivalent  Many protocols work correctly only when nodes see identical wireless channel status  Protocols cannot perform as advertised Wireless channel Access Point A B C When C transmits, A and B may see different channel status

26 Mistake 3 Wireless = Wired Equivalent  Under realistic channel conditions, some of the attacks also difficult to launch undetected  Example: Certain “wormhole” attacks Ignore such attacks?

27 Mistake 3 (Summary)  Pay attention to the physical layer  Wired equivalent for wireless not always reasonable  Use solutions that do not rely on such assumptions Out-of-band solutions, removed from the cause, may be less prone

28 Conclusion  Not everything that can go wrong is worth the cost of protection  Develop small set of solutions for a large problem space  Know the wireless channel Need to protect wireless networks … but

29 Conclusion Wireless networks are complex Focus on the real problems, ignore the imaginary

30 Thanks !