Add ExcludeGuardNodes and ExcludeMiddleNodes options

Closes ticket #40466.

requested review from @nickm

added 4 commits

• 4568fbad - Add ExcludeGuardNodes and ExcludeMiddleNodes options
• 22702d78 - Add ExcludeGuardNodes and ExcludeMiddleNodes unit tests
• 0a163d08 - Add man page entries for ExcludeGuardNodes and ExcludeMiddleNodes
• c8ba27db - Add changes file for GitLab ticket #40466

Compare with previous version

changed title from Add ExcludeEntryNodes and ExcludeMiddleNods options to Add ExcludGuardNodes and ExcludeMiddleNodes options

changed title from Add ExcludGuardNodes and ExcludeMiddleNodes options to Add ExcludeGuardNodes and ExcludeMiddleNodes options

Before we add a feature, we should make sure it has an application. (After all, every feature comes at a cost of complexity and maintenance burden.)

Why would a user want to exclude something from the guard or middle position, and not exclude it entirely?

cc @dgoulet @ahf

I think one use case I can see is if community(ies) outside Tor do relay research on our metrics (OrnetRadar for instance) and could have stricter criteria on what a bad relay is (regardless of its position), they could then apply these more fine grained filters on their services or clients.

There is always a time gap between a detection of an "uncertain set of relays" and the health team actually rejecting them (or soon MiddleOnly flag). And within that time gap, I can assume people would want to be more pro-active on safety while waiting for the consensus to update. It has happened many times that we had a complex report about malicious Guards that we had to spend days between the report and assessment on the health team side.

It is a very good question to ask ourselves and the health team has been battling with it for years: If a relay is malicious in a certain position, can we go on and assume it is not in another?

The BadExit flag has been historically a bit driving that line where if we find out you were snooping on users, we'll keep you in less "power" positions. And today the health team actually barely use the BadExit flag anymore due to the above reasoning that "a bad relay is bad everywhere. Just good safety measure.".

Thus, in that perspective, I'm not against such features in tor since they provide a bit more freedom to whoever wants to judge who is a bad relay within a consensus.

I would worry very much if those lists of excluded relays end up online and being used by a lot of people which would a bit break in part the purpose of the consensus since people would partition themselves left and right... But since we have ExcludeNodes in the first place, not like it is not possible at the moment.

I see the use-case for ExcludeGuardNodes, but I'm curious about the use-case for ExcludeMiddleNodes?

Are we blocked here?

Passing review to @ahf. There are a few things to consider here:

• Is this code integrating with the Guard code correctly? The entrynoes.c code sometimes looks at ExcludeNodes in ways that don't match up with the rest of Tor. I haven't checked whether this is actually in line with what we're supposed to be doing here.
• Is there an application for ExcludeMiddle that isn't already met by ExcludeNodes? IMO any relay that isn't suitable for use as a middle node should probably never be used as a guard or exit either.
• Will this integrate well with the proposed MiddleOnly feature?
• Edited to add: is this the kind of new feature development that we shouldn't be considering in C tor unless really necessary?

Thank you, I remember looking at this a week ago with some of those thoughts in mind too. Going to take a look.

requested review from @ahf and removed review request for @nickm

assigned to @neel

changed milestone to %Tor: 0.4.8.x-freeze

I'm closing this as we ought to do this kind of feature in Arti later on and not do too many new features in C Tor unless it has a use-case that is needed by either the relay ops community or the network health team.

closed

added Close in favor of Arti label