Home Explore Help
Sign In
piros
/
tor
3
0
Fork 0
Files Issues 0 Pull Requests 0 Wiki
Tree: d5b2dab31d
Branches Tags
tor
/
doc
/
spec
/
proposals
/
109-no-sharing-ips.txt

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

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192 
  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. Implemented-In: 0.2.0.x
    9. 

  9. 

  10. Overview:
    11. 

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

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

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

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

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

  16.   router per IP address.
    17. 

  17. 

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

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

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

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

  22.   traffic.
    23. 

  23. 

  24. Motivation:
    25. 

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

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

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

  28. 

  29. Security implications:
    30. 

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

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

  32. 

  33. Specification:
    34. 

  34. 

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

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

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

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

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

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

  41.   servers in increasing order of bandwidth.
    42. 

  42. 

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

  44. 

  45.   If the total observed
    46. 

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

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

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

  49.   servers is under MAX_BW_PER_IP.
    50. 

  50.   ]]
    51. 

  51. 

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

  53. 

  54.   MAX_SERVERS_PER_IP is 3.
    55. 

  55. 

  56.   MAX_BW_PER_IP is 8 MB per s.
    57. 

  57. 

  58. Compatibility:
    59. 

  59. 

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

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

  62. 

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

  64.   WiseUp      68.5.113.81     ip68-5-113-81.oc.oc.cox.net     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.   Unnamed     62.1.196.71     pc01-megabyte-net-arkadiou.megabyte.gr  9001
    68. 

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

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

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

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

  72. 

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

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

  75. 

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

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

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

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

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

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

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

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

  84.     what we can get.
    85. 

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

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

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

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

  89. 

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

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

  92.