<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><br><div>On 29 Jan 2018, at 08:00, Florentin Rochet <<a href="mailto:florentin.rochet@uclouvain.be">florentin.rochet@uclouvain.be</a>> wrote:<br><br></div><blockquote type="cite"><div><span>Hello,</span><br><br><span>On 28/01/18 11:52, teor wrote:</span><br><blockquote type="cite"><span>Hi,</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I have some more questions:</span><br></blockquote><span></span><br><span>Nice, thanks! I still have to answer your previous email and push an</span><br><span>update to the proposal. I should do it this week, sorry for late answers :)</span><br><span></span><br><span>See inline a few answers to your questions:</span><br><span></span><br><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>On 18 Jan 2018, at 11:03, teor <<a href="mailto:teor2345@gmail.com">teor2345@gmail.com</a>> wrote:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Unanswered questions:</span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><span>The Tor network has been experiencing excessive load on guards and </span><br></blockquote><blockquote type="cite"><span>middles since December 2017.</span><br></blockquote><span></span><br><span>If I have correctly followed what was happening: around 1M tor2web</span><br><span>clients appeared at OVH</span></div></blockquote><div><br></div><div>Not just OVH, at least 3 different providers.</div><div><br></div><div>And not just Tor2web, either.</div><div>There are onion services which are overloading the network</div><div>as well, probably in response to these clients. The onion services</div><div>are mostly overloading guard-weighted nodes.</div><br><blockquote type="cite"><div><span>and started to overload the network with circuit</span><br><span>creation requests using the old and costly TAP handshake.</span></div></blockquote><div><br></div><div>Not just TAP. The sheer number of entry connections, extend requests,</div><div>and destroy cells is also creating overloads on some relays.</div><br><blockquote type="cite"><div><span>Tor2web</span><br><span>clients make direct connections to the intro point and to the rendezvous</span><br><span>point, right?</span></div></blockquote><div><br></div><div>Yes.</div><br><blockquote type="cite"><div><span>And, looking into the code right now, it does not looks</span><br><span>like Tor2webs make any distinction to flags. So, basically, the Tor2web</span><br><span>load is only weighted by consensus weight (bandwidth-weights have no</span><br><span>impact) on the overall network (exits too).</span><br></div></blockquote><div><br></div><div>This only applies if Tor2webRendezvousPoints is set.</div><div>Otherwise, the nodes are middle-weighted.</div><br><blockquote type="cite"><div><span>Guess: shouldn't that the reason why all exits logs are flooded with the</span><br><span>message "[warn] Tried to establish rendezvous on non-OR circuit with</span><br><span>purpose Acting as rendevous (pending)"? Those messages would be caused</span><br><span>by tor2web clients picking exit relays as rendezvous node :/ I started</span><br><span>to see them increasing more and more since August 2017.</span><br></div></blockquote><div><br></div><div>No, this is a different issue.</div><div>Exit relays are allowed as rendezvous nodes.</div><br><blockquote type="cite"><div><span>So basically, I *think* we can drop the questions below because</span><br><span>bandwidth-weights do not play any role in the excessive load that the</span><br><span>network is handling with those tor2webs.</span><br></div></blockquote><div><br></div><div><div>Guard weights are used by overloading onion services, and middle</div><div>weights are used by overloading Tor2web clients.</div><br><blockquote type="cite"><div><blockquote type="cite"><span>Does the waterfilling proposal make excessive load on guards worse, by</span><br></blockquote><blockquote type="cite"><span>allocating more guard weight to lower capacity relays?</span><br></blockquote><blockquote type="cite"><span>Is the extra security worth the increased risk of failure?</span></blockquote></div></blockquote><div><br></div><div><div><span style="background-color: rgba(255, 255, 255, 0);">We want to design a network that can handle different kinds of extra load.</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">So these questions are important, even if they don't apply right now.</span></div></div><br><blockquote type="cite"><div><blockquote type="cite"><span>Does the waterfilling proposal make excessive load on middles better, by</span><br></blockquote><blockquote type="cite"><span>allocating more middle weight to higher capacity relays?</span><br></blockquote><blockquote type="cite"><span>Is there a cascading failure mode, where excess middle weight overwhelms</span><br></blockquote><blockquote type="cite"><span>our top relays one by one? (It seems unlikely.)</span></blockquote></div></blockquote><div><br></div><div>I'm going to re-ask this questions, in light of the extra middle load from</div><div>Tor2web clients:</div><div><br></div><div><div><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">Does the waterfilling proposal make excessive load on middles worse, by<br></span></font></div><div><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">allocating more middle weight to higher capacity relays?<br></span></font></div><div><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);"><br></span></font></div><div><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">In particular, connections are limited by file descriptors, and file descriptor</span></font></div><div><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">limits typically don't scale with the bandwidth of the relay. As far as I can tell,</span></font></div><div><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">waterfilling would have directed additional Tor2web traffic to large guards.</span></font></div><div><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">It would have brought down my guards faster, and made it much </span></font><span style="background-color: rgba(255, 255, 255, 0);">harder for me</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">to keep them up.</span></div></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div>If we had implemented waterfilling before this attack, would it have lead to</div><div>cascading failures on our top guards? They would have been carrying</div><div>significantly more middle load, and mine barely managed to cope.</div><div><br></div><div>Can you redesign the proposal so there is some limit on the extra middle load</div><div>assigned to a guard? Or does this ruin the security properties?</div><div><br></div><div>Is there a compelling argument for security over network robustness?</div><br><blockquote type="cite"><div><blockquote type="cite"><span></span></blockquote><blockquote type="cite"><span>I also have another practical question:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>We struggle to have time to maintain the current bandwidth authority</span><br></blockquote><blockquote type="cite"><span>system.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Is it a good idea to make it more complicated?</span><br></blockquote><span></span><br><span>Hm, I don't see how Waterfilling plays any role with torflow or</span><br><span>bwscanner? I mean, there is still this feedback loop thing but it has no</span><br><span>impact on the design of the current torflow or bwscanner?</span></div></blockquote><div><br></div><div>I can't really say.</div><div>I look forward to your explanation of the feedback loop. </div><br><blockquote type="cite"><div><span>Could you be</span><br><span>more specific about your concerns with the bandwidth authorities and</span><br><span>this proposal?</span></div></blockquote><div><br></div><div>It takes time and effort from Tor people to integrate and maintain the</div><div>code and monitoring for a new proposal like this one.</div><div><br></div><div>We will need to take extra time on this proposal, because we already need</div><div>more monitoring for the current bandwidth authority system. And only then</div><div>would we have time to build monitoring specific to this proposal.</div><div><br></div><div>Also, when we change bandwidth measurement or allocation, we need to</div><div>change one thing at a time, and then monitor the change. So depending</div><div>on our priorities, this proposal may need to wait until after we implement</div><div>and monitor other urgent fixes.</div><br><blockquote type="cite"><div><blockquote type="cite"><span>Who will maintain the new code we add to Tor to implement waterfilling?</span><br></blockquote><span></span><br><span>I would volunteer to that.</span><br></div></blockquote><div><br></div><div>Typically, experienced Core Tor team members review and maintain code.</div><div><br></div><div>And there's still a lot of development and testing work to be done before</div><div>the code is ready to merge. Are you able to do this development?</div><div><br></div><div>How much help will you need to write a new consensus method?</div><div>How much help will you need to write unit tests?</div><div>(This help will come from existing team members.)</div><div><br></div><div>Does your current code pass:</div><div>* make check</div><div>* make test-network-all</div><div> * in particular, any new consensus method must pass the "mixed" network,</div><div> with an unpatched Tor version in your path as "tor-stable"</div><div><br></div><blockquote type="cite"><div><blockquote type="cite"><span>Who will build the analysis tools to show that waterfilling benefits the</span><br></blockquote><blockquote type="cite"><span>network?</span><br></blockquote><span></span><br><span>Volunteers or master students. I can definitely suggest this topic in my</span><br><span>university.</span><br></div></blockquote><div><br></div><div>Typically, experienced Tor Metrics team members write, review, and maintain</div><div>monitoring systems. And they don't have a lot of extra capacity right now.</div><div><br></div><div>Even if students do this task, they would need help from existing team</div><div>members.</div><br><blockquote type="cite"><div><blockquote type="cite"><span>Do the benefits of waterfilling justify this extra effort?</span><br></blockquote><span></span><br><span>Question for the other Tor devs :) I am definitely biased towards the "yes"</span><br></div></blockquote><div><br></div><div><div><span style="background-color: rgba(255, 255, 255, 0);">It seems plausible, but I don't feel I have seen a compelling enough argument</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">to prioritise it above fixing bandwidth authorities.</span></div></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><div><span style="background-color: rgba(255, 255, 255, 0);">At the moment, reasonably fast guards </span><span style="background-color: rgba(255, 255, 255, 0);">in Eastern North America and Western</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">Europe are overloaded with client traffic. </span><span style="background-color: rgba(255, 255, 255, 0);">And guards in the rest of the world</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">are under-loaded. </span>Reducing this bias is something we need to do.</div></div><div><br></div><div>And this proposal gets us better security if we fix this geographical bias first.</div><div>Otherwise, adversaries can simply pick a location that massively increases</div><div>their consensus weight, and get lots of client traffic.</div><br><blockquote type="cite"><div><blockquote type="cite"><span>And even if they do, should we focus on getting the bandwidth authorities</span><br></blockquote><blockquote type="cite"><span>in a maintainable state, before adding new features?</span><br></blockquote><blockquote type="cite"><span>(I just gave similar advice to another developer who has some great ideas</span><br></blockquote><blockquote type="cite"><span>about improving bandwidth measurement.)</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><span></span><br><span>Bandwidth-weights and measurements (consensus weights) are two different</span><br><span>things that solve 2 different problems. So, we can work independently on</span><br><span>improving measurements (like what is currently done with bwscanner) and</span><br><span>improving Tor's balancing (bandwidth-weights) with this proposal.</span><br></div></blockquote><div><br></div><div>I don't think this is realistic.</div><div>There is always contention for shared resources.</div><div><br></div><div>Integrating and testing new code, and monitoring its effects, will take effort from</div><div>the teams I mentioned above. This takes away from the urgent work of fixing the</div><div>bandwidth authority system. Which also takes effort from the Core Tor and</div><div>Metrics teams.</div><br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>What about the feedback loop between this new allocation system</span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>and the bandwidth authorities?</span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I am sorry, I don't really understand why a feedback loop is needed. Measuring bandwidth and producing bandwidth-weights seems orthogonal to me.</span><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>You do not need to add a feedback loop, one already exists:</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>1. Consensus weights on guards and middles change</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>2. Client use of guards and middles change</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>3. Bandwidth authority measurements of guards and middles change</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>4. Repeat from 1</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>My question is:</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>How does this existing feedback loop affect your proposal?</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Does it increase or reduce the size of the guard and middle weight changes?</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I have added those questions to the proposal. This looks difficult to know.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Can shadow simulate this?</span><br></blockquote></blockquote><blockquote type="cite"><span>I am still interested in this feedback loop.</span><br></blockquote><blockquote type="cite"><span>If it fails to converge, the system will break down.</span><br></blockquote><span></span><br><span>Yup. Going to answer this on your previous email.</span><br><blockquote type="cite"><span></span></blockquote></blockquote><br></div><div>T</div></body></html>