multiplexing over circuits too

[Roger Dingledine]

On Tue, Dec 17, 2002 at 10:55:09AM -0500, Paul Syverson wrote:
> 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.

Actually, http/1.1 is pretty much everywhere at this point. The reason
we're not using persistent connections is because privoxy (the http
filtering proxy we use) intentionally forces each request to close the
connection afterwards.

I'm not sure why. It's been something I've been meaning to look into
for a while. I'll put it on my (low priority :) todo list.

I just pointed my mozilla to socks proxy directly through tor, and
enabled persistent connections and pipelining, and things worked fine.
So it's just a matter of tradeoffs for which tools we want to use.

> 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.

How? Right now there's no way to tell the local tor process that you
want to do that. I don't have much experience with interfaces, but this
seems like a hard problem to get right.

Adam/John: how did Freedom do this? Maybe tor needs to evolve a
client-side gui? (ugh :)

> 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.

Er. You're going to have to explain this one (when you've got more time).

Since a given tcp connection going out of an exit node can only be
processed from that node, then it's going to be aware of each circuit
that uses it. That is, even if, as I think you're saying above, we open
a given topic on circuit A, and then later shift that topic to circuit B,
then the onion router will now know that both circuit A and circuit B were
created by the same guy. Even if there were some old topics on circuit
A that are closed, we're still linking them to the creator of circuit B.

So it seems we'd be harming anonymity, not helping.

Or perhaps you meant that we should allow topics to not only be outgoing
tcp connections from the endnode, but also let the user "grow" his circuit
from the current endnode. This would seem to make my initial idea (of
using the first 4 bytes of the payload) harder, because the payload is
either encrypted because you're not at the last hop, or plaintext because
you are. Is this what you had in mind? I bet we can make it work; it's
just a matter of how much complexity we end up adding. From here we could
also add in covert signaling from the user to a given node in his circuit,
to (say) drop cells without getting confused, add new ones, etc. Anybody
have good design ideas for this?

--Roger