Loading dir-spec.txt +28 −7 Original line number Diff line number Diff line Loading @@ -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. Loading Loading @@ -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.] Loading @@ -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 Loading Loading @@ -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. proposals/xxx-expose-bandwidth-files.txt 0 → 100644 +85 −0 Original line number Diff line number Diff line 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 Loading
dir-spec.txt +28 −7 Original line number Diff line number Diff line Loading @@ -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. Loading Loading @@ -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.] Loading @@ -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 Loading Loading @@ -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.
proposals/xxx-expose-bandwidth-files.txt 0 → 100644 +85 −0 Original line number Diff line number Diff line 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
