From f9b2aba9b9b93209d9ed3aa0ec17de7520e30678 Mon Sep 17 00:00:00 2001 From: Jim Newsome Date: Tue, 14 Nov 2023 13:30:54 -0600 Subject: flashflow: linkify citations --- proposals/316-flashflow.md | 50 ++++++++++++++++++++++++---------------------- 1 file changed, 26 insertions(+), 24 deletions(-) (limited to 'proposals/316-flashflow.md') diff --git a/proposals/316-flashflow.md b/proposals/316-flashflow.md index ed62cf7..4a1fa15 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\]](#0) or even 177x [\[1\]](#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 @@ -302,7 +302,7 @@ 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 +\[XXX teor suggests in [\[4\]](#4) that the number 10 Mbit/s could be derived more intelligently. E.g. based on AuthDirFastGuarantee or AuthDirGuardBWGuarantee\] ## 3.2 FlashFlow Components @@ -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\]](#0) or even 177x [\[1\]](#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\]](#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\]](#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] @@ -694,30 +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\]](#2) ticket? Was it because of the speed test? Why? Will FlashFlow produce the same behavior? # Citations -```text -[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 -``` +\[0\]: F. Thill. Hidden Service Tracking Detection and Bandwidth Cheating +in Tor Anonymity Network. Master’s thesis, Univ. Luxembourg, 2014. + + +\[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. + + +\[2\]: Mike Perry: Graph onionperf and consensus information from Rob's +experiments + +\[3\]: tor-spec.txt Section 9.3 "Relay" Subprotocol versioning + + +\[4\]: Teor's second respose to FlashFlow proposal + + +\[5\]: Teor's first respose to FlashFlow proposal + # Appendix A: Save CPU at measurer by not encrypting all MEAS_ECHO cells -- cgit v1.2.3-54-g00ecf