Opened 3 years ago

Last modified 23 months ago

#19625 needs_information project

Allow relays to set peering policy

Reported by: twim Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: needs-proposal tor-relay research-program
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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

Child Tickets

Change History (10)

comment:1 Changed 3 years ago by yawning

Keywords: needs-proposal added
Status: newneeds_information

This needs a full design proposal (and also appears to be directly counter to how path selection is intended to function, eg: #19068).

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.

comment:2 Changed 3 years ago by cypherpunks

comment:3 in reply to:  1 ; Changed 3 years ago by twim

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

comment:4 Changed 3 years ago by teor

I had some code draft code to do this via an "ExtendPolicy" in #17788.
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.

comment:5 in reply to:  3 Changed 3 years ago by yawning

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.

comment:6 Changed 3 years ago by nickm

Milestone: Tor: 0.2.???

move some milestone-free tickets into 0.2.???

comment:7 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:8 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:9 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:10 Changed 23 months ago by nickm

Keywords: tor-relay research-program added
Note: See TracTickets for help on using tickets.