Not just OVH, at least 3 different providers. And not just Tor2web, either. There are onion services which are overloading the network as well, probably in response to these clients. The onion services are mostly overloading guard-weighted nodes.
Not just TAP. The sheer number of entry connections, extend requests, and destroy cells is also creating overloads on some relays.
Yes.
This only applies if Tor2webRendezvousPoints is set. Otherwise, the nodes are middle-weighted.
No, this is a different issue. Exit relays are allowed as rendezvous nodes.
Guard weights are used by overloading onion services, and middle weights are used by overloading Tor2web clients.
We want to design a network that can handle different kinds of extra load. So these questions are important, even if they don't apply right now.
I'm going to re-ask this questions, in light of the extra middle load from Tor2web clients: Does the waterfilling proposal make excessive load on middles worse, by allocating more middle weight to higher capacity relays? In particular, connections are limited by file descriptors, and file descriptor limits typically don't scale with the bandwidth of the relay. As far as I can tell, waterfilling would have directed additional Tor2web traffic to large guards. It would have brought down my guards faster, and made it much harder for me to keep them up. If we had implemented waterfilling before this attack, would it have lead to cascading failures on our top guards? They would have been carrying significantly more middle load, and mine barely managed to cope. Can you redesign the proposal so there is some limit on the extra middle load assigned to a guard? Or does this ruin the security properties? Is there a compelling argument for security over network robustness?
I can't really say. I look forward to your explanation of the feedback loop.
It takes time and effort from Tor people to integrate and maintain the code and monitoring for a new proposal like this one. We will need to take extra time on this proposal, because we already need more monitoring for the current bandwidth authority system. And only then would we have time to build monitoring specific to this proposal. Also, when we change bandwidth measurement or allocation, we need to change one thing at a time, and then monitor the change. So depending on our priorities, this proposal may need to wait until after we implement and monitor other urgent fixes.
Typically, experienced Core Tor team members review and maintain code. And there's still a lot of development and testing work to be done before the code is ready to merge. Are you able to do this development? How much help will you need to write a new consensus method? How much help will you need to write unit tests? (This help will come from existing team members.) Does your current code pass: * make check * make test-network-all * in particular, any new consensus method must pass the "mixed" network, with an unpatched Tor version in your path as "tor-stable"
Typically, experienced Tor Metrics team members write, review, and maintain monitoring systems. And they don't have a lot of extra capacity right now. Even if students do this task, they would need help from existing team members.
It seems plausible, but I don't feel I have seen a compelling enough argument to prioritise it above fixing bandwidth authorities. At the moment, reasonably fast guards in Eastern North America and Western Europe are overloaded with client traffic. And guards in the rest of the world are under-loaded. Reducing this bias is something we need to do. And this proposal gets us better security if we fix this geographical bias first. Otherwise, adversaries can simply pick a location that massively increases their consensus weight, and get lots of client traffic.
I don't think this is realistic. There is always contention for shared resources. Integrating and testing new code, and monitoring its effects, will take effort from the teams I mentioned above. This takes away from the urgent work of fixing the bandwidth authority system. Which also takes effort from the Core Tor and Metrics teams. What about the feedback loop between this new allocation systemand the bandwidth authorities?I am sorry, I don't really understand why a feedback loop is needed. Measuring bandwidth and producing bandwidth-weights seems orthogonal to me.You do not need to add a feedback loop, one already exists:1. Consensus weights on guards and middles change2. Client use of guards and middles change3. Bandwidth authority measurements of guards and middles change4. Repeat from 1My question is:How does this existing feedback loop affect your proposal?Does it increase or reduce the size of the guard and middle weight changes?I have added those questions to the proposal. This looks difficult to know.Can shadow simulate this?I am still interested in this feedback loop.If it fails to converge, the system will break down. T |
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev