Subject: Revising the document

From: Sami Lehtinen <[email-masked]>
Date: Tue, 10 Oct 2000 21:38:07 +0300 (EEST)

Niels Möller, on September 27. 2000, wrote:
  : I'd like to know who, if any, is working as document editor for
  : revising the current drafts? 

Ho.

-- 
[[email-masked]          --  Sami J. Lehtinen  --           [email-masked]]
[work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl]
[SSH Communications Security Corp               http://www.ssh.com/]

---

From: Mats Andersson <[email-masked]>
Date: Wed, 11 Oct 2000 10:43:19 +0200 (MEST)

Hi,

Some small questions about the drafts:

1) In the connection draft nothing is explicitly said about whether
GLOBAL_REQUESTS can be sent to the peer without waiting for response.
Though since nothing identifies the response I guess it is implicit that
one HAVE to wait. Maybe this should be stated explicitly?

2) When requesting remote forwarding it would be convenient to be able to
specify a port number 0 to indicate any port and have the response include
the bound port.

3) I might have missed something but I think that some of the disconnect
reasons in the transport draft might need some definition/clarification
(e.g. SSH_DISCONNECT_CONNECTION_LOST, who lost which connection?). Another
example is I guess that now the SSH_DISCONNECT_KEY_EXCHANGE_FAILED should
be sent when host authentication fails? Hence the SSH_DISCONNECT_RESERVED
for the "deprecated" SSH_DISCONNECT_HOST_AUTHENTICATION_FAILED?

4) The drafts ("combined" transport/connection) doesn't say anything about
when the transport is taken down (if ever implicitly?). E.g. openssh
disconnects the transport layer when the "last" session channel has
exited. My interpretation is that the transport layer must be explicitly
killed by the client when it doesn't need it any more (or for some reason,
e.g. "idle timeout", by the server). Is this (should this be) defined?

Cheers,

/Mats

---

From: [email-masked] (Niels M�ller)
Date: 11 Oct 2000 13:55:06 +0200

> one HAVE to wait. Maybe this should be stated explicitly?

The important thing is that replies to GLOBAL_REQUEST:s that have
want_reply = 1 are sent in the right order. There should be no problem
with having several requests pending. It requires some extra
bookkeping to queue replies if one supports some kind of global
request which one can't reply to immediately.

> specify a port number 0 to indicate any port and have the response include

Could be useful, but I think I'd prefer a new requst type for doing
that. If this is addressed, it may also be useful to be able to bind
other kind of sockets, like AF_LOCAL sockets and UDP sockets.

> for the "deprecated" SSH_DISCONNECT_HOST_AUTHENTICATION_FAILED?

I agree, I think it's very unclear what the intended meaning of the
different disconnect reason codes are.

> e.g. "idle timeout", by the server). Is this (should this be) defined?

I think this is mostly an application issue, not a protocol issue. I
believe a server should usually never initiate take down of the
transport layer (even if it could be considered in situations were
there is some limit on the number of simultaneous connections and some
connection appears idle). It should usually be left to the client to
decide when to take down the connection and the transport protocol.

There's one thing though: The spec should probably spell out that it
is considered a protocol failure if the connection dies without a
SSH_MSG_DISCONNECT message being sent or received. (According to the
spec, one will never have both sent and received a
SSH_MSG_DISCONNECT).

/Niels

---

From: Sami Lehtinen <[email-masked]>
Date: Wed, 11 Oct 2000 18:07:03 +0300 (EEST)

Markus Friedl, on October 11. 2000, wrote:
  : On Tue, Oct 10, 2000 at 09:38:07PM +0300, Sami Lehtinen wrote:
  : > Niels Möller, on September 27. 2000, wrote:
  : >   : I'd like to know who, if any, is working as document editor for
  : >   : revising the current drafts? 
  : > 
  : > Ho.
  : 
  : So are you changing the specification for the MAC/hmac?

Yes. It will be along the lines of "key length used MUST be the same
as the digest length" or some such. That is, of course, unless someone
else has a better idea?