135-private-tor-networks.txt 6.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155
  1. Filename: 135-private-tor-networks.txt
  2. Title: Simplify Configuration of Private Tor Networks
  3. Version: $LastChangedRevision$
  4. Last-Modified: $LastChangedDate$
  5. Author: Karsten Loesing
  6. Created: 29-Apr-2008
  7. Status: Open
  8. Change history:
  9. 29-Apr-2008 Initial proposal for or-dev
  10. Overview:
  11. Configuring a private Tor network has become a time-consuming and
  12. error-prone task with the introduction of the v3 directory protocol. In
  13. addition to that, operators of private Tor networks need to set an
  14. increasing number of non-trivial configuration options, and it is hard
  15. to keep FAQ entries describing this task up-to-date. In this proposal we
  16. (1) suggest to (optionally) accelerate timing of the v3 directory voting
  17. process and (2) introduce an umbrella config option specifically aimed at
  18. creating private Tor networks.
  19. Design:
  20. 1. Accelerate Timing of v3 Directory Voting Process
  21. Tor has reasonable defaults for setting up a large, Internet-scale
  22. network with comparably high latencies and possibly wrong server clocks.
  23. However, those defaults are bad when it comes to quickly setting up a
  24. private Tor network for testing, either on a single node or LAN (things
  25. might be different when creating a test network on PlanetLab or
  26. something). Some time constraints should be made configurable for private
  27. networks. The general idea is to accelerate everything that has to do
  28. with propagation of directory information, but nothing else, so that a
  29. private network is available as soon as possible. (As a possible
  30. safeguard, changing these configuration values could be made dependent on
  31. the umbrella configuration option introduced in 2.)
  32. 1.1. Initial Voting Schedule
  33. When a v3 directory does not know any consensus, it assumes an initial,
  34. hard-coded VotingInterval of 30 minutes, VoteDelay of 5 minutes, and
  35. DistDelay of 5 minutes. This is important for multiple, simultaneously
  36. restarted directory authorities to meet at a common time and create an
  37. initial consensus. Unfortunately, this means that it may take up to half
  38. an hour (or even more) for a private Tor network to bootstrap.
  39. We propose to make these three time constants configurable (note that
  40. V3AuthVotingInterval, V3AuthVoteDelay, and V3AuthDistDelay do not have an
  41. effect on the _initial_ voting schedule, but only on the schedule that a
  42. directory authority votes for). This can be achieved by introducing three
  43. new configuration options: V3AuthInitialVotingInterval,
  44. V3AuthInitialVoteDelay, and V3AuthInitialDistDelay.
  45. As first safeguards, Tor should only accept configuration values for
  46. V3AuthInitialVotingInterval that divide evenly into the default value of
  47. 30 minutes. The effect is that even if people misconfigured their
  48. directory authorities, they would meet at the default values at the
  49. latest. The second safeguard is to allow configuration only when the
  50. umbrella configuration option PrivateTorNetwork is set.
  51. 1.2. Immediately Provide Reachability Information (Running flag)
  52. The default behavior of a directory authority is to provide the Running
  53. flag only after the authority is available for at least 30 minutes. The
  54. rationale is that before that time, an authority simply cannot deliver
  55. useful information about other running nodes. But for private Tor
  56. networks this may be different. This is currently implemented in the code
  57. as:
  58. /** If we've been around for less than this amount of time, our
  59. * reachability information is not accurate. */
  60. #define DIRSERV_TIME_TO_GET_REACHABILITY_INFO (30*60)
  61. There should be another configuration option DirAssumeRunningDelay with
  62. a default value of 30 minutes that can be changed when running private
  63. Tor networks, e.g. to 0 minutes. The configuration value would simply
  64. replace the quoted constant. Again, changing this option could be
  65. safeguarded by requiring the umbrella configuration option
  66. PrivateTorNetwork to be set.
  67. 1.3. Reduce Estimated Descriptor Propagation Time
  68. Tor currently assumes that it takes up to 10 minutes until router
  69. descriptors are propagated from the authorities to directory caches.
  70. This is not very useful for private Tor networks, and we want to be able
  71. to reduce this time, so that clients can download router descriptors in a
  72. timely manner.
  73. /** Clients don't download any descriptor this recent, since it will
  74. * probably not have propagated to enough caches. */
  75. #define ESTIMATED_PROPAGATION_TIME (10*60)
  76. We suggest to introduce a new config option
  77. EstimatedDescriptorPropagationTime which defaults to 10 minutes, but that
  78. can be set to any lower non-negative value, e.g. 0 minutes. The same
  79. safeguards as in 1.2 could be used here, too.
  80. 2. Umbrella Option for Setting Up Private Tor Networks
  81. Setting up a private Tor network requires a number of specific settings
  82. that are not required or useful when running Tor in the public Tor
  83. network. Instead of writing down these options in a FAQ entry, there
  84. should be a single configuration option, e.g. PrivateTorNetwork, that
  85. changes all required settings at once. Newer Tor versions would keep the
  86. set of configuration options up-to-date. It should still remain possible
  87. to manually overwrite the settings that the umbrella configuration option
  88. affects.
  89. The following configuration options are set by PrivateTorNetwork:
  90. - ServerDNSAllowBrokenResolvConf 1
  91. Ignore the situation that private relays are not aware of any name
  92. servers.
  93. - DirAllowPrivateAddresses 1
  94. Allow router descriptors containing private IP addresses.
  95. - EnforceDistinctSubnets 0
  96. Permit building circuits with relays in the same subnet.
  97. - AssumeReachable 1
  98. Omit self-testing for reachability.
  99. - AuthDirMaxServersPerAddr 0
  100. - AuthDirMaxServersPerAuthAddr 0
  101. Permit an unlimited number of nodes on the same IP address.
  102. - ClientDNSRejectInternalAddresses 0
  103. Believe in DNS responses resolving to private IP addresses.
  104. - ExitPolicyRejectPrivate 0
  105. Allow exiting to private IP addresses. (This one is a matter of
  106. taste---it might be dangerous to make this a default in a private
  107. network, although people setting up private Tor networks should know
  108. what they are doing.)
  109. - V3AuthVotingInterval 5 minutes
  110. - V3AuthVoteDelay 20 seconds
  111. - V3AuthDistDelay 20 seconds
  112. Accelerate voting schedule after first consensus has been reached.
  113. V3AuthInitialVotingInterval 5 minutes
  114. V3AuthInitialVoteDelay 20 seconds
  115. V3AuthInitialDistDelay 20 seconds
  116. Accelerate initial voting schedule until first consensus is reached.
  117. DirAssumeRunningDelay 0 minutes
  118. Consider routers as Running from the start of running an authority.
  119. EstimatedDescriptorPropagationTime 0 minutes
  120. Clients try downloading router descriptors from directory caches,
  121. even when they are not 10 minutes old.