2007-03-12 14:04:20 +01:00
|
|
|
Filename: 109-no-sharing-ips.txt
|
|
|
|
|
Title: No more than one server per IP address.
|
|
|
|
|
Version:
|
|
|
|
|
Last-Modified:
|
|
|
|
|
Author: Kevin Bauer & Damon McCoy
|
|
|
|
|
Created: 9-March-2007
|
2007-03-17 22:10:08 +01:00
|
|
|
Status: Accepted
|
2007-03-12 14:04:20 +01:00
|
|
|
|
|
|
|
|
Overview:
|
|
|
|
|
This document describes a solution to a Sybil attack vulnerability in the
|
|
|
|
|
directory servers. Currently, it is possible for a single IP address to
|
|
|
|
|
host an arbitrarily high number of Tor routers. We propose that the
|
|
|
|
|
directory servers limit the number of Tor routers that may be registered at
|
|
|
|
|
a particular IP address to some small (fixed) number, perhaps just one Tor
|
|
|
|
|
router per IP address.
|
|
|
|
|
|
|
|
|
|
While Tor never uses more than one server from a given /16 in the same
|
|
|
|
|
circuit, an attacker with multiple servers in the same place is still
|
|
|
|
|
dangerous because he can get around the per-server bandwidth cap that is
|
|
|
|
|
designed to prevent a single server from attracting too much of the overall
|
|
|
|
|
traffic.
|
|
|
|
|
|
|
|
|
|
Motivation:
|
|
|
|
|
Since it is possible for an attacker to register an arbitrarily large
|
2007-03-13 03:37:43 +01:00
|
|
|
number of Tor routers, it is possible for malicious parties to do this
|
2007-03-12 14:04:20 +01:00
|
|
|
as part of a traffic analysis attack.
|
|
|
|
|
|
|
|
|
|
Security implications:
|
|
|
|
|
This countermeasure will increase the number of IP addresses that an
|
|
|
|
|
attacker must control in order to carry out traffic analysis.
|
|
|
|
|
|
|
|
|
|
Specification:
|
2007-03-17 22:10:08 +01:00
|
|
|
|
|
|
|
|
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.
|
2007-03-12 14:04:20 +01:00
|
|
|
|
|
|
|
|
Compatibility:
|
|
|
|
|
|
|
|
|
|
Upon inspection of a directory server, we found that the following IP
|
|
|
|
|
addresses have more than one Tor router:
|
|
|
|
|
|
|
|
|
|
Scruples 68.5.113.81 ip68-5-113-81.oc.oc.cox.net 443
|
|
|
|
|
WiseUp 68.5.113.81 ip68-5-113-81.oc.oc.cox.net 9001
|
|
|
|
|
Unnamed 62.1.196.71 pc01-megabyte-net-arkadiou.megabyte.gr 9001
|
|
|
|
|
Unnamed 62.1.196.71 pc01-megabyte-net-arkadiou.megabyte.gr 9001
|
|
|
|
|
Unnamed 62.1.196.71 pc01-megabyte-net-arkadiou.megabyte.gr 9001
|
|
|
|
|
aurel 85.180.62.138 e180062138.adsl.alicedsl.de 9001
|
|
|
|
|
sokrates 85.180.62.138 e180062138.adsl.alicedsl.de 9001
|
|
|
|
|
moria1 18.244.0.188 moria.mit.edu 9001
|
|
|
|
|
peacetime 18.244.0.188 moria.mit.edu 9100
|
|
|
|
|
|
|
|
|
|
There may exist compatibility issues with this proposed fix. Reasons why
|
|
|
|
|
more than one server would share an IP address include:
|
|
|
|
|
|
|
|
|
|
* Testing. moria1, moria2, peacetime, and other morias all run on one
|
|
|
|
|
computer at MIT, because that way we get testing. Moria1 and moria2 are
|
|
|
|
|
run by Roger, and peacetime is run by Nick.
|
|
|
|
|
* NAT. If there are several servers but they port-forward through the same
|
|
|
|
|
IP address, ... we can hope that the operators coordinate with each
|
|
|
|
|
other. Also, we should recognize that while they help the network in
|
|
|
|
|
terms of increased capacity, they don't help as much as they could in
|
|
|
|
|
terms of location diversity. But our approach so far has been to take
|
|
|
|
|
what we can get.
|
|
|
|
|
* People who have more than 1.5MB/s and want to help out more. For
|
|
|
|
|
example, for a while Tonga was offering 10MB/s and its Tor server
|
|
|
|
|
would only make use of a bit of it. So Roger suggested that he run
|
|
|
|
|
two Tor servers, to use more.
|
|
|
|
|
|
