On Wed, Jul 13, 2011 at 6:32 PM, Nick Jones
<najones@xxxxxxxxxxxxxxxx> 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.