commit 4802bb987511bf54a2cd4ed3bd8c1526bf0242db Author: Mike Perry mikeperry-git@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.t... +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_Ro...