In RFC 4303 Section 3.3.3 states:
Note: If a receiver chooses to not enable anti-replay for an SA, then
the receiver SHOULD NOT negotiate ESN in an SA management protocol.
Use of ESN creates a need for the receiver to manage the anti-replay
window (in order to determine the correct value for the high-order
bits of the ESN, which are employed in the ICV computation), which is
generally contrary to the notion of disabling anti-replay for an SA.
This might have been good advise at the time (2005) but might not work
so well anymore these days.
A 100gbps card produces 100 * 1024 * 1024 *1024 / 8 / 1500 = 8947848
packets per second.
Without ESN, the IPsec SA has to rekey before it hits 2^32 (4294967296)
packets.
So that gives the IPsec SA a lifetime of 4294967296 / 8947848 = 480
seconds before it needs to have been rekeyed to precent running out of
sequence numbers.
The Nvidia ConnectX-7 can do 400gbps, so that would be a rekey within
every 120 seconds without ESN. I think this shows there is a use case
for ESN even if one would want no replay protection. I think it would
make sense to NOT disable ESN when replay detection is disabled.
But the question is how do current IPsec stacks keeps track of
the 64bit ESN numbers without the replay-window code. I believe,
but I'm not certain, that the Linux stack might not support ESN with
replay-window=0. I believe the nvidia driver also does not support this
for their packet offload engine. So current implementations might not
be able to support this.
Provided the stacks would do something to support ESN without doing
full replay protection, would it make sense to update this advise from
RFC 4303?
Currently with libreswan, we do disable ESN when a user configures
replay-window=0 (disable)
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
