IETF-SSH archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: maximum size of packets from client to server
> 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
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Home |
Main Index |
Thread Index |
Old Index