Home Explore Help
Sign In
sengler
/
tor-parallel-relay-conn
1
0
Fork 0
Files Issues 0 Pull Requests 0 Wiki
Tree: 0a865bc277
Branches Tags
tor-parallel...
/
doc
/
spec
/
proposals
/
109-no-sharing-ips.txt

109-no-sharing-ips.txt 4.0 KB
History Raw

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091 
  1. Filename: 109-no-sharing-ips.txt
    2. 

  2. Title: No more than one server per IP address.
    3. 

  3. Version: $Revision$
    4. 

  4. Last-Modified: $Date$
    5. 

  5. Author: Kevin Bauer & Damon McCoy
    6. 

  6. Created: 9-March-2007
    7. 

  7. Status: Closed
    8. 

  8. 

  9. Overview:
    10. 

  10.   This document describes a solution to a Sybil attack vulnerability in the
    11. 

  11.   directory servers. Currently, it is possible for a single IP address to
    12. 

  12.   host an arbitrarily high number of Tor routers. We propose that the
    13. 

  13.   directory servers limit the number of Tor routers that may be registered at
    14. 

  14.   a particular IP address to some small (fixed) number, perhaps just one Tor
    15. 

  15.   router per IP address.
    16. 

  16. 

  17.   While Tor never uses more than one server from a given /16 in the same
    18. 

  18.   circuit, an attacker with multiple servers in the same place is still
    19. 

  19.   dangerous because he can get around the per-server bandwidth cap that is
    20. 

  20.   designed to prevent a single server from attracting too much of the overall
    21. 

  21.   traffic.
    22. 

  22. 

  23. Motivation:
    24. 

  24.   Since it is possible for an attacker to register an arbitrarily large
    25. 

  25.   number of Tor routers, it is possible for malicious parties to do this
    26. 

  26.   as part of a traffic analysis attack.
    27. 

  27. 

  28. Security implications:
    29. 

  29.   This countermeasure will increase the number of IP addresses that an
    30. 

  30.   attacker must control in order to carry out traffic analysis.
    31. 

  31. 

  32. Specification:
    33. 

  33. 

  34.   For each IP address, each directory authority tracks the number of routers
    35. 

  35.   using that IP address, along with their total observed bandwidth.  If there
    36. 

  36.   are more than MAX_SERVERS_PER_IP servers at some IP, the authority should
    37. 

  37.   "disable" all but MAX_SERVERS_PER_IP servers.  When choosing which servers
    38. 

  38.   to disable, the authority should first disable non-Running servers in
    39. 

  39.   increasing order of observed bandwidth, and then should disable Running
    40. 

  40.   servers in increasing order of bandwidth.
    41. 

  41. 

  42.   [[  We don't actually do this part here. -NM
    43. 

  43. 

  44.   If the total observed
    45. 

  45.   bandwidth of the remaining non-"disabled" servers exceeds MAX_BW_PER_IP,
    46. 

  46.   the authority should "disable" some of the remaining servers until only one
    47. 

  47.   server remains, or until the remaining observed bandwidth of non-"disabled"
    48. 

  48.   servers is under MAX_BW_PER_IP.
    49. 

  49.   ]]
    50. 

  50. 

  51.   Servers that are "disabled" MUST be marked as non-Valid and non-Running.
    52. 

  52. 

  53.   MAX_SERVERS_PER_IP is 3.
    54. 

  54. 

  55.   MAX_BW_PER_IP is 8 MB per s.
    56. 

  56. 

  57. Compatibility:
    58. 

  58. 

  59.   Upon inspection of a directory server, we found that the following IP
    60. 

  60.   addresses have more than one Tor router:
    61. 

  61. 

  62.   Scruples    68.5.113.81     ip68-5-113-81.oc.oc.cox.net     443
    63. 

  63.   WiseUp      68.5.113.81     ip68-5-113-81.oc.oc.cox.net     9001
    64. 

  64.   Unnamed     62.1.196.71     pc01-megabyte-net-arkadiou.megabyte.gr  9001
    65. 

  65.   Unnamed     62.1.196.71     pc01-megabyte-net-arkadiou.megabyte.gr  9001
    66. 

  66.   Unnamed     62.1.196.71     pc01-megabyte-net-arkadiou.megabyte.gr  9001
    67. 

  67.   aurel       85.180.62.138   e180062138.adsl.alicedsl.de     9001
    68. 

  68.   sokrates    85.180.62.138   e180062138.adsl.alicedsl.de     9001
    69. 

  69.   moria1      18.244.0.188    moria.mit.edu   9001
    70. 

  70.   peacetime   18.244.0.188    moria.mit.edu   9100
    71. 

  71. 

  72.   There may exist compatibility issues with this proposed fix.  Reasons why
    73. 

  73.   more than one server would share an IP address include:
    74. 

  74. 

  75.   * Testing. moria1, moria2, peacetime, and other morias all run on one
    76. 

  76.     computer at MIT, because that way we get testing. Moria1 and moria2 are
    77. 

  77.     run by Roger, and peacetime is run by Nick.
    78. 

  78.   * NAT. If there are several servers but they port-forward through the same
    79. 

  79.     IP address, ... we can hope that the operators coordinate with each
    80. 

  80.     other. Also, we should recognize that while they help the network in
    81. 

  81.     terms of increased capacity, they don't help as much as they could in
    82. 

  82.     terms of location diversity. But our approach so far has been to take
    83. 

  83.     what we can get.
    84. 

  84.   * People who have more than 1.5MB/s and want to help out more. For
    85. 

  85.     example, for a while Tonga was offering 10MB/s and its Tor server
    86. 

  86.     would only make use of a bit of it. So Roger suggested that he run
    87. 

  87.     two Tor servers, to use more.
    88. 

  88. 

  89. [Note Roger's tweak to this behavior, in
    90. 

  90. http://archives.seul.org/or/cvs/Oct-2007/msg00118.html]
    91. 

  91.