Subject: RE: Timers and Timeouts in the SSH Transport Protocol

From: Dan Davidson <[email-masked]>
Date: Wed, 3 Jul 2002 12:10:24 +0200

Also more complicated, I personally tend to prefer the multiple timer
approach. I see this approach more user friendly as the user won't have
to wait for long periods of time when the error occurred at the beginning of

a connection setup.

An intermediate approach may also be considered: dividing the connection
setup into major stages, and timing these parts only (and not per message).

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, July 03, 2002 10:30 AM
To: Dan Davidson
Cc: [email-masked]
Subject: Re: Timers and Timeouts in the SSH Transport Protocol

Dan Davidson <[email-masked]> writes:

> Based on your experience, what do you think the default
> timeout should be.

I don't think you need a specialized timeout for just the version
string exchange. I think it is reasonable to apply a timeout to the
entire initial handshake. E.g. set a timer at 5-15 minutes when you
accept a connection, cancel the timer when userauthentication is
completed, and disconnect if the timer fires.

> Moreover, I do agree with your remark about the
> retransmission and TCP/IP. However, please notice that in 
> numerous telecommunications protocol messages are retransmitted 
> although a reliable transport level is used.
> Example: H.323/H.225.

I've heard that is true also of the IETF SIP protocol, with a
motivation like "messages might have been forwarded over an
un-reliable mechanism like udp somewhere along the path.". Sounds real
ugly.

/Niels