[or-cvs] r9810: clarify roger's alternatives on proposal 109 (tor/trunk/doc/spec/proposals)

[arma@xxxxxxxx]

Author: arma
Date: 2007-03-12 22:37:43 -0400 (Mon, 12 Mar 2007)
New Revision: 9810

Modified:
   tor/trunk/doc/spec/proposals/109-no-sharing-ips.txt
Log:
clarify roger's alternatives on proposal 109


Modified: tor/trunk/doc/spec/proposals/109-no-sharing-ips.txt
===================================================================
--- tor/trunk/doc/spec/proposals/109-no-sharing-ips.txt	2007-03-13 02:01:17 UTC (rev 9809)
+++ tor/trunk/doc/spec/proposals/109-no-sharing-ips.txt	2007-03-13 02:37:43 UTC (rev 9810)
@@ -22,7 +22,7 @@
 
 Motivation:
   Since it is possible for an attacker to register an arbitrarily large
-  number of Tor routers, it is possible for malicious parties to do this to
+  number of Tor routers, it is possible for malicious parties to do this
   as part of a traffic analysis attack.
 
 Security implications:
@@ -32,7 +32,7 @@
 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 this router from joining the network.
+  then prevent the new router from joining the network.
 
 Compatibility:
 
@@ -70,8 +70,13 @@
 
   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.)
+  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 Valid.
+  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.)