Bug ID 636818: IKEv1 DELETE payload can use wrong source IP address for floating IPs

Last Modified: Jul 13, 2024

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

Known Affected Versions:
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, 12.1.3.6, 12.1.3.7, 12.1.4, 12.1.4.1, 12.1.5, 12.1.5.1, 12.1.5.2, 12.1.5.3, 12.1.6, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0, 13.1.0.1, 13.1.0.2, 13.1.0.3, 13.1.0.4, 13.1.0.5, 13.1.0.6, 13.1.0.7, 13.1.0.8, 13.1.1, 13.1.1.2, 13.1.1.3, 13.1.1.4, 13.1.1.5, 13.1.3, 13.1.3.1, 13.1.3.2, 13.1.3.3, 13.1.3.4, 13.1.3.5, 13.1.3.6, 13.1.4, 13.1.4.1, 13.1.5, 13.1.5.1

Opened: Jan 04, 2017

Severity: 3-Major

Symptoms

When a BIG-IP system uses a floating IP to establish an IKEv1 IPsec tunnel, and then the Security Association (SA) is deleted, under rare conditions the ISAKMP notification will use a non-floating IP as the source address.

Impact

The IKEv1 racoon daemon now deletes an SA without requiring the source IP to be the correct peer. It is possible that this will allow a random peer to delete another peer's security associations.

Conditions

Define a tunnel with floating IP addresses, then toggle version between IKEv1 and IKEv2.

Workaround

None.

Fix Information

None

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips