(FWD) Re: Restricted entry (helper) nodes in 0.1.1.x

Roger Dingledine arma at mit.edu
Wed Dec 21 15:39:43 UTC 2005


[I added this email address so it can post automatically next time. -RD]

----- Forwarded message from owner-or-dev at freehaven.net -----

Date: Wed, 21 Dec 2005 10:18:42 -0500
From: =?ISO-8859-1?Q?Lasse_=D8verlier?= <tor at zone.no>
To: or-dev at freehaven.net
Cc: tor at zone.no
Subject: Re: Restricted entry (helper) nodes in 0.1.1.x

Roger Dingledine wrote:

>.....
>
>Thoughts? Guesses on what I've left out, or security problems with
>the above plans?
>
>--Roger
>  
>

Hi Roger,

I am a bit concerned with performance if we are to have e.g. two out of
three helper nodes down or unreachable. How often should Tor check if
they are back up and running? Hopefully not every time, but what happens
if(when?) performance of the third node is bad? When should there be
added an extra node to the helper node list? This is kind of an
important threshold?

If running from a laptop you will meet different firewall settings, so
how should Helper Nodes settings keep up with moving from an open
ReachableAddresses to a FascistFirewall setting after the helper nodes
have been selected?

Another point you might want to keep in mind, is the possibility to
reuse the code in order to add a second layer helper node (meaning node
number two) to "protect" the first layer (node number one) helper nodes.
These nodes should be tied to each of the first layer nodes. E.g. there
is one helper node list, as described in your mail, for each of the
first layer nodes, following their create/destroy.

Another of the things might worth adding to the to do list is
localization of server (helper) nodes. Making it possible to pick
countries/regions where you do (not) want your helper nodes located. (As
in "HelperNodesLocated us,!eu" etc.) I know this requires the use of
external data and may not be worth it, but it _could_ be integrated at
the directory servers only -- adding a list of node IP's and e.g. a
country/region code to the directory and thus reduce the overhead. (?)
Maybe extending the Family-term?
And I would like to keep an option to pick the first X helper nodes
myself and then let Tor extend this list if these nodes are down (like
EntryNodes in current code). Even if this opens up for some new types of
"relationship" attacks.

I am sure my next point has been asked before, but what about testing
the current speed of the connections when looking for new helper nodes,
not only testing the connectivity? I know this might contribute to a lot
of overhead in the network, but if this only occur e.g. when using
helper nodes as a Hidden Service it might not have that large an impact,
but could help availability for the services?

My last request is if you or Nick could send an email to or-dev
describing your lastest plans for the future of the directory servers at
some point?

 - Lasse

BTW. I feel confortable with all the terms helper/entry/contact nodes,
but I think you (the developers) should just pick one and stay with it
to avoid confusion.


----- End forwarded message -----



More information about the tor-dev mailing list