Last Modified: Oct 16, 2023
Affected Product(s):
BIG-IP TMOS
Known Affected Versions:
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, 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.5, 14.1.0.6, 14.1.2, 14.1.2.1, 14.1.2.2, 15.0.0, 15.0.1, 15.0.1.1, 15.0.1.2, 15.0.1.3
Fixed In:
15.1.0, 15.0.1.4, 14.1.2.3, 13.1.3.4
Opened: Mar 19, 2019 Severity: 2-Critical
Rekey with non BIG-IP systems can fail when a response contains a VENDOR_ID payload.
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.
- 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.
No workaround is known at this time.
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.