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
Sybil & Eclipse Attacks

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 & Eclipse Attacks

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
Sybil & Eclipse Attacks

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
Sybil & Eclipse Attacks

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
Sybil & Eclipse Attacks

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
Sybil & Eclipse Attacks

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
Sybil & Eclipse Attacks

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
Sybil & Eclipse Attacks

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
Sybil & Eclipse Attacks

Attackers gain disproportionate influence compared to legitimate users
•
Fewer attackers
•
Disproportionate level of influence
•
Attackers eclipse legitimate users
Singh, Ngan, Druschel, Wallach
Sybil & Eclipse Attacks

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
Sybil & Eclipse Attacks

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
Sybil & Eclipse Attacks

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
Sybil & Eclipse Attacks

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
Sybil & Eclipse Attacks

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
Sybil & Eclipse Attacks

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
Sybil & Eclipse Attacks

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)
Sybil & Eclipse Attacks

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
Sybil & Eclipse Attacks

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%)
Sybil & Eclipse Attacks

Profile before auditing starts
Without prevention, malicious nodes have great influence
(chart from paper)
Sybil & Eclipse Attacks

Profile during auditing
Auditing is effective in mitigating Eclipse attacks
(chart from paper)
Sybil & Eclipse Attacks f/(1-f)

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
Sybil & Eclipse Attacks

Yeah, but....
“The idea of churn as shelter from route poisoning
•
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
Sybil & Eclipse Attacks