diff options
| -rw-r--r-- | dir-spec.txt | 35 | ||||
| -rw-r--r-- | proposals/xxx-expose-bandwidth-files.txt | 85 |
2 files changed, 113 insertions, 7 deletions
diff --git a/dir-spec.txt b/dir-spec.txt index f2447c2..f15da95 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -2607,6 +2607,28 @@ IPv4 addresses (two /8 networks) were blocked. The list is encoded as described in section 3.8.2. +3.4.3 Serving bandwidth list files + + If an authority has used a bandwidth list file to generate a vote + document it SHOULD make it available at + + http://<hostname>/tor/status-vote/next/bandwidth.z + + at the start of each voting period. + + It MUST NOT attempt to send its bandwidth list file in a HTTP POST to + other authorities and it SHOULD NOT make bandwidth list files from other + authorities available. + + If an authority makes this file available, it MUST be the bandwidth file + used to create the vote document available at + + http://<hostname>/tor/status-vote/next/authority.z + + The bandwidth list format is described in bandwidth-file-spec.txt. + + The standard URLs for bandwidth list files first-appeared in Tor 0.3.5. + 3.5. Downloading missing certificates from other directory authorities XXX when to download certificates. @@ -3329,16 +3351,14 @@ 3.11. Publishing the signed consensus - Once there are enough signatures, or once the voting period starts, - these documents are available at + The voting period ends at the valid-after time. If the consensus has + been signed by a majority of authorities, these documents are made + available at http://<hostname>/tor/status-vote/current/consensus.z and http://<hostname>/tor/status-vote/current/consensus-signatures.z [XXX current/consensus-signatures is not currently implemented, as it is not used in the voting protocol.] - [XXX It's actually false that the first document is available as soon - as there are enough signatures. It's only available as soon as the - voting period starts. -KL] [XXX possible future features include support for downloading old consensuses.] @@ -3347,13 +3367,15 @@ http://<hostname>/tor/status-vote/current/authority.z http://<hostname>/tor/status-vote/current/<fp>.z http://<hostname>/tor/status-vote/current/d/<d>.z - once the consensus is complete. + http://<hostname>/tor/status-vote/current/bandwidth.z + once the voting period ends, regardless of the number of signatures. The authorities serve another consensus of each flavor "F" from the locations /tor/status-vote/(current|next)/consensus-F.z. and /tor/status-vote/(current|next)/consensus-F/<FP1>+....z. + The standard URLs for bandwidth list files first-appeared in Tor 0.3.5. 4. Directory cache operation @@ -4021,4 +4043,3 @@ E. Limited ed diff format just a period (".") ends the block (and is not part of the lines to add). Note that it is impossible to insert a line with just a single dot. - diff --git a/proposals/xxx-expose-bandwidth-files.txt b/proposals/xxx-expose-bandwidth-files.txt new file mode 100644 index 0000000..12abe0e --- /dev/null +++ b/proposals/xxx-expose-bandwidth-files.txt @@ -0,0 +1,85 @@ +Filename: xxx-expose-bandwidth-files.txt +Title: Have Directory Authorities expose raw bandwidth list files +Author: Tom Ritter +Created: 11-December-2017 +Status: Open +Ticket: https://trac.torproject.org/projects/tor/ticket/21377 + +1. Introduction + +Bandwidth Authorities (bwauths) perform scanning of the Tor Network +and calculate observed bandwidths for each relay. They produce a bandwidth +list file that is given to a Directory Authority. The Directory +Authority uses the bw (bandwidth) value from this file in its vote file +denoting its view of the bandwidth of the relay. + +After collecting all of the votes from other Authorities, a consensus +is calculated, and the consensus's view of a relay's speed is +determined by choosing the low-median value of all the authorities' +values for each relay. + +Only a single metric from the bandwidth list file is exposed by a +Directory Authority's vote, however the original file contains +considerably more diagnostic information about how the bwauth arrives +at that measurement for that relay. + +For more details, see the bandwidth list file specification in +bandwidth-file-spec.txt. + +2. Motivation + +The bandwidth list file contains more information than is exposed in the +overall vote file. This information is useful to debug: + * anomalies in relays' utilization, + * suspected bugs in the (decrepit) bwauth code, and + * the transition to a replacement bwauth implementation. + +Currently, all bwauths expose the bandwidth list file through various (non- +standard) means, and that file is downloaded (hourly) by a single person +(as long as his home internet connection and home server is working) +and archived (with a small amount of robustness.) + +It would be preferable to have this exposed in a standard manner. +Doing so would no longer require bwauths to run HTTP servers to expose +the file, no longer require them to take additional manual steps to +provide it, and would enable public consumption by any interested +parties. We hope that Collector will begin archiving the files. + +3. Specification + +An authority SHOULD publish the bandwidth list file used to calculate its +next vote. It SHOULD make the bandwidth list file available whenever the +corresponding vote is available, at the corresponding URL. (See +dir-spec for the exact details.) + +It SHOULD make the file available at + http://<hostname>/tor/status-vote/next/bandwidth.z + http://<hostname>/tor/status-vote/current/bandwidth.z + +It MUST NOT attempt to send its bandwidth list file in a HTTP POST to +other authorities and it SHOULD NOT make bandwidth list files from other +authorities available. + +Clients interested in consuming these documents should download them from +each authority's: + * next URL when votes are created. (In the public Tor network, this is + after HH:50 during normal operation, and after HH:20 during a + consensus failure.) + * current URL after the valid-after time in the consensus. + (After HH:00, and HH:30 during consensus failure.) + +4. Security Implications + +The raw bandwidth list file does not [really: is not believed to] expose +any sensitive information. All authorities currently make this +document public already, an example is at + https://bwauth.ritter.vg/bwauth/bwscan.V3BandwidthsFile + +5. Compatibility + +Exposing the document presents no compatibility concerns. + +Applications that parse the document should follow the bandwidth list file +specification in bandwidth-file-spec.txt. +If a new bandwidth list format version is added, the applications MAY need +to upgrade to that version.
\ No newline at end of file |