[tor-dev] Notes from the prop259 proposal reading group

[George Kadianakis <desnacked@xxxxxxxxxx>]

Hello,

we had a meeting about proposal 259 "New Guard Selection Behaviour". You can
see the logs here: http://meetbot.debian.net/tor-dev/2016/tor-dev.2016-03-23-15.01.log.txt

Some notes:

- The latest version of the proposal can be found here:
     https://lists.torproject.org/pipermail/tor-dev/2016-March/010625.html
  There is also some discussion with Tim that has been happening in that thread
  since yesterday.

  It's likely that the proposal will be slightly changed (read: improved) as
  implementation and testing proceeds.

  The implementation of the proposal is currently happening here:
    https://github.com/twstrike/tor_for_patching/tree/prop259

- We discussed whether the guard algorithm should care about circuit
  restrictions like requiring that the guard of a circuit needs to be Stable
  (needs_uptime) or Fast (needs_capacity).

  We decided that for now the algorithm should be able to handle these
  restrictions, by skipping to the next guard that satisfies the conditions in
  case the top guard does not. This is also how the current guard algorithm works.

  In the future we should make it so that all Guards are both Stable and Fast,
  so that this stupid check does not need to happen [TODO: I should open a
  ticket for this if it doesn't already exist].

- We discussed how ReachableAddresses should work with regards to guardlists.

  A suggestion by Tim came from here: https://lists.torproject.org/pipermail/tor-dev/2016-March/010630.html
  who says:
   "I suggest that we compose the set of UTOPIC guards based on addresses that
    are reachable and preferred (or, if there are no guards with preferred
    addresses, those guards that are reachable). I suggest that we use the same
    mechanism with DYSTOPIC guards, but add a port restriction to 80 & 443 to all
    the other restrictions. (This may result in the empty set.)"

  I think this suggstion makes sense for now.

- We also talked about directory guards and how they should work but we didn't
  come to a conclusion.

  My current intuition is that if a directory circuit appears that requires a
  directory guard, we treat it as a constraint the same way we treat
  needs_capacity and needs_uptime. So if our top guard cannot be a directory
  guard (is not a V2Dir), we skip it and go down our list till we find a guard
  that does.

  In the future (almost) all guards will be directory guards so this should
  become less of an issue (see #12538).
  
- Finally, a topic that came up after the meeting in: 
    https://lists.torproject.org/pipermail/tor-dev/2016-March/010635.html
  had to do with how we treat bad guards in SAMPLED_UTOPIC_GUARDS and
  SAMPLED_DYSTOPIC_GUARDS.

  So if suddenly 90% of the guards in SAMPLED_UTOPIC_GUARDS drop out of the
  consensus, what do we do? We mark them as bad, and then what? Do we remove
  them from the sampled list? Or do we keep them in there in case they come
  back? (This latter behavior is what tor currently does).

  But then if we keep them, don't we also need to add some more guards in there
  to make up for the bad ones? How exactly should this work? Some thinking
  needs to be done here.

- We also discussed the need for good debug logging in the prop259 tor branch,
  so that we can test it ourselves. Ideally, the logging should be nice and
  intuitive, so that we can monitor the logs every now and then and check if
  the guard picking works properly.

  For example, if the algorithm keeps on switching guards all the time, there
  is a problem. If the algo is using the 5th guard while the 1st guard is up,
  it's a problem. Good logging should be able to reveal all these problems
  without having to spend 20 minutes investigating every new log message.

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev