diff options
Diffstat (limited to 'proposals/316-flashflow.md')
| -rw-r--r-- | proposals/316-flashflow.md | 93 |
1 files changed, 48 insertions, 45 deletions
diff --git a/proposals/316-flashflow.md b/proposals/316-flashflow.md index 8258d76..6755913 100644 --- a/proposals/316-flashflow.md +++ b/proposals/316-flashflow.md @@ -56,7 +56,7 @@ time while Torflow takes days/weeks to assign them their full fair share of bandwidth (especially for non-exits). FlashFlow is more secure than Torflow: FlashFlow allows a relay to inflate its measured capacity by up to 1.33x (configured by a parameter) while Torflow allows weight -inflation by a factor of 89x [0] or even 177x [1]. +inflation by a factor of 89x [\[0\]] or even 177x [\[1\]]. After an overview in section 2 of the planned deployment stages, section 3, 4, and 5 discuss the short, medium, and long term deployment plans in @@ -133,7 +133,7 @@ allow itself to be measured more than twice by a FlashFlow deployment in any time window of this length. Relays should not change this option unless they really know what they're doing. Changing it at the relay will not change how often FlashFlow will attempt to measure the relay. -Possible values are in the range [1 hour, 1 month] inclusive. Default: 1 +Possible values are in the range \[1 hour, 1 month\] inclusive. Default: 1 day. FFBackgroundTrafficPercent: The maximum amount of regular @@ -142,7 +142,7 @@ percent of total traffic (measurement + non-measurement). This parameter is a trade off between having to limit background traffic and limiting how much a relay can inflate its result by handling no background traffic but reporting that it has done so. Possible values -are in the range [0, 99] inclusive. Default: 25 (a maximum inflation +are in the range \[0, 99\] inclusive. Default: 25 (a maximum inflation factor of 1.33). FFMaxMeasurementDuration: The maximum amount of time, in seconds, that @@ -151,7 +151,7 @@ measurement will begin soon and the end of the measurement. If this amount of time passes, the relay shall close all measurement connections and exit its measurement mode. Note this duration includes handshake time, thus it necessarily is larger than the expected actual measurement -duration. Possible values are in the range [10, 120] inclusive. +duration. Possible values are in the range \[10, 120\] inclusive. Default: 45. ### 3.1.2 New Cell Types @@ -219,7 +219,7 @@ error to the coordinator and considers the measurement a failure. It is also a failure if any measurer is unable to open at least half of its circuits with the target. -The payload of MEAS_PARAMS cells [XXX more may need to be added]: +The payload of MEAS_PARAMS cells \[XXX more may need to be added\]: ``` - meas_duration [2 bytes] [1, 600] @@ -231,10 +231,10 @@ meas_duration is the duration, in seconds, that the actual measurement will last. num_measurers is how many link_specifier structs follow containing information on the measurers that the relay should expect. Future versions of FlashFlow and MEAS_PARAMS will use TLS certificates instead of IP addresses. -[XXX probably need diff layout to allow upgrade to TLS certs instead of +\[XXX probably need diff layout to allow upgrade to TLS certs instead of link_specifier structs. probably using ext-type-length-value like teor -suggests] -[XXX want to specify number of conns to expect from each measurer here?] +suggests\] +\[XXX want to specify number of conns to expect from each measurer here?\] MEAS_PARAMS_OK has no payload: it's just padding bytes to make the cell PAYLOAD_LEN (509) bytes long. @@ -245,7 +245,7 @@ The payload of MEAS_ECHO cells: - arbitrary bytes [PAYLOAD_LEN bytes] ``` -The payload of MEAS_BG cells [XXX more for extra info? like CPU usage]: +The payload of MEAS_BG cells \[XXX more for extra info? like CPU usage\]: ``` - second [2 byte] [1, 600] @@ -260,7 +260,7 @@ subsequent cell will increment it by one. sent_bg_bytes is the number of background traffic bytes sent in the last second (since the last MEAS_BG cell). recv_bg_bytes is the same but for received bytes. -The payload of MEAS_ERR cells [XXX need field for more info]: +The payload of MEAS_ERR cells \[XXX need field for more info\]: ``` - err_code [1 byte] [0, 255] @@ -302,8 +302,8 @@ If x is very small, the relay will perform the calculation s.t. x is the number of cells required to produce 10 Mbit/s of measurement traffic, thus ensuring some minimum amount of background traffic is allowed. -[XXX teor suggests in [4] that the number 10 Mbit/s could be derived more -intelligently. E.g. based on AuthDirFastGuarantee or AuthDirGuardBWGuarantee] +\[XXX teor suggests in [\[4\]] that the number 10 Mbit/s could be derived more +intelligently. E.g. based on AuthDirFastGuarantee or AuthDirGuardBWGuarantee\] ## 3.2 FlashFlow Components @@ -317,7 +317,7 @@ values. They are: with the target relay. We suggest s=160 based on the FF paper. - The bandwidth multiplier, m. Given an existing capacity estimate for a relay, z, the coordinator will instruct the measurers to, in - aggregate, send m*z Mbit/s to the target relay. We recommend m=2.25. + aggregate, send m\*z Mbit/s to the target relay. We recommend m=2.25. - The measurement duration, d. Based on the FF paper, we recommend d=30 seconds. @@ -419,7 +419,7 @@ slot for it. It picks slot 3. The coordinator takes the next largest, ``` The coordinator takes the next largest, 250, and randomly picks slot 2. -Slot 2 already has 600 Mbit/s of measurer capacity reserved (300*m); +Slot 2 already has 600 Mbit/s of measurer capacity reserved (300\*m); given just 1000 Mbit/s of total measurer capacity, there is just 400 Mbit/s of spare capacity while this relay requires 500 Mbit/s. There is not enough room in slot 2 for this relay. The coordinator picks a new @@ -473,11 +473,11 @@ v3bw.2020-03-01-04-00-00 v3bw.2020-03-01-05-00-00 ``` -[XXX Either FF should auto-delete old ones, logrotate config should be +\[XXX Either FF should auto-delete old ones, logrotate config should be provided, a script provided, or something to help bwauths not accidentally -fill up their disk] +fill up their disk\] -[XXX What's the approxmiate disk usage for, say, a few years of these?] +\[XXX What's the approxmiate disk usage for, say, a few years of these?\] ### 3.2.2 FlashFlow Measurer @@ -532,7 +532,7 @@ report more than ~33 Mbit/s, FlashFlow limits it to just ~33 Mbit/s.) With r=25%, FlashFlow only allows 1.33x weight inflation. Prior work shows that Torflow allows weight inflation by a factor of 89x -[0] or even 177x [1]. +[\[0\]] or even 177x [\[1\]]. The ratio chosen is a trade-off between impact on background traffic and security: r=50% allows a relay to double its weight but won't impact @@ -578,7 +578,7 @@ supports it. New link- and relay-subprotocol versions will be used by the relay to indicate FF support. E.g. at the time of writing, the next relay subprotocol version is -4 [3]. +4 [\[3\]]. We plan to host a FlashFlow deployment consisting of a FF coordinator and a single FF measurer on a single 1 Gbit/s machine. Data produced by @@ -652,7 +652,7 @@ The following is quoted from Section 4.3 of the FlashFlow paper. ensures that old relays will continue to be measured, with new relays given secondary priority in the order they arrive. -[XXX Teor leaves good ideas in his tor-dev@ post [5], +\[XXX Teor leaves good ideas in his tor-dev@ post [\[5\]], including a good plain language description of what the FF paper quotes says, and a recommendation on which consensus to use when making a new schedule] @@ -665,7 +665,7 @@ time. What specifically to do here is left for medium/long term work. ## 5.3 Experiments - [XXX todo] +\[XXX todo\] ## 5.4 Other Changes/Investigations/Ideas @@ -694,28 +694,32 @@ time. What specifically to do here is left for medium/long term work. background traffic. - What to do about co-located relays. Can they be detected reliably? Should we just add a torrc option a la MyFamily for co-located relays? -- What is the explanation for dennis.jackson's scary graphs in this [2] +- What is the explanation for dennis.jackson's scary graphs in this [\[2\]] ticket? Was it because of the speed test? Why? Will FlashFlow produce the same behavior? -# Citations - -[0] F. Thill. Hidden Service Tracking Detection and Bandwidth Cheating - in Tor Anonymity Network. Master’s thesis, Univ. Luxembourg, 2014. - https://www.cryptolux.org/images/b/bc/Tor_Issues_Thesis_Thill_Fabrice.pdf -[1] A. Johnson, R. Jansen, N. Hopper, A. Segal, and P. Syverson. - PeerFlow: Secure Load Balancing in Tor. Proceedings on Privacy - Enhancing Technologies (PoPETs), 2017(2), April 2017. - https://ohmygodel.com/publications/peerflow-popets2017.pdf -[2] Mike Perry: Graph onionperf and consensus information from Rob's - experiments - https://trac.torproject.org/projects/tor/ticket/33076 -[3] tor-spec.txt Section 9.3 "Relay" Subprotocol versioning - https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n2132 -[4] Teor's second respose to FlashFlow proposal - https://lists.torproject.org/pipermail/tor-dev/2020-April/014251.html -[5] Teor's first respose to FlashFlow proposal - https://lists.torproject.org/pipermail/tor-dev/2020-April/014246.html +<!-- # Citations --> + +[\[0\]]: <https://www.cryptolux.org/images/b/bc/Tor_Issues_Thesis_Thill_Fabrice.pdf> +"F. Thill. Hidden Service Tracking Detection and Bandwidth Cheating +in Tor Anonymity Network. Master’s thesis, Univ. Luxembourg, 2014." + +[\[1\]]: <https://ohmygodel.com/publications/peerflow-popets2017.pdf> +"A. Johnson, R. Jansen, N. Hopper, A. Segal, and P. Syverson. +PeerFlow: Secure Load Balancing in Tor. Proceedings on Privacy +Enhancing Technologies (PoPETs), 2017(2), April 2017." + +[\[2\]]: <https://trac.torproject.org/projects/tor/ticket/33076> +"Mike Perry: Graph onionperf and consensus information from Rob's experiments" + +[\[3\]]: ../tor-spec/subprotocol-versioning.md#relay +"Tor Specification: \"Relay\" Subprotocol versioning" + +[\[4\]]: <https://lists.torproject.org/pipermail/tor-dev/2020-April/014251.html> +"Teor's second response to FlashFlow proposal" + +[\[5\]]: <https://lists.torproject.org/pipermail/tor-dev/2020-April/014246.html> +"Teor's first response to FlashFlow proposal" # Appendix A: Save CPU at measurer by not encrypting all MEAS_ECHO cells @@ -745,10 +749,10 @@ measurement. Consider bucket_size is 1000. For the moment ignore cell encryption. -We start at idx=0 and pick an idx in [0, 1000) to record, say 640. At -idx=640 we record the cell. At idx=1000 we choose a new idx in [1000, +We start at idx=0 and pick an idx in \[0, 1000) to record, say 640. At +idx=640 we record the cell. At idx=1000 we choose a new idx in \[1000, 2000) to record, say 1236. At idx=1236 we record the cell. At idx=2000 -we choose a new idx in [2000, 3000). Etc. +we choose a new idx in \[2000, 3000). Etc. There's 2000+ cells in flight and the measurer has recorded two items: @@ -821,7 +825,7 @@ will have (49/50)^(2*146) or 0.2% odds of success, which is quite low. Wanting a <1% chance that a 10 Mbit/s relay can successfully cheat results in a bucket size of approximately 125: -- 10*30 = 300 Mbit of traffic during 30s measurement. 37.5 million +- 10\*30 = 300 Mbit of traffic during 30s measurement. 37.5 million bytes. - 37,500,000 bytes / 514 bytes/cell = ~73,000 cells - bucket_size of 125 cells means 73,000 / 125 = 584 buckets @@ -830,4 +834,3 @@ results in a bucket size of approximately 125: Slower relays can cheat more easily but the amount of extra weight they can obtain is insignificant in absolute terms. Faster relays are essentially unable to cheat. - |