It is normal for packets to be reordered in IP networks, where QoS mechanisms (on the egress interface of the encrypting device
or on other network elements in the path), loadbalancing mechanisms or routing / path selection mechanisms (that send different
flows over different paths) are used.
The above diagram shows how anti-replay protection system causes problems when QoS reorders packets. The encryption engine
adds sequence numbers. After these numbers are added, packets are enqueued in egress queues depending on the application within
that packet. In the example in the diagram, packets are already present in the bandwidth queues (data and class-default),
when packets with the sequence numbers 101 and 102 are enqueued in the priority queue. The priority packets will be scheduled
first. When the decrypting device receives the packet with the sequence number 101, the history in the sliding window is moved
to 101, implying that the sliding window creates a history of sequence numbers 30-101. When the next packet which has the
sequence number 102 is received, the history in the sliding window is changed to 39-102. Now, that there are no more packets
in the priority queue, packets from one of the other queue is taken – for example, packet with the sequence number 1. Although
this is the first time the decrypting device is receiving a packet with sequence number 1, the packet is dropped because of
the history maintained in the sliding window.
Moving QoS scheduling before the encryption may solve the anti-replay issue but would render the QoS functionality useless.
In addition, scheduling needs to be driven by the congestion of the egress interface (or a shaper on that interface). Increasing
the size of the anti-replay window places a huge load load on the memory of the devices that handles this functionality.
Hence, the solution of maintaining multiple sequence number spaces per security association was introduced. The number spaces
would be aligned with the egress queuing scheme such that all packets in a given queue would receive a sequence number from
the same sequence number space. Since all packets within a sequence number space would go through the same queue, the possibility
of egress QoS causing reordering within those packets is eliminated. It is still possible (but unlikely) that reordering within
a number space could happen elsewhere in the network. If packets are tail dropped rather than enqueued out of sequence (not
out of order), sequence numbers will still be received on the receiving side. Hence, we still maintain a history window per
sequence number space but that history is considerably shorter.
The image shows that the sequence number consists of two parts, namely the selector and the sequence number. The receiving
side would use the selector to choose the correct history to use and the sequence number would operate as always.
IPSec Anti-Replay feature does not support Group Encrypted Transport VPN (GETVPN) when multiple sequence number space (multi-SNS)