From 3c3a3db72f87ed324120c9fea73c33d2cb9e57c5 Mon Sep 17 00:00:00 2001 From: Roger Dingledine Date: Fri, 19 May 2017 03:07:38 -0400 Subject: more subtle fixes to guard-spec i don't think i broke anything, but it would be worth somebody looking over it to be sure. --- guard-spec.txt | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) (limited to 'guard-spec.txt') diff --git a/guard-spec.txt b/guard-spec.txt index 267edab..41bc3e4 100644 --- a/guard-spec.txt +++ b/guard-spec.txt @@ -105,7 +105,7 @@ 3.1 Path selection - For any circuit, at least one entry guard and middle node(s) are + For any multi-hop circuit, at least one entry guard and middle node(s) are required. An exit node is required if traffic will exit the Tor network. Depending on its configuration, a relay listed in a consensus could be used for any of these roles. However, this @@ -151,12 +151,13 @@ Once a path is chosen, Tor will use this path to build a new circuit. - If the circuit is built successfully, it either can be used - immediately or wait for a better guard, depending on whether other - circuits already exist with higher-priority guards. + If the circuit is built successfully, Tor will either use it + immediately, or Tor will wait for a circuit with a more preferred + guard if there's a good chance that it will be able to make one. - If at any point the circuit fails, the guard is marked as - unreachable, the circuit is closed, and waiting circuits are updated. + If the circuit fails in a way that makes us conclude that a guard + is not reachable, the guard is marked as unreachable, the circuit is + closed, and waiting circuits are updated. 4. The algorithm. @@ -181,7 +182,8 @@ - {pvar:ADDED_ON_DATE}: The date on which it was added to sampled_guards. - We base this value on RAND(now, {GUARD_LIFETIME}/10). See + We set this value to a point in the past, using + RAND(now, {GUARD_LIFETIME}/10). See Appendix [RANDOM] below. - {pvar:ADDED_BY_VERSION}: The version of Tor that added it to @@ -193,7 +195,7 @@ - {pvar:FIRST_UNLISTED_AT}: If IS_LISTED is false, the publication date of the earliest consensus in which this guard was listed such that we have not seen it listed in any later consensus. Otherwise "None." - We randomize this, based on + We randomize this to a point in the past, based on RAND(added_at_time, {REMOVE_UNLISTED_GUARDS_AFTER} / 5) For each guard in {SAMPLED_GUARDS}, we also record this data, @@ -322,7 +324,7 @@ - {pvar:CONFIRMED_ON_DATE} When we added this guard to {CONFIRMED_GUARDS}. - Randomized as RAND(now, {GUARD_LIFETIME}/10). + Randomized to a point in the past as RAND(now, {GUARD_LIFETIME}/10). We add new members to {CONFIRMED_GUARDS} when we mark a circuit built through a guard as "for user traffic." @@ -478,8 +480,8 @@ all the sampled guards. In this case we proceed by marking all guards as reachable so that we can keep on sampling. - Whenever we yield a guard, we update the {last_tried_connect} time - for the guard to 'now.' + Whenever we select a guard for a new circuit attempt, we update the + {last_tried_connect} time for the guard to 'now.' In some cases (for example, when we need a certain directory feature, or when we need to avoid using a certain exit as a guard), we need to -- cgit v1.2.3-54-g00ecf