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

From: Thomas Anderson <[email-masked]>
Date: Sat, 12 Sep 2009 20:54:34 -0700 (PDT)

der Mouse wrote:
>> Per RFC4254, the maximum size field of an SSH_MSG_CHANNEL_OPEN packet
>> places an upper bound on just how big a packet from the server to the
>> client can be: [...]
> 
>> My question is...  what about the other way around?  What about
>> packets sent from the client to the server?
> 
> See the SSH_MSG_CHANNEL_OPEN_CONFIRMATION packet sent in response to
> the open request, which holds the corresponding values for data flowing
> in the other direction.

Hmmm - the first time I looked at the structure of SSH_MSG_CHANNEL_OPEN_CONFIRMATION, I thought those extra fields were for confirmation purposes and didn't give it a second thought.  Seems like the RFC should maybe state their purpose in SSH_MSG_CHANNEL_OPEN_CONFIRMATION a bit more explicitly - as is, although it's clear what they mean for SSH_MSG_CHANNEL_OPEN, for the confirmation response, it kinda requires you guess.  Maybe it's an easy enough thing to guess correctly, but I, apparently, didn't...

Anyway, thanks!

---

From: der Mouse <[email-masked]>
Date: Sun, 13 Sep 2009 06:43:56 -0400 (EDT)

>> See the SSH_MSG_CHANNEL_OPEN_CONFIRMATION packet [...]
> Hmmm - the first time I looked at the structure of
> SSH_MSG_CHANNEL_OPEN_CONFIRMATION, I thought those extra fields were
> for confirmation purposes and didn't give it a second thought.  Seems
> like the RFC should maybe state their purpose in
> SSH_MSG_CHANNEL_OPEN_CONFIRMATION a bit more explicitly -

Agreed.  When (if) 4254 is updated, that's a change I'd like to see; as
it stands, it is entirely silent on the purpose of those fields, which
strikes me as a bad idea for a formal spec.

/~\ 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

---

From: der Mouse <[email-masked]>
Date: Mon, 14 Sep 2009 01:42:40 -0400 (EDT)

>   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?).

I thought it was obvious, but here we have three people thinking of
three different interpretations, so it clearly isn't as obvious as I
thought.  (The main reason I considered it obvious is that neither of
the other two interpretations seems useful to me: echoing back the
values is pointless, since the channel open initiator (which may or may
not be the client) already has them, and the channel open confirmer may
use a smaller max packet size when sending data if it feels like it but
there's no need to tell the open initiator about it.  The only case
where sending those values is actually useful is when they describe the
maximum packet size for packets from the confirmer to the initiator
(whether the same value applies to the first direction also or not is
open for discussion, but see below).  And there needs to be a way for
the open confirmer to tell the open initiator what max packet size to
use; the open confirmer may impose a lower limit than the open
initiator does.)

> So my code treats the incoming size as being the same as the outgoing
> size, and so far has never run into problems.  I'd prefer to see this
> behaviour retained, since there doesn't seem to be anything making
> use of the capability for asymmetric sizes (or at least nothing I've
> run into), so explicitly introducing this is just going to add a pile
> of new exception and error states that need to be handled.

I'd prefer to see the two sizes explicitly separated, since everything
else about the two directions is independent and I see no reason to
introduce an exception for this.

I don't see it as introducing any new exception or error states; all
the exception states I can see already exist.  The only difference is
whether the value being compared against always equals the value used
as the maximum when constructing outgoing packets.

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?

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 14 Sep 2009 17:19:48 +1200

der Mouse <[email-masked]> writes:

>When (if) 4254 is updated, that's a change I'd like to see; as it stands, it
>is entirely silent on the purpose of those fields, which strikes me as a bad
>idea for a formal spec.

Ditto.  My code's handling of this is:

  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?).  In
  the absence of any further guidance we just ignore the returned values,
  which seems to work for all deployed servers.

