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

From: Chris Lonvick <[email-masked]>
Date: Mon, 13 Sep 2004 08:40:37 -0700 (PDT)

Hi,

Refreshing this discussion:

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

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

On Thu, 19 Aug 2004, [iso-8859-1] Niels Möller wrote:

> Anil Madhavapeddy <[email-masked]> writes:
>
> > 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"
>
> I think you're right.
>
> > 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.
>
> 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
>

On Mon, 23 Aug 2004, Jacob Nevins wrote:

> Niels Moller writes:
> > 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).
>
> 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?)
>

It appears that some changes need to be made to [connect].

1) In Section 7.1
  s/SSH_MSG_GLOBAL_REQUEST_SUCCESS/SSH_MSG_REQUEST_SUCCESS/
in the spot noted by Anil.

2) Make a decision that [connect] must either
  a) mandate that replies to channel requests MUST be in order, or
  b) change the protocol to have the responses identify the channel.
I'm betting that this group will opt for (a).  If so, could someone please
propose some text.

Thanks,
Chris

---

From: "denis bider" <[email-masked]>
Date: Sat, 18 Sep 2004 22:26:58 +0200

> It appears that some changes need to be made to [connect].
...
> I'm betting that this group will opt for (a).  If so, could 
> someone please propose some text.

Beg pardon?

Responses do identify the channel.

>      byte      SSH_MSG_CHANNEL_SUCCESS

[CONNECT] should mandate that replies to channel requests need not be in order
overall, but must be in order for each channel. Replies to global requests must
be in order overall.

---

From: Chris Lonvick <[email-masked]>
Date: Mon, 20 Sep 2004 07:57:34 -0700 (PDT)

Hi,

> overall, but must be in order for each channel. Replies to global requests must

OK.  I've added text to the bottom of Section 4 "Global Requests" as
follows:

   In general, the reply messages do not include request type
   identifiers.  To make it possible for the originator of a request to
   identify to which request each reply refers, it is REQUIRED that
   replies to SSH_MSG_GLOBAL_REQUESTS MUST be sent in the same order as
   the corresponding request messages.  For channel requests, replies
   that relate to the same channel MUST also be replied to in the right
   order.  However, channel requests for distinct channels MAY be
   replied to out-of-order.

Is this acceptable?

Thanks,
Chris

---

From: Joseph Galbraith <[email-masked]>
Date: Mon, 20 Sep 2004 09:40:53 -0600

>    order.  However, channel requests for distinct channels MAY be

This sounds good to me.

- Joseph

---

From: [email-masked] (Niels Möller)
Date: 20 Sep 2004 20:47:57 +0200

>    order.  However, channel requests for distinct channels MAY be

It's ok. I think it could be improved slightly by striking the first
sentence.

(The request type is mostly irrelevant when it comes to disambiguating
replies, as one may well have several outstanding requests of the same
type; I think mentioning it as a possible alternative will just add
more confusion).

Regards,
/Niels

---

From: Anil Madhavapeddy <[email-masked]>
Date: Mon, 20 Sep 2004 20:02:17 +0100

>    order.  However, channel requests for distinct channels MAY be

Looks fine to me.

---

From: "denis bider" <[email-masked]>
Date: Mon, 20 Sep 2004 20:59:04 +0200

> >    order.  However, channel requests for distinct channels MAY be

Sounds good to me too.