slide1
Download
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


  • 88 Views
  • 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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
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
slide1
Sybil & Eclipse Attacks

Disrupting Peer-to-Peer Networks

Lee Brintle

University of Iowa

slide2
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
slide3
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
slide4
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
slide5
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
slide6
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
slide7
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
slide8
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
slide9
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
slide10
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
slide11
Eclipse Attack

Attackers gain disproportionate influence compared to legitimate users

  • Fewer attackers
  • Disproportionate level of influence
  • Attackers eclipse legitimate users
  • Singh, Ngan, Druschel, Wallach
slide12
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
slide13
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
slide14
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
slide15
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
slide16
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
slide17
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
slide18
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)

slide19
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

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

slide21
Distributed Audit Results

Profile before auditing starts

Without prevention, malicious nodes have great influence

(chart from paper)

slide22
Distributed Audit Results

Profile during auditing

f/(1-f)

Auditing is effective in mitigating Eclipse attacks

(chart from paper)

slide23
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

slide24
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
ad