BitTorrent

1
BitTorrent

• Nathan Marz
• Raylene Yung

2
BitTorrent

• BitTorrent consists of two protocols
• Tracker HTTP protocol (THP)
• How an agent joins a swarm
• How an agent learns of other agents in the swarm
• Peer Wire Protocol (PWP)
• How agents connect with each other (handshake)
• How agents tell each other what data they have
• How agents request and send data
• We focused on this part of the protocol

3
Peer Wire Protocol Messages
4
Overview

• PRISM is not a natural way to define distributed
  protocols with non-deterministic adversary
• Presentation
• Overview of challenges of modeling a complicated
  protocol in PRISM
• Techniques we used to overcome these challenges
• Results

5
Generating PRISM Model

• We wrote PHP Script
• Always generates
• One seeder
• One attacker
• Takes parameters
• Agents
• Pieces
• Blocks per Piece

6
Issues with PRISM

• Problem 1 We want to model logical structures
  like
• If received block l for piece p
• If all blocks downloaded for p
• if all blocks for p verify
• set status of p to dl/verified
• else clear all blocks for p
• PRISM only allows commands of the following form
• condition -gt probability distribution of
  results

7
Issues with PRISM

• Solution Hierarchical commands

a1 b1 c1 -gt 0.5 (a0) (c2) 0.5
(a2) (c2) a1 b2 -gt 0.5 (a0)
(c3) 0.5 (a2) (c3) a1 !(b1
c1) !(b2) -gt 0.5 (a0) 0.5 (a2)
8
Issues with PRISM

• Problem 2 ONLY the attacker can be
  nondeterministic AND all agents must be able to
  make progress at the same time
• If agents are nondeterministic
• Attacks PRISM finds will include attackers
  decisions and agents decisions
• This doesnt make sense
• Attacker should only be allowed to do a certain
  amount of actions before letting the agents
  process their state/make requests/etc.

9
Issues with PRISM

• Solution Part 1
• Simulation is turn based
• Turn counter increments from agent 0 to agent 1
  to agent 2, etc. and eventually back to agent 0

( ... Tasks for agent 0 )
10
Issues with PRISM

• Solution Part 2 Force agent to execute tasks in
  sequence
• Takes advantage of most tasks being
  self-contained and independent
• Ex If I received an interested message from
  agent 2, set internal state of
  thinks_agent_2_is_interested to true
• Ex If I think agent 2 has a block, make a
  request for that block with random probability
• Implemented with a counter variable

11
Issues with PRISM

• Solution Part 2

(Task 2)
(Task 1)
12
Issues with PRISM

• Problem 3 State space must be kept small or
  else PRISM runs out of memory
• Various optimizations were made to reduce state
  space
• Counter variable instead of boolean flag for
  whether task was done during turn
• Seeder doesnt send requests and agents dont
  send blocks to seeder
• Maximum feasible model was (unfortunately)
• 2 agents
• 2 pieces
• 1 blocks
• 1 seeder
• 1 attacker
• Anything bigger causes PRISM to run out of memory

13
Sample Code
14
Sample Code
15
Results

• Our feasible model is too small to simulate any
  realistic scenario
• Key part of attacks is blocks/piece
• agents changes how attacks would work
• In realistic scenario, agents are downloading
  from many different peers

16
Rational Reconstruction

• Handshaking protocol
• Attackers can easily change agents perception of
  other agents (what pieces they have, what pieces
  they are interested in)
• When something unusual happens, agents break
  connections
• When connection reestablished they reset their
  perceptions

17
Rational Reconstruction

• Verify message consistency
• BitTorrent protocol is unclear about what to do
  when a message is received
• Example What happens when an agent receives a
  Piece message?
• An agent should verify that they made a request
  for that data from the source IP address
• Otherwise, it could be an attacker sending bad
  data
• Similar verification of IP addresses should occur
  with other BitTorrent messages

18
DOS Opportunity in BitTorrent
If an attacker can cause an agent to accept one
bad block, the agent needs to re-download entire
piece! There are typically 200 blocks per piece
by default!
blocks/piece is a speed/security tradeoff
Good block
Bad block
19
Conclusion

• BitTorrent is too large and complicated to be
  analyzed by model checker
• More feasible approach would be to define
  specific attacks and use simulation to estimate
  their efficiency
• The conditions under which to accept data should
  be stricter than described in RFC