1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
|
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 or Tor relays. 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.
Note that for the moment, only transitions between client and
bridge are being considered. Transitions to public relay will
be considered at a future date, but will use the same
infrastructure for measuring capacity and reliability.
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 relays, 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
- relay (R): Currently a public relay, 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 *relay*, but the user has chosen to remain a *bridge*
Auto -> relay: Tor has detected that it is sufficiently reliable
to be *relay*, and will skip being a *bridge*
Auto-bridge -> relay: Tor has detected that it is sufficiently
reliable to be a *relay*
Note that this model does not support automatic demotion. If this
is desirable, there should be some memory as to whether the
previous state was relay, bridge, or auto-bridge. Otherwise the
user may be prompted to become a relay, 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. If
Vidalia is not available, it still may be possible to solicit an
email address on install, and contact the operator to ask whether
a transition to bridge or relay is permitted.
Finally, Tor could by default not make any transition, and the user
would need to opt in by stating the maximum level (bridge or
relay) to which the node may automatically promote itself.
3.x New options
3.x New controller message
4. Related proposals
5. Open questions:
- What user interaction policy should we take?
- When (if ever) should we turn a relay into an exit relay?
- What should the rate limits be for auto-promoted bridges/relays?
Should we prompt the user for this?
- Perhaps the bridge authority should tell potential bridges
whether to enable themselves, by taking into account whether
their IP address is blocked
- How do we explain the possible risks of running a bridge/relay
* Use of bandwidth/congestion
* Publication of IP address
* Blocking from IRC (even for non-exit relays)
- What feedback should we give to bridge relays, to encourage then
e.g. number of recent users (what about reserve bridges)?
|
