Last Modified: Oct 16, 2023
Affected Product(s):
BIG-IP LTM
Known Affected Versions:
11.5.1 HF1, 11.5.1 HF2, 11.5.1 HF3, 11.5.1 HF4, 11.5.1 HF5, 11.5.1 HF6, 11.5.1 HF7, 11.5.1 HF8, 11.5.1 HF9, 11.5.1 HF10, 11.5.1 HF11, 11.5.2 HF1, 11.5.3 HF1, 11.5.3 HF2, 11.5.4 HF1, 11.5.4 HF2, 11.5.4 HF3, 11.5.4 HF4, 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
Fixed In:
13.0.0, 12.1.2, 11.6.1 HF1
Opened: Jan 08, 2016 Severity: 3-Major
ICAP with OneConnect sometimes initiates a new ICAP request (REQMOD or RESPMOD) on the server connection while a previous response on the same connection is still being streamed from the ICAP server. This can cause the server to append the new response after the end of the previous response, in the same packet.
The connection used by the interrupted transaction is returned to the pool for reuse, potentially resulting in a new ICAP transaction beginning before the end of the interrupted one, and its response may be concatenated to the incomplete tail of the first one. OneConnect is unable to separate the contiguous ICAP responses whose boundary is within a packet. All the packet payload goes to the first ICAP transaction, and any payload after the terminating chunk is discarded. Thus the beginning of the second response is lost and its header parser gets confused. It keeps waiting for more data and rescanning the entire response, resulting in increasing CPU use up to 100% until the connection is aborted.
There is a 'oneconnect' profile on the internal virtual server along with the 'icap' profile. Triggered by a disconnection of the IVS by the parent HTTP virtual server, before the ICAP transaction is complete. This can happen for a number of reasons, such as an error in detected on the HTTP virtual server, or an HTTP::respond iRule that replaces an IVS response in progress.
Remove OneConnect.
Big-IP with ICAP and OneConnect never reuses a server connection while a previous ICAP transaction is still in progress. Whenever the IVS disconnects prior to completion of an ICAP transaction, the connection is not pooled for reuse.