Bug ID 762205: IKEv2 rekey fails to recognize VENDOR_ID payload when it appears

Last Modified: Dec 13, 2019

Bug Tracker

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

Known Affected Versions:
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.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, 14.0.0, 14.0.0.1, 14.0.0.2, 14.0.0.3, 14.0.0.4, 14.0.0.5, 14.0.1, 14.0.1.1, 14.1.0, 14.1.0.1, 14.1.0.2, 14.1.0.3, 14.1.0.4, 14.1.0.5, 14.1.0.6, 14.1.2, 14.1.2.1, 14.1.2.2, 15.0.0, 15.0.1

Fixed In:
15.1.0

Opened: Mar 19, 2019
Severity: 2-Critical

Symptoms

Rekey with non BIG-IP systems can fail when a response contains a VENDOR_ID payload.

Impact

BIG-IP as the initiator of rekey drops the rekey negotiation without making further progress when the responder included a VENDOR_ID payload in a response. This will result in deleting the SA for good when the hard lifetime expires, causing a tunnel outage.

Conditions

- IKEv2 Responder sends VENDOR_ID payload in rekey response. - The ipsec.log misleadingly reports: [I] [PROTO_ERR]: unexpected critical payload (type 43) Note: This message may be correctly present under other conditions, with different type constants not equal to 43.

Workaround

No workaround is known at this time.

Fix Information

Handling of payload types during rekey will now ignore VENDOR_ID when it appears, the same way we ignore VENDOR_ID in other messages during IKE negotiation.

Behavior Change