Bug ID 693106: IKEv1 newest established phase-one SAs should be found first in a search

Last Modified: Nov 07, 2022

Bug Tracker

Affected Product:  See more info
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, 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

Fixed In:
14.0.0, 13.1.1.4, 12.1.3.6

Opened: Nov 06, 2017
Severity: 3-Major

Symptoms

Some IKEv1 implementations might delete "duplicate" phase one IKE SAs, even though not yet expired, keeping only the most recently negotiated IKE-SA. If this happens, and BIG-IP uses an older SA to negotiate, then phase two negotiation can fail. If at all possible, we want BIG-IP to prefer the newest SA for a given remote peer. If a peer deletes a second SA without notifying BigIP, preferring a newest SA may mitigate the problem.

Impact

If BIG-IP picks a mature IKE-SA for phase two negotiation that has been deleted by a peer, then BIG-IP's attempt to negotiate a new phase two SA will fail.

Conditions

The situation seems mostly easily arranged when two peers initiate a new IKE-SA at the same time, so that both are negotiated concurrently, since neither has yet been established. Afterward, there are two IKE-SAs for one remote peer, nearly the same age. If the other end deletes a duplicate without sending a DELETE message to BigIP, we might accidently use the older SA of a pair.

Workaround

Try to configure other IPsec implementations to avoid deleting duplicate IKE-SAs.

Fix Information

At the momenet a new IKE-SA is established, we now move that SA to the head of the hashmap bucket searched for that remote peer in the future. This makes us more likely to use the newest SA from the perspective of a remote peer, the next time we initiate another phase two negotiation ourselves.

Behavior Change