[or-cvs] added a section about how to deal with connectivity informa...

[goodell at seul.org]

Update of /home/or/cvsroot/tor/doc
In directory moria.mit.edu:/tmp/cvs-serv24739

Modified Files:
	dir-spec.txt 
Log Message:
added a section about how to deal with connectivity information in Blossom/Tor


Index: dir-spec.txt
===================================================================
RCS file: /home/or/cvsroot/tor/doc/dir-spec.txt,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- dir-spec.txt	19 Jan 2005 04:36:56 -0000	1.1
+++ dir-spec.txt	20 Jan 2005 07:45:14 -0000	1.2
@@ -28,7 +28,7 @@
     and admission (which nodes are "recommended" for certain uses).
 
 1c. [optional] We want to permit servers that can't route to all other
-    servers, e.g. because they're behind NAT or otherwise firewalled.
+    servers, e.g. because they're behind NAT or otherwise firewalled.*
 
 2. Assumptions.
 
@@ -95,3 +95,76 @@
     figurehead?
   - 'Extend policies' -- middleman doesn't really mean middleman, alas.
 
+----------
+
+(*) Regarding "Blossom: an unstructured overlay network for end-to-end
+connectivity."
+
+In this section we address possible solutions to the problem of how to allow
+Tor routers in different transport domains to communicate.
+
+First, we presume that for every interface between transport domains A and B,
+one Tor router T_A exists in transport domain A, one Tor router T_B exists in
+transport domain B, and (without loss of generality) T_A can open a persistent
+connection to T_B.  Any Tor traffic between the two routers will occur over
+this connection, which effectively renders the routers equal partners in
+bridging between the two transport domains.  We refer to the established link
+between two transport domains as a "bridge" (we use this term because there is
+no serious possibility of confusion with the notion of a layer 2 bridge).
+
+Next, suppose that the universe consists of transport domains connected by
+persistent connections in this manner.  An individual router can open multiple
+connections to routers within the same foreign transport domain, and it can
+establish separate connections to routers within multiple foreign transport
+domains.
+
+As in regular Tor, each Blossom router pushes its descriptor to directory
+servers.  These directory servers can be within the same transport domain, but
+they need not be.  The trick is that if a directory server is in another
+transport domain, then that directory server must know through which Tor
+routers to send messages destined for the Tor router in question.  Descriptors
+for Blossom routers held by the directory server must contain a special field
+for specifying a path through the overlay (i.e. an ordered list of router
+names/IDs) to a router in a foreign transport domain.  (This field may be a set
+of paths rather than a single path.)  A new router publishing to a directory
+server in a foreign transport should include a list of routers.  This list
+should be either:
+
+a. ...a list of routers to which the router has persistent connections, or, if
+the new router does not have any persistent connections,
+
+b. ...a (not necessarily exhaustive) list of fellow routers that are in the
+same transport domain.
+
+The directory server will be able to use this information to derive a path to
+the new router, as follows.  If the new router used approach (a), then the
+directory server will define the same path(s) in the descriptors for the
+router(s) specified in the list, with the corresponding specified router
+appended to each path.  If the new router used approach (b), then the directory
+server will define the same path(s) in the descriptors for the routers
+specified in the list.  The directory server will then insert the newly defined
+path into the descriptor from the router.
+
+If all directory servers are within the same transport domain, then the problem
+is solved: routers can exist within multiple transport domains, and as long as
+the network of transport domains is fully connected by bridges, any router will
+be able to access any other router in a foreign transport domain simply by
+extending along the path specified by the directory server.  However, we want
+the system to be truly decentralized, which means not electing any particular
+transport domain to be the master domain in which entries are published.
+
+Generally speaking, directory servers share information with each other about
+routers.  In order for a directory server to share information with a directory
+server in a foreign transport domain to which it cannot speak directly, it must
+use Tor, which means referring to the other directory server by using a router
+in the foreign transport domain.  However, in order to use Tor, it must be able
+to reach that router, which means that a descriptor for that router must exist
+in its table, along with a means of reaching it.  Therefore, in order for a
+mutual exchange of information between routers in transport domain A and those
+in transport domain B to be possible, when routers in transport domain A cannot
+establish direct connections with routers in transport domain B, then some
+router in transport domain B must have pushed its descriptor to a directory
+server in transport domain A, so that the directory server in transport domain
+A can use that router to reach the directory server in transport domain B.
+
+