Bug ID 626861: Ensure unique IKEv2 sequence numbers

Last Modified: Oct 16, 2023

Affected Product(s):
BIG-IP TMOS(all modules)

Known Affected Versions:
11.6.0, 11.6.1, 11.6.2, 11.6.3,,,,, 11.6.4, 11.6.5,,,, 12.1.0, 12.1.1, 12.1.2, 12.1.3,,,,,, 13.0.0

Fixed In:
13.1.0, 13.0.0 HF1,

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.



Fix Information

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.

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips