Re: Updated RSA SHA-2 draft / New draft: SSH Extension Negotiation

[denis bider <nospam%denisbider.com@localhost>]

It seems to me the only known applications that might want to use "no-handbrake" are those that don't want to use multiplexing. I don't know of a different usage case.

To support a different usage case that we do not know of, we would have to specify a mechanism for enabling this on a per-channel basis. This could be a channel request sent by the client. If supported and confirmed by the server, the channel request would switch the channel to infinite-window mode.

The way I see it, though, supporting infinite windows with multiple channels just doesn't seem to make sense.

The problem is not sending data. Yeah, in that case, you send in a round-robin fashion, no problem.

The problem is receiving. What happens when you can't write to the infinite-window channel, but the data keeps coming?

In this situation, you must stop reading from the SSH socket, which affects all channels. You must stop reading because you have no way of knowing whether the next packet you receive is going to be data for the infinite-window channel.

The way I see it, the only clean usage scenario for this feature is where there's a single channel. Anything else introduces dirty dilemmas that aren't even necessary, because the only actual usage case is single-channel.

Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost> , 11/12/2015 7:50 AM:

Niels Möller <nisse%lysator.liu.se@localhost> writes:

>Send 0, ignore received value, would have made it actually useful.

Can we get any figures on what effect making it nonzero would have?  We know
that there are at least some implementations who would have problems with
this, but if they're OSS and frequently updated then it may not be such a big
issue, push out a fix fairly soon and by the time the RFC is ready most of the
problem will have fixed itself.

Another workaround, although it's a bit of a hack, is if the two major client
and server implementations, putty and OpenSSH, could retry an initial connect
with a nonzero field that's failed with a zeroed field and if it works, report
to the user that the implementation needs an update.

>Also, I'm not sure it has to be restricted to a single channel, I think it
>would make sense to disable flow control independently for a single channel
>or a single unidirectional flow.

Ah, good point.  The number of users of multichannel that I have is pretty
minimal, so I never see this (it's used almost exclusively as a secure telnet
or for firmware upgrades, neither of which need multi-channel, to the point
where it's disabled by default in the source code).

>Do we have a common understanding of how it's going to work?

Not yet, I think :-).  I'd just seen it as all-or-nothing, is there any reason
why you'd have windowing on three channels but not a fourth?  That is, is
there a need for per-channel windowing enable/disable?  Can it be enabled mid-
flow or only on channel open?

Peter.