[tor-dev] Latest state of the guard algorithm proposal (prop259) (April 2016)

[George Kadianakis]

Fan Jiang <fanjiang at thoughtworks.com> writes:

> [ text/plain ]
> Hi George,
>
> Thanks for following up,
> We have been updating the prop259 actively in recent two weeks,
>
>>
>> It seems like the latest version of prop259 was posted a few weeks ago:
>>    https://lists.torproject.org/pipermail/tor-dev/2016-March/010625.html
>>
>> My understanding is that since then a few things have changed particularly
>> with
>> regards to the dystopic heuristic, and the various filtering torrc options.
>> More discussion happened in the mailing list, but we have not posted a
>> newer version of the proposal yet:
>>    https://lists.torproject.org/pipermail/tor-dev/2016-April/010714.html
>>
>>
> the newer version of prop259 is sort of feasible again. it's here
> https://github.com/twstrike/torspec/blob/review/proposals/259-guard-selection.txt
>

Ah great. Will read it and comment on it ASAP.

I notice that the prop now contains many many implementation details (like
variable names, etc.). Ideally, we should abstract those details and make them
look more like a specification.


> And, we have our fork of Tor *running* with new proposal:
> https://github.com/twstrike/tor_for_patching/tree/prop259
>

How is this going? Does it work as intended? Any graphs?

I should find some time and run it myself soon.

>
>
>> A few things:
>>
>> a) Are there still proposal design decisions that need to be taken and we
>> are
>>    unclear on? I admit I'm a bit lost in the latest [tor-dev] thread, so
>> maybe
>>    I can be of help somehow here?
>>
>> There are still some issues, like for_directory may leads to maintain two
> sets of
> sampled_set independently, which is not yet defined clearly in proposal.
>

Hm, how come this is happening?

I would think that for_directory would now be just another filter (like the
ipv6 one etc.) that can be applied on top of the sampled list.

> <snip>
>
> c) Let me know if there are any open implementation questions that I could
>>    assist with.
>
>
> About implementation, one problem is when we try to remove the global
> *entry_guards*,
> The following functions are still using the global list:
>
> we already get rid of these:
>
> //- update_node_guard_status (OK - called from *set_from_config and
> //  *parse_state. This is an optimization to set the using_as_guard flag.)
> //- entry_guards_compute_status (OK - when a new consensus arrives)
> //- log_entry_guards (OK - wont be used)
> //- add_an_entry_guard (OK - wont be used)
> //- entry_guard_register_connect_status (OK - wont be used)
> //- entry_guards_set_from_config (OK - wont be used)
> //- entry_guards_parse_state and entry_guards_update_state (OK - wont be
> used)
> //- choose_random_entry_impl (OK - wont be used)
>
> there are still some remaining:
>
> //- get_entry_guards()
> //- num_live_entry_guards()
> //- getinfo_helper_entry_guards()
> //- entries_retry_helper()
> //- any_bridge_supports_microdescriptors() // Don't quite understand this,
> what's a microdescriptors?

A microdescriptor is a new type of relay descriptor that is more compact.
(well, it used to be new, but it's a few years old these days and most bridges
support it afaik). They were introduced to reduce the download sizes of
clients, because asking for thousands of normal descriptors required too much
bandwidth. Microdescriptors include almost all the details of normal
descriptors (like onion keys, etc.) but in a much more succinct format.

That function checks if the bridge supports microdescriptors. If yes, it will
ask it for its microdescriptor. Otherwise, it will just ask for the normal
descriptor.

(I'm actually not sure how that function gets away without checking the bridge
version or something.)

> //- any_bridge_descriptors_known() // Calling choose_random_entry to check
> a bridge, which doesn't make sense.
>

Hah. I didn't know of that function either.

That function seems to call choose_random_entry() just to check if bridges
have been configured correctly and are ready to use. It doesn't actually use
the return value of the function :)

Basically, if that func returns not NULL, it means that at least one bridge is
live and ready to be attempted.

>
>
> Another issue is about finding a better way to handle configuration
> changes, especially for EntryNodes,
> UseBridges and ReachableAddresses. The treshould numbers like
> N_PRIMARY_GUARDS should be different
> in such cases.
>

Hmm, yes I have not thought how the primary guards heuristic would work when
bridges are enabled. Why do you think the thresholds should be different?

Thanks for the info. Will try to have feedback on the proposal tomorrow or
early next week.