Subject: Re: Definition of "packet"

From: [email-masked] (Niels Möller)
Date: 02 Nov 2005 12:35:10 +0100

Henrick Hellström <[email-masked]> writes:

> This ought to be a simple question, but it seems it is not spelled out
> anywhere in specification:
> 
> Exactly what is to be included in the calculation of the length of a
> "packet", when checking if it exceeds the Maximum Packet Size
> parameter sent during SSH Connection establishment?

If we're talking about CHANNEL_OPEN / CHANNEL_OPEN_CONFIRM, I think
it's best to interpret the max pcket size as the maximum amount of
channel "upper layer" data in a CHANNEL_DATE or CHANNEL_EXTENDED_DATA
message.

I think this has been discussed earlier, and I think that was the
conclusion.

When reading data to be sent over an ssh channel, the length for the
underlying read call can be selected as MIN(channel max packet size,
current channel window size), which is nice and simple. I have earlier
thought that the channel's max packet size should be interpreted as a
the payload size for the ssh *transport* layer, but that makes the
read logic unnecessarily complicated.

This means that if you want to limit the ssh transport layer payload
size of sent or received transport packets to 32768 bytes, then you
need to limit the received or sent max packet size for a channel to
32768 - transport overhead.

I agree a clarification would be nice, but perhaps it's too late.

Regards,
/Niels

---

From: [email-masked] (Niels Möller)
Date: 02 Nov 2005 18:08:12 +0100

Jacob Nevins <[email-masked]> writes:

> How about the following change to secsh-connect 5.1, which makes the
> 'maximum packet size' language match that used for 'initial window
> size'?:
> 
>                           The 'maximum packet size' specifies the
>    maximum number of bytes of channel data that may be sent to the
>    sender in a single SSH packet.

It's not entirely trivial to make this clear. I would propose a change
to section "5.2  Data transfer", in the description of
SSH_MSG_CHANNEL_DATA.

Before:

   The maximum amount of data allowed is the current window size.  The
   window size is decremented by the amount of data sent.  Both parties
   MAY ignore all extra data sent after the allowed window is empty.

After:

   The maximum amount of data allowed is determined by the maximum
   packet size for the channel, and the current window size, whichever
   is smaller. The window size is decremented by the amount of data
   sent. Both parties MAY ignore all extra data sent after the allowed
   window is empty.

*Maybe* also add a clarification along these lines:

   Implementations are expected to have some limit on the ssh
   transport layer packet size (any limit for rececived packets MUST
   be 32768 bytes or larger, as described in [SSH-TRANSPORT]). The
   implementation of the SSH connection layer

   * MUST NOT advertise a maximum packet size that would result in
     transport packets larger than its transport layer is willing to
     receive.

   * MUST NOT generate data packets larger that its transport layer is
     willing to send, even if the remote end would be willing to
     accept very large packets.

Although I feel this text is much too long, and we probably shouldn't
say anything about this at all if we can't say it more concisely. The
first point is a clarification of the actual wire protocol, it says
that if the other end advertises a huge maximum packet size, it can
also be expected to accept huge packets, and in this case it is safe
to send packets larger than 32768 bytes. The second point is almost
self-evident; if your transport layer can't send a 10 MB packet, don't
do that, and don't rely in the *remote* end to advertize a maximum
packet size that is supported by your implementation.

Regards,
/Niels

---

From: Chris Lonvick <[email-masked]>
Date: Thu, 3 Nov 2005 06:34:11 -0800 (PST)

Hi,

I'm inclined to include everything that Niels proposes below.  Some 
lengthy notations are acceptable for clarity.  Please send OBJECTIONS or 
CORRECTIONS to the proposed text quickly.

Thanks,
Chris

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 4 Nov 2005 19:49:03 -0800 (PST)

Hi,

Just a note that the references for the new RFCs in the text are 
inconsistent with the references for the other RFCs; [SSH-ARCH] as opposed 
to [RFC4251].  I think that the way that the RFC Editor has them is more 
informative to a reader so I'm going to leave them that way.

Thanks,
Chris

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 9 Nov 2005 18:27:52 -0800 (PST)

Hi,

Changes made.

Thanks,
Chris