Hi Antony, > 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.
Sorry, I fail to understand how the task of determining the upper 32 bits of ESN is related to the anti-replay protection status. If you disable replay protection then set W=0 (zero-length window) in the algorithms from appendix A2 of RFC 4303 and they continue to work (with careful implementation). Am I missing something? > 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. The same can happen if anti-replay protection is enabled and the existence of replay window doesn't help here. > 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. This is generally not possible in the current architecture regardless of the status of anti-replay protection. The principal difference between SN and ESN is that in the former case you always know whether the packet is "new" or "old" in case it misses the window. With ESN you cannot determine this, since the upper 32 bits are not transmitted. Thus, if the packet is more than 2^32 ahead or behind the expected ESN, then you generally are unable to distinguish these two cases until you try-and-find the proper upper 32 bits by taking candidates one by one and try to check ICV. This is expensive and generally infeasible if the difference from expected value is large enough. > 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. This will solve this problem. > 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. I still fail to understand how this is related to the status of anti-replay protection. The existence of the anti-replay window doesn't help if the packet is too far ahead or behind the expected value, thus the receiver could drop it anyway. > 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. As far as I remember, you will still be able to determine the upper 32 bits in accordance with algorithms from RFC 4303 even if you set W=0 (no relay window). > > 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. BTW, G-IKEv2 draft renames ESN transform to "Anti-Replay Protection" and adds a value "Not Used". Regards, Valery. > > 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 _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
