s7r s7r@sky-ip.org writes:
[ text/plain ] Hello,
teor, asn, see comments inline.
On 3/24/2016 5:00 PM, Tim Wilson-Brown - teor wrote: [snip]
[snip]
This isn't how Tor works - it tries multiple guards simultaneously. (See below for details.) Can we rework this calculation to take that into account?
I think the current proposal tries to balance this, by enabling this heuristic only after Alice exhausts her utopic guardlist. Also, keep in mind that the utopic guardlist might contain 80/443 guards as well. So if Alice is lucky, she got an 80/443 guard in her utopic guard list, and she will still bootstrap before the dystopic heuristic triggers.
There are various ways to make this heuristic more "intelligent", but I would like to maintain simplicity in our design (both simple to understand and to implement). For example, we could imagine that we always put some 80/443 guards as our primary guards, or in the utopic guardlist. Or, that we reduce the 2% requirement so that we go trigger the dystopic heuristic faster.
I agree that the maximum total time at client side to get a working connection is probably too much. However, I am thinking asn's arguments about _ensuring_ we keep at least n dystopic guards in our PRIMARY_GUARDS list: a) overloading 80/443 (dystopic guards); b) creating incentives for attackers to run 80/443 (dystopic guards) that will give them unfair probabilities to be picked by clients;
are very important and could be worth the effort to make this tradeoff and increase the maximum possible time to get a working connection at client side.
As I understand, the utopic guard list _can_ also contain dystopic guards, so a client behind a FascistFirewall might be lucky and don't have to wait until utopic guard list is exhausted entirely. This is better, but I still think it would be simpler if instead of 2 guard lists:
- SAMPLED_UTOPIC_GUARDS
- SAMPLED_DYSTOPIC_GUARDS
We create a single SAMPLED_GUARDS list, but we make the selection by taking into account the ratio of utopic and dystopic guards based on their weights from the last consensus. I have suggested a simple example for this few months ago in this post:
https://lists.torproject.org/pipermail/tor-dev/2015-November/009871.html
If we compute the guard list like this, load balancing shouldn't be affected in any way (we use the weights to build the list, not the number of relays). I saw the algorithm has been improved so much and covers so many aspects we didn't consider initially, but I still don't understand why we need two separate lists of utopic guards and dystopic guards when we can create a single list.
This will also allow us to safely decrease a little bit the total number of guards we are willing to try, being sure that clients behind FascistFirewalls get a chance while also taking into account teor's concern not to make this list too big.
Hmm, this seems like something worth considering.
IIUC you are basically suggesting using a single guardlist instead of having two. And then also making sure that a representative amount of dystopic bridges are present in that guardlist. So if the set of guards in the latest consensus is 20% dystopic bridges (in bandwidth), we should choose 20% of our guardlist to be dystopic guards.
I can see how this simplifies the guard selection logic, with the cost of slightly complicating the guard sampling logic. It seems like a good trade in this case.
However, this whole suggestion assumes that a good percentage of the total guard bandwidth is actually dystopic (your mail assumes 28% which is a pretty good number). What's the actual bandwidth % of dystopic bridges in the current network? If it's 20% it's a good number for our purposes, but if it's like 1% then that's bad since we are only going to end up adding 1 or 2 dystopic bridges only making our heuristic much more flaky. Also, in the end the quality of our heuristic will depend on this % which is suboptimal.
FWIW in my definition of dystopic bridge above I've been assuming it's bridges with ORPort on 80 or 443.
We should look more into this. Reinaldo, Ola, any comments? Is this simulatable?