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

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

Thanks for your reply.

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

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.
		The H.225 uses a TCP connection, however, several
		messages (e.g. SETUP) are retransmitted after a 
		timer T expires, regardless of the TCP protocol.

Cheers,
Dan
-----Original Message-----
From: Simon Tatham [mailto:[email-masked]]
Sent: Tuesday, July 02, 2002 5:36 PM
To: [email-masked]
Subject: Re: Timers and Timeouts in the SSH Transport Protocol

Dan Davidson  <[email-masked]> wrote:
> 	- A TCP/IP connection on port 22 was setup.
> 	- The server sent the identification string
> 		"SSH-protoversion-softwareversion" but didn't
> 		receive such a message/string from the remote side.
> 
> Should there be a re-transmission ? 
> Should the connection be disconnected after a T timeout
> 	- What is the timer length ?

There certainly shouldn't be a retransmission! That's what TCP is
for - it will retransmit it _anyway_ until it either gets an ACK
from the client's TCP layer, and if the client fails to see it after
that then no more retransmissions are likely to help.

The server probably should disconnect after a while, because if it
doesn't then a DoS attack becomes possible. I wouldn't have thought
it was necessary to specify that timeout precisely in the protocol
definition, though; it's up to individual server maintainers. If you
find you're getting a lot of hanging connections, reduce the
timeout; if you find a lot of users are complaining that your server
cuts them off before they can send anything, increase it.
-- 
Simon Tatham         "Selfless? I'm so selfless I
<[email-masked]>    don't even know who I am."

---

From: [email-masked] (Niels Möller)
Date: 03 Jul 2002 10:29:48 +0200

> Based on your experience, what do you think the default

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.

> although a reliable transport level is used.

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

---

From: "Phillip Remaker" <[email-masked]>
Date: Wed, 3 Jul 2002 11:12:51 -0700

> However, please notice that in

This is really an unfair comparison, and probably a glaring exception.  The
issue with H.323/H.225 is that the protocol is frequently gatewayed to an
alternate network, and the end-to-end retransmission is required because of
errors possible after the end of the TCP tunnel/stack.  H.225/H.323 tries to
emulate telephony network protocols in a TCP universe, and since it may not
be TCP end-to-end, the retransmissions are required.

For communcations that are directly stack-to-stack, TCP should be relied
upon for retransmission.  The retransmitting behavior of H.323 is an
artifact of the legacy of the protocol.  No natively TCP based communication
should retransmit at the application layer.

It seems a bug that the identification string was not received.  The SSHD
should be able to rely on the TCP stack for reliable delivery.

I can't think of any other examples of protocols that retransmit over TCP.