Question about the SSHv2.0 protocol specification

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
    I am reading the SSHv2.0 RFCs in order to gain a deeper  
understanding of the SSH foundations. I have come across something I am  
finding a bit intriguing; hopefully somebody well versed into the  
intricacies of the RFCs might help me here.

    IN RFC 4254, section 5.1, the SSH_MSG_CHANNEL_OPEN is described.  
One of the pieces of information conveyed in this message is the maximum  
size of packets to be exchanged between client and server. The RFC then  
says that this can be used to select smaller maximum packet sizes for  
interactive sessions.

    If I understand the RFC correctly, that is true for the client,  
but not by the server. The client sends an SSH_MSG_CHANNEL_OPEN message  
proposing a maximum packet size, and the server responds with  
SSH_MSG_CHANNEL_OPEN_CONFIRMATION where it specifies the maximum packet  
size that it will accept.

    Now at that point the client obviously must know what type of  
session it wishes to establish - therefore it can select the maximum  
packet size accordingly. However, the server will still not have the  
session type information - which will be conveyed by the client when  
sending an SSH_MSG_CHANNEL_REQUEST message later on.

    Is this a correct reading of the RFC? If so, is the implication  
that the server just can't make a decision concerning the maximum packet  
size that it will accept on the basis of the type of session that the  
client is trying to establish, or is there a way around this?

Re: Question about the SSHv2.0 protocol specification

Quoted text here. Click to load it
Quoted text here. Click to load it

It's not so much 'proposing': each side specifies the maximum packet
size _it_ is willing to accept. The max packet size in the client's
CHANNEL_OPEN is not a _proposal_; it's a hard limit that the server
must honour when sending channel data to the client. And conversely,
the max packet size in CHANNEL_OPEN_CONFIRMATION is a hard limit that
the client must honour when sending channel data to the server.

(Incidentally, client and server aren't always that way round: some
channel types, e.g. 'forwarded-tcpip' and agent forwarding, are opened
by the server.)

Quoted text here. Click to load it

Yes and no. For some channel types (e.g. 'direct-tcpip') the channel
type is given as part of the CHANNEL_OPEN. It's only the 'session'
channel type where important auxiliary type information is deferred
until the CHANNEL_REQUEST that says whether you're launching a shell
or a subsystem or what.

Quoted text here. Click to load it

Bear in mind that interactive sessions generally transmit individual
keystrokes (plus occasional pastes) from client to server, so the
packet size limit in the client->server direction will not generally
be attained! So the max packet size specified by the client for the
server->client side is the interesting one, if either one is.

Personally I don't really see what the big deal is with max packet
size anyway. If I have a lot of data to send to the other end and it's
specified a too-small max packet, then I have to split it up into
multiple packets which I send in rapid succession, but what difference
does that make to anything? A few bytes of overhead more or less is
about all. _Window_ size is actually important, because that forces me
to buffer more stuff at my end and push back on the sender if it's not
going through fast enough, but max packet size is just a matter of
whether or not I put an arbitrary packet boundary in the middle of my
data, but I send basically the same data either way, so who cares?
Simon Tatham         "Thieves respect property; they only wish the property to

Site Timeline