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. 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. 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).
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
