Subject: Channel window limits

From: Ben Harris <[email-masked]>
Date: Mon, 17 Jan 2005 19:26:29 +0000 (GMT)

In draft-ietf-secsh-connect-23.txt, there seems to be no limit on the 
window size that an implementation can advertise.  While each 
SSH_MSG_CHANNEL_WINDOW_ADJUST can add at most 2^32-1 bytes to the window, 
an implementation can send as many WINDOW_ADJUSTs as it wants.  This is a 
problem because it means that its peer has to keep track of an 
arbitrarily-large window, and in particular one that can't be represented 
by a 32-bit unsigned integer.  I doubt that this is the intention of the 
spec, so I'd suggest the following change:

After:

    After receiving this message, the recipient MAY send the given number
    of bytes more than it was previously allowed to send; the window size
    is incremented.

add:

                     The window MUST NOT be increased above 2^32-1 bytes.

This isn't desperately important, since I doubt any sane implementation 
would violate this constraint anyway, but if there's another draft of 
-connect- I think it should be in there.

Of course, that assumes I'm right about the implication of the current 
draft...

-- 
Ben Harris

---

From: Joseph Galbraith <[email-masked]>
Date: Mon, 17 Jan 2005 14:13:39 -0700

Ben Harris wrote:
> SSH_MSG_CHANNEL_WINDOW_ADJUST can add at most 2^32-1 bytes to the 
> window, an implementation can send as many WINDOW_ADJUSTs as it wants.  
> This is a problem because it means that its peer has to keep track of an 
> arbitrarily-large window, and in particular one that can't be 
> represented by a 32-bit unsigned integer.  I doubt that this is the 
> intention of the spec, so I'd suggest the following change:
> 
> After:
> 

How about:

   After receiving this message, the recipient MAY send the given number
   of bytes more than it was previously allowed to send; the window size
   is incremented.  Implementations MUST correctly handle window sizes of
   up to 2^32 - 1.  The window MUST NOT be increased above 2^32 - 1
   bytes.

It is a little stronger than what you proposed, but I believe there are
already imcompatibilites with some implementations using a signed 32 bit
integer to represent this and others using an unsigned, so it does need
to be clarified.

- Joseph

---

From: Ben Harris <[email-masked]>
Date: Tue, 18 Jan 2005 00:16:44 +0000 (GMT)

>  up to 2^32 - 1.  The window MUST NOT be increased above 2^32 - 1

That sounds good to me, yes.  I'd insert "bytes" after the first instance 
of "2^31 - 1", giving:

   After receiving this message, the recipient MAY send the given number
   of bytes more than it was previously allowed to send; the window size
   is incremented.  Implementations MUST correctly handle window sizes of
   up to 2^32 - 1 bytes.  The window MUST NOT be increased above 2^32 - 1
   bytes.

-- 
Ben Harris