nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-28 06:13:31 +01:00
Code Issues Packages Projects Releases Wiki Activity

added a section about how to deal with connectivity information in Blossom/Tor

Browse Source 
svn:r3381
This commit is contained in:
Geoff Goodell 2005-01-20 07:45:14 +00:00
parent a6e91f8157
commit 8acf5bed3c
1 changed files with 74 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

75
doc/dir-spec.txt
View File

@ -28,7 +28,7 @@ In particular:
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 @@ which nodes bridge the networks.
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.