Skip this Video
Download Presentation
Disrupting Peer-to-Peer Networks

Loading in 2 Seconds...

play fullscreen
1 / 24

Disrupting Peer-to-Peer Networks - PowerPoint PPT Presentation

  • Uploaded on

Sybil & Eclipse Attacks. Disrupting Peer-to-Peer Networks. Lee Brintle University of Iowa. 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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Disrupting Peer-to-Peer Networks' - pello

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Sybil & Eclipse Attacks

Disrupting Peer-to-Peer Networks

Lee Brintle

University of Iowa


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

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
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
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
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
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
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
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
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
Eclipse Attack

Attackers gain disproportionate influence compared to legitimate users

  • Fewer attackers
  • Disproportionate level of influence
  • Attackers eclipse legitimate users
  • Singh, Ngan, Druschel, Wallach
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
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
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
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
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
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
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)

Distributed Audit Results

The auditor may be lying too...


Audit legit, Target hostile

Audit hostile, Target legit


Auditor legit, Target legit

Auditor hostile, Target hostile

Auditor legit, Target lucky hostile

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%)

Distributed Audit Results

Profile before auditing starts

Without prevention, malicious nodes have great influence

(chart from paper)

Distributed Audit Results

Profile during auditing


Auditing is effective in mitigating Eclipse attacks

(chart from paper)

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


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