Eclipse Attacks on Overlay Networks: Threats and Defenses

Eclipse Attacks on Overlay Networks: Threats and Defenses By Atul Singh et alibi INFOCOM 2006 Presented by James Newell

Outline • Eclipse attack description • Previous defenses • New approach • Analysis • Evaluation • Conclusion

Eclipse Attack • Overlay network • Decentralized graph of nodes on edge of network • Each node maintains a neighbor set • Typically limited control over membership • Eclipse Attack • Malicious nodes conspire to hijack and dominate the neighbor set of correct nodes • “Eclipse” correct nodes from each other • Control data traffic through routing

Example C & F controls traffic A B C B to * D E F G H I

Structured vs. Unstructured • Unstructured Overlays • Little constraints on neighbor selection • Easy to bias neighbor discovery • Random walks • Learning from other neighbors • Structured Overlays • Constrained routing table to bound number of hops • Typically, long-distance hops are less restrictive and more susceptible

Eclipse and Sybil Attack • Sybil Attack • Create multiple network identities for one physical host • Loosely related • Can perform an Eclipse attack with a Sybil attack • A Sybil attack is not required for an Eclipse attack • In Gnutella, malicious nodes can only advertise other malicious nodes during neighbor discovery

Existing Defenses • Central Authority (BitTorrent tracker) • Constrained Routing Tables (CRT) • Certified, random-unique ID for every node • Neighbors consist of picking nodes with IDs closest to a specified point. • Lacks proximity optimizations • Proximity Selection • Select node with lowest delay (but satisfies constraints) • Attacker may be able to manipulate this • Resolution/accuracy could pose a problem

New Approach • Enforcing node degree bounds • To mount large-scale attack, you need a higher than avg in-degree neighbor set • f = fraction of malicious nodes in network • f’= fraction of out-bound neighbors consumed by malicious nodes • Oexp = Exp # of out-bound neighbors, Imax = max number of in-bound neighbors (Imax = t*Oexp) • f’N(1-f)Oexp≤ NfImax • f’ ≤ ft/(1-f) • If t=1, f’ ≤ f/(1-f)

Example Revisited A Bound degree: 2 B C D E F G H

Enforcing Degree Bounds • Anonymous auditing of neighbor sets • Each node periodically obtains the backpointer set (in-bound neighbor set) from a random out-bound neighbor • If |{bp-set}| > bound or NodeID  {bp-set}, removes auditee from neighbor set • Includes nonce and signature for freshness and accuracy • The reverse process can be done to ensure out-bound degree bounds as well

Anonymization Process • Requirements are lax (identity can be occasionally revealed) • Routes through n random Anonymizer Nodes as anonymous relays • Needs to satisfy k out of n challenges correctly (and fail none) • Randomizes intervals and time between discovering and using an Anonymizer Node

Anonymization Analysis • What can happen? • Assume b is malicious with probability f • Prob. of a correct node be detected as malicious A B C C can guess or not respond. Outcome depends on if C guesses correctly C responds honestly, everyone is happy B can drop the challenge, making A suspect C B colludes with C and crafts a response that fools A

Analysis continued… • r = overload ratio, c = prob. of replying to a challenge • Prob. of f of anonymizer collusion • Prob. of (1-f)c/r of passing a challenge • Prob. of (1-f)c(1-1/r) of failing a challenge Prob. Of (1-f)(1-c) of not responding • Prob. of a malicious node passing an audit

Optimization • Assume r = 1.2 • Given an upper-bound on f, one can choose n and k • minimize exposure to correct nodes • Sufficiently detect malicious nodes

Choosing Anonymizer Nodes • Random Node • Auditee could see the request along the route and possibly infer the source • Hash(x) • Once found, can be repeatibly used directly • If comprimised, no audits will work on x • l nodes around Hash(x) • Benefits of Hash(x) • If nodes are assigned IDs randomly, chances of compromising all l nodes are low. • Size of l

