[tor-commits] [torspec/master] Rework security section.

[nickm@xxxxxxxxxxxxxx]

commit a535071f141cefcf4a6de73b2ba5a4f8326e91ff
Author: Mike Perry <mikeperry-git@xxxxxxxxxx>
Date:   Wed Oct 10 20:44:55 2012 -0700

    Rework security section.
    
    It seems it's actually not possible to target specific guard nodes
    for DoS with this scheme.
---
 proposals/xxx-path-bias-tuning.txt |   59 +++++++++++++++++++-----------------
 1 files changed, 31 insertions(+), 28 deletions(-)

diff --git a/proposals/xxx-path-bias-tuning.txt b/proposals/xxx-path-bias-tuning.txt
index b6cf165..cd4a459 100644
--- a/proposals/xxx-path-bias-tuning.txt
+++ b/proposals/xxx-path-bias-tuning.txt
@@ -7,10 +7,11 @@ Target: 0.2.4.x+
 
 Overview
 
- This proposal describes how we can use the results of network scans to
- set reasonable limits for the Path Bias defense, which causes clients to
- be informed about and ideally rotate away from Guards that provide
- extremely low circuit success rates.
+ This proposal describes how we can use the results of simulations in
+ combination with network scans to set reasonable limits for the Path
+ Bias defense, which causes clients to be informed about and ideally
+ rotate away from Guards that provide extremely low circuit success
+ rates.
 
 Motivation
 
@@ -114,34 +115,36 @@ Future Analysis: Deployed Clients
 
 Security Considerations
 
- Circuit failure can occur for many reasons. The most common of which is
- CPU resource exhaustion at high speed relays.
+ While the scaling window does provide freshness and can help mitigate
+ "bait-and-switch" attacks, it also creates the possibility of conditions
+ where clients can be forced off their Guards due to temporary
+ network-wide CPU DoS. This provides another reason beyond false positive
+ concerns to set the scaling window as large as is reasonable.
 
- While the scaling window does provide freshness, it also creates the
- possibility of conditions where clients can be forced off their Guards
- due to temporary network-wide or Guard-specific CPU DoS. This provides
- another reason beyond false positive concerns to set the window as
- large is reasonable.
+ A DoS directed at specific Guard nodes is unlikely to allow an
+ adversary to cause clients to rotate away from that Guard, because it
+ is unlikely that the DoS can be precise enough to allow first hops to
+ that Guard to succeed, but also cause extends to fail. This leaves
+ network-wide DoS as the primary vector for influencing clients.
 
- In my mind, the value to aim for here is a number of circuits large
- enough to put this attack vector on par with the timescales used by
- the bandwidth authorities to redirect client activity away from
- loaded (ie DoSed) nodes.
-
- Simulation results show that a Guard node that previously
- succeeded 80% of its circuits would need to be DoSed down to
- 5% success rate for around 230 circuit attempts before the client
- would reject it, using a scaling window of 300 circuits.
+ Simulation results show that in order to cause clients to rotate away
+ from a Guard node that previously succeeded 80% of its circuits, an
+ adversary would need to induce a 25% success rate for around 350 circuit
+ attempts before the client would reject it or a 5% success rate
+ for around 215 attempts, using a scaling window of 300 circuits.
 
  Assuming one circuit per Guard per 10 minutes of normal client
- activity, this is a sustained DoS attack of around 38 hours,
- which is on the order of the bandwidth authority measurement 
- interval (nodes are measured every 1-2 days).
-
- The converse of this, though, is that larger values allow
- Guard nodes to compromise clients for duty cycles of around the
- size of this window (up to the (c/n)^2 * 100/CUTOFF_PERCENT
- limit in aggregate), so we do have to consider that trade off.
+ activity, this is a sustained network-wide DoS attack of 60 hours
+ for the 25% case, or 38 hours for the 5% case.
+
+ Presumably this is enough time for the directory authorites to respond
+ by altering the pb_disablepct consensus parameter before clients
+ rotate.
+
+ The converse of this, though, is that larger values allow Guard nodes
+ to compromise clients for duty cycles of around the size of this window
+ (up to the (c/n)^2 * 100/CUTOFF_PERCENT limit in aggregate), so we do
+ have to consider that trade off.
 
 Implementation Notes: Log Messages
 



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