When two IPsec chassis are configured in a stateful redundancy, the IPsec state information is periodically synchronized from active to standby, as demonstrated in Figure 2 .

However, this synchronization is not always perfectly accurate, especially the ESP/AH sequence number. There is often a calculated delay in the process, which can lead to inconsistency (information mismatch) between the active and standby during synchronizations. This can potentially cause packet loss or delayed traffic during failover. Considering there is a new sequence number for each ESP/AH packet, and if the peer is processing a high-throughput traffic, the packet loss can become significant. In a way, the amount of packet loss is directly proportional to both synchronization interval and the throughput.

Compared to Section 2.1, here the synchronizing information is between line card levels within the same chassis, and communication must be done between line cards via the backplane. However, if the gateway is capable of high-throughput traffic, there will be a significant sequence number mismatch between each update.

One of the existing solutions is that whenever a switchover occurs, the newly active device initiates a Phase 2 rekey immediately [8] (Here, Stateful Redundancy can be Line card level or node level), triggered by the redundant side. Once the new Phase2 Security Association (SA) is established, the sequence number will be in sync again.

Potential Issues with (3.1) rekey initiated by the redundant Gateway is that in most cases, the redundancy peer will be the aggregation gateway handles millions of IPsec tunnels. This can lead to significant processing and traffic issues, especially when all these tunnels attempt to rekey within a short period. The large volume of tunnels being rekeyed simultaneously can overwhelm the system, potentially causing delays, performance degradation, or even packet/tunnel loss during the rekeying process.

Disabling anti-replay or expanding anti-replay window [9] protection can help resolve the issue of out-of-sequence ESP/AH packet drops on the local side during a switchover in a redundant IPsec setup, specifically for data traffic. When anti-replay is disabled, the local peer does not perform sequence number checks, and it may accept out-of-sequence packets that would otherwise be discarded. This can help avoid packet drops caused by sequence number mismatches during failover or switchover events.

Potential Issues with (3.2) expanding anti-replay windows are that it makes the window too large and takes time to detect an attack. Disabling anti-replay window makes the tunnel susceptible to replay attacks as well as the receiver may accept out-of-order packets that go undetected. This can cause significant issues for applications like VoIP, video conferencing, etc.

If only out-of-sequence ESP/AH packets are received on the inbound Security Association (SA) of the standalone IPsec peer for a defined interval or packet threshold—without any in-sequence packet observed during that period—this condition may indicate a remote Stateful Switchover event, it indicates a sequence number synchronization issue on the remote stateful peer. If it is a real anti-replay attack, there is a chance that some legitimate traffic also be received in between from the actual remote peer.

There is a scope to improve or add more ways to detect the stateful switchover by the standalone peer.

The proposed solution is to introduce functionality on the standalone side to initiate a Phase2 rekey (Phase2 rekey in the case of IKEv1, and Child SA rekey in the case of IKEv2) once a switchover is detected on the stateful peer.

After reaching maximum induced rekey count within a certain time, there should be a quiet period during which the standalone device does not initiate any further induced rekey based on the aforementioned condition. During this period, standalone peers should ignore any pattern that matches the stateful switchover if identified. Once the quiet period expires, this timer should be reset, allowing the device to resume its operation based on the reception of out-of-sequence packets. This ensures that the system can recover from transient issues while maintaining security by filtering out potential replay attacks as well as a fault that causes the remote to do frequent switchovers.

In this approach, all tunnels in the newly active stateful peer need to initiate a Phase2/Child SA rekey [8] , which is unnecessary and creates a processing spike in the gateway router, irrespective of whether the remote is facing out-of-sequence drops or not. Even if the redundant gateway tries to identify which peers are experiencing out-of-sequence drops, it’s impossible. There are several other factors that make a tunnel unaffected by out-of-sequence traffic issues, such as the timing of switchover, comparatively lower traffic rates, etc. An induced rekey for those tunnels is unnecessary.

Whereas the proposed solution requires only the peers that receive out-of-sequence IPsec packets to initiate the rekey. Tunnels that fall within the sequence number windowing mechanism do not need to be rekeyed.

Disabling anti-replay can affect real-time traffic, such as voice and video, which may experience increased jitter as well as susceptible to anti-replay attacks. With the proposed solution in Section 3, the IPsec devices can still enable anti-replay protection, effectively avoiding replay attacks while addressing the issue of out-of-sequence packets issue due to switchover.