Why do relays not end idle TCP sessions?

Question

I'm running a relay on a 1Gbps connection. However, my relay averages around 3Mbps up/down each after several months. After substantial investigation, I found the cause: my relay sets up TCP sessions with clients and other relays, and NEVER closes them (it simply waits 24 hours for them to expire). I quickly hit my router's NAT session limit and can't build any more circuits. At any given time 99% of my connections are using zero bandwidth, and I can't build more connections because of my router's limitation.

Is this a design decision in tor that has some security properties? It just seems extremely inefficient, like mallocing all your memory and never freeing it, why not end sessions that have not been used in an operator configurable amount of time, e.g. 30 minutes.

The only downside I see is that clients who idle for a very long time (AFK? not recommended using tor!) may have an extra second of load time inbetween idle periods. But by definition, this wouldn't affect people who are actually using tor.

On the upside, it would allow some relay operators (like myself) to increase their bandwidth by factors of hundreds.

Answer 1

TLDR: Get a better router, or don't stick your relay behind a NAT.

Tor has a notion of circuits (a path through the Tor network) and channels (the actual TLS link between Tor instances). A single channel will carry multiple circuits worth of payload, muliplexing/demultiplexing each circuit as appropriate. If 5 clients all happen to chose A<->B as part of of a circuit, all of their traffic will go over a single A<->B TLS connection. Circuit lifespan can be very very long, especially with the recent Tor Browser change to keep the user's IP constant when browsing a given site (which also results in idle circuits hanging around for a long time).

Tearing down a channel when there are still circuits that are considered live will kill off all the circuits that are being transported through the channel. This is bad, because each circuit can be transporting multiple streams worth of data, and building a circuit is relatively expensive to the network as a whole, because it involves a lot of cryptography spread across relays along the circuit, and potentially TCP and TLS handshakes.

Your relay in an ideal world should be able to handle 1 TCP connection per client (since you will become a Guard eventually), and 1 (in some cases 2) per relay in the Tor network (to actually relay data). If you are using a low end residential router, this number will most certainly be above what the NAT table in a low end consumer router can handle (nb: This is somewhat of a high/pessimistic estimate).

While it may be possible to maintain the new (and improved) Tor Browser behavior (since websites freak out when a user's IP address changes mid-session), while allowing for a circuit to be torn down/reestablished, visibility into what is actually being transported in a given channel is not available to intermediary relays, and such a change would necessitate a tighter coupling between Tor and Tor Browser than what is currently present, and the maintenance of state so that an identical circuit can be re-established in the event that it is killed off as idle.