A Secure Ad-hoc Routing Approach using Localized Self-healing Communities

1. A Secure Ad-hoc Routing Approach using Localized Self-healing Communities Jiejun Kong, *Xiaoyan Hong, Yunjung Yi, Joon-Sang Park, *Jun Liu,Mario Gerla WAM Laboratory Computer Science Department *Computer Science Department University of California, Los Angeles University of Alabama, Tuscaloosa {jkong,yjyi,jspark,gerla}@cs.ucla.edu {jliu,hxy}@cs.ua.edu

2. Problem Statement • RREQ flooding attack by non-cooperativemembers(selfish or intruded member nodes) • Direct RREQ floods • Non-cooperative members continuously generate RREQ • RREQ rate limited & packet suppression needed • Indirect RREQ floods • RREP & DATA packet loss • Caused by rushing attack etc. [Hu et al.,WiSe’03] • Indirectly trigger more RREQ floods • Don’t blame the RREQ initiator • Excessive floods deplete network resource

3. RREQ RREP Indirect Attack Example • RREQ forwarding • Rushing attackers disobey delay (MAC/routing/queuing) requirements& w/ higher prob., are placed on RREP / DATA path • Can trigger more RREQ floods initiated by other good nodes • RREP & DATA packet loss is common in MANET • Hard to differentiate attackers from non-attackers;network dynamics? non-cooperative behaviors? dest source

4. Outline • Related work • Community-based secure routing approach • Strictly localized • “Self-healing community”substitutes“single node” • Our analytic model • Asymptotic network security model • Stochastic model for mobile networks • Empirical simulation verification • Summary

5. Related Secure Routing Approaches • Cryptographic protections [TESLA in Ariadne, PKI in ARAN] • Cannot stop non-cooperative network members;They have required credentials / keys • Network-based protections • Straight-forward RREQ rate limit [DSR, AODV] • Long RREQ interval causes non-trivial routing performance degradation • Multi-path secure routing [Awerbuch,WiSe’02] [Haas,WiSe’03] • Not localized, incurs global overhead, expensive • Node-disjoint multi-path preferred, but challenging • Rushing Attack Prevention (RAP) [Hu,WiSe’03] • RREQ forwarding delayed and randomized to counter rushing • Causes large route acquisition delay; less likely to find optimal path

6. Our design • Goal: minimize # of allowed RREQ floods • Ideally, 1 initial on-demand RREQ flood for each e2e connection • Maintain comparable routing performance • Solution: • Build multi-node communities to counter non-cooperative packet loss • Design applies to wide range of ad hoc routing protocols & various ad hoc networks

7. Community: 2-hop scenario Community • Area defined by intersection of 3 consecutive transmissions • Node redundancy is common in MANET • Not unusually high, need 1 “good” node inside the community area • Community leadership is determined by contribution • Leader steps down (being taken over)if not doing its job (doesn’t forward within a timeout Tforw)

8. Communities dest source Community: multi-hop scenario • The concept of “self-healing community” is applicable to multi-hop routing

9. Community Based Security (CBS) • End-to-end communication between ad hoc terminals • Community-to-community forwarding (not node-to-node) • Challenge: adversary knows CBS prior to its attack • It would prevent the network from forming communities • Network mobility etc. will disrupt CBS

10. On demand initial config • Communities formed during RREP • Simple heuristics: promiscuously overheard 3 consecutive (ACKs of) RREP packets set community membership flag for the connection • Goal revisited: reduce the need of RREQ floods • In spite of non-cooperative behavior

11. RREQ Community around Vformed upon hearing RREP upstream RREPEV On demand initial config around V • (Potentially non-cooperative)V’s community must be formed at RREP • Else V drops RREP and succeeds • V1 and V2 need to know V’s “upstream” V1 U V E V2

12. Communities(C’ and C” not in transmission range & C’ wins) ACK-based config Communities (if C forwards a correct RREP) C” D E B C dest source C’

13. Proactive re-config • Each community loses shape due to network dynamics (mobility etc.) • End-to-end proactive probing to maintain the shape • PROBE unicast + take-over • PROBE_REP unicast + take-over • Just like RREP • Again: reduce the need of RREQ floods • In spite of random mobility & non-cooperative behavior

14. PROBE PROBE_REP X no ACK Newly re-configured community Node D's roaming trace Re-config: 2-hop scenario Old community becomes staledue to random node mobility etc. (PROBE, upstream, …) (PROBE_REP, hop_count, …) oldF S D newF

15. PROBE PROBE_REP X no ACK Re-config: multi-hop scenario • Optimization • Probing message can be piggybacked in data packets • Probing interval Tprobe adapted on network dynamicsSimple heuristics: Slow Increase Fast Decrease source dest

16. Control flow & Data flow • Control flows’ job • Config communities: RREP • Reconfig communities: PROBE, PROBE_REP(& data packets piggybacked with probe info) • Unicast + take-over • DATA • DATA packets • Unicast + make-up (not take-over)[community setup unchanged]

17. Outline • Other countermeasures • Community-based routing approach • Strictly localized w/ clearly-defined per-hop operation • “Self-healing community” substitutes “single node” • Our analytic model • Asymptotic network security model • Stochastic model for mobile networks • Empirical simulation verification • Summary

