Subject: Re: maximum size of packets from client to server

From: Thomas Anderson <[email-masked]>
Date: Tue, 15 Sep 2009 19:56:48 -0700 (PDT)

der Mouse wrote:
>>   The SSH spec doesn't really explain the semantics of the server's
>>   response to the channel open command, in particular whether the
>>   returned data size parameters are merely a confirmation of the
>>   client's requested values or whether the server is allowed to
>>   further modify them to suit its own requirements (or perhaps one is
>>   for send and the other for receive?).
>
> One thing I would like to see clarified here but haven't seen mentioned
> is what level the max packet size applies at.  Is it the max data
> payload of a CHANNEL_DATA (or CHANNEL_EXTENDED_DATA) packet, the max
> size of a CHANNEL_DATA (or ...) packet in cleartext form, the max size
> of such a packet with encryption and padding, what?

I actually mentioned that in my third email as something else I'd like to see clarification on.  The other thing I mentioned in that email as being unclear to me was this:

> On this same subject, here's something else I think could use 
> clarification.  RFC4254#section-5.1 states that the "maximum packet 
> size" refers to the "maximum size of an individual data packet".  This 
> raises the question...  what qualifies as a data packet.  Does 
> SSH_MSG_CHANNEL_REQUEST qualify as a data packet, for example?  Often, 
> they wouldn't, but if the request type is "exec", a 
> SSH_MSG_CHANNEL_REQUEST could easily exceed "maximum packet size".

---

From: der Mouse <[email-masked]>
Date: Wed, 16 Sep 2009 07:38:44 -0400 (EDT)

>> One thing I would like to see clarified here but haven't seen
>> mentioned is what level the max packet size applies at.
> I actually mentioned that in my third email as something else I'd
> like to see clarification on.

Sorry, I must have missed your mention.  Since people are quoting the
comments from their code, here's the relevant comment from mine:

/*
 * This value is what we put in the "maximum packet size" field of
 *  CHANNEL_OPEN and CHANNEL_OPEN_CONFIRMATION messages we generate.
 *  This is documented as
 *	The 'maximum packet size' specifies the maximum size of an
 *	individual data packet that can be sent to the sender.
 *  There is disagreement over exactly what this means.  It seems to me
 *  that this means "the maximum size of a CHANNEL_DATA or
 *  CHANNEL_EXTENDED_DATA message", but at least two other
 *  implementations take it to mean "the maximum size of a CHANNEL_DATA
 *  or CHANNEL_EXTENDED_DATA data payload".  When I put
 *  SSH_MAX_PAYLOAD_LEN in here, I would relatively routinely get
 *  crashes in which the remote end overran my specified maximum size
 *  by 9 bytes (ie, the difference between the size of a CHANNEL_DATA
 *  packet and the size of its data payload).  While I still think my
 *  reading is right, the wording is now frozen (and thus won't change
 *  even if it turns out I'm right) and other implementations aren't
 *  going to change their deployed base overnight even if they agree
 *  with me today.  So we allow some slop.  It's tempting to produce
 *  nag messages if we detect a peer treating this value as a max data
 *  _payload_ size instead of a max data _packet_ size, in an attempt
 *  to get people to fix their other implementations, but for now I'm
 *  holding off on that; I'm going to try to get this nailed down on
 *  the WG list first.
 *
 * We take the opposite interpretation when handling maxsend values
 *  from incoming CHANNEL_OPEN and CHANNEL_OPEN_CONFIRMATION messages,
 *  taking them as maximum data packet size rather than maximum data
 *  payload size.  This is not because we're twisted (though that might
 *  be a defensible position :), but because we're conservative; doing
 *  this causes us to use a lower value, making it harder to overrun
 *  other implementations.  (Besides, it's what the spec specifies. :)
 *  (Actually, we do this only if the max-packet value is >13;
 *  otherwise, when we subtract 13, the result would be zero or
 *  negative.  Anyone specifying a value that small *must* be treating
 *  it as a max payload size rather than a max total packet size - or
 *  severely buggy, I suppose.)
 *
 * 13 is the difference between a CHANNEL_EXTENDED_DATA packet size and
 *  its data payload size.  This is the largest overhead we have to
 *  deal with; for CHANNEL_DATA packets, the overhead is only 9, but
 *  there's only one value, so we have to deduct for the largest packet
 *  overhead.
 */
#define MAX_PACKET_SIZE_VALUE (SSH_MAX_PAYLOAD_LEN-13)

I think the data payload size is probably what the author of that part
of the spec had in mind, but it's not what the language actually says.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B