[proposal 136] Re: Proposal: Simplify Configuration of Private Tor Networks

[Nick Mathewson]

On Tue, Apr 29, 2008 at 10:19:57PM +0200, Karsten Loesing wrote:
[...]
> Filename: xxx-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.

Sounds plausible, especially with the "make a single option required
to control all the sub-options that shouldn't be run on the main
network" feature.  I say we do it.

 [...]
>   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.

Is PrivateTorNetwork for directory authorities only?  If so, it should
be prefixed with V3Auth*.  In fact, maybe all options that can only be
adjusted in a private network should share.

Also, do we mean "Private" or "Testing"?  (This is a bikeshed, I know.)

Also, as a safeguard for the system as a whole, perhaps it should be
an error to specify PrivateTorNetwork without configuring a
non-default set of dirservers.  [ISTR we once did something a little
like this.  Arma: did it end well? :) ]

>   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.

Sounds good, but DirTimeToLearnReachability would probably be a better
name.  I don't think that it needs to be conditioned on
PrivateTorNetwork, though: the affect of an authority setting it badly
is not "voting fails" but "the authority gets confused and outvoted."

>   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.

Right.  This one is potentially dangerous for clients to use in the
mainstream network (because of the partitioning issues), and doesn't
provide any benefit other than faster network bootstrapping, so making
it conditional on the umbrella option is a good idea.
 
>   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:

If the option is going to do all this, it should definitely be called
TestingTorNetwork.  Also, you should define the semantics for
specifying TestingTorNetwork *and* a specifying a value for one of
these options, as in:
   TestingTorNetwork 1
   DirAllowPrivateAddresses 0
I think that the more specific option should take precedence.

Another interesting issue is: what happens when a controller is used
to change TestingTorNetwork to 0, or when to reset (say)
DirAllowPrivateAddresses to its default.

Thoughts?

yrs,
-- 
Nick