Re: Speaking of implementation quirks...

[nisse%lysator.liu.se@localhost (Niels Möller)]

pgut001%cs.auckland.ac.nz@localhost (Peter Gutmann) writes:

> The reason I asked for the disambiguation in -transport is that I've only ever
> found one implementation that, if asked for a max.packet size of nK, sends
> significantly more than nK.

I think it would be good if you spelled out exactly which
implementation(s) you are talking about. Mine (lsh) applies the
channel max packet size to the application data portion of DATA and
EXTENDED_DATA packets. I don't know what other implementors do.

> What critical interoperability requirement is being served by the
> MUST 32K? It just appeared from nowhere in one of the early drafts
> (-02 I think). Why not 64K? 2MB? 2GB? (or going the other way, 2K?).
> The point is that since it's a negotiable parameter, there's no need
> to have a MUST tying it to a single value.

It's not *explicitly* negotiated, but as long as the largest packets
are the channel data packets, one can make sure one doesn't get very
large packets by advertising a small channel max packet size. So it
would probably work with a required buffer size of just a few thousand
bytes.

The packets that may potentially hit this limit, besides channel data
(which is of negotiated size), are key exchange messages including
certificate chains, as well as debug and ignore messages, which can
potentially be large.

In practice, I think you could manage with small buffers and still be
99% compliant to the spec, by advertising a smallish max packet size on
all channels, and have special code that can skip and discard messages
of type DEBUG and IGNORE without buffering the complete messages.

(You would fail to interoperate with implementations that put
ridiculously long algorithm or language lists into their KEXINIT
message, but that should not be common. Only example I'm aware of is
SSH-2.0-Sun_SSH_1.0 which dumps its complete locale list into the ssh
language list, resulting in a KEXINIT message of some 1400 bytes plus
header, and that's a known bug which I hope will be fixed in the next
release).

/nisse