Changes between Initial Version and Version 1 of org/meetings/2017Montreal/Notes/BWAuthandTorScanning

Oct 13, 2017, 3:58:53 PM (2 years ago)

added notes


  • org/meetings/2017Montreal/Notes/BWAuthandTorScanning

    v1 v1  
     3meeting notes
     6goal of session is to talk about directory/bandwidth authority systems
     7and scanning tor relays for other properties
     9Current code of bw auth system is very old.
     11BW authorities download over a Tor circuit to measure bandwidth of the relays involves;
     12Downloading content of various locations may change results.
     13Possibility of using a CDN to host data that is downloaded.
     15bw auth tools:
     17a. Current state of torflow is that it is old and breaks often... is not maintained.
     18b. bwscanner, a newer tool has more recently received attention from Aaron Gibson and Donncha.
     19c. bridge bw scanner being built by intern of Isis
     21complaints of torflow:
     22- difficult to maintain
     23- difficult to diagnose problems
     24- difficult to setup
     25- old and insecure libraries
     26- not available in recent distros
     30- audit torflow and bwscanner and other tool(s): compare methodologies.
     31- port torflow to supported deps or not?
     32- ask one or two more dir auth to run torflow
     33- setup test env for testing changes to torflow
     34  1. try implement local integration testing with chutney
     35  2. deploy code on test tor network
     36  3. run parallel bw auths on live network
     37  4. use a fraction of the live network for testing
     38(cons to running torflow: servers that run it might get pwned)
     39- ask 2 more authorities to run torflow or other tool
     40- it would be good to have a design document for the bw auth
     41- determine how results are computed
     42- compare results of torflow to "new tool"
     43- staged migration
     44- bw auth client and servers outside of the EU/NorthAmerica
     45- develop good metrics to determine if new design of the bw auth is better or worse
     46- what kind of metrics does OONI provide that would be useful to our determining
     47if a new bw auth design is better or worse.
     48- determine what kind of transition to a new bw auth: one big switch or gradual?
     49- perhaps use a test set of the dir auth to see if the vote results are accurate
     50- nickm suggests possibly putting both old and new bandwidth measurements in the consensus
     51- direct e-mails regarding bw auth to tor-dev mailing list
     53design of bw auth:
     55- ratio of reported bandwidth versus measured bandwidth
     56  w/ decayed weighted involved
     57- medium as measurement from bw auth is what ends up in consensus
     58- metric not completely defined
     59- client geographic location biases results: not sure what the solution is.
     60- many relays started in south america get very little traffic
     61- out of scope to get clients to measure nearby relays
     62- ask bw auths to expose the readonly bandwidths file
     65other scans of tor network
     68- meejah suggests possibly combining exitmap-like scan with bwauth scan:
     69  his tool downloads an EXE file to see if an exit relay modifies it
     70- connectivity testing: terrible results from scanning top 100 relays with fast and stable flags
     72two papers are about how relays can determine bandwidth of circuits:
     73- peerflow:
     74  (shadow repo has a torflow port to C which might be useful)
     75- eigen speed
     76- torperf?