18. Notion: Security as a “landslide” game • Played by the guard and the adversary • Proposal can be found as early as Shannon’s 1949 paper • Not a 50%-50% chance game, which is too good for the adversary • The notion has been used in modern crypto since 1970s • Based on NP-complexity • The guard wins the game with 1 - negligible probability • The adversary wins the game with negligible probability • The asymptotic notion of “negligible” applies to one-way function (encryption, one-way hash), pseudorandom generator, zero-knowledge proof, ……AND this time ……

19. Definition: A function m: NR is negligible, if for every positive integer c and all sufficiently large x’s (i.e., there exists Nc>0, for all x>Nc), Our Asymptotic Network Security Model • Concept: the probability of security breach decreases exponentially toward 0 when network metric increases linearly / polynomially • Consistent with computational cryptography’s asymptotic notion of “negligible / sub-polynomial” • is negligible by definition x is key length in computational cryptox is network metric (e.g., # of nodes) in network security

20. Insecure Secure(Ambiguous area) The Asymptotic Cryptography Model The “negligible” line(sub-polynomial line) • Security can be achieved by a polynomial-bounded guard against a polynomial-bounded adversary Probability of security breach 1 2 # of key bits (key length) 128 • See Lenstra’s analysis for proper key length(given adversary’s brute-force computational power) • There are approximately 2268 atoms in the entire universe

21. Insecure Secure(Ambiguous area) Our Asymptotic Network Security Model The “negligible” line(sub-polynomial line) • Conforming to the classic notion of security used in modern cryptography ! We’ve used the same security notion The “exponential” line(memory-less line) Probability of network security breach Network metric (e.g., # of nodes -- network scale)

22. Mobile network model • Divides the network into large number n of very small tiles (i.e., possible “positions”) • A node’s presence probability p at each tile is small Follows a spatial bionomial distributionB(n,p) • When n is large and p is small, B(n,p) is approximately a spatial Poisson distribution with rate r1 • If there are N mobile nodes roaming i.i.d.rN= N·r1 • The probability of exactly k nodes in an area A’

23. r1in Random Way Point model [Bettstetter et al.] a=1000

24. Community area Aheal • (left) maximal community • 2-hop RREP nodes are (1 + e)·R away • Area approaching • (right) minimal community • 2-hop RREP nodes are (2 - e)·R away • Area approaching 0 • Real world scenarios randomly distribute between these two extremes

25. Modeling adversarial presence • q : percentage of non-cooperative network members (e.g., probability of node selfishness & intrusion) • 3 random variables • x :number of nodes in the forwarding community area • y: number of cooperative nodes • z: number of non-cooperative nodes

26. Effectiveness of CBS routing • Per-hop failure prob. of community-to-community routing is negligible with respect to network scale N • Per-hop success prob. of node-to-node ad hoc routing schemes is negligible (under rushing attack) • TremendousgainEG:= 1 / negligibleapproaching +1

27. q N q N Community Based Security Pcommunity Pregular • In summary, in mobile networks haunted by non-cooperative behavior, community-based security has tremendous( )gain( )

28. QualNet simulation verification • Perfermance metrics • Data delivery fraction, end-to-end latency, control overhead • # of RREQ • x-axis parameters • Non-cooperative ratio q • Mobility (Random Way Point Model, speed min=max) • Protocol comparison • AODV: standard AODV • RAP-AODV: Rushing Attack Prevention (WiSe’03) • CBS-AODV: Community Based Security

29. Performance Gap • CBS-AODV’s performance only drops slightly with more non-cooperative behavior • Tremendous EG justifies the big gap between CBS-AODV and others %

30. Mobility’s impact

31. Less RREQ • In CBS-AODV, # of RREQ triggered is less sensitive to non-cooperative ratio q • Enforcing RREQ rate limit is more practical in CBS-AODV %

32. Summary • Conventional node-to-node routing is vulnerable to routing disruptions • Excessive but protocol-compliant RREQ floods • Rushing attack + RREP / DATA packet loss • The new community-to-community secure routing is our answer • Analytic study approves the community design • Empirical simulation study justifies the analytic results • General design • Open challenges • More optimal estimation of forwarding window Tforw & probing interval Tprobe • Secure and efficient key management between two communities

33. Thank you! Questions?

34. This slide is intentionally left blank • Backup slides follow

35. r1 • Inspired by Bettstetter et al.’s work • For any mobility model (random walk, random way point), Bettstetter et al. have shown thatr1 is computable following • For example, in random way point model in a square network area of size a£a defined by -a/2·x· a/2 and -a/2·y· a/2 • r1 is “location dependent”, yet computable in NS2 & QualNet given any area A’(using finite element method)

36. Delivery fraction & Control overhead • CBS-AODV’s performance only drops slightly with more non-cooperative behavior • Tremendous EG justifies the big gap (of delivery fraction & total control overhead) between CBS-AODV and others

37. Latency • Route acquisition latency monotonically increases with q • AODV’s avg. data packet latency drops due to short routes

38. Mobility’s impact • CBS’s have better delivery fraction • CBS-AODV,cons_flood’s cost is too high

39. RREQ limit control • In CBS-AODV, # of RREQ triggered is less sensitive to non-cooperative ratio q • Enforcing RREQ rate limit is more practical in CBS-AODV

40. Protocol Details • Packet format • (RREQ, upstream_node, ……) • (RREP, hop_count, ……) • In DSR or AODV , some of the extra fields can be spared

41. Protocol Details • Unicast control packets & their ACKs

42. Protocol Details • Unicast control flows config/re-config communities • RREP, PROBE, PROBE_REP packets & data packets piggybacked with probe info • Unicast + take-over • Data flows • DATA packets • Unicast + make-up (not take-over)