Re: Speaking of implementation quirks...

[pgut001%cs.auckland.ac.nz@localhost (Peter Gutmann)]

der Mouse <mouse%Rodents.Montreal.QC.CA@localhost> writes:

>>Based on this, it'd be useful if the text could emphasise that the
>>value refers to the total packet size by adding the "(including
>>length, padding length, payload, padding, and MAC)" in -transport...
>
>Except the text that needs changing isn't in -transport; it's in -connect.
>The description of channel opening just says it's "the maximum size of an
>individual data packet that can be sent to the sender".  In context, this
>could reasonably be taken to refer to packets at the SSH Connection Protocol
>layer, though whether it refers to data payload or payload plus nine bytes of
>CHANNEL_DATA header is still ambiguous.

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.  This would imply that most implementations regard
the packet size as "(including length, padding length, payload, padding, and
MAC)" rather than excluding all that, thus leading to over-sized packets when
you add all the other bits.

(Either that or they all use very small amounts of padding, I allow some slop
 in lengths, but not that much.  In any case it needs clarification, otherwise
 there's not much point in being able to specify a length if there are several
 different interpretations of what it means.  What do other implementations
 do?).

>First, -connect 5.1's limit applies only to channel data packets; it has no
>bearing whatever on other packets and thus cannot usefully be used as a limit
>on other packets.

That's fine, channel data packets are the only ones that are likely to get
very big.

>As for your own issues, nothing says that you have to have a 32K buffer in
>order to receive and process packets 32K in length.  You're entirely free to
>process packets byte by byte, chewing your way through that 32K packet
>piecemeal - though you have to be careful that you can back out any global
>data structure changes in case the MAC turns out to be wrong.

You're also entirely free to push a pea up a mountain with your nose, however
that's not a very good way of getting it there.  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 interesting to note that SSL has introduced extensions to allow the use
 of shorter packets in resource-constrained devices, while SSH, which is often
 used as the CLI admin interface on such devices, mandates 32K buffers for an
 interface that usually transmits single keystrokes).

Peter.