Proposal 251: Add two more routers, and tweak timeout values.

Also add more data points to the padding timer distribution table.

1 files 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