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