wiki:org/meetings/2017Montreal/Notes/BWAuthandTorScanning

meeting notes


goal of session is to talk about directory/bandwidth authority systems and scanning tor relays for other properties

Current code of bw auth system is very old.

BW authorities download over a Tor circuit to measure bandwidth of the relays involves; Downloading content of various locations may change results. Possibility of using a CDN to host data that is downloaded.

bw auth tools:

  1. Current state of torflow is that it is old and breaks often... is not maintained.
  2. bwscanner, a newer tool has more recently received attention from Aaron Gibson and Donncha.
  3. bridge bw scanner being built by intern of Isis

complaints of torflow:

  • difficult to maintain
  • difficult to diagnose problems
  • difficult to setup
  • old and insecure libraries
  • not available in recent distros

tasks:

  • audit torflow and bwscanner and other tool(s): compare methodologies.
  • port torflow to supported deps or not?
  • ask one or two more dir auth to run torflow
  • setup test env for testing changes to torflow
    1. try implement local integration testing with chutney
    2. deploy code on test tor network
    3. run parallel bw auths on live network
    4. use a fraction of the live network for testing

(cons to running torflow: servers that run it might get pwned)

  • ask 2 more authorities to run torflow or other tool
  • it would be good to have a design document for the bw auth
  • determine how results are computed
  • compare results of torflow to "new tool"
  • staged migration
  • bw auth client and servers outside of the EU/NorthAmerica
  • develop good metrics to determine if new design of the bw auth is better or worse
  • what kind of metrics does OONI provide that would be useful to our determining

if a new bw auth design is better or worse.

  • determine what kind of transition to a new bw auth: one big switch or gradual?
  • perhaps use a test set of the dir auth to see if the vote results are accurate
  • nickm suggests possibly putting both old and new bandwidth measurements in the consensus
  • direct e-mails regarding bw auth to tor-dev mailing list

design of bw auth:

  • ratio of reported bandwidth versus measured bandwidth w/ decayed weighted involved
  • medium as measurement from bw auth is what ends up in consensus
  • metric not completely defined
  • client geographic location biases results: not sure what the solution is.
  • many relays started in south america get very little traffic
  • out of scope to get clients to measure nearby relays
  • ask bw auths to expose the readonly bandwidths file

other scans of tor network


  • meejah suggests possibly combining exitmap-like scan with bwauth scan: his tool downloads an EXE file to see if an exit relay modifies it
  • connectivity testing: terrible results from scanning top 100 relays with fast and stable flags

two papers are about how relays can determine bandwidth of circuits:

  • peerflow: (shadow repo has a torflow port to C which might be useful)
  • eigen speed
  • torperf?

https://github.com/shadow/shadow-plugin-tor/

Last modified 6 months ago Last modified on Oct 13, 2017, 3:58:53 PM