Last Modified: Apr 28, 2025
Affected Product(s):
BIG-IP TMOS
Known Affected Versions:
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, 11.6.1, 11.6.1 HF1, 11.6.1 HF2, 11.6.2, 11.6.2 HF1, 11.6.3, 11.6.3.1, 11.6.3.2, 11.6.3.3, 11.6.3.4, 11.6.4, 11.6.5, 11.6.5.1, 11.6.5.2, 11.6.5.3, 12.1.0, 12.1.0 HF1, 12.1.0 HF2, 12.1.1, 12.1.1 HF1, 12.1.1 HF2, 12.1.2, 12.1.2 HF1, 12.1.2 HF2, 12.1.3, 12.1.3.1, 12.1.3.2, 12.1.3.3, 12.1.3.4, 12.1.3.5, 13.0.0
Fixed In:
13.1.0, 13.0.0 HF1, 12.1.3.6
Opened: Nov 03, 2016 Severity: 2-Critical Related Article:
K31220138
Although BIG-IP generates random sequence numbers for use in protocol negotiation, it is possible to allocate a new number already in use by a phase-one ike-SA or a phase-two child-SA.
On sequence number collision, this might confuse an old SA, and probably never complete negotiation of a new SA. In addition, the system might crash if updating an old SA happened in a state where update is not expected.
When a sufficiently large number of tunnels are in use (e.g., numbering in thousands), odds of generating a duplicate sequence number is relatively high, given the number of random bits used to generate the number. More tunnels makes it more likely to occur.
None.
Now BIG-IP uses more random bits in generated sequence numbers, and it always checks whether a new sequence number is currently in use anywhere else before proceeding. Thus collisions cannot be generated in sequence number allocation. New numbers should always be guaranteed unique now.