On Tue, Jul 30, 2024 at 11:16 AM Valery Smyslov <smyslov.i...@gmail.com> wrote:
> Hi Paul, > > > > 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. > > > > Perhaps this discussion is a bit premature, since I currently > have to guess what > > you intend to achieve and how this influences packet processing. > > Can you please include answers to the following questions in the > next revision: > > > > 1. What happens with SN if peers negotiate not using replay > protection: > > - will it be incremented or send as a constant (what constant)? > > - if incremented will it be allowed to wrap around (I guess yes)? > It will be incremented, eg just like today, guaranteed to be unique. It will not be allowed to wrap (this cannot work with things like AES_GCM where the same number is in use) > > > 2. What happens with ESN if peers negotiate ESN and not using > replay protection: > > - will SN be incremented or send as a constant (what constant)? > Same as above. The sending does not get modified at all. Only the receiving side omits any checks for in-order or in-window and will always allow any packet with any SN. > - how the upper half of ESN is computed (it is included in ICV > calculation)? Will it be deducted as usual or be constant? > Same as now. > - if ESN is incremented, will it be allowed to wrap around? > No - same as now. > 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 dr > aft-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. > > > > Not really, this is still integers: > > - SN > > - ESN > > - no replay protection (do not look at SN at all) > SN or ESN cannot be sent as constant number, or rather it can be since you have to keep a counter anyway for the AEAD counter, there is no point doing that. Only the receiver changes as to not drop any packets based on SN / ESN. replay protection is therefor orthogonal to SN/ESN, which is why I don't like mashing this into the Transform Type 5. > > > 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? > > > > Because if we want to negotiate replay protection in IKEv2 this > is > > a better way to do it via transform then via notify. Because, > > for example, you may propose no replay protection only with > > those encryption transforms, that have explicit IV and always > propose > > replay protection for implicit IV. > I don't believe in this, but if I did, wouldn't you extend the Transorm Type 5 to: - SN - ESN - SN without replay protection - ESN without replay protection Hence my comment about bytes and flags being a bit confusing. I don't think we can repurpose this registry as flags (bits) because some implementations will read the two octets and require the integer 0 or 1 out of that. > > > - 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. > > > > This is wrong, RFC 8750 supports ESN. In fact it does always use > 64 bit IV, > > but with no ESN the upper half is set to zero. > I'll reread it, that is not how I understood it. > > > I just wonder that if you negotiate not using replay protection, > then > > the sender is free to send constant (E))SN or allowing SN it to > wrap around, > > that is obviously incompatible with RFC 8750. > I don't think anyone should do constant (E)SN or wrapping around ever. I think these two items have nothing to do with replay protection. Paul
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
