[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[or-cvs] r9864: Merge or-dev discussion into 109; mark 109 accepted. (in tor/trunk: . doc/spec/proposals)
- To: or-cvs@xxxxxxxxxxxxx
- Subject: [or-cvs] r9864: Merge or-dev discussion into 109; mark 109 accepted. (in tor/trunk: . doc/spec/proposals)
- From: nickm@xxxxxxxx
- Date: Sat, 17 Mar 2007 17:10:10 -0400 (EDT)
- Delivered-to: email@example.com
- Delivered-to: firstname.lastname@example.org
- Delivered-to: email@example.com
- Delivery-date: Sat, 17 Mar 2007 17:10:23 -0400
- Reply-to: or-talk@xxxxxxxxxxxxx
- Sender: owner-or-cvs@xxxxxxxxxxxxx
Date: 2007-03-17 17:10:08 -0400 (Sat, 17 Mar 2007)
New Revision: 9864
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
--- 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]
--- 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 @@
Author: Kevin Bauer & Damon McCoy
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.
- 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.
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.
- 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.)