Last Modified: Jul 24, 2024
Affected Product(s):
BIG-IP LTM
Known Affected Versions:
15.1.0, 15.1.0.1, 15.1.0.2, 15.1.0.3, 15.1.0.4, 15.1.0.5, 15.1.1, 15.1.2, 15.1.2.1, 15.1.3, 15.1.3.1, 15.1.4, 15.1.4.1, 15.1.5, 15.1.5.1, 15.1.6, 15.1.6.1, 15.1.7, 15.1.8, 15.1.8.1, 15.1.8.2, 15.1.9, 15.1.9.1, 15.1.10, 15.1.10.2, 15.1.10.3, 15.1.10.4, 16.1.0, 16.1.1, 16.1.2, 16.1.2.1, 16.1.2.2, 16.1.3, 16.1.3.1, 16.1.3.2, 16.1.3.3, 16.1.3.4, 16.1.3.5, 16.1.4, 16.1.4.1, 16.1.4.2, 16.1.4.3, 16.1.5, 17.0.0, 17.0.0.1, 17.0.0.2
Fixed In:
17.1.0
Opened: Sep 08, 2021 Severity: 2-Critical
A complete TCP close requires cooperation from client and server applications. A client initiated close may not immediately elicit a corresponding server close. The server application may continue sending data, indefinitely delaying closing the socket. When the socket is closed, the kernel must continue flushing send buffers before continuing the TCP close handshake. Even when the client does not need to receive remaining server data, it must wait for the server to send the full response before the connection is closed.
Even though the client intends to close the socket immediately, the socket stays open while the server sends the full response leading to a long delay in closing the socket and wasting bandwidth.
-- The virtual server uses a FastL4 profile. -- The client attempts to close the socket. -- While the backend server receives the client close request (TCP FIN), the server application continues sending the complete response.
None
The feature is enabled with the FastL4 profile property reset-on-client-fin. When enabled on a fastL4 profile, on a client-initiated close, bigproto will abort the connection, sending a reset to the client and server. For loose-close (nPath) connections, a reset is sent only to the server. Sending a reset to the client in this case is not useful since the BIG-IP does not have the latest SEQ number from the server. The client will get resets when it sends ACKs through the BIG-IP.