Disrupting Peer-to-Peer Networks

1. Sybil & Eclipse Attacks Disrupting Peer-to-Peer Networks Lee Brintle University of Iowa

2. Motivations Many organizations may wish to disrupt some part of a P2P network • Intellectual Property Owners • Both piracy and legitimate content • Governments • Banned content, censorship • Corporations • Advertising, reputation, public relations

3. Disruptions More subtle actions than just shutting it down • Missing Results • Only censor some items • Degraded Results • Intentionally provide damaged or slow results • Delayed Actions • Function normally until a point in the future

4. Sybil Attack Single entity posing as multiple entities • One attacker with many identities • Named after character with MPD • Many real-world examples • John R. Douceur, Microsoft Research

5. Three Sources of Information How does a peer know about the trustworthiness of other peers? • Itself • Results of protocol interactions • Other peers • Trust in a large number of strangers • External agencies • Direct or indirect vouching for uniqueness of peers

6. Direct Entity Validation Tests Weed out duplicates by asking all to performing a task that a single entity cannot • Ask all to perform task that one cannot do • Make the attacker “too busy” to simulate all of them • Simultaneously validate peers • The attacker should not be allowed to focus on one • Limit number of Sybil identities • Ratio of resources – attacker / weakest legitimate user

7. Sample Validation Tests Ways to see if a number of peers are sharing resources • Communication • Require each to prove they have X Mb/s bandwidth • Storage • Require each to prove they can store Y GB • Computation • Require each to solve a “hard” puzzle

8. Vouched-For Entities Trust a new entity based on the word of an already-verified entity • One Sybil Vouches for them All • Pushes the problem around • Verified Users May Vouch for Sybils • Once they gain your trust, invite in other Sybils • Faulty Verifications are Amplified

9. Attackers Have Resources Attacking entity has more resources than the average user of the network • Lots of Bandwidth • Lots of Disk Space • Lots of CPU • Lots of Identities

10. Direct Physical Knowledge Knowing information about a peer beyond the peering protocol • Explicit • Signing authorities, well-known users, software authors • Implicit • IP address allocation, network locale • Irrelevant • Ignore bad results, accept performance loss

11. Eclipse Attack Attackers gain disproportionate influence compared to legitimate users • Fewer attackers • Disproportionate level of influence • Attackers eclipse legitimate users • Singh, Ngan, Druschel, Wallach

12. Structured Networks Constrained routing table networks are difficult to attack – but perform poorly • Topology is “fixed” – nodes have constant influence • The routing is hard-wired based on address • No flexibility in neighbor selection • Cannot take advantage of proximity • Some resistance to Eclipse attacks • The more structure, the less susceptible

13. Unstructured Neighbor Selection Eclipse attacks target the neighbor peering decision • Neighbors are selected, not assigned • Each node picks “good” neighbors • Nodes that look “good” have influence • If a node is selected more often, gains more influence • Potentially vulnerable to Eclipse attacks • Attacking nodes become more influential

14. Eclipse Defenses Mitigate Eclipse attacks by additional network structure, proximity, or degree bounds • Enforce strong structural routing • Routes are dictated randomly, but performance suffers • Select neighbors based on proximity • But... most non-LAN nodes have roughly same delay • Place a limit on number of degrees • Degree bounds prevent nodes from being too influential

15. Profile of a Hostile Node Detect hostile nodes, so they can be avoided in neighbor selection • High in-degree • Must have higher influence than average • High out-degree • Tries to consume resources of average nodes • Extremely effective • 20% of nodes eventually have almost complete control

16. Enforce In-Degree Bounds Avoid peers with large numbers of in-degree links • Refuse to peer with overloaded nodes • Force each node to have “typical” influence • Bound based on expected average degree • Lower bounds more defense, worse performance • Performance hit is 25% at average degree • Degree bounds mean that less-optimal nodes are selected

17. Catch a Lying Node: Audit Links Anonymously verify link set contains known nodes • Ask each peer for list of in-nodes • For now, assume peer tells truth • Drop peer if list is too long • Do not allow a peer to gain too much influence • Drop peer if list does not contain us • If peer returns sub-set of true list, drop peer

18. Catch Lying Nodes: Distributed Audit Ask someone else to verify the node list • Use random seed point • Select multiple nodes • Audits are aggregated Random node among the l closest to H(x) (chart from paper)

19. Distributed Audit Results The auditor may be lying too... Fail Audit legit, Target hostile Audit hostile, Target legit Pass Auditor legit, Target legit Auditor hostile, Target hostile Auditor legit, Target lucky hostile

20. Distributed Audit Tuning Parameters which impact detection and performance f: fraction of hostile nodes (.2) n: number of audits (24) (.2% false ID) k: number of successful audits (n/2) r: overload ratio on hostile nodes (1.2) t: permitted overload ratio (1) audit period (2 minutes) churn rate (0%, 5%, 10%, 15%)

21. Distributed Audit Results Profile before auditing starts Without prevention, malicious nodes have great influence (chart from paper)

22. Distributed Audit Results Profile during auditing f/(1-f) Auditing is effective in mitigating Eclipse attacks (chart from paper)

23. Performance Gain Optimized neighbors with auditing is still faster than non-optimized neighbors At t=.2, auditing rate=2 min, churn = 5 min: 4.75 msg/node/min messaging overhead

24. Caveats Yeah, but.... • “The idea of churn as shelter from route poisoning attacks...” • Unstructured networks need structured auditing • BitTorrent can use a distributed tracker, for example • Does not help super-node networks (KaZaAa) • Asymmetry is part of performance gain • Still weak against localized attacks • Can target users on same network