Hi Wei Pan, On Sun, Nov 03, 2024 at 03:50:26PM +0000, Panwei (William) wrote: > Hi Scott, > > Thank you very much for your comments. > > What you suggested is actually we proposed in draft v00. In our last version, > the notification only contains the status of replay protection, and after > both peers exchanged this notification, they can choose not to do the > sequence number monitoring. > > But we think someone may still want to use ESN while prefer disabling > anti-replay for reasons like QoS and others. And there are cases that not > both peers will disable anti-replay. So we try to consider whether we can use > ESN without anti-replay. > Besides that, after today’s discussion with Antony, we find the situation is > even complicated than what the current draft describes. Because we currently > consider more from the perspective of the control plane, i.e., IKEv2, but > many trick things will encounter when considering from the perspective of ESP > implementation. > > (@antony.ant...@secunet.com<mailto:antony.ant...@secunet.com> please correct > me if my interpretation below is wrong) > Antony mentioned that 64-bit sequence number is required in some crypto > processing, so not using ESN is not the best option and may be unacceptable.
May be look at the problem with ESN first. To disable Anti-replay protection, the main issue lies with the higher-order 32 bits, which, while not be transmitted, are included in the Integrity Check Value (ICV) of the packet. When integrity protection is enabled (typically the default), the receiver has to guess the higher order 32 bits, a wrong guess would prevent the receiver from decrypting out-of-order packets. RFC 4303: "Only the low-order 32 bits of the sequence number are transmitted in the plaintext ESP header of each packet, thus minimizing packet overhead. The high-order 32 bits are maintained as part of the sequence number counter by both transmitter and receiver and are included in the computation of the ICV (if the integrity service is selected)." Saving 4 bytes need a careful reciever window mangament at highers speed. As an extreme example, consider the case where anti-replay protection is disabled. Suppose the receiver first receives a packet with sequence number 0x00000003 00000011. Then, it receives an out-of-order packet with sequence number 0x00000000 FFFFFFF0. Although this is likely a corner case, it would prevent the receiver from decrypting the packet correctly because it would guess the higher-order 32 bits as 0x00000002 or, at best, 0x00000001. Accurately guessing 0x00000000 would likely be impossible. In my opinion, when anti-replay protection is disabled, the receiver should be able to decrypt any packet across the entire 64-bit sequence number space, regardless of the order in which it arrives. Some thoughts on solutions. 1. No sequence number on the packet. This is the cleanest solution when both sides decide to anti-replay protection is be disabled. However, note the sender have to keep a 64 bit counter if it use SN as the IV for AEAD ciphers such AES GCM. And in IKEv2 you may need an option NOSN. 2. Transmit the full 64 bit SN on the wire. As an optimization, when using AEAD use Implicit IV(RFC 8750), You can save 64 bit IV in this case. Now the receiver can independly decide to enable or disable Anti-replay protection. This proposal was discussed several times in IPsec list. 3. I am also trying a light weight hack without any changes to IKEv2, or the ESP sender, to disable Anti-replay protection. The receiver would gues the higher oreder 32bits correct most of time, however not always, and the receiver may drop packets when ICV fails. The the current ESN replay-window has two functions. The first is Anti-replay protection. This is typically use a bitmap, and the second function is to guess the higher order 32 bits using a replay window. If I disable the bitmap and keep large window, say 2^20, I may effectively achive dsiabling of Anti-replay protection. > Regarding using ESN without anti-replay, the ESP sender does not need to have > specific processing, but the receiver needs to not using the sequence number > in the decrypt processing, otherwise some packets may be dropped due to the > high-order 32 bits of the sequence number is wrong determined. Therefore, > notification payload is not a suitable way to handle this, and it’s better to > adding a third ESN option in the ESN Transform when negotiation the Child SA. > > Regards & Thanks！ > Wei PAN (潘伟) > > From: Scott Fluhrer (sfluhrer) <sfluhrer=40cisco....@dmarc.ietf.org> > Sent: Sunday, November 3, 2024 11:29 AM > To: ipsec@ietf.org > Subject: [IPsec] draft-pan-ipsecme-anti-replay-notification > > I just went through this draft, and I think the problem (which is “why do we > avoid rekeying after 2^32 packets if replay is not enabled”) is actually > simpler than what the authors expect. > > Solution 1: > > The note about ESN and antireplay is (section 3.3.3) > > If a receiver chooses to not enable anti-replay for an SA, then > the receiver SHOULD NOT negotiate ESN in an SA management protocol. > > Note that this states “SHOULD NOT”, not “MUST NOT”. We have the option of > ignoring the SHOULD NOT, and if we do, there’s no issue (and no protocol > changes are needed in this case). Of course, this works only if both sides > use this convention. > This solution would work. However the sender has to keep 64 bit counter, for IV. This is a minimlal change. However, I wonder why send the lower 32 bits:) > > Solution 2: > > The actual requirements about rekeying from RFC 4303 is (section 2.2, the > non-ESN section) > > If anti-replay is enabled > (the default), the transmitted sequence number must never be allowed > to cycle. Thus, the sender's counter and the receiver's counter MUST > be reset (by establishing a new SA and thus a new key) prior to the > transmission of the 2^32nd packet on an SA. > > (Emphesis added). > > Not that, if anti-replay is not enabled, there is no such requirement (nor is > there any security issue; wrapping around could mean that the attacker could > reissue a previous packet with the same counter, however this is a replay, > which we are explicitly allowing). > > > Hence, I believe that this draft can be simplified to a notification that > “I’m not doing replay checking, you don’t need to rekey on a wrap” (which > means you don’t need ESN in the first place). -antony _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
