Last Modified: Sep 13, 2023
Known Affected Versions:
12.1.1, 12.1.2, 12.1.3, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 13.1.0, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 13.1.1, 126.96.36.199, 188.8.131.52
14.0.0, 184.108.40.206, 220.127.116.11
Opened: Nov 06, 2017 Severity: 3-Major
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.
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.
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.
Try to configure other IPsec implementations to avoid deleting duplicate IKE-SAs.
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.