Subject: query about draft-ietf-secsh-connect-19.txt

From: Anil Madhavapeddy <[email-masked]>
Date: Fri, 13 Aug 2004 14:09:51 +0100

In draft-ietf-secsh-connect-19.txt, Section 7.1, there is a reference
to:

byte     SSH_MSG_GLOBAL_REQUEST_SUCCESS
uint32   port that was bound on the server

which should probably be "SSH_MSG_REQUEST_SUCCESS"

The other odd thing about this packet is that it's the only one which 
doesn't encode the request type in which it's in response to.

This form would appear to make more sense:

byte    SSH_MSG_REQUEST_SUCCESS
string  "tcpip-forward"
uint32  port that was bound on the server

As this is the only packet for which the contents of the packet can
vary without a "constant field" on which to make the decision of which
further packets to inspect.  In other cases, e.g. SSH_MSG_CHANNEL_REQUEST,
the decision to decode further fields can be taken by lookinng at the
first string argument.

-- 
Anil Madhavapeddy                                 http://anil.recoil.org
University of Cambridge                          http://www.cl.cam.ac.uk

---

From: [email-masked] (Niels Möller)
Date: 19 Aug 2004 17:46:02 +0200

> which should probably be "SSH_MSG_REQUEST_SUCCESS"

I think you're right.

> doesn't encode the request type in which it's in response to.

The *reply* messages in general includes *no* request type identifier:

     byte      SSH_MSG_REQUEST_SUCCESS
     .....     response specific data
--
     byte      SSH_MSG_REQUEST_FAILURE
--
     byte      SSH_MSG_CHANNEL_SUCCESS
     uint32    recipient_channel
--
     byte      SSH_MSG_CHANNEL_FAILURE
     uint32    recipient_channel

To make it possible for the originator of a request to identify to
which request each reply refers to, it is required that replies to
SSH_MSG_GLOBAL_REQUESTS must be sent in the same order as the
corresponding request messages.

And for channel requests, replies that relate to the same channel must
also be replied to in the right order (channel requests for *distinct*
channels can be replied to out-of-order, at least that's my
understanding of things).

Regards,
/Niels

---

From: Jacob Nevins <[email-masked]>
Date: Mon, 23 Aug 2004 11:29:56 +0100

> understanding of things).

I can't find language spelling out these requirements in connect-19
after a brief skim through. Perhaps some should be added? (Would current
implementations meet these requirements?)