Re: Protocol ambiguity: want_reply vs CHANNEL_CLOSE

["denis bider \(Bitvise\)" <ietf-ssh3%denisbider.com@localhost>]

> Out of interest has PuTTY encountered this problem in the wild?

Yes, with our server (Bitvise).

The way I see this issue is that in the described situation, the request 
sender can implement behavior that accommodates all responders, but the 
request responder cannot implement behavior that accommodates all request 
senders.

The behavior that accommodates all request responders is as follows:

- Do not wait for channel request responses after receiving CLOSE.

- Do not reuse channel numbers, so that you can reliably ignore channel 
request responses received after CLOSE.

On the responder's end, however, there are these choices:

- If a channel request arrives after we sent CLOSE, but before we received 
remote CLOSE, ignore it. This will work for request senders which don't wait 
for request responses after CLOSE, but it will hurt request senders that do.

- Alternately, if a channel request arrives after we sent CLOSE, but before 
we received remote CLOSE, reply to it. This will work for request senders 
which wait for request responses after CLOSE, but it creates a possible race 
condition for request senders which do not:

 (a) The request sender might have already sent CLOSE that we haven't 
received yet, might have freed channel state, and might abort the session 
due to unexpected channel number in request response.

 (b) Alternately, the request sender might have already sent CLOSE that we 
haven't received yet, and immediately after, respond to our CHANNEL_OPEN 
that we might have just sent. The request sender might then interpret our 
response as arriving on that new channel, rather than the previous one being 
closed.

With millions of SSH implementations out there, we are no longer in a 
position to mandate behavior that makes implementations incompatible with 
one another. I think we ought to advise in favor of the most compatible 
strategy, which is:

- Do not reuse channel numbers.

- Do not send responses after sending CLOSE.

- Do not wait for responses after receiving CLOSE.

denis


-----Original Message----- 
From: Matt Johnston
Sent: Friday, April 4, 2014 07:09
To: Simon Tatham
Cc: ietf-ssh%netbsd.org@localhost
Subject: Re: Protocol ambiguity: want_reply vs CHANNEL_CLOSE

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