Subject: channel association

From: der Mouse <[email-masked]>
Date: Wed, 14 Apr 2004 02:52:52 -0400 (EDT)

I'm working on my ssh implementation and I see more problems with the
spec.

There are a number of things which are conceptually associated with a
session channel, but which are not actually entirely so associated.  At
the moment, these are primarily X and agent forwarding: they are
requested with a CHANNEL_REQUESTs on a session channel, but when a
forwarded connection arrives, the client gets no indication which
session's forwarding it is due to.  This is causing me trouble, for
reasons I can go into if anyone is curious but which are mostly
irrelevant here.

More generally, it is a conceptual problem to associate a request with
a session, but have no way to associate an asynchronous response to
that request with the relevant session (or the particular request that
produced it, which would allow identifying the session).

In passing, I note that TCP connection forwarding was done right in
this regard: it makes no pretense of being associated with any session,
and is requested with not a CHANNEL_REQUEST but a GLOBAL_REQUEST.

Has anyone addressed such issues before?  I can think of at least two
different ways of addressing them, and while I could simply pick one
and implement it with private requests, I'd be interested in hearing
about experiences from anyone who's tackled the issue already.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 14 Apr 2004 13:57:12 -0500

> produced it, which would allow identifying the session).

Agreed.  But note that the draft does say "[t]he resulting channels are
independent of the session, ..."

> about experiences from anyone who's tackled the issue already.

I think this problem probably ought to be fixed, but if it is to be
fixed it should be fixed in a separate document.

There are several fixes for this that I can imagine:

a) Add a channel request for opening forwarded whatever channels.

b) Add new SSH_MSG_CHANNEL_OPEN channel types for channels associated
with session channels that includes the channel id of the associated
session channel.

c) Add new channel requests for associating an open channel with a
session channel.  Of course, if may be to late at that point for the
client to do anything useful with this info, so this may not be useful
at all.

I much prefer (b).

Nico
--

---

From: der Mouse <[email-masked]>
Date: Wed, 14 Apr 2004 16:54:13 -0400 (EDT)

>> More generally, it is a conceptual problem to associate a request
>> with a session, but have no way to associate an asynchronous
>> response to that request with the relevant session [...]
> Agreed.  But note that the draft does say "[t]he resulting channels
> are independent of the session, ..."

This is true in terms of their lifetime, but not in terms of the
content they carry.  (Note that the following phrase, which you didn't
quote, specifically speaks of the lifetime, strongly implying that this
remark is intended to refer to channel lifetimes.)

> I much prefer (b).

Me too, and that's what I'm doing for the moment.  For example, when my
client requests agent forwarding, it does so by requesting
"[email-masked]", and if that is refused
it will fall back to trying "auth-agent-req", noting in the process
that the resulting agent forwarding is inconsistent with the kind of
optimization I want to do.  The fixed- request is just like the one in
the draft except it includes an additional uint32, which is returned in
the "[email-masked]" CHANNEL_OPEN that comes
back when a forwarded connection is called for.  X forwarding, when I
add that, will work analogously.

Unless, of course, someone comes up with a reason to do otherwise,
which is why I was asking if anyone had addressed it already.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 14 Apr 2004 18:48:09 -0500

> remark is intended to refer to channel lifetimes.)

Certainly reading that sentence doesn't make the problem immediately
apparent, but I do think that the first clause of that sentence has
meaning beyond that of the second clause.  But let's not quibble.  The
text could be clarified and the problem could be fixed in a separate
doc.

> which is why I was asking if anyone had addressed it already.

I think this is the way to go.  Obviously we'd need a standard channel
open request name, but that's a minor detail.