1 / 42

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

This paper presents a secure routing approach for ad-hoc networks using localized self-healing communities to counter non-cooperative behaviors and mitigate packet loss. The approach minimizes the number of RREQ floods and maintains comparable routing performance.

vmerritt
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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)

More Related