[or-cvs] r9864: Merge or-dev discussion into 109; mark 109 accepted. (in tor/trunk: . doc/spec/proposals)

[nickm@xxxxxxxx]

Author: nickm
Date: 2007-03-17 17:10:08 -0400 (Sat, 17 Mar 2007)
New Revision: 9864

Modified:
   tor/trunk/
   tor/trunk/doc/spec/proposals/000-index.txt
   tor/trunk/doc/spec/proposals/109-no-sharing-ips.txt
Log:
 r12212@catbus:  nickm | 2007-03-17 17:05:54 -0400
 Merge or-dev discussion into 109; mark 109 accepted.



Property changes on: tor/trunk
___________________________________________________________________
 svk:merge ticket from /tor/trunk [r12212] on 8246c3cf-6607-4228-993b-4d95d33730f1

Modified: tor/trunk/doc/spec/proposals/000-index.txt
===================================================================
--- tor/trunk/doc/spec/proposals/000-index.txt	2007-03-17 21:10:00 UTC (rev 9863)
+++ tor/trunk/doc/spec/proposals/000-index.txt	2007-03-17 21:10:08 UTC (rev 9864)
@@ -27,6 +27,6 @@
 106  Checking fewer things during TLS handshakes [CLOSED]
 107  Uptime Sanity Checking [CLOSED]
 108  Base "Stable" Flag on Mean Time Between Failures [OPEN]
-109  No more than one server per IP address [OPEN]
+109  No more than one server per IP address [ACCEPTED]
 110  Avoiding infinite length circuits [OPEN]
 111  Prioritizing local traffic over relayed traffic [OPEN]

Modified: tor/trunk/doc/spec/proposals/109-no-sharing-ips.txt
===================================================================
--- tor/trunk/doc/spec/proposals/109-no-sharing-ips.txt	2007-03-17 21:10:00 UTC (rev 9863)
+++ tor/trunk/doc/spec/proposals/109-no-sharing-ips.txt	2007-03-17 21:10:08 UTC (rev 9864)
@@ -4,7 +4,7 @@
 Last-Modified:
 Author: Kevin Bauer & Damon McCoy
 Created: 9-March-2007
-Status: Open
+Status: Accepted
 
 Overview:
   This document describes a solution to a Sybil attack vulnerability in the
@@ -30,10 +30,25 @@
   attacker must control in order to carry out traffic analysis.
 
 Specification:
-  We propose that the directory servers check if an incoming Tor router IP
-  address is already registered under another router. If this is the case,
-  then prevent the new router from joining the network.
 
+  For each IP address, each directory authority tracks the number of routers
+  using that IP address, along with their total observed bandwidth.  If there
+  are more than MAX_SERVERS_PER_IP servers at some IP, the authority should
+  "disable" all but MAX_SERVERS_PER_IP servers.  If the total observed
+  bandwidth of the remaining non-"disabled" servers exceeds MAX_BW_PER_IP,
+  the authority should "disable" some of the remaining servers until only one
+  server remains, or until the remaining observed bandwidth of non-"disabled"
+  servers is under MAX_BW_PER_IP.  When choosing which servers to disable,
+  the authority should first disable non-Running servers in increasing order
+  of observed bandwidth, and then should disable Running servers in
+  increasing order of bandwidth.
+
+  Servers that are "disabled" MUST be marked as non-Valid and non-Running.
+
+  MAX_SERVERS_PER_IP is 3.
+
+  MAX_BW_PER_IP is 8 MB per s.
+
 Compatibility:
 
   Upon inspection of a directory server, we found that the following IP
@@ -66,17 +81,3 @@
     would only make use of a bit of it. So Roger suggested that he run
     two Tor servers, to use more.
 
-Alternatives:
-
-  Roger suggested that instead of capping number of servers per IP to 1, we
-  should cap total declared bandwidth per IP to some N, and total declared
-  servers to some M.  (He suggested N=5MB/s and M=5.) Directory authorities
-  would then always choose to keep the highest-bandwidth running servers
-  -- if they pick based on time joining the network we can get into bad
-  race conditions.
-
-  Roger also suggested that rather than not listing servers, we mark them as
-  not Running. (He originally suggested marking them as Running but not
-  Valid, but that would still allow an attacker to control an arbitrary
-  number of middle hops, which is still likely to be worrisome.)
-