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.4,, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0,,,,,,,,, 13.1.1,,,,, 13.1.3,, 14.0.0,,,,,, 14.0.1

Fixed In:
14.1.0,,, 12.1.5

Opened: Jul 26, 2018
Severity: 3-Major


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.


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


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


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