Re: Protocol ambiguity: want_reply vs CHANNEL_CLOSE

[Damien Miller <djm%mindrot.org@localhost>]

On Fri, 4 Apr 2014, Simon Tatham wrote:

> I think this list still reaches a reasonable number of SSH
> implementors. I'd like to see if we can get a consensus on the
> following problem.
> 
> 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 agree the spec doesn't make this clear but IMO no. 'A' will receive
SSH_MSG_CHANNEL_CLOSE before it would have received any reply and
should, based on it, abandon it expectation that a reply will be
forthcoming.

> 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.

^^^ this.

>  (b) Issue an RFC specifying a protocol extension that allows an
>      implementation to advertise which interpretation it will follow
>      (since either behaviour is easy to cope with if you know which
>      one you're talking to). I suppose we'd still have to decide on
>      the default answer in the absence of such an advertisement.

IMO no - it's overkill and not necessary.

-d