Getting 'Unreachable' Servers Onto The Network

Robert Hogan robert at roberthogan.net
Thu Feb 28 19:38:04 UTC 2008


Maybe it's a solution in search of a problem, maybe UPnP will sort most of 
this out, but assuming that the following problem is real and substantial:

Problem: Restrictive local/remote firewalls and routers are preventing many 
willing candidates from becoming OR servers. UPnP can mitigate this problem 
if it is confined to a DSL router firewall (with UPnP enabled by the user) 
but it still leaves a substantial chunk of willing servers out there whose 
ORPort is not available to outside connection attempts. The Tor network is 
losing out on their bandwidth. At the moment we don't even know how many 
such 'candidate' servers there are.

Possible solution:

Tor servers whose ORPort reachability testing fails should:

 i. enlist themselves with the authorities setting a 'Fallback' flag. This 
flag indicates that the server is up and running but cannot connect to 
itself.

 ii. Open an orconn with an Xth part of the other Tor servers on the network. 
The management of this orconn will be transferred entirely to the servers at 
the other end. 

 iii. When building circuits clients will take into account the number of 
servers it knows about that have a 'Fallback' flag. Whatever proportion this 
is of the total will determine what proportion of circuits it attempts to 
build using one of these servers. So if 1/4 of listed servers are flagged 
fallback it will attempt to build 1 in every 4 circuits with one of these 
servers at either middleman or exit. (These numbers are hypothetical).

 iv. After a presumably mathematically predictable number of maximum tries the 
client will try a combination that works and build a circuit with a fallback 
server on it. 

Expected behaviour of 'Fallback' servers:

 i. Open as many idle orconns with other servers on the network as possible 
and keep them open until the server is shut down.

 ii. Always respect other servers requests to shut down the orconn.

 iii. Always allow themselves to be exit servers if called upon.

Expected behaviour of other server towards 'Fallback' servers:

 i. Only accept orconns from listed 'Fallback' servers.
 ii. Do not always build client-requested circuits to 'Fallback' servers you 
have an orconn with. Reject some as unreachable?

Halfway house:

If we don't know how big the problem actually is, perhaps we should start 
allowing such servers to at least register their attempt with the authorities 
in some way, perhaps just by implementing step i under 'Possible Solution'.

Questions I don't know the answers to:

i. How many other servers a 'Fallback' server should connect to in order to 
allow a client successfully include it in a circuit without trying an 
unreasonable amount of times.

ii. How a client proportions the number of 'fallback' servers listed to the 
number of circuits it attempts to build with them.

iii. What kind of critical mass of fallback servers is required for the thing 
to work.

Major objections:

 i. Thousands, millions of idle orconns! Uugh! It's an ugly thought I admit, 
but they're pretty cheap as far as I know. Would a server have any actual 
problem handling them?

 ii. [insert major anonymity problem here]

This isn't the result of days of solemn reflection so feel free to kick me out 
of the park on it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20080228/63a7025d/attachment.pgp>


More information about the tor-dev mailing list