Re: Still confused about window adjust :-(

On Fri, 13 Jul 2007 16:28:05 +0100, Simon Tatham wrote:

H.K. Kingston-Smith <HKK-S@xxxxxxxxx> wrote:
Thanks for your answers, which are most informative. However, I believe
that you are not addressing my two core issues here. Forget about
partial packets for a moment. Assuming that we have just sent a
complete SSH_MSG_CHANNEL_DATA packet of total length L, containing a
data string of length S, S < L, how does the window size change after
this? Does it decrease by S bytes? By L bytes? Something else?

Window size is entirely about the actual channel data, not about the SSH
packets in which it is encapsulated, so it decreases by S bytes. (Was
this not already obvious from our previous discussions?)

Let me quote the standard again (RFC 4253, section 5.2):

Data transfer is done with messages of the following type.

byte SSH_MSG_CHANNEL_DATA
uint32 recipient channel
string data

The maximum amount of data allowed is determined by the maximum
packet size for the channel, and the current window size, whichever
is smaller. The window size is decremented by the amount of data
sent. Both parties MAY ignore all extra data sent after the allowed
window is empty.

The second sentence from the end is, in my view, ambiguous. What does
"the amount of data sent" mean? The total length of the packet, or the
length of the data field? I am happy to acknowledge your expertise and
accept your interpretation - after all, that's what PuTTY must be doing,
and I know that it works.


About partial packets now. How can the SSH layer be sure that it will
get at least one complete SSH packet when reading data from the
network?

Indeed, it may not get a complete packet when doing a single network
read. So it continues to do network reads until it has managed to put
together a complete packet, and then it decrypts that packet, verifies
the MAC, and acts on it.

The receiving SSH layer doesn't need to look at network read boundaries.
It works solely on the basis of the stream of _data_ received. The first
8 bytes received (or more, depending on the cipher block size) are
decrypted to find the packet length and padding values, which determines
the total length of the current packet. Then the receiver continues to
read more data from the network, waiting if necessary, until it has that
much; it can then decrypt the rest of the packet and verify the MAC.
Then the next 8 bytes it receives are decrypted to find the next packet
length, and so on. So the only criterion is that the entire stream of
data sent down the SSH connection must be composed of complete packets
concatenated end-to-end. Anything else will confuse the decoder.

I violently agree.

So if you really wanted to, you _could_ send part of a packet and
deliberately hold back the rest of it to send later; but if you did
that, then you would be committed to sending the rest of it before you
sent _anything else at all_.

Correct.

Also, the receiver wouldn't be able to act
on the partial packet, because it would be a security hazard for it to
do so without verifying the MAC.

Absolutely. In the general case, it would not be able to anyway,
for the partial packet would not be likely to end right at the beginning
of the MAC.

So while it's technically _legal_, it's also totally pointless.

Well, that's an implementation issue, I guess.




.

Relevant Pages

  • alt.2600 FAQ Revision .014 (2/4)
    ... One type of firewall is the packet filtering firewall. ... Dropping packets instead of rejecting them greatly increases the time required to scan your network. ... Port scanning UDP ports is much slower than port scanning TCP ports. ... Chartreuse Use the electricity from your phone line Cheese Connect two phones to create a diverter Chrome Manipulate Traffic Signals by Remote Control ...
    (alt.2600)
  • RE: Freebsd Theme Song
    ... from the network into the ethernet receiver. ... It takes a certain amount of time to get the packet out of ... At low data rates polling is less ... >Subject: Re: Freebsd Theme Song ...
    (freebsd-questions)
  • Re: [PATCH 1/1] network memory allocator.
    ... Kevent network AIO uses usual alloc_skb, naio is called when packet is ... data and main system can work with that free memory. ... You do not see the point of network tree allocator. ...
    (Linux-Kernel)
  • Re: very slow convergence of ntp to correct time.
    ... Many years ago the Proteon routers dropped the first packet ... David> after the cache timed out; ... cause issues for others when they are reconfiguring part of the network. ...
    (comp.protocols.time.ntp)
  • [TOOL] IPTraf, IP Network Monitoring Software
    ... IPTraf is a console-based network statistics utility for Linux. ... LAN station packet and byte counts. ... Includes TCP flag information, packet and byte counts, ... * General and detailed interface statistics showing IP, TCP, UDP, ICMP, ...
    (Securiteam)