Re: Request for comments: onion routing design paper

[Roger Dingledine <arma@mit.edu>]

On Sun, Nov 02, 2003 at 02:54:53PM -0800, Paul Holman wrote:
> So, I haven't read through the docs or the code or really anything yet, 
> but I do have a tor node running.  I have a question about "sessions" 
> with web sites.  If I'm using tor as a proxy, should I expect 
> successive requests to the same web site to show up with a variety of 
> IP addresses?  This will break some web applications that key off the 
> IP address.  The obvious follow-up question is whether there is any 
> reasonable way to make a given web session use the same IP.  I've been 
> unable to tell what they dynamics here are, probably because we have 
> too few nodes.
> 
> No need for flames about how web applications that use IPs for session 
> keys are broken, I understand the implications.

A quote from section 4.2 of the tor-design paper:

In Tor, each circuit can be shared by many TCP streams. To avoid delays,
users construct circuits preemptively. To limit linkability among their
streams, users' OPs build a new circuit periodically if the previous one
has been used, and expire old used circuits that no longer have any open
streams. OPs consider making a new circuit once a minute: thus even heavy
users spend a negligible amount of time and CPU in building circuits,
but only a limited number of requests can be linked to each other through
a given exit node. Also, because circuits are built in the background,
OPs can recover from failed circuit creation without delaying streams
and thereby harming user experience.

So yes, unless you use http 1.1's persistent connections or something
else to keep it on the same TCP stream, you should expect that over time
your exit hop will migrate to different IPs.

The way to make it use the same IP would be to let the users fix their
exit node in the config file. Currently we plan to let them fix the
first hop, e.g. so they can use an OR running in the same domain. There
was some talk earlier about not letting the client decide his exit node,
e.g. to make targetted abuse harder, but that probably doesn't actually
help much.

Fixing your exit node to one place for very long seems quite dangerous,
because of linkability issues. Also, an adversary who observes the
webserver you keeping going to, plus some of the nodes in the network,
may be able to use knowledge of your fixed exit node to do predecessor
attacks as you keep building new circuits -- effectively your path length
is one hop shorter than you thought it was.

But yeah, overall it doesn't seem like the end of the world. We'll
probably also want this feature when we're doing enclave-style recipients
(where the client should choose an exit hop that's nearby his destination;
the code should choose automatically, but presumably it won't always
get it right). I'll put it on the low-priority todo list.
--Roger