Allow relays to set peering policy
As mentioned in the discussion at tor-relays@ ([1], [2]), it would be nice to have some kind of peering policy for relays so that relay operators could restrict connections with suspicious/malicious relays themselves.
Having PeeringPolicy similar to ExitPolicy (accept, reject) is what comes to mind first. Though it may not be the best solution.
Also, as a side effect it can allow to have smaller state table/less file descriptors for average relay that can help with scaling of the network in the future.
[1] https://lists.torproject.org/pipermail/tor-relays/2016-July/009633.html [2] https://lists.torproject.org/pipermail/tor-relays/2016-July/009641.html
Activity
changed milestone to %Tor: unspecified
This needs a full design proposal (and also appears to be directly counter to how path selection is intended to function, eg: #19068 (moved)).
There's at least two open major design questions:
-
Clients need to know this information when doing path selection, thus this information needs to be part of the descriptor/microdescriptor. Most clients only fetch the latter, and those don't even have the full exit policy. How will this impact bootstrapping overhead, particularly when relays start to do things like "block all the relays in the US because the NSA is spying on them from their orbital satellite platforms" leading to gigantic descriptors.
-
How would one guard against malicious relays using this mechanism to mount a partitioning attack. More generically, currently clients are responsible for 100% of the path selection. What is the security/anonymity impact of allowing potentially malicious relays to influence this.
Trac:
Status: new to needs_information
Keywords: N/A deleted, needs-proposal added-
different use case but related https://trac.torproject.org/projects/tor/ticket/3028
Replying to yawning:
- Clients need to know this information when doing path selection, thus this information needs to be part of the descriptor/microdescriptor. Most clients only fetch the latter, and those don't even have the full exit policy. How will this impact bootstrapping overhead, particularly when relays start to do things like "block all the relays in the US because the NSA is spying on them from their orbital satellite platforms" leading to gigantic descriptors.
True, as the network grows and quantum computers are on the way, descriptors are going to be huge. I don't think there is a way around it.
- How would one guard against malicious relays using this mechanism to mount a partitioning attack. More generically, currently clients are responsible for 100% of the path selection. What is the security/anonymity impact of allowing potentially malicious relays to influence this.
These relays can influence this right now and not be caught (we discussed this at tor-relays@).
There was an idea at tor-dev@ discussion [1], that seems really nice and straightforward to me:
Rob van der Hoeven:
Maybe a client can download all descriptors, but only store a fixed number of (randomly selected) routers? This could be a configuration option, something like: maxDescriptorStorageCount.
The point is to do path selection before we need any paths. A client parses the consensus and picks relays in advance for all possible purposes since only small fraction of consensus is really used. For a passive adversary it looks like the client just downloads consensus, so there is no way to mount partitioning attack (all clients have the same consensus). Honestly I don't see any new attack surface with 'early path selection'. Maybe you are.
[1] https://lists.torproject.org/pipermail/tor-dev/2016-May/010977.html
I had some code draft code to do this via an "ExtendPolicy" in #17788 (moved). But I abandoned it because there were issues using it for single onion services. The code could have worked on relays, but the issues become more serious on a relay due to the clique requirement.
Replying to twim:
Replying to yawning:
- How would one guard against malicious relays using this mechanism to mount a partitioning attack. More generically, currently clients are responsible for 100% of the path selection. What is the security/anonymity impact of allowing potentially malicious relays to influence this.
These relays can influence this right now and not be caught (we discussed this at tor-relays@).
Well, that's why someone needs to write a clique reachability test. The path selection code is written under the assumption that the Tor Network in it's ideal form is a complete graph. Giving relays the ability to break edges on the graph arbitrarily is bad in that it influences client path selection (why should the client trust the relay operator's idea of "what an acceptable peer to connect to" is).
Basically, I don't view "relays can currently engage in bad behavior and get away with it" as a compelling reason for making it easier to do said bad behavior, and I want the clique reachability instrumentation so that relays that do engage in bad behavior are easier to detect and reject.
There was an idea at tor-dev@ discussion [1], that seems really nice and straightforward to me:
Rob van der Hoeven:
Maybe a client can download all descriptors, but only store a fixed number of (randomly selected) routers? This could be a configuration option, something like: maxDescriptorStorageCount.
The point is to do path selection before we need any paths. A client parses the consensus and picks relays in advance for all possible purposes since only small fraction of consensus is really used. For a passive adversary it looks like the client just downloads consensus, so there is no way to mount partitioning attack (all clients have the same consensus). Honestly I don't see any new attack surface with 'early path selection'. Maybe you are.
This will scale like utter shit for certain use cases, and beyond saving bandwidth in fetching descriptors, is totally orthogonal to "intermediary relays can impose restrictions to clients on what peers they can extend the circuit to".
Anyway. If you care about this feature, write a proposal.
moved to tpo/core/tor#19625 (closed)
