[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #17592 [Tor]: Clean up connection timeout logic
#17592: Clean up connection timeout logic
-----------------------+------------------------------------
Reporter: mikeperry | Owner: mikeperry
Type: defect | Status: new
Priority: Medium | Milestone: Tor: 0.2.8.x-final
Component: Tor | Version:
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: #16861 | Points:
Sponsor: |
-----------------------+------------------------------------
Comment (by mikeperry):
Ok, I think I want to combine CircuitIdleTimeout and
PredictedPortsRelevanceTime into a single option (call it
CircuitsAvailableTimeout?) and also randomize the value by some range when
it is used.
Where CircuitIdleTimeout is currently used, I would sample a random
timeout value on circuit creation and store it in origin_circuit_t. Where
PredictedPortsRelevantTime is used, I think the right thing to do is to
sample a new value whenever the list of predicted ports is empty.
For the TLS connection timeout, I want to explicitly separate canonical
relay connections from client connections and non-canonical relay
connections, and make the relay connection timeout be on the order of an
hour (randomized +/- 25%) and be controlled by a consensus parameter. The
client TLS connection timeout can be much shorter, since client TLS
lifespan will be governed primarily by circuit activity (which will be
controlled via CircuitsAvailableTimeout).
With these two sets of changes, it will be much easier to control how long
TLS connections live (and thus more easily control network activity and
padding), for both relays and clients.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17592#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs