Re: Protocol ambiguity: want_reply vs CHANNEL_CLOSE

[nisse%lysator.liu.se@localhost (Niels Möller)]

Simon Tatham <anakin%pobox.com@localhost> writes:

> Suppose two SSH implementations have a channel open between them.
> Party A sends an SSH_MSG_CHANNEL_REQUEST of some kind, with the
> want_reply flag set. Party B, meanwhile, independently decides to
> initiate shutdown of the channel, and sends SSH_MSG_CHANNEL_CLOSE.
> These two messages cross in the network, so that B receives the
> channel request after it's already sent a close message for that
> channel.
>
> Should B send a reply?

I'd say no. I think it is pretty clear that the intention is that the
CLOSE message is the final one. So that the receiver of the CLOSE close
message can respond with a CLOSE, unless it has already sent one, and
then forget *all* state of the channel.

(Maybe one also have the option to sending additional messages before
responding with a matching CLOSE. I don't know if any implementations do
that. I think receiving a CLOSE means that the other end has lost all
interest in the channel, and then it doesn't make any sense to send
anything but a matching CLOSE).

> Would anyone like to state an opinion on what ought to happen about
> this? I can think of two reasonably sensible options:
>
>  (a) Issue a clarifying RFC that resolves the ambiguity by designating
>      one or other behaviour as correct, and consider implementations
>      doing the other thing to have a bug requiring a fix.

I think it would be useful to sort out what problems that bug causes,
and if there are any reasonable workarounds. I think there are a couple
of cases:

1. We receive an unexpected response (which the sender intended for a
   now dead channel). Treated an a protocol error, and handled by
   closing the connection. Here's one has the option of ignoring
   unexpected responses, possibly depending on the other side's version
   string.

2. We send a CHANNEL_REQUEST for a channel and get two replies (where
   the first was intended for a no longer alive channel). I imagine this
   could lead to more subtle problems. This is the case that can be
   eliminated by following the suggestion of not reusing channel
   numbers.

3. The implementation at the other end somehow expects a response after
   CLOSE, and not sending that breaks it's channel close handshake
   logic, leaving a channel alive for ever. I hope this problem doesn't
   require any new workarounds: The other end is typically untrusted,
   and we shouldn't let deviations like this cause us any big problems.

Can you give us some more details on the problems you have encountered?
Maybe there are simple workarounds for 95% of the problems, maybe
there isn't.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.