Home / server / Questions / 1019447
In Process
jhourback
Asked: 2020-06-01 08:32:36 +0800 CST

On a TCP connection, can the recipient control the TCP window size that the sender uses?

  • 772

The TCP window size is the amount of data that the sender will send before waiting for a TCP ack. Does the receiver have a way to control this (e.g., as part of the TCP handshake), or is it only the sender who can control?

networking tcp tcp-window-scaling

1 Answers

  1. Yes the receiver can dynamically control the TCP window size, all along the TCP communication, not only at handshake, as stated in RFC 793:

    Flow Control:

    TCP provides a means for the receiver to govern the amount of data sent by the sender. This is achieved by returning a "window" with every ACK indicating a range of acceptable sequence numbers beyond the last segment successfully received. The window indicates an allowed number of octets that the sender may transmit before receiving further permission.

    Since you added , the TCP window scaling is just a multiplier used to overcome the initial limit of 64k for the maximum window size. This is negotiated using TCP options in the initial TCP handshake, as described in RFC 7323:

    The Window Scale option negotiates fundamental parameters of the TCP session. Therefore, it is only sent during the initial handshake. Furthermore, the Window Scale option will be sent in a <SYN,ACK> segment only if the corresponding option was received in the initial <SYN> segment.

    ....

    This option MAY be sent in an initial <SYN> segment (i.e., a segment
    with the SYN bit on and the ACK bit off). If a Window Scale option
    was received in the initial <SYN> segment, then this option MAY be
    sent in the <SYN,ACK> segment. A Window Scale option in a segment
    without a SYN bit MUST be ignored.

    So this scaling factor can't be changed later. It's described further there:

    The window scale extension expands the definition of the TCP window
    to 30 bits and then uses an implicit scale factor to carry this
    30-bit value in the 16-bit window field of the TCP header (SEG.WND in [RFC0793]). The exponent of the scale factor is carried in a TCP
    option, Window Scale. This option is sent only in a segment (a segment with the SYN bit on), hence the window scale is fixed in each direction when a connection is opened.

    Here's an example of extreme and abnormal window control "abuse" from the receiver invented to delay scans used to propagate worms: Linux iptables' TARPIT add-on target, based on LaBrea's tar pit (Jim McClurg, 2001 PDF):

    TARPIT
    Captures and holds incoming TCP connections using no local per-connection resources.
    [...] play along like a listening server, but aside from sending an ACK or RST, no data is sent. [...]
    --tarpit
    This mode completes a connection with the attacker but limits the window size to 0, thus keeping the attacker waiting long periods of time. While he is maintaining state of the connection and trying to continue every 60-240 seconds, we keep none, so it is very lightweight. Attempts to close the connection are ignored, forcing the remote side to time out the connection in 12-24 minutes. This mode is the default.

    • 5