Computing window sizes and adjustments

[JCA]

On 7/16/07, Damien Miller <djm at mindrot.org> wrote:
> On Mon, 16 Jul 2007, JCA wrote:
>
> >    In SSHv2, the data that consumes window space is that sent in the
> > channel data and channel data extended messages. My question is, how
> > is the data that consumes window space reckoned? One would have
> > thought that it is the total length of the message itself, but the
> > standard seems to imply that only the data contained in the data
> > string field in the messages above is to be taken into account. That
> > is, things like eg the padding and HMAC fields do not consume window
> > space.
>
> Windows in the SSH protocol are per-channel, so it only makes sense to use
> the data that is sent over a channel. This does not include MAC and padding
> as these are protocol-level, not channel level.
>
> >    What is it that OpenSSH does in this respect?
>
> OpenSSH counts the data sent over a channel against the window, not
> including the protocol-level framing used to send it.

   Thanks for the feedback. Let me see if I can pin things down.

   The structure of an SSHv2 packet is laid down in section 6 of RFC 4253:

      uint32    packet_length
      byte      padding_length
      byte[n1]  payload; n1 = packet_length - padding_length - 1
      byte[n2]  random padding; n2 = padding_length
      byte[m]   mac (Message Authentication Code - MAC); m = mac_length

If I understand you correctly, the only field that is to be taken into
account when adjusting the window size is the payload. Now only two
packet types, namely, SSH_MSG_CHANNEL_DATA and
SSH_MSG_CHANNEL_DATA_EXTENDED, consume window space. The structures of
these packets are

      byte      SSH_MSG_CHANNEL_DATA
      uint32    recipient channel
      string    data

and

      byte      SSH_MSG_CHANNEL_EXTENDED_DATA
      uint32    recipient channel
      uint32    data_type_code
      string    data

Are all the fields in the packets to be reckoned with for window space
consumption purposes, or only the data string? I mean, both the packet
ID and recipient channel can be considered to be protocol data;
probably the data_type_code as well; therefore, they should be left
out. Is this the case?