[tor-dev] Hashring understanding

[George Kadianakis]

Ola Bini <obini at thoughtworks.com> writes:

> Hi,
>
>> I think it's fine to use randomness to generate it for now; that's what tor
>> also currently does [0].
> Cool - we have a local clone of the specs and updating it with this understanding.
>

Great!

For better or worse I think making design decisions (or at least simulating
them) as well as improving and finalizing the spec is a big part of this task :)

>> The real lifetime of guards is currently a random value between 2 to 3 months
>> (see chosen_on_date) This is regardless of whether the guard is your primary
>> guard or not. We might increase the lifetime in the future, but probably the
>> precise value should not matter too much since it's a constant
>> change.
> Does this mean the choice of guard is saved in the state file or
> config file?

Indeed. It is saved in the state file. Check the end of:
    https://lists.torproject.org/pipermail/tor-dev/2016-February/010355.html
also see here for another explanation of how parts of it work:
    https://lists.torproject.org/pipermail/tor-dev/2014-June/007042.html

> Should the PRIMARY_GUARDS chosen by #259 here be saved as well?

Hmm. Not sure how this will work exactly in practice.

The way I imagine it, is that the first N_PRIMARY_GUARDS active guards on your
guard list are considered to be your primary guards. It's more of a label, than
a static set. That's because the set of primary guards changes over time, as
nodes go inactive. Like prop259 says, "by 'active' we mean that we only
consider guards that are present in the latest consensus as primary".

> I suspect that might not work very well because of the difference between
> dystopic and utopic networks, and when people move around between
> networks. Or maybe we should have two sets, UTOPIC and DYSTOPIC
> PRIMARY_GUARDS that are more long lived?

Hmm... Not sure how this would work if utopic and dystopic guard lists are
separated. That is if there should be both dystopic primary guards _and_
entropic primary guards.

I'd personally prefer the approach where we don't have such strictly separated guard
lists. I tried to explain parts of it in the top of this email:
       https://lists.torproject.org/pipermail/tor-dev/2016-February/010355.html
but it probably requires more design work.

The way I'm thinking of it, we have a main guardlist GUARDS, where we put every
guard we have sampled and connected or planning to connect to. We would sample
both normal and 80/443 guards for this guardlist. This guardlist should work
for most clients (except from 80/443 firewalled clients).

To handle these 80/443 firewalled clients, if we try more than
GUARDLIST_FAILOVER_THRESHOLD nodes from GUARDS and we can't connect, then we
consider it to be a firewall issue, and go into "dystopic firewall
mode". During this mode we only sample dystopic guards (potentially from a
separate DYSTOPIC_GUARDS guardlist). If we try more than
GUARDLIST_FAILOVER_THRESHOLD of guards from the dystopic guardlist, then we
complain about network issues.

(There are various optimizations and heuristics that can be applied to the
above system, but let's not get to them now.)

[The reason I don't like having separate disjoint utopic and dystopic
guardlists and first trying the former and then the latter, is because it means
that normal people will use the utopic guards, and the dystopic guards will
only be used by people that have 80/443 firewalled. We don't really know how
big these user sets are right now so it's hard to make load-balancing
assumptions, and from a security PoV we should probably not isolate those user
sets if we can help it.]

Bleh sorry for the mess... It's been a while since I've thought of this stuff.