[tor-dev] New Paper: Cloud-based Onion Routing

[Brandon Wiley]

Cool stuff. I like how the system can be automated and self-funding.

With regards to bootstrapping, giving out one node at a time is not a useful
defense because requests can be parallelized. [1] Moving nodes is similarly
useless because the attacker can continually map the network using free
parallelized requests. Therefore, requesting a node address needs to cost
something. [2] Since you already have tokens, you can just make it cost a
token to request a node address.

To solve the initial introduction problem, you need to include fresh node
addresses with the distribution of the executable. You could in fact
dispense with the directory servers, which add no defense, and include fresh
node addresses with each executable upon download. For instance, with
BitTorrent we had a neat trick where we would encode the URL to a torrent
file at the end of the uTorrent executable (dynamically for each user when
they downloaded it from the web server) and the program new how to look for
and extract this URL upon startup. If present, uTorrent would automatically
start downloading this torrent. You could use a similar technique here. Much
as above, getting fresh peers, in this case by downloading the executable,
should cost something so that it can't be parallelized for free.

An alternative to paying per node address is to pay to establish an identity
and then use a DHT to map node addresses to identities so that you have a
way to obtain new addresses as they change due to churn, but mapping the
whole network requires multiple identities and so once again incurs a linear
cost. [2]

Best of luck with your project!

[1] Sybil attack <http://www.cs.rice.edu/Conferences/IPTPS02/101.pdf>
[2] Arcadia <http://blanu.net/Arcadia.pdf>

On Wed, Jul 13, 2011 at 6:32 PM, Nick Jones <najones at cs.princeton.edu>wrote:

>
>
> On Wednesday, July 13, 2011 at 4:58 PM, Aaron wrote:
>
> > I have a few questions
> >
> > Q1: Regarding network bootstrap protocol: Consider the scenario where
> > a censor mines the boostrap node list and blocks these nodes. Do you
> > implement any mechanisms to prevent a censor from obtaining the entire
> > set of bootstrap nodes? Similarly, aren't public directory servers
> > also vulnerable to censorship?
> >
>
> Currently, we don't have any major protection from enumerating the list of
> bootstrapping nodes.
> It is definitely a problem we are aware of, and we're thinking about
> possible ways to protect
> them. In our design, we only give out one bootstrapping node at a time,
> with the hope that this
> makes enumerating them somewhat more difficult. Additionally, if we can
> detect that a
> bootstrapping node has been blocked, we can use the elasticity of cloud
> hosting to move it to a
> new IP or a new cloud. Admittedly, this may devolve into a cat and mouse
> game of moving the
> bootstrapping nodes around.
>
> Similarly, since you learn about the bootstrapping nodes through the
> directories, the directories
> have many of the same problems and solutions. If the directories stay at a
> static IP/DNS name,
> then they will be blocked quickly. However, if the user still has a cached
> valid directory from the
> last time he was connected to COR, he could build a circuit and then
> retrieve an updated directory,
> assuming at least some of the nodes from the last directory retrieval were
> still active. We can
> move the directories around within the cloud, but then you need a
> "directory of directories", and
> that gets messy.
>
> Admittedly, our system doesn't fundamentally solve the bootstrapping
> problem (of new users
> gaining access), but we hope that it makes it more difficult for existing
> users to be blocked.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20110713/22f8f33e/attachment.htm>