Bug ID 600732: IKEv1 racoon daemon dangling pointer from phase-one SA to deleted peer description

Last Modified: Mar 21, 2019

Bug Tracker

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

Known Affected Versions:
11.6.0, 11.6.0 HF1, 11.6.0 HF2, 11.6.0 HF3, 11.6.0 HF4, 11.6.0 HF5, 11.6.0 HF6, 11.6.0 HF7, 11.6.0 HF8, 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, 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

Fixed In:
13.0.0

Opened: Jun 22, 2016
Severity: 3-Major

Symptoms

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.

Impact

IKEv1 racoon daemon restarts, and then tunnel outage until new SAs are negotiated.

Conditions

When a v1 ike-peer is changed in any way while the racoon daemon actually has a valid security association in current use.

Workaround

No workaround is known at this time.

Fix Information

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.

Behavior Change