Opened 7 years ago

Last modified 17 months ago

#5048 new defect

cbtmintimeout should have a lower maximum

Reported by: nickm Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: maybe-proposal, tor-relay cbt
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Wanoskarnet in #tor suggests that the INT32_MAX maximum for cbtmintimeout is ridiculously high. If it were ever set to an absurdly high value, then all users who had LearnCircuitBuildTimeout set would break much of the time, while users with LearnCircuitBuildTimeout turned off would break only some of the time.

60 seconds or so seems like a good "maximum minimum."

cbtinitialtimeout also could use more sane cap. wanoskarnet suggests 120 seconds.

Child Tickets

Change History (12)

comment:1 in reply to:  description Changed 7 years ago by arma

Replying to nickm:

Wanoskarnet in #tor suggests that the INT32_MAX maximum for cbtmintimeout is ridiculously high. If it were ever set to an absurdly high value, then all users who had LearnCircuitBuildTimeout set would break much of the time, while users with LearnCircuitBuildTimeout turned off would break only some of the time.

60 seconds or so seems like a good "maximum minimum."

Let me see if I can get my logic straight here. If we set an absurdly high minimum, say, 200 seconds, then that means every client that computes a cbt for itself would never compute one less than 200 seconds. Most would probably pick 200 seconds.

So that means these clients would only give up on a circuit ("it's taking too long") if it took 200 seconds to build.

How would that cause them to break much of the time? I mean, it wouldn't be great, but I don't think it's as bad as you say.

comment:2 in reply to:  description Changed 7 years ago by arma

Replying to nickm:

cbtinitialtimeout also could use more sane cap. wanoskarnet suggests 120 seconds.

That seems low to me. The CBT_MAX_TIMEOUT_INITIAL_VALUE is a constraint on what the consensus can tell clients who haven't calculated their cbt yet to start out at. For the current Tor network, as currently deployed, 60 seconds is probably conservatively high. But what if you deployed a Tor network on a pile of satellite modems, and it had a lot of load? You might want to tell your clients that they should pick a really high timeout while they're trying to figure out what their timeout is.

I guess this issue exposes the question of how much we should enforce mins and maxes on consensus parameters. We started the process when we realized that certain values would cause Tor to crash. Then we followed through by assigning *every* consensus param a min and a max, just to be thorough. I still tend toward the "if it wouldn't actually cause Tor to die, it's a valid value" camp.

comment:3 Changed 7 years ago by arma

<wanoskarnet> cbtmintimeout can't be more than 60 s, as it what tor used for 5
years as staticaly limited cbt. It have no sense to raise timeout because
consensus limit is 61 s.
<wanoskarnet> maximum of cbtinitialtimeout is 120 seconds. Because
SocksTimeout is 120 seconds. It have no sense to have timeout more than socks
client can waiting for.
<wanoskarnet> "if it wouldn't actually cause Tor to die, it's a valid value"
is wrong logic. you limiting 0.001% of users that can't normally or can't use
tor at all because senseless consensus params. No need to segregate user just
because connection stuff.
> re "cbtmintimeout can't be more than 60 s", part of the reason for cbt was
to allow the timeout to be *more* than 60s if it needs to be.
> re "SocksTimeout is 120 seconds", if a client changes sockstimeout, and
the consensus changes the initialtimeout, then it can work. why disallow it?
> re "limiting 0.001% of users that can't normally or can't use tor at all", i
still don't understand. are you saying a high value would make most people
unable to use tor at all?
<wanoskarnet> cbtmintimeout is about min of cbt, of course cbt can be more
than 60 s for some cases.
<wanoskarnet> but cbtmintimout from consensus can't be more than 60s
> also, sockstimeout is for streams, and cbt is for circuits. so you can still
use a circuit that took 400 seconds to build, and have your socks handshake
finish within 120. (neither of which will be fun, but hey)
<wanoskarnet> yes, I just try to find senseless limits.
<wanoskarnet> s/senseless/correct/
> if three directory authorities conspire, they can do bad things. they
shouldn't do bad things. i think that's a good enough policy.
> maybe that means we should have current directory authorities vote for the
current defaults?
> that way it would take way more than 3 dir auths to conspire.
<wanoskarnet> it is not about conspirasy. it's about non informed aut and bad
conns in the noeth pole isp.
> which could also be solved by having authorities vote for the current
defaults.
> shall i add your comments to the trac ticket so other people might see them?
<wanoskarnet> ok

comment:4 Changed 6 years ago by nickm

Keywords: maybe-proposal added

comment:5 Changed 6 years ago by nickm

Keywords: tor-relay added

comment:6 Changed 6 years ago by nickm

Component: Tor RelayTor

comment:7 Changed 6 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: 0.2.5.x-final

comment:8 Changed 5 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.???

comment:9 Changed 2 years ago by teor

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

Milestone renamed

comment:10 Changed 22 months 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:11 Changed 17 months ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:12 Changed 17 months ago by nickm

Keywords: cbt added
Severity: Normal
Note: See TracTickets for help on using tickets.