[tor-commits] [torspec/master] Document consensus paramters that changed defaults.
nickm at torproject.org
nickm at torproject.org
Thu Oct 18 01:02:41 UTC 2012
Author: Mike Perry <mikeperry-git at fscked.org>
Date: Tue Oct 16 18:29:09 2012 -0700
Document consensus paramters that changed defaults.
Also clarify the timeout decision.
proposals/209-path-bias-tuning.txt | 33 ++++++++++++++++++++++-----------
1 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/proposals/209-path-bias-tuning.txt b/proposals/209-path-bias-tuning.txt
index 25ee9de..926f561 100644
@@ -59,8 +59,11 @@ Design Description
Circuit build timeouts are only counted as path failures if the
circuit fails to complete before the 95% "right-censored" (aka
"MEASUREMENT_EXPIRED") timeout interval, not the 80% timeout
- condition. See 2.4.1 of path-spec for further details on circuit
- timeout calculations.
+ condition. This was done based on the assumption that destructive
+ cryptographic tagging is the primary vector for the path bias attack,
+ until such time as Tor's circuit crypto can be upgraded. Therefore,
+ being more lenient with timeout makes us more resilient to network
To ensure correctness, checks are performed to ensure that
we do not count successes without also counting the first hop (see
@@ -199,16 +202,12 @@ Security Considerations: Targeted Failure Attacks
rate to 51% for the 10% compromise case, or 34% for the 20%
- Since both conditions would elicit notices and/or warns from all
+ Since both conditions would elicit notices and/or warns from *all*
clients, this attack should be detectable. It can also be detected
through the bandwidth authorities (who could possibly even
set pathbias parameters directly based on measured ambient circuit
failure rates), should we deploy #7023.
- We could also conceivably lower pb_disablepct to 25% as a
- potential mitigation, based on the fact that a 20% c/n adversary
- would only carry 24% of their circuits in the extreme case.
Implementation Notes: Log Messages
Log messages need to be chosen with care to avoid alarming users.
@@ -257,7 +256,7 @@ Implementation Notes: Consensus Parameters
If non-zero, we should actually drop guards as opposed to warning.
-Implementation Notes: Differences between this proposal and source
+Implementation Notes: Differences between proposal and current source
This proposal adds a few changes over the implementation currently
deployed in origin/master.
@@ -265,13 +264,25 @@ Implementation Notes: Differences between this proposal and source
The log messages suggested above are different than those in the
+ The following consensus parameters had changes to their default
+ values, based on results from simulation and scanning:
Also, the following consensus parameters are additions:
+ Finally, 0.2.3.x needs to be synced with origin/master, but should
+ also ignore the pb_dropguards parameter (but ideally still provide
+ the equivalent pb_dropguards torrc option).
+5. See 2.4.1 of path-spec.txt for further details on circuit timeout calculations.
More information about the tor-commits