Experimental Evaluation • Setup • MSPastry (b = 4 and l = 16) • GT-ITM trans-stub topolgy of 5050 routers • Measure pair-wised latency values from the King tool • Set f = 0.2 • Malicious Nodes • Misroute join messages to malicious nodes • Supply only malicious nodes as references • Have only good nodes in routing table (16 per row)

Eclipse Attack Effectiveness • With PSN turned off • 70% on 1000 node-overlay, 80% on 5000 • 90% for top-row on 1000, 100% on 5000 • With PSN turned on GT-ITM latencies King latencies

Effectiveness Continued… • As overlay size increases, PSN becomes less effective • In real Internet, large fraction of nodes lie in small latency band • Easier to hijack top row of routing table (less restrictive) • Also the most dangerous because it tends to be the first hop for sending its own message GT-ITM latencies King latencies

Degree Bounding Effectiveness • Used oracle to maintain idealized degree-bounding • Effective decreases with larger overlays and looser in-bound restrictions • Increase of 25% avg. delay with degree-bounding (8% with bound increased to 32) due to tighter constraints on neighbor selection f = 0.2, t=1: ft/(1-f) = 0.25

Auditing Effectiveness • Setup • 2000 overlay nodes • Set n = 24, k = 12 (c is optimal) • Imax = 16 nodes per row (for correct nodes) • Strategy • Node audits every neighbor randomly between a 2 min interval neighbor once • When malicious nodes reply, they reply with a random subset that follow bounding limits • Considered static membership, 5%, 10%, and 15% churn (every simulated hour)

Effectiveness Continued… • Before auditing, the malicious nodes are successful (in-degree >>> 16) • After 10 simulated hours (assuming static) all nodes had in-degree <= 16

Routing Table • Auditing starts after 1.5 hours • Fraction of malicious nodes significantly drops after auditing • With 15% churn, new nodes that haven’t been sufficiently audited yet can maintain a higher in-degree • Doubling the auditing rate for 15% is equivalent to 10% at normal rate • Relationship between auditing rate and churn rate Entire Routing Table Top Row

Overhead • Overhead includes everything (Pastry overlay w/ PSN, Secured routing, and Auditing) and is (4.2 msg/node/sec) • Overhead of Auditing rate of once per 2 mins is (2 msg/node/sec) • Spike is due to every node searching for anonymizer nodes it will use

False Positives • After 10 hours, 100/96,000 connections are incorrectly marked as suspicious • 0.001 false positive rate • Strategy to reduce rate • Unmark 1 suspicious node every week for a 2000 node network • Freshly re-audit the node as if it was new • Increase value of n

Comparisons • Compare to straight CRT • Assume both is effective • Setup • Auidting rate once per 2 mins • 5% churn rate per hour • First use PNS-based routing table • Fails, then re-sent using CRT • Difference is if PNS is degree-bounded (DB) or without degree-bounded (WDB)

Overhead and Delay • Overhead • DB has lower overhead • Application sends at least 4.75 msg/node/min • Overcome additional cost of auditing • DB reduces reliance on CRT by more than half • Delay • Knee is an artifact of implementation of CRT • Avg. delay 3.05 sec DB, 5.4 WDB • 90% of DB msgs. delivered within 5.8 sec • WDB can take more than 16 sec

Limitations • Auditing • Each node has to discover a malicious node independently • No mechanism to notify other members -> Byzantine agreement? • Hierarchical Overlays • Need to exempt high-level nodes • Unstructured Overlays • Need to mechanism to secure select anonymizer set • Could possibly use an alternate structured overlay • Localized Attacks • Only Eclipse attack a small section of the network • Might not require a higher than avg. degree of neighbors • PSN requires that they are physically close to victims

Conclusion • Eclipse attack are a real threat • Possible even in structured overlays or PSN-aware networks • Doesn’t require Sybil attack to be effective • Bounding degree of nodes in network is a simple and effective measure • Distributive enforcement using anonymous auditing • Lightweight and allows PSN optimization • Limitations • Sensitive to high churn rates • Higher overhead for low application traffic • Doesn’t work in all cases (hierarchy, local attacks, etc..) • Requires secure routing (CRT) for locating anonymizer set

Eclipse Attacks on Overlay Networks: Threats and Defenses