[IPsec] RFC 4303 ESN and replay protection entanglement
Paul Wouters writes: > 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 is SHOULD, not a MUST. You do have good reason to do ESN even with anti-replay turned off if your link speeds are that fast, so simply negotiate ESN, and implement your window code in such way that it can keep track of ESN window even when the anti-replay is turned off. I agree that this advise is bad, as ESN is enabled by the sender, but anti-replay is property of the receiver, thus there is no way of sender to know whether other end enables or disables the anti-replay. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] RFC 4303 ESN and replay protection entanglement
Hi, We are facing the same problem, too. We were planning to construct an email to the list, and we're happy to find that we're not alone. > -Original Message- > From: IPsec On Behalf Of Steffen Klassert > > > 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? The problem is that the sender doesn't know whether the receiver disables the anti-replay function. In RFC 4303, it says: If the receiver does not enable anti-replay for an SA, no inbound checks are performed on the Sequence Number. However, from the perspective of the sender, the default is to assume that anti-replay is enabled at the receiver. To avoid having the sender do unnecessary sequence number monitoring and SA setup (see section 3.3.3), if an SA establishment protocol is employed, the receiver SHOULD notify the sender, during SA establishment, if the receiver will not provide anti-replay protection. But we didn't find which Notify Message is used to notify the sender about this. Therefore, the sender will always assume the receiver enables the anti-replay function and do monitor the sequence number. The worse is that, when the sender tries to negotiate the ESN and the receiver disables the anti-replay, the receiver replies without including ESN-related payload, the sender won't know whether the receiver disables the anti-replay or enables the anti-replay but doesn't support ESN. In our thoughts, there may be two ways to solve this problem. One is to add a NOTIFY in IKEv2 about the receiver disables the anti-replay. The other is to update RFC 4303 to avoid entanglement between ESN and anti-replay. These two are not contradictory, so do them in the same time may also be the third way. Regards & Thanks！ Wei PAN (潘伟) > 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 > >
Re: [IPsec] RFC 4303 ESN and replay protection entanglement
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
[IPsec] RFC 4303 ESN and replay protection entanglement
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
