Bug ID 554761: Unexpected handling of TCP timestamps under syncookie protection.

Last Modified: Apr 10, 2019

Bug Tracker

Affected Product:  See more info
BIG-IP All(all modules)

Known Affected Versions:
10.2.4, 11.0.0, 11.1.0, 11.2.0, 11.2.1, 11.3.0, 11.4.0, 11.4.1, 11.5.0, 11.5.1, 11.5.1 HF1, 11.5.1 HF10, 11.5.1 HF11, 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.2, 11.5.2 HF1, 11.5.3, 11.5.3 HF1, 11.5.3 HF2, 11.5.4, 11.5.4 HF1, 11.5.4 HF2, 11.6.0, 11.6.0 HF1, 11.6.0 HF2, 11.6.0 HF3, 11.6.0 HF4, 11.6.0 HF5, 11.6.0 HF6, 11.6.0 HF7, 11.6.0 HF8, 12.0.0, 12.0.0 HF1, 12.0.0 HF2

Fixed In:
13.0.0, 12.1.0, 12.0.0 HF3, 11.6.1, 11.5.4 HF3

Opened: Oct 28, 2015
Severity: 3-Major
Related AskF5 Article:
K53433830

Symptoms

The BIG-IP system experiences intermittent packet drops. Despite being negotiated during TCP handshake, the BIG-IP system fails to present timestamp option in subsequent segments. The BIG-IP system calculates invalid round trip time immediately after handshake, which might result in delayed retransmissions.

Impact

Connection might be reset by remote TCP stack (e.g., NetBSD and FreeBSD), which requires timestamps to be maintained once negotiated. Retransmission timeout (RTO) value may be skewed. Segments that are subject to RTO might take up to 64 segments to retransmit.

Conditions

This occurs when the following conditions are met: - Virtual server configured with a TCP profile with timestamps enabled. - The syncookie mode has been activated. - Clients that support timestamps.

Workaround

Choose or create a TCP profile that has timestamps disabled.

Fix Information

TCP Timestamps are now maintained on all negotiated flows.

Behavior Change