From 6008fcf863b253306cb59a0e169408a1028e47f3 Mon Sep 17 00:00:00 2001 From: Steven Murdoch Date: Sun, 14 Mar 2010 23:06:48 +0000 Subject: [PATCH] Start idea xxx-automatic-node-promotion - Initial draft of overview and motivation - Start of design --- .../ideas/xxx-automatic-node-promotion.txt | 96 +++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 doc/spec/proposals/ideas/xxx-automatic-node-promotion.txt diff --git a/doc/spec/proposals/ideas/xxx-automatic-node-promotion.txt b/doc/spec/proposals/ideas/xxx-automatic-node-promotion.txt new file mode 100644 index 0000000000..2af1df62dc --- /dev/null +++ b/doc/spec/proposals/ideas/xxx-automatic-node-promotion.txt @@ -0,0 +1,96 @@ +Filename: xxx-automatic-node-promotion.txt +Title: Automatically promoting Tor clients to nodes +Author: Steven Murdoch +Created: 12-Mar-2010 +Status: Draft +Target: + +1. Overview + + This proposal describes how Tor clients could determine when they + have sufficient bandwidth capacity and are sufficiently reliable to + become either bridges are Tor servers. When they meet this + criteria, they will automatically promote themselves, based on user + preferences. The proposal also defines the new controller messages + and options which will control this process. + +2. Motivation and history + + Tor has a growing user-base and one of the major impediments to the + quality of service offered is the lack of network capacity. This is + particularly the case for bridges, because these are gradually + being blocked, and thus no longer of use to people within some + countries. By automatically promoting Tor clients to bridges, and + perhaps also to full public servers, this proposal aims to solve + these problems. + + Only Tor clients which are sufficiently useful should be promoted, + and the process of determining usefulness should be performed + without reporting the existence of the client to the central + authorities. The criteria used for determining usefulness will be + in terms of bandwidth capacity and uptime, but parameters should be + specified in the directory consensus. State stored at the client + should be in no more detail than necessary, to prevent sensitive + information being recorded. + +3. Design + +3.x Opt-in state model + + Tor can be in one of five node-promotion states: + + - off (O): Currently a client, and will stay as such + - auto (A): Currently a client, but will consider promotion + - bridge (B): Currently a bridge, and will stay as such + - auto-bridge (AB): Currently a bridge, but will consider promotion + - server (S): Currently a public server, and will stay as such + + The state can be fully controlled from the configuration file or + controller, but the normal state transitions are as follows: + + Any state -> off: User has opted out of node promotion + Off -> any state: Only permitted with user consent + + Auto -> auto-bridge: Tor has detected that it is sufficiently + reliable to be a *bridge* + Auto -> bridge: Tor has detected that it is sufficiently reliable + to be a *server*, but the user has chosen to remain a *bridge* + Auto -> server: Tor has detected that it is sufficiently reliable + to be *server*, and will skip being a *bridge* + Auto-bridge -> server: Tor has detected that it is sufficiently + reliable to be a *server* + + Note that this model does not support demotion. If this is + desirable, there should be some memory as to whether the previous + state was server, bridge, or auto-bridge. Otherwise the user may be + prompted to become a server, although he has opted to only be a + bridge. + +3.x User interaction policy + + There are a variety of options in how to involve the user into the + decision as to whether and when to perform node promotion. The + choice also may be different when Tor is running from Vidalia (and + thus can readily prompt the user for information), and standalone + (where Tor can only log messages, which may or may not be read). + + The option requiring minimal user interaction is to automatically + promote nodes according to reliability, and allow the user to opt + out, by changing settings in the configuration file or Vidalia user + interface. + + Alternatively, if a user interface is available, Tor could prompt + the user when it detects that a transition is available, and allow + the user to choose which of the available options to select. + + Finally, Tor could by default not make any transition, and the user + would need to opt in by stating the maximum level (bridge or + server) to which the node may automatically promote itself. + +3.x New options + +3.x New controller message + +4. Related proposals + +5. Open questions: