Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[SRX] Bad SPI event observed sometimes during IPsec rekey process

0

0

Article ID: KB33415 KB Last Updated: 12 Apr 2019Version: 1.0
Summary:

For security purposes, VPN peers refresh the encryption key every hour, by default, after establishing the IPsec tunnel. This is called the "rekey" process. During the rekey process, users might see a bad SPI event and observe a few packet drops going through the IPsec tunnel.

This article gives the reason for the bad SPI events to occur and if any action is required.

Note: A Security Parameter Index (SPI) is an arbitrary value that uniquely identifies which SA to use at the receiving host. The sending host uses the SPI to identify and select which SA to use to secure every packet. The receiving host uses the SPI to identify and select the encryption algorithm and key used to decrypt packets.

 

Symptoms:

Topology

[SRX340](ge-0/0/0) --- <VPN> -- [SRX240H2]
 

Below is an example output of a syslog message and the related command output when a bad SPI event occurs.

Note: This output is confirmed on SRX340 that is running Junos OS 15.1X49-D140.3.

IPsec SA Status

Users will observe old/new SPI entries simultaneously during the rekey process.

root@jtac-srx340-r2021> show security ipsec security-associations | refresh 1

---(refreshed at 2019-01-16 14:32:40 JST)---
Total active tunnels: 1
ID    Algorithm       SPI      Life:sec/kb  Mon lsys Port  Gateway
<131073 ESP:aes-cbc-256/sha256 aea6b37 97/ unlim - root 500 10.51.0.253
>131073 ESP:aes-cbc-256/sha256 85426da1 97/ unlim - root 500 10.51.0.253
---(refreshed at 2019-01-16 14:32:44 JST)---
Total active tunnels: 1
ID    Algorithm       SPI      Life:sec/kb  Mon lsys Port  Gateway
<131073 ESP:aes-cbc-256/sha256 aea6b37 expir/expir - root 500 10.51.0.253 << OLD SPI
>131073 ESP:aes-cbc-256/sha256 85426da1 expir/expir - root 500 10.51.0.253 << OLD SPI 
<131073 ESP:aes-cbc-256/sha256 398bbc8d 298/ unlim - root 500 10.51.0.253 << NEW SPI
>131073 ESP:aes-cbc-256/sha256 eba754bf 298/ unlim - root 500 10.51.0.253 << NEW SPI
---(refreshed at 2019-01-16 14:32:48 JST)---
Total active tunnels: 1
ID    Algorithm       SPI      Life:sec/kb  Mon lsys Port  Gateway
<131073 ESP:aes-cbc-256/sha256 398bbc8d 295/ unlim - root 500 10.51.0.253
>131073 ESP:aes-cbc-256/sha256 eba754bf 295/ unlim - root 500 10.51.0.253
 

Syslog Output Example

Users may observe bad SPI events towards the ESP packet with the new SPI.

Note: SPI 0x398bbc8d is the new SPI, which will be used after completion of the rekey process.

Jan 16 14:32:43  jtac-srx340-r2021 RT_IPSEC: RT_IPSEC_BAD_SPI: IPSec tunnel on int ge-0/0/0.0 with tunnel ID 0x20001 received a packet with a bad SPI.
10.51.0.253->10.51.0.193/156, ESP, SPI 0x398bbc8d, SEQ 0x1.
 

Output of show interfaces detail

Users may observe "No SA" in the incoming SPI counter value increment. This is related to the above bad SPI event.

show interfaces ge-0/0/0 detail | match "No SA" | refresh 3

---(refreshed at 2019-01-16 14:32:41 JST)---
No SA for incoming SPI:            0
---(refreshed at 2019-01-16 14:32:44 JST)---
No SA for incoming SPI:            1  << count up

 

Cause:

At the time of the rekey process, the SRX device installs the new key into the data plane after negotiating the SA with the VPN peer.

The timing of this installation can be slightly different between VPN devices. Sometimes, one device may install the new key faster than the other device and send the ESP packet with the new SPI. When the above ESP packet arrives, however, the other device might not be ready to accept it.

Due to this, a "bad SPI" event is sometimes logged on the SRX device.

 

Solution:

This is by design. The installation timing of the new key can be slightly different between the VPN devices, depending on the platform, resource usage state, and so on.

This bad SPI event is frequently seen in lab environments where VPN devices are located very close to each other. In this situation, traffic from one VPN device can reach the other device very fast.

On the other hand, real network environments are likely to have more distance, which will help the SRX device install the new key before receiving the new ESP packet. As a result, the chances of encountering this bad SPI message decrease.

 

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search