|
|
@@ -0,0 +1,47 @@
|
|
|
+Filename: 128-bridge-families.txt
|
|
|
+Title: Families of private bridges
|
|
|
+Version: $Revision$
|
|
|
+Last-Modified: $Date$
|
|
|
+Author: Roger Dingledine
|
|
|
+Created: 2007-12-xx
|
|
|
+Status: Needs-Research
|
|
|
+
|
|
|
+1. Overview
|
|
|
+
|
|
|
+ Proposal 125 introduced the basic notion of how bridge authorities,
|
|
|
+ bridge relays, and bridge users should behave. But it doesn't get into
|
|
|
+ the various mechanisms of how to distribute bridge relay addresses to
|
|
|
+ bridge users.
|
|
|
+
|
|
|
+ One of the mechanisms we have in mind is called 'families of bridges'.
|
|
|
+ If a bridge user knows about only one private bridge, and that bridge
|
|
|
+ shuts off for the night or gets a new dynamic IP address, the bridge
|
|
|
+ user is out of luck and needs to re-bootstrap manually or wait and
|
|
|
+ hope it comes back. On the other hand, if the bridge user knows about
|
|
|
+ a family of bridges, then as long as one of those bridges is still
|
|
|
+ reachable his Tor client can automatically learn about where the
|
|
|
+ other bridges have gone.
|
|
|
+
|
|
|
+ So in this design, a single volunteer could run multiple coordinated
|
|
|
+ bridges, or a group of volunteers could each run a bridge. We abstract
|
|
|
+ out the details of how these volunteers find each other and decide to
|
|
|
+ set up a family.
|
|
|
+
|
|
|
+
|
|
|
+somebody needs to run a bridge authority
|
|
|
+
|
|
|
+it needs to have a torrc option to publish networkstatuses of its bridges
|
|
|
+
|
|
|
+it should also do reachability testing just of those bridges
|
|
|
+
|
|
|
+people ask for the bridge networkstatus by asking for a url that
|
|
|
+contains a password. (it's safe to do this because of begin_dir.)
|
|
|
+
|
|
|
+so the bridge users need to know a) a password, and b) a bridge
|
|
|
+authority line.
|
|
|
+
|
|
|
+the bridge users need to know the bridge authority line.
|
|
|
+
|
|
|
+the bridge authority needs to know the password.
|
|
|
+
|
|
|
+
|
Roger Dingledine