Ola Bini obini@thoughtworks.com 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? :)