[tor-dev] Proposal 259: New Guard Selection Behaviour

[Michael Rogers]

On 04/04/16 11:47, George Kadianakis wrote:
> I wonder what would happen there if FascistFirewall gets toggled on and off.
> 
> If our guardlist was sampled when FascistFirewall was on, shouldn't we sample
> from the beginning if FascistFirewall goes off? That's terrible though since we
> lose all that guard state...

Throwing this out there as food for brainstorming rather than a fully
formed idea: what would happen if we sampled from a single list of all
guards, then filtered the sampled list according to current conditions?

Filtering conditions would include:
* Does the guard have the required flags in the latest consensus?
* Does it match the ReachableAddresses setting, if any?
* Does it match the Use/PreferIPv6 settings, if any?
* Does it match the FascistFirewall setting, if any?
* Does it match our current firewall guesswork?
* Anything else that makes a guard a priori unsuitable

Apply all these filters to the sampled list to get a list of candidates.
If the conditions change, update the filters without modifying the
underlying list. If the filtered list is too short, sample more guards
into the underlying list.

If I understand right, this is how the "good/bad" flag for membership in
the latest consensus already works - the idea is just to use the same
method for all the combined conditions.

There wouldn't be separate lists of utopic and dystopic guards - rather
the list of all guards would be filtered down to dystopic guards
whenever settings and/or current guesswork indicated it was appropriate.

Presumably the guesswork should be reset if there's a clue that the
network has changed, such as a change in the local IP address. So, going
back to the scenario you mentioned above, a less restrictive set of
filters would be applied to the underlying list, resulting in more
candidates without repeating any sampling.

Cheers,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x9FC527CC.asc
Type: application/pgp-keys
Size: 4660 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160404/b36df8c4/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160404/b36df8c4/attachment.sig>