nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-28 06:13:31 +01:00
Code Issues Packages Projects Releases Wiki Activity

r12212@catbus: nickm | 2007-03-17 17:05:54 -0400

Browse Source 
Merge or-dev discussion into 109; mark 109 accepted.


svn:r9864
This commit is contained in:
Nick Mathewson 2007-03-17 21:10:08 +00:00
parent 5679edfd3a
commit c50cf094b1
2 changed files with 20 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/spec/proposals/000-index.txt
View File

@ -27,6 +27,6 @@ Proposals by number:
106 Checking fewer things during TLS handshakes [CLOSED] 106 Checking fewer things during TLS handshakes [CLOSED]
107 Uptime Sanity Checking [CLOSED] 107 Uptime Sanity Checking [CLOSED]
108 Base "Stable" Flag on Mean Time Between Failures [OPEN] 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] 110 Avoiding infinite length circuits [OPEN]
111 Prioritizing local traffic over relayed traffic [OPEN] 111 Prioritizing local traffic over relayed traffic [OPEN]

37
doc/spec/proposals/109-no-sharing-ips.txt
View File

@ -4,7 +4,7 @@ Version:
Last-Modified: Last-Modified:
Author: Kevin Bauer & Damon McCoy Author: Kevin Bauer & Damon McCoy
Created: 9-March-2007 Created: 9-March-2007
Status: Open Status: Accepted
Overview: Overview:
This document describes a solution to a Sybil attack vulnerability in the This document describes a solution to a Sybil attack vulnerability in the
@ -30,9 +30,24 @@ Security implications:
attacker must control in order to carry out traffic analysis. attacker must control in order to carry out traffic analysis.
Specification: 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, For each IP address, each directory authority tracks the number of routers
then prevent the new router from joining the network. 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: Compatibility:
@ -66,17 +81,3 @@ Compatibility:
would only make use of a bit of it. So Roger suggested that he run would only make use of a bit of it. So Roger suggested that he run
two Tor servers, to use more. 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.)