1 / 20

Scalable Onion Routing with Torsk

Scalable Onion Routing with Torsk. Presented by Huabo Lu. Images of Torsk. For v isual learning, here is how Torsk looks like:. Scalable Onion Routing with Torsk. Onion Routing Tor Scalable Onion Routing Tor would not scale.

liz
Download Presentation

Scalable Onion Routing with Torsk

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. Scalable Onion Routing with Torsk Presented by Huabo Lu

  2. Images of Torsk For visual learning, here is how Torsk looks like:

  3. Scalable Onion Routing with Torsk • Onion Routing • Tor • Scalable Onion Routing • Tor would not scale. • Scale is important: large number of users is a must for anonymity. • Torsk: P2P & DHT lookup mechanism for relay nodes selection and communication circuit construction. • P2P: Peer to Peer • DHT: Distributed Hash Table

  4. The problem: TOR would not scale • General framework for anonymous networking: • Centralized schemes: • All traffic flows over a small, constant routes, • Trivial relay discovery, • Limited # of users. • P2P: • Relay and client • More scalable • Unstable service • Various attack, due to imperfect knowledge.

  5. The problem: TOR would not scale • TOR is a hybrid of: • (Centralized) trusted directory servers • Maintain a good list of active relays. • (P2P) all nodes (freely) can join as a relay or client • Available bandwidth increases as more nodes (relay) join • Seems all right since: • You know which relay to trust, • You have more bandwidth as more relays joins. As of 2009: 10K simultaneous users,2K relay nodes.

  6. The problem: TOR would not scale • A closer look: • Each client needs to know the all relays info to select relays, periodically. • Relay info: status docs, router descriptors(pubic key, exit policy…) … • And all these request are filled by trusted directory servers! • Directory servers (DS) may overload. • Even if we have sufficient DS, the whole Tor network is flooded with relay info.

  7. The prolem: TOR would not scale

  8. The problem: TOR would not scale • Let’s quantify: • Bandwidth needed for relay info O(nr), • n: # of users • r: # of relays • Bandwidth provided by relay: O(r)

  9. The solution: TORSK • Introducing TORSK: • A new design for a low-latency anonymous networking scheme • Better scalability • Introduces no new attack • Incrementally deployable: relays can serve both Tor and Torsk. • O(n log r): bandwidth spent on relay selection (relay info)

  10. The solution: TORSK • How: • By using NA BS DHT • NA: Neighborhood Authority • BS: Buddy Support • DHT: Distributed Hash Table

  11. The solution: TORSK • Background: TOR • Providing anonymity by using encrypted circuit for traffic. • (Default) circuit length = 3, • Entry node .. Knows sender, but not receiver • Intermediate node .. Knows entry/exit nodes • Exit node .. Knows receiver, but not sender • Three types of node: • OP: onion proxy, client • OR: onion router, relay • DS: directory server,

  12. The solution: TORSK • Background: DHT • Each node holds a piece of hash table • A look up process: • A node wants to file look up request, s/he must know where this request can be served. • Some nodes may provide routing info, so the initializer node knows where to send the look up request. • The node sends look up request to the right node, so that a look up can be done there. • What is the benefit of “a piece of hash table”? • Well, e.g. Wichita’s post office does not need New York’s street addr. • O(nr) vs. O(n log r)

  13. The solution: TORSK • Background: DHT • Attacks to DHT: • Misrouting • Passive logging • Selective dropping • Route fingerprinting • … • That is why we need NABSDHT • NA: Neighborhood Authority • BS: Buddy Support

  14. The solution: TORSK • We do have NA DHT: Myrmic • Myrmic: • Issues certificate (relatively long term) to each node • Node’s neighbors keep eyes on each other • So a node can hardly claim something incorrect • Myrmicsolves: • Misrouting • Selective dropping

  15. The solution: TORSK • Everything set? Not really. • E.g., “Hi, I am writing to you to verify that …” • What you verified exposed your interest/node/circuit. • Also, looking up a node is kind of multicast. • You send to multiple nodes to do the look up.

  16. The solution: TORSK • OK, since looking up and verifying are exposing, how about we delegate these jobs to someone else? • That is NA BS DHT • BS: buddy support • More stranger than buddy • Perform random walk to select a buddy

  17. The solution: TORSK

  18. The solution: TORSK

  19. The solution: TORSK • That is general idea of Torsk. • Does it work? • According to the author, yes. • Tons of technique details. • E.g.

  20. Thank you!

More Related