1 / 19

BitTorrent

BitTorrent. Nathan Marz Raylene Yung. 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)

abena
Download Presentation

BitTorrent

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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] -> [probability distribution of results]

  7. Issues with PRISM • Solution: Hierarchical commands Cond: a = 1 Cond: b = 1 & c=1 Cond: b=2 Cond: ELSE Result: 0.5: a’=0 + 0.5: a’=2 Result: c’=2 Result: c’=3 Result: NULL [] a=1 & b=1 & c=1 -> 0.5: (a’=0) & (c’=2) + 0.5: (a’=2) & (c’=2); [] a=1 & b=2 -> 0.5: (a’=0) & (c’=3) + 0.5: (a’=2) & (c’=3); [] a=1 & !(b=1 & c=1) & !(b=2) -> 0.5: (a’=0) + 0.5: (a’=2); ELSE <-> Conjunction of negations of siblings

  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 attacker’s decisions and agent’s decisions • This doesn’t 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 Cond: turn=0 Cond:ELSE Result: NULL Result: turn’=1 ( ... 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 Cond: turn=0 Cond:ELSE Cond: counter=0 Cond: counter=1 Cond: ELSE Cond: ELSE Result: NULL Result: turn’=1 & counter’=0 Result: counter’=1 Result: counter’=2 Result: NULL Result: NULL (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 doesn’t send requests and agents don’t 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! Honest agent #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

More Related