On Wed, Jan 03, 2024 at 03:40:52PM -0500, Paul Wouters wrote: > > > 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.
I guess the question is, why would you want to have ESN (or sequence numbers in general) if the receiver does not check it? Of course, we need to make sure that we don't transmit more than 2^64 packets with the same key. But that counter can be local to the sender in this case. > 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. Linux does not support that, as this is not possible as long as the sender includes the high-order bits implicitly into the ICV computation. > 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? RFC 4303 Section 2.2.1 states: If a combined mode algorithm is employed, the algorithm choice determines whether the high-order ESN bits are transmitted or are included implicitly in the computation. So it might be possible to transmit the full 64 bit sequence number. But again, why would that make sense? The receiver will just ignore it if replay protection is disabled. Btw. The fact that ESN is contrary to disabling anti-replay means also that the advice to disable replay protection if you have problems with reordering due to multicore processing, QoS etc. is not such a good one. Steffen _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