So my code treats the incoming size as being the same as the outgoing size, 
and so far has never run into problems.  I'd prefer to see this behaviour 
retained, since there doesn't seem to be anything making use of the capability 
for asymmetric sizes (or at least nothing I've run into), so explicitly 
introducing this is just going to add a pile of new exception and error states 
that need to be handled.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 14 Sep 2009 18:04:49 +1200

der Mouse <[email-masked]> writes:

>The main reason I considered it obvious is that neither of the other two
>interpretations seems useful to me: echoing back the values is pointless,
>since the channel open initiator (which may or may not be the client) already
>has them, and the channel open confirmer may use a smaller max packet size
>when sending data if it feels like it but there's no need to tell the open
>initiator about it.

The reason why the second interpretation could be argued to be useful is if
you see the exchange as:

Client: I propose a max.packet size of 128 MB.
Server: That looks a bit large to me, how about 64kB?

So the client is advertising what it's prepared to accept as a maximum, and
the server is either confirming it or saying it'd prefer a bit less, an
exchange a bit like some of the cipher suite-type negotiation.

Peter.

---

From: [email-masked] (Niels Möller)
Date: Mon, 14 Sep 2009 10:02:35 +0200

der Mouse <[email-masked]> writes:

> I thought it was obvious,

Me too. I found it fairly clear that the two directions of a channel
are mostly independent and that each direction has it's own values for
window size and maximum packet size.

> is what level the max packet size applies at.

Again, I couldn't agree more. I interpret it as a maximum data payload
in CHANNEL_DATA / CHANNEL_EXTENDED_DATA.

Regards,
/Niels

---

From: [email-masked] (Niels Möller)
Date: Mon, 14 Sep 2009 10:23:28 +0200

> Server: That looks a bit large to me, how about 64kB?

But the server can lower the value however it likes, without telling
the client. Like

  Client: I can accept packets of size up to 128 MB.

  Server: That's too high for my taste. I'll just pretend that the
  client said only 64kB.

You might argue that it would be useful for the client to know that
this server has decided to not send any packets larger than 64kB, but
I'd say that really getting any advantage out of that information is
too much complexity for too small gain.

(And same goes with the roles of client and server reversed, of
course).

Regards,
/Niels

---

From: der Mouse <[email-masked]>
Date: Mon, 14 Sep 2009 08:05:30 -0400 (EDT)

>> and the channel open confirmer may use a smaller max packet size
>> when sending data if it feels like it but there's no need to tell
>> the open initiator about it.

> The reason why the second interpretation could be argued to be useful
> is if you see the exchange as:

> Server: That looks a bit large to me, how about 64kB?

Yes, but, as Niels pointed out, there's no need for the server to tell
the client it's lowering the effective value.

...unless, of course, you see this as being a single value negotiated
for both directions at once, rather than a limit on just the size of
server->client packets.  This is a self-consistent point of view, of
course; the major thing I see going against it is that it violates the
way everything else is determined separately for the two directions.

I suspect the reason you haven't run into any interop issues with your
interpretation is that everything (or at least everything you've
interop tested against) uses (approximately) the same limit you do.
Try artificially lowering your max-packet value to, say, 64 octets, and
see what happens.

(And, of course, nothing says that the one sending the CHANNEL_OPEN is
the client and the one sending the CHANNEL_OPEN_CONFIRMATION is the
server; either end may initiate channel opens.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Mon, 14 Sep 2009 21:47:46 -0400

> window size and maximum packet size.

I must agree. This interpretation is obvious, sensible, and is in the 
spirit of the SSH protocol. This is why the spec doesn't spell it out 
(though I agree it should).

I think Peter's interpretation is unreasonable.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 15 Sep 2009 17:09:32 +1200

"denis bider (Bitvise)" <[email-masked]> writes:

>I must agree. This interpretation is obvious, sensible, and is in the spirit
>of the SSH protocol. This is why the spec doesn't spell it out (though I
>agree it should).

If it's so obvious then why have a number of different people been unable to
guess the "obvious" interpretation?  If implementors are having difficulty
interpreting what the spec is trying to say then by definition it cannot be
"obvious".

Peter.

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 15 Sep 2009 17:21:24 -0600

> in CHANNEL_DATA / CHANNEL_EXTENDED_DATA.

I agree this is unclear.  We don't enforce anything for max packet
size (other than the 35K limit at the transport level), and for
the purposes of sending, I interpreted the max packet as the
maximum size of the outgoing SSH packet before compression and
encryption.

Maximum size of the data payload would be a heck of a lot easier
though ... I'd prefer a different name if it doesn't actually
refer to the packet.

Thanks,

Joseph

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Tue, 15 Sep 2009 20:33:53 -0400

>>spirit
> If it's so obvious then why have a number of different people been 
> unable
> to guess the "obvious" interpretation?

The "number of different people" that you refer to is 1. Thomas is a 
newbie who understood the concept the instant it was explained.

> If implementors are having difficulty interpreting what the spec is 
> trying
> to say then by definition it cannot be "obvious".

It's not obvious to you because you've always refused to accept SSH the 
way it is, and have always tried to shoehorn it into something it is 
not - something more along your way of doing things, not necessarily 
bad, but idiosyncratic.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 16 Sep 2009 16:52:23 +1200

"denis bider (Bitvise)" <[email-masked]> writes:

>The "number of different people" that you refer to is 1. 

I was referring to an earlier email in the thread where someone made a comment
about three different interpretations from three different people.
Unfortunately the list doesn't appear to be archived anywhere (it's not listed
on the NetBSD lists index) so I can't check the exact wording.

Peter.

---

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

> I was referring to an earlier email in the thread where someone made
> a comment about three different interpretations from three different
> people.

That would have been me.  It's recent enough to still be in my mail
history trail; here's the quote:

| I thought it was obvious, but here we have three people thinking of
| three different interpretations, so it clearly isn't as obvious as I
| thought.

The three were:

- Thomas, earlier in this thread, saying "I thought those extra fields
   were for confirmation purposes and didn't give it a second thought".
   (You mentioned this one too.)
- You, speculating that "the server is allowed to further modify them
   to suit its own requirements".
- Me, taking the OPEN_CONFIRMATION values as being the values for the
   confirmer->opener direction, with the values in the OPEN packet
   being just for the opener->confirmer direction.

And, denis, even if, as you wrote, "Thomas is a newbie who understood
the concept the instant it was explained", Peter's point that the spec
is unclear is still valid: the spec's wording has provoked three
incompatible interpretations from three different people, indicating
(to me at least) that the spec is unclear enough to need fixing.  How
those people react to having other interpretations presented to them is
irrelevant to this point.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Wed, 16 Sep 2009 10:54:42 -0400

> And, denis, even if, as you wrote, "Thomas is a newbie who
> understood the concept the instant it was explained", Peter's
> point that the spec is unclear is still valid: the spec's wording
> has provoked three incompatible interpretations from three
> different people, indicating (to me at least) that the spec is
> unclear enough to need fixing.

Yes, I agree. The spec needs to be clarified on this point.