[tor-commits] [torspec/master] Proposal 251: Add two more routers, and tweak timeout values.
isis at torproject.org
isis at torproject.org
Sun Sep 6 03:16:54 UTC 2015
commit 4802bb987511bf54a2cd4ed3bd8c1526bf0242db
Author: Mike Perry <mikeperry-git at torproject.org>
Date: Fri Sep 4 18:00:09 2015 -0700
Proposal 251: Add two more routers, and tweak timeout values.
Also add more data points to the padding timer distribution table.
---
proposals/251-netflow-padding.txt | 82 +++++++++++++++++++------------------
1 file changed, 43 insertions(+), 39 deletions(-)
diff --git a/proposals/251-netflow-padding.txt b/proposals/251-netflow-padding.txt
index c934610..18de188 100644
--- a/proposals/251-netflow-padding.txt
+++ b/proposals/251-netflow-padding.txt
@@ -76,7 +76,8 @@ Status: Draft
H3C (Netstream)[8] 60s (60-600s) 30min (1-60min)
Fortinet[9] 15s 30min
MicroTik[10] 15s 30min
-
+ nProbe[14] 30s 120s
+ Alcatel-Lucent[15] 15s (10-600s) 30min (1-600min)
1. Proposal Overview
@@ -111,12 +112,14 @@ Status: Draft
Both clients and Guards will maintain a timer for all application (ie:
non-directory) TLS connections. Every time a non-padding packet is sent or
received by either end, that endpoint will sample a timeout value from
- between 4 seconds and 14 seconds. If the connection becomes active for any
- reason before this timer expires, the timer is reset to a new random value
- between 4 and 14 seconds. If the connection remains inactive until the timer
- expires, a single CELL_PADDING cell will be sent on that connection.
+ between 1.5 seconds and 9.5 seconds. If the connection becomes active for
+ any reason before this timer expires, the timer is reset to a new random
+ value between 1.5 and 9.5 seconds. If the connection remains inactive until
+ the timer expires, a single CELL_PADDING cell will be sent on that connection.
- In this way, the connection will only be padded in the event that it is idle.
+ In this way, the connection will only be padded in the event that it is
+ idle, and will always transmit a packet before the minimum 10 second inactive
+ timeout.
2.1. Tunable parameters
@@ -125,10 +128,10 @@ Status: Draft
* nf_ito_low
- The low end of the range to send padding when inactive, in ms.
- - Default: 4000
+ - Default: 1500
* nf_ito_high
- The high end of the range to send padding, in ms.
- - Default: 14000
+ - Default: 9500
* nf_pad_relays
- If set to 1, we also pad inactive relay-to-relay connections
@@ -149,23 +152,18 @@ Status: Draft
2.2. Maximum overhead bounds
With the default parameters, we expect a padded connection to send one
- padding cell every 8 seconds (see Appendix A for the statistical analysis of
- expected padding packet rate on an idle link). This averages to 63 bytes per
- second, assuming a 512 byte cell and 55 bytes of TLS+TCP+IP headers. For a
- connection that remains idle for a full 30 minutes of inactivity, this is
- about 112KB of overhead.
-
- With 2.5M completely idle clients connected simultaneously, 63 bytes per
- second still amounts to only 157MB/second network-wide, which is roughly
- 1.5X the current amount of Tor directory traffic[11]. Of course, our 2.5M
- daily users will neither be connected simultaneously, nor entirely idle,
- so we expect the actual overhead to be much lower than this.
-
- If we choose to set the range such it is no longer even possible to
- configure an inactive timeout low enough such that a new record would be
- generated, (for example: 6.5 to 9.5 seconds for an average of 8 seconds),
- then the maximum possible overhead is 70 bytes/second, 125KB per connection,
- and 175MB/sec network-wide.
+ padding cell every 5.5 seconds (see Appendix A for the statistical analysis
+ of expected padding packet rate on an idle link). This averages to 103 bytes
+ per second full duplex (~52 bytes/sec in each direction), assuming a 512 byte
+ cell and 55 bytes of TLS+TCP+IP headers. For a connection that remains idle
+ for a full 30 minutes of inactivity, this is about 92KB of overhead in each
+ direction.
+
+ With 2.5M completely idle clients connected simultaneously, 52 bytes per
+ second still amounts to only 130MB/second in each direction network-wide,
+ which is roughly the current amount of Tor directory traffic[11]. Of course,
+ our 2.5M daily users will neither be connected simultaneously, nor entirely
+ idle, so we expect the actual overhead to be much lower than this.
2.3. Measuring actual overhead
@@ -217,8 +215,8 @@ Status: Draft
quickly if the adversary loses resolution at any observation points. It is
especially unlikely for the the attacker to benefit from only a few
high-resolution collection points while the remainder of the Tor network
- is only subject to connection-level netflow configuration data retention,
- or even less data retention than that.
+ is only subject to connection-level/per-flow netflow data retention, or even
+ less data retention than that.
Nonetheless, it is still worthwhile to consider what the adversary is capable
of, especially in light of looming data retention regulation.
@@ -282,13 +280,12 @@ Status: Draft
Because this defense only sends padding when the OR connection is completely
idle, it should still operate optimally when combined with other forms of
- padding (such as padding for website traffic fingerprinting and hidden
- service circuit fingerprinting). If those future defenses choose to send
- padding for any reason at any layer of Tor, then this defense
- automatically will not.
+ padding (such as padding for website traffic fingerprinting and hidden service
+ circuit fingerprinting). If those future defenses choose to send padding for
+ any reason at any layer of Tor, then this defense automatically will not.
In addition to interoperating optimally with any future padding defenses,
- simple changes to Tor network usage can serve to further reduce the
+ simple changes to the Tor network usage can serve to further reduce the
usefulness of any data retention, as well as reduce the overhead from this
defense.
@@ -301,9 +298,10 @@ Status: Draft
Similarly, if bridge guards[13] are implemented such that bridges use their
own guard node to route all of their connecting client traffic through, then
- users who run bridges bridges will also benefit from the concurrent traffic of
- their connected clients, which will also be optimally padded when it is
- concurrent with their own.
+ users who run bridges will also benefit from blending their own client traffic
+ with the concurrent traffic of their connected clients, the sum total of
+ which will also be optimally padded such that it only transmits padding when
+ the connection to the bridge's guard is completely idle.
Appendix A: Padding Cell Timeout Distribution Statistics
@@ -325,16 +323,20 @@ Appendix A: Padding Cell Timeout Distribution Statistics
random variable Y = max(X,X) has Prob(Y == i) = (2.0*i + 1)/(R*R).
Then, when both sides apply timeouts sampled from Y, the resulting
- bidirectional padding packet rate is now third random variable:
+ bidirectional padding packet rate is now a third random variable:
Z = min(Y,Y).
The distribution of Z is slightly bell-shaped, but mostly flat around the
mean. It also turns out that Exp[Z] ~= Exp[X]. Here's a table of average
values for each random variable:
- R Exp[X] Exp[Z] Exp[min(X,X)] Exp[Y=max(X,X)]
- 5000 2499.5 2662 1666.2 3332.8
- 6000 2999.5 3195 1999.5 3999.5
+ R Exp[X] Exp[Z] Exp[min(X,X)] Exp[Y=max(X,X)]
+ 2000 999.5 1066 666.2 1332.8
+ 3000 1499.5 1599.5 999.5 1999.5
+ 5000 2499.5 2666 1666.2 3332.8
+ 6000 2999.5 3199.5 1999.5 3999.5
+ 7000 3499.5 3732.8 2332.8 4666.2
+ 8000 3999.5 4266.2 2666.2 5332.8
10000 4999.5 5328 3332.8 6666.2
15000 7499.5 7995 4999.5 9999.5
20000 9900.5 10661 6666.2 13332.8
@@ -357,3 +359,5 @@ Appendix A: Padding Cell Timeout Distribution Statistics
11. https://metrics.torproject.org/dirbytes.html
12. http://freehaven.net/anonbib/cache/murdoch-pet2007.pdf
13. https://gitweb.torproject.org/torspec.git/tree/proposals/188-bridge-guards.txt
+14. http://www.ntop.org/wp-content/uploads/2013/03/nProbe_UserGuide.pdf
+15. http://infodoc.alcatel-lucent.com/html/0_add-h-f/93-0073-10-01/7750_SR_OS_Router_Configuration_Guide/Cflowd-CLI.html
More information about the tor-commits
mailing list