Re: Protocol ambiguity: want_reply vs CHANNEL_CLOSE

[Matt Johnston <matt%ucc.asn.au@localhost>]

On Fri, Apr 04, 2014 at 10:58:47AM +0100, Simon Tatham wrote:
> 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. It's hard to imagine a situation where the reply
would not be SSH_MSG_REQUEST_FAILURE, and a requestor
wouldn't be able to do much with a "success" reply in any
case. In addition it adds an another state for
implementations to handle, "both sides closed but waiting
for a reply".

Given there are millions of deployed servers that won't
change, would it be best to just publish a RFC and keep
using a compatibility table? Out of interest has PuTTY
encountered this problem in the wild?

FWIW Dropbear ignores requests after having sent
SSH_MSG_CHANNEL_CLOSE, though that was more from omission
of the wantreply case. All SSH_MSG_CHANNEL_REQUEST messages
have wantreply=0, so no replies are expected.


Cheers,
Matt