[tor-commits] [torspec/master] Nick Hopper changes
nickm at torproject.org
nickm at torproject.org
Wed Apr 23 18:20:04 UTC 2014
Author: George Kadianakis <desnacked at riseup.net>
Date: Thu Apr 17 21:30:16 2014 +0300
Nick Hopper changes
Acked-by: George Kadianakis <desnacked at riseup.net>
proposals/xxx-single-guard-node.txt | 65 +++++++++++++++++++++--------------
1 file changed, 39 insertions(+), 26 deletions(-)
diff --git a/proposals/xxx-single-guard-node.txt b/proposals/xxx-single-guard-node.txt
index 94cb736..f47735f 100644
@@ -2,7 +2,7 @@ Filename: xxx-single-guard-node.txt
Title: The move to a single guard node
Author: George Kadianakis
-Status: Draft and potentially a bad idea
@@ -37,7 +37,10 @@ Status: Draft and potentially a bad idea
A Guard node is considered unusable according to section "5. Guard
nodes" in path-spec.txt. The rest of the rules from that section
- apply here too. XXX which rules specifically?
+ apply here too. XXX which rules specifically? -asn
+ XXX Probably the rules about how to add a new guard (only after
+ contact), when to re-try a guard for reachability, and when to
+ discard a guard? -nickhopper
XXX Do we need to specify how already existing clients migrate?
@@ -98,36 +101,46 @@ Status: Draft and potentially a bad idea
1.3. Age of guard as a factor on guard probabilities
By increasing the guard rotation period we also increase the lack
- of clients for young guards since clients will rotate guards even
+ of utilization for young guards since clients will rotate guards even
more infrequently now (see 'Phase three' of ).
- We can try to mitigate this phenomenon by giving higher priority to
- young guards to be picked as guards:
+ We can mitigate this phenomenon by treating these recent guards as
+ "fractional" guards:
To do so, everytime an authority needs to vote for a guard, it
- reads a set of consensus documents spanning the past NNN months, and
- calculates the age of the guard; that is, in how many consensuses
- its public key has been included in the past.
+ reads a set of consensus documents spanning the past NNN months,
+ where NNN is the number of months in the guard rotation period (10
+ months if this proposal is adopted in full) and calculates the
+ visibility of the guard; that is, in how many consensuses it has
+ had the guard flag.
The authorities include the age of each guard by appending
- '[SP "Age=" INT]' in the guard's "w" line.
- When a client picks a guard, it applies the age of each guard as a
- weight on its guard probability. XXX unspecified how
- XXX How much should the age of a guard influence its probability?
- Should we say that a guard that just appeared should have 10%
- more chance of being selected as a guard node than the oldest
- guard in town?
- XXX Should the authorities include the age itself, or just the
- weight that clients should apply to the probability?
- XXX Is this risky? Maybe we shouldn't give too much priority to new
- guards, otherwise an adversary can start up a few new relays
- every month, enjoy maximum priority when they get the guard
- flag, leave them running for a bit till the next batch gets the
- guard flag and then trash them.
+ '[SP "GV=" INT]' in the guard's "w" line.
+ A guard N that has been visible for V out of NNN*30*24 consensuses
+ has had the opportunity to be chosen as a guard by approximately
+ F = V/NNN*30*24 of the clients in the network, and the remaining
+ 1-F fraction of the clients have not noticed this change. So when
+ being chosen for middle or exit positions on a circuit, clients
+ should treat N as if F fraction of its bandwidth is a guard
+ (respectively, dual) node and (1-F) is a middle (resp, exit) node.
+ Let Wpf denote the weight from the 'bandwidth-weights' line a
+ client would apply to N for position p if it had the guard
+ flag, Wpn the weight if it did not have the guard flag, and B the
+ measured bandwidth of N in the consensus. Then instead of choosing
+ N for position p proportionally to Wpf*B or Wpn*B, clients should
+ choose N proportionally to F*Wpf*B + (1-F)*Wpn*B.
+ Similarly, when calculating the bandwidth-weights line as in
+ section 3.8.3 of dir-spec.txt, directory authorities should treat N
+ as if fraction F of its bandwidth has the guard flag and (1-F) does
+ not. So when computing the totals G,M,E,D, each relay N with guard
+ visibility fraction F and bandwidth B should be added as follows:
+ G' = G + F*B, if N does not have the exit flag
+ M' = M + (1-F)*B, if N does not have the exit flag
+ D' = D + F*B, if N has the exit flag
+ E' = E + (1-F)*B, if N has the exit flag
1.4. Raise the bandwidth threshold for being a guard
More information about the tor-commits