Getting 'Unreachable' Servers Onto The Network
Robert Hogan
robert at roberthogan.net
Fri Feb 29 18:36:28 UTC 2008
On Thursday 28 February 2008 19:38:04 Robert Hogan wrote:
> 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.
>
>
> 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?
>
The notion of connecting to *loads* of other servers is pretty daft. Perhaps a
better way of doing it would be:
- Every published server accepts orconns from a maximum of N fallback servers.
- Every fallback server maintains N orconns with published servers.
When clients are building fallback circuits they simply request an unspecified
fallback server for either the middleman or exit. The choice of server is
left to the node constructing that leg of the circuit.
The choice of server is communicated to the client and the client verifies
that a listed fallback server has been chosen. It would only use the same
fallback server X number of times per fallback circuit, and never more than a
specific number of times from the same published server for a defined period
of time.
> ii. [insert major anonymity problem here]
Which is probably where this comes in. The choice of fallback server is
delegated to a published server but as long as the client is careful this
shouldn't matter.
>
> 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/20080229/ea88ab68/attachment.pgp>
More information about the tor-dev
mailing list