RE: problems with the aci range too small?

[Paul Syverson <syverson@itd.nrl.navy.mil>]

So this is something we also thought about long ago.
And we considered most of these solutions. It is interesting
that ubiquitous of 1.1 is still in the offing.

I prefer the fourth answer. A nice thing is that it's tunable.
You can limit a particular connection to an individual page or
session at a given web site if you wish. As Roger says, there's
lots of potential complexity here. And there is ever the potential
of affecting anonymity sets, e.g., if I'm an intermediate node
maybe shortlived connections are more paranoid hence more interesting?

In any case, I would expand it a bit to allow the `topics' to also
mate existing connections. This allows a certain degree of circuit
hopping, which reduces (or diffuses, which is after all the whole
story) profilability at small additional overhead of
total connections. We had such an idea long ago, but it never got
past the high level design discussion stage. Too many other things
to do today to write more, and I gotta leave in a few hours.

-Paul



> Date: Tue, 17 Dec 2002 00:30:02 -0500
> From: Roger Dingledine <arma@mit.edu>
> 
> Right now the client builds an onion for every new tcp connection,
> which in turn creates a new circuit on the network. In other words,
> the onion routers do three or four public key decrypts for every picture
> loaded from cnn.com. An RSA oaep decrypt on a 1024 bit key is 7ms on my
> 1GHz Athlon, so that puts us at 150 decrypts per second per node tops,
> and more likely closer to 50 decrypts per second.
> 
> So it's going to be a race to see whether we run out of bandwidth or
> cpu first on the servers. One answer is to add crypto hardware to the
> servers so they can handle more decrypts each second. But that's not a
> very flexible / extensible / cheap answer.
> 
> Another answer is to encourage people to use http/1.1's persistent
> connections, so a single tcp connection is made to www.cnn.com, and
> many GET requests are made over that one connection. That will help us,
> but only by a bit.
> 
> A third answer would be to step back and try to convince ourselves
> that our users don't actually generate that many new web requests each
> second, so being able to handle 15 new circuits per second per node in
> the network is plenty. I think this reasoning won't work very far.
> 
> A fourth answer is to add another layer of multiplexing. Each connection
> currently handles multiple circuits and distinguishes them via the
> 'aci' identifier. We might treat the first 4 bytes of each data
> cell's payload as special. (Perhaps call it the 'topic', to follow our
> conversation metaphor? Other names are 'request'..somebody give me a
> better one?) Creates and destroys continue to work as before. But now
> when you're an endpoint node in a circuit, you examine the topic. The
> first byte describes the command (one of "open a new topic to the site
> that the rest of this data cell describes", "this is a data cell for
> an established topic", "this topic should close", "your topic is ready
> to start talking about" (which lets me remove the separate 'connected'
> cell type), etc), and the remaining bytes of the topic identifier specify
> which topic we're talking about.
> 
> Effectively we're allowing the users to build a tunnel to the exit point,
> and from there they can make a variety of requests, even to different
> servers, without laying down a new circuit. We use the same symmetric key
> at each hop for all topics, and indeed only the exit node can distinguish
> between different topics.
> 
> Of course, the cost is that now our users are more profilable because
> they're linking together actions at a variety of websites. I'm not sure
> what a good interface would be to let the user have multiple nyms and
> switch between them. On the surface these 'topics' are easy to add,
> but they may be introducing lots of complexity when we try to retain
> anonymity. Hm.
> Thoughts?
> 
> --Roger