Bug ID 738445: IKEv1 handles INVALID-SPI incorrectly in parsing SPI and in phase 2 lookup

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, 12.1.3.6, 12.1.3.7, 12.1.4, 12.1.4.1, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 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, 13.1.1.4, 13.1.1.5, 13.1.3, 13.1.3.1, 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

Fixed In:
14.1.0, 14.0.1.1, 13.1.3.2, 12.1.5

Opened: Jul 26, 2018
Severity: 3-Major

Symptoms

INVALID_SPI notification does not delete the IPsec-SA with the SPI value that appears in the notify payload. This occurs because the handler of INVALID-SPI notifications performs the following incorrect actions: -- Fetches SPI from payload as if it's a string, rather than the network byte order integer it actually is. -- Attempts phase 2 lookup via selector ID (reqid) rather than SPI. Either alone prevents finding the SA to delete.

Impact

The IPsec-SA with that SPI cannot be found and is not deleted.

Conditions

An IKEv1 IPsec peer sends an INVALID-SPI notification to the BIG-IP system.

Workaround

From the BIG-IP command line, you can still manually delete any IPsec-SA, including the invalid SPI, using the following command: # tmsh delete net ipsec ipsec-sa spi <spi number>

Fix Information

SPI is now extracted correctly from the payload as a binary integer, and the phase 2 SA lookup is done with a proper SPI search, which also requires a match in the peer address.

Behavior Change