GitLab #40448: Add MiddleOnly flag

Part of #40448.

mentioned in merge request tor!428 (closed)

mentioned in issue tor#40448 (closed)

requested review from @nickm

When we're adding new features, we use the proposal process—that's documented in proposal 001-process.txt.

Shouldn't a "MiddleOnly" flag also affect whether the Exit flag can be assigned and/or whether the node can be used as an exit, an hsdir, etc? (The spec change here doesn't mention anything besides the guard position.)

The proposal and eventual spec change should describe how the authorities decide how to vote on this flag, and what they do with it after they vote on it. If it needs a new consensus method, that needs to be documented too.

added Needs Revision label

Yes, echoing @nickm here. I had a talk with @ahf on friday about this and here are some thoughts.

1. New consensus method.

So, I don't think this is like the Sybil flag, which doesn't require a consensus method, because the "Sybil" flag is meant to be informative and doesn't impact any of the tor protocol itself as in doesn't impact path selection.

This MiddleOnly flag does impact path selection on every client and for that reason, we need an actual majority of all authorities to agree on it and that comes with a consensus method. We can't just have 1 authorities voting for it and because all other authorities don't know that flag, then it ends up in the consensus and all clients knowing it start using it. That is a whole lot of power for not having the majority of ALL authorities to decide.

2. Another possible question we might want to answer is how the implementation should behave here with regards to that flag. In other words, if that flag is set for a relay, do you just put the Exit and Guard weight down to 0 or you keep those untouched and simply refuse to use that relay for Guard and Exit.

Furthermore, can they be used for Rendezvous point, Intro point or HSDir? Can they be used for fallback directories?

The spec should detail those. What are the good answers to those questions, unclear at this point but at least if we get a spec that details these, we can go forward with our review/discussion on what is best.

Thanks!

my commend about this feature on the mailing list: https://lists.torproject.org/pipermail/tor-dev/2021-September/014620.html

Closing in favor of proposal-335 approach.

closed