update and integrate proposals 125 (bridges) and 137 (bootstrap status)

svn:r16374

1 files changed, 22 insertions, 69 deletions

diff --git a/proposals/125-bridges.txt b/proposals/125-bridges.txt
index bc6de66..8bb3169 100644
--- a/proposals/125-bridges.txt
+++ b/proposals/125-bridges.txt
@@ -4,7 +4,7 @@ Version: $Revision$
 Last-Modified: $Date$
 Author: Roger Dingledine
 Created: 11-Nov-2007
-Status: Finished
+Status: Closed
 Implemented-In: 0.2.0.x
 
 0. Preface
@@ -36,52 +36,32 @@ Implemented-In: 0.2.0.x
   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.
-
-  As of Tor 0.2.0.13-alpha, bridges will answer begin_dir questions
-  (and cache dir info they see so the answers will be more useful)
-  whether their DirPort is enabled or not. (After all, we don't care if
-  they have an open or reachable DirPort to answer begin_dir questions.)
-
-  We need to investigate if there are any anonymity worries with answering
-  BEGIN_DIR requests when our DirPort is off. I claim that we don't open
-  any new attacks: it's still a fine question to ask what partitioning
-  attacks there are when you can query a Tor client about its current
-  directory opinions, but these attacks already exist when DirPort is on.
-  We should investigate this in 0.2.1.x.
-
-1.3. Exit policy
+1.2. 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
+1.3. 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.
+1.4. 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, perhaps in 0.2.1.x.
+  We need to work harder on this step, perhaps in 0.2.2.x.
 
-1.6. Vidalia integration
+1.5. Vidalia integration
 
-  Vidalia 0.0.15 has turned its "Relay" settings page into a tri-state
+  Vidalia has turned its "Relay" settings page into a tri-state
   "Don't relay" / "Relay for the Tor network" / "Help censored users".
 
-  If you click the third choice, it forces your exit policy to reject *:*,
-  and it forces your DirPort to 9030 (but see Sec 1.2 above about DirPort).
+  If you click the third choice, it forces your exit policy to reject *:*.
 
   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
@@ -93,7 +73,7 @@ Implemented-In: 0.2.0.x
   the bridge identifier to the operator (see Section 3.1) so he can pass
   it on to bridge users.
 
-1.7. What if the default ORPort is already used?
+1.6. What if the default ORPort is already used?
 
   If the user already has a webserver or some other application
   bound to port 443, then Tor will fail to bind it and complain to the
@@ -102,7 +82,7 @@ Implemented-In: 0.2.0.x
   "ORPort auto" option that tells Tor to try to find something that's
   bindable and reachable. This would also help us tolerate ISPs that
   filter incoming connections on port 80 and port 443. But this should
-  be a different proposal, and can wait until 0.2.1.x.
+  be a different proposal, and can wait until 0.2.2.x.
 
 2. Bridge authorities.
 
@@ -127,25 +107,16 @@ Implemented-In: 0.2.0.x
   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.
+  Currently we export the bridge descriptors from Tonga to the
+  BridgeDB server, so it can give them out according to the policies
+  in blocking.pdf.
 
 2.2. Reachability/uptime testing
 
-  Right now the bridge authorities just passively collect bridge
-  descriptors, and give them out on request. At some point we are going
-  to want to recommend new bridges to users, and we'll want to have
-  some way of deciding which ones are up right now, which ones have
-  been around for a while, etc. We should have the bridge authorities
-  do active measurements of bridges just as the normal authorities do
-  active measurements of normal relays. Then we can export the results
-  just like in Section 2.1. above.
+  Right now the bridge authorities do active reachability testing of
+  bridges, so we know which ones to recommend for users.
 
-  In the design document, we suggested that bridges should publish
+  But in the design document, we suggested that bridges should publish
   anonymously (i.e. via Tor) to the bridge authority, so somebody watching
   the bridge authority can't just enumerate all the bridges. But if we're
   doing active measurement, the game is up. Perhaps we should back off on
@@ -164,7 +135,7 @@ Implemented-In: 0.2.0.x
   a random bridge authority. This resolves the robustness bottleneck,
   but makes the trust bottleneck even worse.
 
-  In 0.2.1.x and later we should think about better ways to have multiple
+  In 0.2.2.x and later we should think about better ways to have multiple
   bridge authorities.
 
 3. Bridge users.
@@ -174,10 +145,9 @@ Implemented-In: 0.2.0.x
   entry guards (their first hop) and directory guards (the source of
   all their directory information).
 
-  To become a bridge user, add the following two lines to your torrc:
+  To become a bridge user, add the following line to your torrc:
 
     UseBridges 1
-    TunnelDirConns 1
 
   and then add at least one "Bridge" line to your torrc based on the
   format below.
@@ -293,35 +263,18 @@ Implemented-In: 0.2.0.x
   first attempt, after 15 minutes for the second attempt, and after 60
   minutes for subsequent attempts.
 
-  In 0.2.1.x we should come up with some smarter retry schedules.
+  In 0.2.2.x we should come up with some smarter retry schedules.
 
 3.6. Vidalia integration
 
-  Vidalia 0.0.15 has a new checkbox in its Network config window called
+  Vidalia 0.0.16 has a checkbox in its Network config window called
   "My ISP blocks connections to the Tor network." Users who click that
   box change their configuration to:
-    TunnelDirConns 1
-    PreferTunneledDirConns 1
-
-  Once the box is checked, there is also a section for adding bridge
-  identifiers. When at least one bridge identifier is present, Vidalia
-  also changes their config to:
     UseBridges 1
     UpdateBridgesFromAuthority 1
-  and updates their Bridge config option accordingly.
-
-3.7. When should we make TunnelDirConns default
-
-  Right now Tor's directory requests can be filtered on the network,
-  and some tools used by Middle Eastern governments even do this. A user
-  who wants to circumvent these filters should click the above box in
-  Vidalia 0.0.15. But at what point should we make tunneled directory
-  requests the default?
-
-  Once proposal 124 (modified TLS handshake) is in place, we should
-  consider doing the switch. This might even be in the 0.2.0.x timeframe.
+  and should specify at least one Bridge identifier.
 
-3.8. Do we need a second layer of entry guards?
+3.7. Do we need a second layer of entry guards?
 
   If the bridge user uses the bridge as its entry guard, then the
   triangulation attacks from Lasse and Paul's Oakland paper work to