static struct xfrm_link xfrm_dispatch[XFRM_NR_MSGTYPES]
xfrm_add_sa(struct nlattr **attrs)
xfrm_alloc_replay_state_esn(struct nlattr *rta)
return (char *) nla + NLA_HDRLEN;
struct xfrm_replay_state_esn *replay_esn;
x->props.replay_window = sa->sadb_sa_replay;
static pfkey_handler pfkey_funcs[SADB_MAX + 1]
pfkey_msg2xfrm_state or xfrm_state_clone(CONFIG_XFRM_MIGRATE)
[strongSwan] anti-replay window size?
currently the kernel interface method add_sa() of the IKEv2 daemon
sets the replay window size to a constant value of 32:
whereas in the kernel interface method netlink_add_sa() of the IKEv1
daemon the size is configurable:
but in kernel.c where netlink_add_sa() is called, the value is set
invariably to 32,
Strongswan also limits the maximum window size to 64 in pfkey_prop_parse().
IPSec Anti-Replay Window: Expanding and Disabling - Cisco Systems
IPsec Anti-Replay Window
Cisco IPsec authentication provides anti-replay protection against an attacker duplicating encrypted packets by assigning a unique sequence number to each encrypted packet. (Security association [SA] anti-replay is a security service in which the receiver can reject old or duplicate packets to protect itself against replay attacks.) The decryptor checks off the sequence numbers that it has seen before. The encryptor assigns sequence numbers in an increasing order. The decryptor remembers the value X of the highest sequence number that it has already seen. N is the window size, and the decryptor also remembers whether it has seen packets having sequence numbers from X-N+1 through X. Any packet with the sequence number X-N is discarded. Currently, N is set at 64, so only 64 packets can be tracked by the decryptor.
At times, however, the 64-packet window size is not sufficient. For example, Cisco quality of service (QoS) gives priority to high-priority packets, which could cause some low-priority packets to be discarded even though they could be one of the last 64 packets received by the decryptor. The IPsec Anti-Replay Window: Expanding and Disabling feature allows you to expand the window size, allowing the decryptor to keep track of more than 64 packets.
Increasing the anti-replay window size has no impact on throughput and security. The impact on memory is insignificant because only an extra 128 bytes per incoming IPsec SA is needed to store the sequence number on the decryptor. It is recommended that you use the full 1024 window size to eliminate any future anti-replay problems.