From 42e4acc41a51b1b170ecab91d9e6de5d104171bc Mon Sep 17 00:00:00 2001 From: Roger Dingledine Date: Fri, 2 Nov 2007 19:21:42 +0000 Subject: [PATCH] get my in-progress bridge proposal draft into svn so i don't lose it svn:r12347 --- doc/spec/proposals/xxx-bridges.txt | 145 +++++++++++++++++++++++++++++++++++++ 1 file changed, 145 insertions(+) create mode 100644 doc/spec/proposals/xxx-bridges.txt diff --git a/doc/spec/proposals/xxx-bridges.txt b/doc/spec/proposals/xxx-bridges.txt new file mode 100644 index 0000000000..d0191b9662 --- /dev/null +++ b/doc/spec/proposals/xxx-bridges.txt @@ -0,0 +1,145 @@ +Filename: xxx-bridges.txt +Title: Behavior for bridge users, bridge relays, and bridge authorities +Version: $Revision: 12051 $ +Last-Modified: $Date: 2007-10-19 14:56:24 -0400 (Fri, 19 Oct 2007) $ +Author: Roger Dingledine +Created: xx-Oct-2007 +Status: Open + +0. Preface: + + This document describes the design decisions around support for bridge + users, bridge relays, and bridge authorities. + + For more details on what all of these mean, look at blocking.tex in + /doc/design-paper/ + +1. Bridge relays. + + Bridge relays are just like normal Tor relays except they don't publish + their server descriptors to the main directory authorities. + +1.1. PublishServerDescriptor + + To configure your relay to be a bridge relay, just add + PublishServerDescriptor bridge + to your torrc. This will cause your relay to publish its descriptor + to all the bridge authorities rather than the default authorities. + + Alternatively, you can say + PublishServerDescriptor 0 + which will cause your relay to not publish anywhere. This could be + useful for private bridges. + +1.2. Defining DirPort + + Bridges need to answer BEGIN_DIR requests, both so they can answer + /server/authority questions ("what's your descriptor?") and so they + can supply their bridge users with cached copies of all the various + Tor network information. + + Right now (0.2.0.9-alpha) we require that bridges turn their DirPort on + -- which means both that we answer BEGIN_DIR requests and that we fetch + and cache directory information in an aggressive way like other servers. + + But: + a) we don't enforce that DirPort is on, since it's not clear how to + detect if the user meant to be a bridge. So it's easy to launch a bridge + relay that silently refuses BEGIN_DIR requests and is thus useless. + b) We don't actually care if they have an open or reachable DirPort. So + at some point we should separate having an open DirPort from answering + directory questions. Which leads to: + c) We need to investigate if there are any anonymity worries with + answering BEGIN_DIR requests when our DirPort is off. If there aren't, + we can drop the DirPort requirement. + +1.3. Exit policy + + Bridge relays should use an exit policy of "reject *:*". This is + because they only need to relay traffic between the bridge users + and the rest of the Tor network, so there's no need to let people + exit directly from them. + +1.4. RelayBandwidthRate / RelayBandwidthBurst + + We invented the RelayBandwidth* options for this situation: Tor clients + who want to allow relaying too. See proposal 111 for details. Relay + operators should feel free to rate-limit their relayed traffic. + +1.5. Helping the user with port forwarding, NAT, etc. + + Just as for operating normal relays, our documentation and hints for + how to make your ORPort reachable are inadequate for normal users. + + We need to work harder on this step. + +1.6. Vidalia integration + + Vidalia has turned into "Relay" settings page into a tri-state + "Don't relay" "Relay for the Tor network" "Help censored users". + + If the click the third choice, it forces your exit policy to reject *:*, + and it forces your DirPort to 9030 (see Sec 1.2 above about DirPort). + + If all the bridges end up on port 9001, that's not so good. On the + other hand, putting the bridges on a low-numbered port in the Unix + world requires jumping through extra hoops. The current compromise is + that Vidalia makes the ORPort default to 443 on Windows, and 9001 on + other platforms. + +2. Bridge authorities. + + Bridge authorities are like normal directory authorities, except they + don't create their own network-status documents. So if you ask an + authority for a network-status document, they behave like a directory + mirror: they give you one from one of the main authorities. But if + you ask the bridge authority for a particular identity fingerprint, + it will happily give you the latest descriptor for that fingerprint. + + Right now there's one bridge authority, running on the Tonga relay. + +2.1. Exporting bridge-purpose descriptors + + We've added a new purpose for server descriptors, the "bridge" + purpose. With the new router-descriptors file that includes annotations, + it's easy to look through it and find the bridge-purpose descriptors. + + We should work with Tonga to export its router-descriptors file to + some place where we can distribute the bridge addresses according to + the policies in blocking.pdf. It might even be easier to have it write + out a separate file, just for export, that includes only the bridge + descriptors; or maybe a six-liner perl postprocessing script is the + better plan there to create a file for export. + +2.2. Reachability/uptime testing + + should bridge relays publish anonymously to the bridge authority? + + migrating to multiple bridge authorities + +3. Bridge users. + + UseBridges 1 + TunnelDirConns 1 + + Format of the bridge identifier. + + bridges as entry guards + + bridges as directory guards + + UpdateBridgesFromAuthority 1 + + when to use a one-hop circuit, when to use a three-hop, to reach + the directory authority + + bridge descriptor retry schedule + + when to make TunnelDirConns default. + + Vidalia integration: + + vidalia looks up the geoip data for tor servers it knows about. which + is fine, except when they're bridges. now geoip.vidalia-project.net + is a place to go to learn bridge IP addresses. + -- 2.11.4.GIT