Added proposal 135: Simplify Configuration of Private Tor Networks

svn:r14509

doc/spec/proposals/000-index.txt

@@ -57,6 +57,7 @@ Proposals by number:
 132  A Tor Web Service For Verifying Correct Browser Configuration [DRAFT]
 133  Incorporate Unreachable ORs into the Tor Network [DRAFT]
 134  More robust consensus voting with diverse authority sets [DRAFT]
+135  Simplify Configuration of Private Tor Networks [OPEN]
 
 
 Proposals by status:
@@ -71,6 +72,7 @@ Proposals by status:
  OPEN:
    120  Suicide descriptors when Tor servers stop
    121  Hidden Service Authentication
+   135  Simplify Configuration of Private Tor Networks
  NEEDS-REVISION:
    110  Avoiding infinite length circuits
    117  IPv6 exits

doc/spec/proposals/135-private-tor-networks.txt

@@ -0,0 +1,155 @@
+Filename: 135-private-tor-networks.txt
+Title: Simplify Configuration of Private Tor Networks
+Version: $LastChangedRevision$
+Last-Modified: $LastChangedDate$
+Author: Karsten Loesing
+Created: 29-Apr-2008
+Status: Open
+
+Change history:
+
+  29-Apr-2008  Initial proposal for or-dev
+
+Overview:
+
+  Configuring a private Tor network has become a time-consuming and
+  error-prone task with the introduction of the v3 directory protocol. In
+  addition to that, operators of private Tor networks need to set an
+  increasing number of non-trivial configuration options, and it is hard
+  to keep FAQ entries describing this task up-to-date. In this proposal we
+  (1) suggest to (optionally) accelerate timing of the v3 directory voting
+  process and (2) introduce an umbrella config option specifically aimed at
+  creating private Tor networks.
+
+Design:
+
+  1. Accelerate Timing of v3 Directory Voting Process
+
+  Tor has reasonable defaults for setting up a large, Internet-scale
+  network with comparably high latencies and possibly wrong server clocks.
+  However, those defaults are bad when it comes to quickly setting up a
+  private Tor network for testing, either on a single node or LAN (things
+  might be different when creating a test network on PlanetLab or
+  something). Some time constraints should be made configurable for private
+  networks. The general idea is to accelerate everything that has to do
+  with propagation of directory information, but nothing else, so that a
+  private network is available as soon as possible. (As a possible
+  safeguard, changing these configuration values could be made dependent on
+  the umbrella configuration option introduced in 2.)
+
+  1.1. Initial Voting Schedule
+
+  When a v3 directory does not know any consensus, it assumes an initial,
+  hard-coded VotingInterval of 30 minutes, VoteDelay of 5 minutes, and
+  DistDelay of 5 minutes. This is important for multiple, simultaneously
+  restarted directory authorities to meet at a common time and create an
+  initial consensus. Unfortunately, this means that it may take up to half
+  an hour (or even more) for a private Tor network to bootstrap.
+
+  We propose to make these three time constants configurable (note that
+  V3AuthVotingInterval, V3AuthVoteDelay, and V3AuthDistDelay do not have an
+  effect on the _initial_ voting schedule, but only on the schedule that a
+  directory authority votes for). This can be achieved by introducing three
+  new configuration options: V3AuthInitialVotingInterval,
+  V3AuthInitialVoteDelay, and V3AuthInitialDistDelay.
+
+  As first safeguards, Tor should only accept configuration values for
+  V3AuthInitialVotingInterval that divide evenly into the default value of
+  30 minutes. The effect is that even if people misconfigured their
+  directory authorities, they would meet at the default values at the
+  latest. The second safeguard is to allow configuration only when the
+  umbrella configuration option PrivateTorNetwork is set.
+
+  1.2. Immediately Provide Reachability Information (Running flag)
+
+  The default behavior of a directory authority is to provide the Running
+  flag only after the authority is available for at least 30 minutes. The
+  rationale is that before that time, an authority simply cannot deliver
+  useful information about other running nodes. But for private Tor
+  networks this may be different. This is currently implemented in the code
+  as:
+
+  /** If we've been around for less than this amount of time, our
+   * reachability information is not accurate. */
+  #define DIRSERV_TIME_TO_GET_REACHABILITY_INFO (30*60)
+
+  There should be another configuration option DirAssumeRunningDelay with
+  a default value of 30 minutes that can be changed when running private
+  Tor networks, e.g. to 0 minutes. The configuration value would simply
+  replace the quoted constant. Again, changing this option could be
+  safeguarded by requiring the umbrella configuration option
+  PrivateTorNetwork to be set.
+
+  1.3. Reduce Estimated Descriptor Propagation Time
+
+  Tor currently assumes that it takes up to 10 minutes until router
+  descriptors are propagated from the authorities to directory caches.
+  This is not very useful for private Tor networks, and we want to be able
+  to reduce this time, so that clients can download router descriptors in a
+  timely manner.
+
+  /** Clients don't download any descriptor this recent, since it will
+   * probably not have propagated to enough caches. */
+  #define ESTIMATED_PROPAGATION_TIME (10*60)
+
+  We suggest to introduce a new config option
+  EstimatedDescriptorPropagationTime which defaults to 10 minutes, but that
+  can be set to any lower non-negative value, e.g. 0 minutes. The same
+  safeguards as in 1.2 could be used here, too.
+
+  2. Umbrella Option for Setting Up Private Tor Networks
+
+  Setting up a private Tor network requires a number of specific settings
+  that are not required or useful when running Tor in the public Tor
+  network. Instead of writing down these options in a FAQ entry, there
+  should be a single configuration option, e.g. PrivateTorNetwork, that
+  changes all required settings at once. Newer Tor versions would keep the
+  set of configuration options up-to-date. It should still remain possible
+  to manually overwrite the settings that the umbrella configuration option
+  affects.
+
+  The following configuration options are set by PrivateTorNetwork:
+
+  - ServerDNSAllowBrokenResolvConf 1
+      Ignore the situation that private relays are not aware of any name
+      servers.
+
+  - DirAllowPrivateAddresses 1
+      Allow router descriptors containing private IP addresses.
+
+  - EnforceDistinctSubnets 0
+      Permit building circuits with relays in the same subnet.
+
+  - AssumeReachable 1
+      Omit self-testing for reachability.
+
+  - AuthDirMaxServersPerAddr 0
+  - AuthDirMaxServersPerAuthAddr 0
+      Permit an unlimited number of nodes on the same IP address.
+
+  - ClientDNSRejectInternalAddresses 0
+      Believe in DNS responses resolving to private IP addresses.
+
+  - ExitPolicyRejectPrivate 0
+      Allow exiting to private IP addresses. (This one is a matter of
+      taste---it might be dangerous to make this a default in a private
+      network, although people setting up private Tor networks should know
+      what they are doing.)
+
+  - V3AuthVotingInterval 5 minutes
+  - V3AuthVoteDelay 20 seconds
+  - V3AuthDistDelay 20 seconds
+      Accelerate voting schedule after first consensus has been reached.
+
+    V3AuthInitialVotingInterval 5 minutes
+    V3AuthInitialVoteDelay 20 seconds
+    V3AuthInitialDistDelay 20 seconds
+      Accelerate initial voting schedule until first consensus is reached.
+
+    DirAssumeRunningDelay 0 minutes
+      Consider routers as Running from the start of running an authority.
+
+    EstimatedDescriptorPropagationTime 0 minutes
+      Clients try downloading router descriptors from directory caches,
+      even when they are not 10 minutes old.
+