[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[or-cvs] [tor/master] Add proposal 170 "Configuration options regarding circuit building"
Author: Sebastian Hahn <sebastian@xxxxxxxxxxxxxx>
Date: Wed, 3 Mar 2010 23:56:23 -0500
Subject: Add proposal 170 "Configuration options regarding circuit building"
Commit: f3003d588fb379fae9a99568aa58d445ee7e2f0d
---
doc/spec/proposals/000-index.txt | 2 +
doc/spec/proposals/170-user-path-config.txt | 95 +++++++++++++++++++++++++++
2 files changed, 97 insertions(+), 0 deletions(-)
create mode 100644 doc/spec/proposals/170-user-path-config.txt
diff --git a/doc/spec/proposals/000-index.txt b/doc/spec/proposals/000-index.txt
index 664c565..62327a1 100644
--- a/doc/spec/proposals/000-index.txt
+++ b/doc/spec/proposals/000-index.txt
@@ -90,6 +90,7 @@ Proposals by number:
167 Vote on network parameters in consensus [CLOSED]
168 Reduce default circuit window [OPEN]
169 Eliminate TLS renegotiation for the Tor connection handshake [DRAFT]
+170 Configuration options regarding circuit building [DRAFT]
Proposals by status:
@@ -101,6 +102,7 @@ Proposals by status:
141 Download server descriptors on demand
144 Increase the diversity of circuits by detecting nodes belonging the same provider
169 Eliminate TLS renegotiation for the Tor connection handshake [for 0.2.2]
+ 170 Configuration options regarding circuit building
NEEDS-REVISION:
131 Help users to verify they are using Tor
OPEN:
diff --git a/doc/spec/proposals/170-user-path-config.txt b/doc/spec/proposals/170-user-path-config.txt
new file mode 100644
index 0000000..fa74c76
--- /dev/null
+++ b/doc/spec/proposals/170-user-path-config.txt
@@ -0,0 +1,95 @@
+Title: Configuration options regarding circuit building
+Filename: 170-user-path-config.txt
+Author: Sebastian Hahn
+Created: 01-March-2010
+Status: Draft
+
+Overview:
+
+ This document outlines how Tor handles the user configuration
+ options to influence the circuit building process.
+
+Motivation:
+
+ Tor's treatment of the configuration *Nodes options was surprising
+ to many users, and quite a few conspiracy theories have crept up. We
+ should update our specification and code to better describe and
+ communicate what is going during circuit building, and how we're
+ honoring configuration. So far, we've been tracking a bugreport
+ about this behaviour (
+ https://bugs.torproject.org/flyspray/index.php?do=details&id=1090 )
+ and Nick replied in a thread on or-talk (
+ http://archives.seul.org/or/talk/Feb-2010/msg00117.html ).
+
+ This proposal tries to document our intention for those configuration
+ options.
+
+Design:
+
+ Five configuration options are available to users to influence Tor's
+ circuit building. EntryNodes and ExitNodes define a list of nodes
+ that are for the Entry/Exit position in all circuits. ExcludeNodes
+ is a list of nodes that are used for no circuit, and
+ ExcludeExitNodes is a list of nodes that aren't used as the last
+ hop. StrictNodes defines Tor's behaviour in case of a conflict, for
+ example when a node that is excluded is the only available
+ introduction point. Setting StrictNodes to 1 breaks Tor's
+ functionality in that case, and it will refuse to build such a
+ circuit.
+
+ Neither Nick's email nor bug 1090 have clear suggestions how we
+ should behave in each case, so I tried to come up with something
+ that made sense to me.
+
+Security implications:
+
+ Deviating from normal circuit building can break one's anonymity, so
+ the documentation of the above option should contain a warning to
+ make users aware of the pitfalls.
+
+Specification:
+
+ It is proposed that the "User configuration" part of path-spec
+ (section 2.2.2) be replaced with this:
+
+ Users can alter the default behavior for path selection with
+ configuration options. In case of conflicts (excluding and requiring
+ the same node) the "StrictNodes" option is used to determine
+ behaviour. If a nodes is both excluded and required via a
+ configuration option, the exclusion takes preference.
+
+ - If "ExitNodes" is provided, then every request requires an exit
+ node on the ExitNodes list. If a request is supported by no nodes
+ on that list, and "StrictNodes" is false, then Tor treats that
+ request as if ExitNodes were not provided.
+
+ - "EntryNodes" behaves analogously.
+
+ - If "ExcludeNodes" is provided, then no circuit uses any of the
+ nodes listed. If a circuit requires an excluded node to be used,
+ and "StrictNodes" is false, then Tor uses the node in that
+ position while not using any other of the excluded nodes.
+
+ - If "ExcludeExitNodes" is provided, then Tor will not use the nodes
+ listed for the exit position in a circuit. If a circuit requires
+ an excluded node to be used in the exit position and "StrictNodes"
+ is false, then Tor builds that circuit as if ExcludeExitNodes were
+ not provided.
+
+ - If a user tries to connect to or resolve a hostname of the form
+ <target>.<servername>.exit and the "AllowDotExit" configuration
+ option is set to 1, the request is rewritten to a request for
+ <target>, and the request is only supported by the exit whose
+ nickname or fingerprint is <servername>. If "AllowDotExit" is set
+ to 0 (default), any request for <anything>.exit is denied.
+
+ - When any of the *Nodes settings are changed, all circuits are
+ expired immediately, to prevent a situation where a previously
+ built circuit is used even though some of its nodes are now
+ excluded.
+
+
+Compatibility:
+
+ The old Strict*Nodes options are deprecated, and the StrictNodes
+ option is new. Tor users may need to update their configuration file.
--
1.6.5