Last Modified: Sep 13, 2023
Known Affected Versions:
11.6.2, 11.6.3, 184.108.40.206, 220.127.116.11, 12.0.0, 12.0.0 HF1, 12.1.0 HF1, 12.0.0 HF2, 12.1.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.1 HF1, 12.1.1 HF2, 12.1.2 HF1, 12.1.2 HF2, 12.1.0, 12.1.1, 12.1.2, 12.1.3, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11
14.0.0, 18.104.22.168, 22.214.171.124, 126.96.36.199
Opened: Jan 05, 2018 Severity: 3-Major Related Article:
Related Article: K07330445
When sending a software syncookie and there is no TCP timestamp option, tmm sends back TCP options like window scaling (WS), sackOK, etc. The values for these options are encoded in the timestamp field which is not sent. When the final ACK of the 3WHS arrives (without a timestamp), there is no way to know that the BIG-IP system negotiated the use of SACK, WS and other options that were encoded in the timestamp. This will leave the client believing that options are enabled and the BIG-IP believing that they are not.
In one known case, the client was Windows 7 which apparently disables timestamps by default. Users might experience poor connection performance because the client believed it was using WS, and that the BIG-IP system would scale up the advertised window. However, the BIG-IP system does not using WS in this case, and used the window size from the TCP header directly, causing the BIG-IP system to send small packets (believing it had filled the window) and wait for a response.
TCP timestamps are disabled by the client, or in the TCP profile.
Specifically prevent the WS issue by lowering the send_buffer_size and receive_window_size to less than or equal to 65535.
Added dependency between the window scale option and the timestamp option in a SYN/ACK response.