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

[Chris Lonvick <clonvick%cisco.com@localhost>]

Hi,

Refreshing this discussion:

On Fri, 13 Aug 2004 14:09:51 +0100
Anil Madhavapeddy <anil%recoil.org@localhost> 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 <anil%recoil.org@localhost> 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