Re: getting more exit nodes

[Alexander Bernauer <alex-tor@xxxxxxxxxx>]

Hi

We discussed the open questions yesterday and came up with the
following:

Client-exit nodes should be considered like normal IP routers
or to be precice like simple TCP bouncers. 

This means that the connection between a pseudo-exit node and a
client-exit node needs no encryption and the fact that there are more
people able to read the plain Alice-to-Bob traffic is nothing new. Every
router on the way from the Tor exit to Bob already has this possibility.
The same counts for the fact that Alice has no influence on which
client-exit node is used which is true for any IP router as well.  Last
the client-exit does not debase anonymity. Just like no IP router or any
other traffic relay is able to do so - given of course, Tor itself
resists. 

The client-exit also does not add any anonymity for Alice. This means
her circuit to the pseudo-exit must already be complete. Thus exitting
over client-exit nodes means an extra latency of one TCP connection.

The purpose of client-exit nodes is to give anonymity to the
pseudo-exit nodes. This means it must be impossible to estimate the
pseudo-exit when knowing the client-exit and that the client-exit
node must choose its pseudo-exit uniformly distributed among all
available Tor nodes.

Concerning exit policies we think that propagating any client-exit
information weakens the anonymity of the pseudo-exit node because it
makes the client- to pseudo-exit link traceable. Furthermore client-exit
nodes are very different from each other, so that we don't see how a
pseudo-exit node could unify all client policies. So the only thing a
pseudo-exit can say is: "well, there are some client-exit nodes
connected to me."

Generally client-exit circuits have drawbacks. Those are limited
bandwidth, higher latency, low average and high variance for the uptime
and unknown exit policies as we can not ask the personal firewall which
outgoing ports are blocked.

A reputation system for client-exit nodes could soften some of the
drawbacks. But as far as we can see it would always weaken the anonymity
of the pseudo-exit node because by the rules of the reputation
system the possibility for a client-exit to pseudo-exit connection is
not evenly distributed any more. But maybe it still would be impossible
to reveal the pseudo-exit node. Do you have any suggestions on this?

What is also still unclear is how the pseudo-exit node chooses from the
available client-exit nodes. Perhaps it could select for each TCP
connection of a circuit a different client-exit. Or it must try
different client-exits until the TCP connection to Bob can be
established. This would also soften some drawbacks.

The idea of trying the next possibility until it works could be
generalized by letting Alice open circuits until the pseudo-exit node
has client-exit nodes attached to it. Thus the problem of information
propagation at the directory servers are circumvented.
 
On last thing is the question how a Tor node knows whether inbound
traffic is meant to be normally relayed to the designated destination or
whether it should be redirected through a client-exit node. To be honest
we don't know all aspectes of the Tor protocols yet but as far as we
know there already is a command protocol between Alice and Tor nodes.
Is it possible for Alice to tell a node by this means to act as a
pseudo-exit node? 

regards
 
-- 
Alexander Bernauer