Route selection

Adam Shostack adam at homeport.org
Fri Dec 5 16:07:41 UTC 2003


On Fri, Dec 05, 2003 at 12:51:36AM -0500, Roger Dingledine wrote:
| On Sun, Nov 30, 2003 at 09:39:59AM -0500, Paul Syverson wrote:
| > So I woke up some time ago thinking that we were wrong to bother with
| > voting on network state in the directory servers, that they should
| > just be voting on membership and maybe exit policy. Working on it for
| > a while I now think we probably still want a voted network state at
| > least c. every hour or so, since `simpler' ideas now seem even more
| > complicated, but I think I uncovered another issue.
| 
| The reason we need to tell clients which nodes are up right now is so
| they can choose working nodes for their circuits. Getting a consensus
| prevents a bad directory server from partitioning clients. I think we
| want a quick turnaround. Probably the right way to implement it is to

You can't know what nodes are up "right now" except by sending a
packet from a near neighbor.  The best you can do is know which nodes
have been "fairly stable" for "a while" and expect that past
performance is an indicator of future returns.

I think the right approach is to experimentally determine how often
your nodes actually crash, and from that try to find a set of "fairly
stable" and "a while" that allows voting to happen rarely while still
reflecting the facts well.

| Agreed, this is a problem. There's a broader problem though, which
| is that many of our ideas about how to rebuild circuits from partway,
| have streams leave circuits from intermediate nodes, etc seem to assume
| that circuits are many hops long, whereas for usability they should be
| as short as possible. The current planned compromise is around 3 hops,
| plus one if the first OR is revealing, e.g. you, and plus one if the
| last OR is revealing, e.g. it's your destination or it has a very limited
| exit policy.

We (ZKS) found that two hops was a nice idea, because there's an
obvious security win in that no one node knows all.  Proving that a
third node actually wins against an adversary that is competent to
count packets was harder, so two gives you a nice understandable
security/performance tradeoff.  I know, I'm hammering on this, but I
think that the performance gain is important for the default
experience. 


Adam

-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume




More information about the tor-dev mailing list