From eec5ec9b72d0d412f9813b4f264a439f2d05dff6 Mon Sep 17 00:00:00 2001 From: Karsten Loesing Date: Tue, 29 Apr 2008 20:36:51 +0000 Subject: [PATCH] Added proposal 135: Simplify Configuration of Private Tor Networks svn:r14509 --- doc/spec/proposals/000-index.txt | 2 + .../proposals/135-private-tor-networks.txt | 155 ++++++++++++++++++ 2 files changed, 157 insertions(+) create mode 100644 doc/spec/proposals/135-private-tor-networks.txt diff --git a/doc/spec/proposals/000-index.txt b/doc/spec/proposals/000-index.txt index e8a34073c4..b7c9d75acc 100644 --- a/doc/spec/proposals/000-index.txt +++ b/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 diff --git a/doc/spec/proposals/135-private-tor-networks.txt b/doc/spec/proposals/135-private-tor-networks.txt new file mode 100644 index 0000000000..8ed51c9328 --- /dev/null +++ b/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. +