Re: Protocol ambiguity: want_reply vs CHANNEL_CLOSE

Simon Tatham <[email protected]> writes:

> Background: as I mentioned in a previous message, PuTTY periodically
> sends a bogus channel request "[email protected]",
> with want_reply set. There is no correct handling defined for this
> request, so we expect CHANNEL_FAILURE from the server (though we know
> of at least one server which amusingly sends CHANNEL_SUCCESS :-).

I think I've heard of keep-alive requests which work the same way.

Anyway, in the work-around category, does this have to be a channel
request, or could you use a global request instead? (I think I've heard
of servers disconnecting on unknown global requests, but that was some
years ago).

> OpenSSH did not, because Damien
> Miller questioned my analysis of it as a server-side bug on the basis
> that the spec was unclear (which indeed it is):
>
>   https://bugzilla.mindrot.org/show_bug.cgi?id=1818

The spec is a bit unclear, but I think your initial interpretation is
the one which makes the most sense. Consider the sequence (which I think
you mentioned in some comment):

  A sends CHANNEL_REQUEST (with want_reply set), followed by
  CHANNEL_CLOSE.

  B responds with a CHANNEL_CLOSE, followed by a CHANNEL_FAILURE.

At the time A receives the CHANNEL_CLOSE, section 5.3 is pretty clear
that the channel is dead, and that A may reuse the channel number. So in
this scenario the CHANNEL_FAILURE clearly violates the protocol spec.
Note that it's not really possible for A to know if B's CHANNEL_CLOSE
was a response to A's, or if it was sent while A's messages were still
in flight.

Now, the question is where to put the blame for this violation. I'd say
put the blame on B: After CHANNEL_CLOSE, no further messages relating to
the channel can be sent, period. The alternative is to say that it's A's
fault: A shouldn't send CHANNEL_CLOSE while it has a pending request. I
see two related problems with this alternative:

1. Say A sends a CHANNEL_REQUEST, which B never responds to. Maybe B is
   misbehaving, or maybe progress on the request simply depends on some
   process which is stuck or otherwise takes a very long time to
   complete. Then it will not be possible for A to tear down the
   channel; since it hasn't seen the response, it would be forbidden to
   send a CHANNEL_CLOSE. While I think the intention is that either
   party can initiate teardown by sending CHANNEL_CLOSE any time it
   likes.

2. It doesn't quite handle the case B generated the CHANNEL_CLOSE
   independently of A's actions. If B sends the CHANNEL_CLOSE while A's
   CHANNEL_REQUEST is in flight, the spec still requires A to respond
   with a CHANNEL_CLOSE. I think it's fairly clear that the intention is
   that that response should be prompt, with no long delay. On the other
   hand, there's no limit on how long it might take to respond to a
   CHANNEL_REQUEST.

I'm not sure how the update/errata process works. I think it would make
sense to amend section 5.3 to say something like:

  SSH_MSG_CHANNEL_CLOSE is the final message a party for a channel. If,
  at the time a party receives a SSH_MSG_CHANNEL_CLOSE, there are some
  SSH_MSG_CHANNEL_REQUEST that party has sent but not received any
  replies for, the SSH_MSG_CHANNEL_CLOSE message should be treated as an
  implicit SSH_MSG_CHANNEL_FAILURE for all outstanding requests

The lst piece is actually a bit subtle. If you have received a
CHANNEL_REQUEST, and started acting on it at the time you receive a
CHANNEL_CLOSE, and the request has any potential side effects, you would
need to somehow cancel it. As long as it is still possible that the
request might succeed, you can't send the required CHANNEL_CLOSE
response. In practice, I think a *short* delay to sort this out is
perfectly acceptable.

> The only people I know who have so far _deliberately_ gone with the
> other behaviour (in the sense of arguing against fixing it when it was
> pointed out) are the OpenSSH maintainers. Are any of them reading
> this?

The way I read that bug log, at least they don't say they won't fix it
ever. So the low priority doesn't necessarily mean that they are
convinced that there is no openssh bug here.

Regards,
/Niels

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