Re: [tor-dev] Entry guards, primary guards, dir guards

[George Kadianakis <desnacked@xxxxxxxxxx>]

Ola Bini <obini@xxxxxxxxxxxxxxxx> writes:

> Hi again,
>
> Two questions - first, hopefully I simple one. What are directory
> guards, exactly?
>
> Second, we found a weird behavior in the current code
> base. Specifically, when Tor first downloads the microdescriptors, it
> chooses 3 guards for this with the V2Dir flag. That's a little bit
> less than 1600 nodes right now. However, these three guards gets
> persistes as primary guards, which means that almost all Tor users
> will have primary guards among those 1600, not among the 1900 that
> have the Guard flag. Is this intented behavior?
>

Very relevant questions.

Directory guards were intoduced by proposal 207. They are basically guard nodes
for directory connections, so that Tor clients expose themselves to the minimum
number of directory relays when downloading the various Tor documents
(microdescriptors, etc.).

Currently Tor uses the same guardlist for directory guards and entry
guards. That's a feature because ideally you would have a single guard that
would be both your entry guard and your directory guard. Unfortunately, that's
not always possible because some entry guards are not directories (they don't
have the V2Dir flag) so they can't be picked as directory guards. And that's
basically the weird behavior that you noticed. Because Tor pick its directory
guards first and they are picked from a slightly restricted set compared the
total set of guards nodes. Eventually when #12538 gets to stable Tor, all
relays will be directories, and hence all guards will be potential directory
guards.

---

So everything is explained now except from why Tor picks 3 directory guards and
not one. That's because we have decided to keep the number of directory guards
to 3, instead of using a single guard like we do for normal
circuits. Otherwise, that single directory guard could launch some
hard-to-detect route biasing attacks. For more details see:
  https://lists.torproject.org/pipermail/tor-dev/2014-May/006820.html
  https://lists.torproject.org/pipermail/tor-dev/2014-June/006944.html

So basically when Tor picks a directory guard for a directory connection, it
finds the first three reachable entry guards in its guardlist, and picks one of
them.

It might be smart to be able to support "multiple guards" mode in the
algorithms that we are currently designing. That's because we might keep the "3
directory guards" design for some more time, but even more importantly because
if we ever go with a layered guards design we will need to have multiple guards
in some layers.

For example, consider proposal 247 which specifies a layer guard design to
defend against hidden service guard discovery attacks. The proposal basically
makes hidden services pick guard nodes for their second and third hops. So
instead of looking like this:

                     -> middle_1 -> middle_A
                     -> middle_2 -> middle_B
                     -> middle_3 -> middle_C
                     -> middle_4 -> middle_D
       HS -> guard   -> middle_5 -> middle_E -> Rendezvous Point
                     -> middle_6 -> middle_F
                     -> middle_7 -> middle_G
                     -> middle_8 -> middle_H
                     ->   ...    ->  ...
                     -> middle_n -> middle_n

it will look like this:


                                  -> guard_3A_A
                     -> guard_2_A -> guard_3A_B
                                  -> guard_3A_C -> Rendezvous Point
       HS -> guard_1
                                  -> guard_3B_D
                     -> guard_2_B -> guard_3B_E
                                  -> guard_3B_F -> Rendezvous Point


As you can see in this latter design, we pick amongst "2 guard nodes" for the
second hop, and amongst "6 guard nodes" for the third hop. Feel free to read
the introduction of the proposal for more info.

So yeah... it would be nice to support this multiple guard node design in our
algorithms as well. We discussed this a bit during our proposal meeting some
weeks ago but we kind of let it drop. Do you think it's possible? :)
 
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev