Last Modified: Jul 13, 2024
Affected Product(s):
BIG-IP TMOS
Known Affected Versions:
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.0.0, 12.0.0 HF1, 12.0.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 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
Fixed In:
13.0.0, 12.1.5.3
Opened: Jun 22, 2016 Severity: 3-Major
The IKEv1 racoon daemon can crash when a security association (SA) is deleted (which can be done either explicitly on the command line, or indirectly by changing the ike-peer definition in config via tmsh). Usually this crash also requires that the ike-peer be altered or removed at the same time. Note: Merely altering a v1 ike-peer causes the racoon daemon to first delete the old ike-peer, and then add a new one. So 'modify' effectively means 'delete' in this bug context.
IKEv1 racoon daemon restarts, and then tunnel outage until new SAs are negotiated.
When a v1 ike-peer is changed in any way while the racoon daemon actually has a valid security association in current use.
No workaround is known at this time.
When a v1 ike-peer changes, which causes the racoon daemon to delete and then redefine the peer, existing security associations are also deleted (because they were only valid for the last definition). During the process of tearing things down, it was possible for a security association to access the old, destroyed ike-peer during a late-stage followup action. This is now prevented.