On Mon, Jul 29, 2024 at 6:37 AM Valery Smyslov <smyslov.i...@gmail.com> wrote:
> > I think that the following assertion in the draft is wrong: > > Although > ESN is good to avoid the sequence number running out in a short > period, there is a prerequisite for using ESN - RFC 4302 and RFC 4303 > both require ESN to be used in conjunction with the anti-replay > function. That is, ESN can only be used if the anti-replay feature > is enabled. > > Actually, RFC 4303 and RFC 4302 say: > > 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. > > While SHOULD is a strong requirement, it is still not MUST, so it is > perfectly valid to use ESN with no replay protection if you have a good > reason (and you have). > The text can be tweaked. But in practise these two properties are currently linked. > In the case when the receiver has disabled anti-replay, but negotiated > ESN, it still needs to monitor SN values in the incoming packets and > maintain the upper > half of the ESN, since it is included in the ICV calculation. > But this is really small burden, compared to full replay protection. > > Thus, I don't see a need for this notification at all. > The issue is that clients want to have both "disable replay protection" and "ESN". Currently, many implementations (including Linux) do not support this. We are working on getting that fixed, but that will inevitably need a signal by the IKE daemon to let peers know what is supported and desired, so that ESN can be requested for those that support ESN without replay protection. And so that NO-ESN can be selected for those implementations that do not support "disable replay protection" with ESN. I missed the deadline to extend the notify payload to add this signaling. The next revision will include this. If the negotiation of the replay protection status is still needed, then: > > - it is better to be done in a way it is done in draft-ietf-ipsecme-g-ikev2 > (section 2.6), > since it couples this feature with negotiation of ESN > I am not a big fan of renaming the type 5 registry into "replay protection". It seems to mixup integers with flags (bits) and become a grab bag of miscellaneous things. Why doesn't the g-ikev2 doc simply say to always negotiate NO-ESN if that is what is needed. I don't see the need for a rename of the ESN IANA registry? > - a text should be added about incompatibility with RFC 8750 > I guess we could, although I feel that RFC 8750 should have been more explicit in saying "ESN is not supported due to re-using the same counter after 2^32 bytes". There is nothing specific to this draft that related to that. Seems more like an errata against 8750, but I don't object to warning users here either. Paul
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
