Hi Tero, This is correct. When reading Paul's comment I had in mind the text was about the SN roll over. However, re-reading the full section this is not the case and the SN roll over mechanism is described later in the section. I propose to simply remove the current text "Note ... "
Yours, Daniel On Wed, Jul 20, 2022 at 4:20 PM Tero Kivinen <kivi...@iki.fi> wrote: > Paul Wouters writes: > > > The sequence number discussion mentions the issue of packets > falling > > > out of the receive window. We talked about an IKE option/notify > to > > > signal this and during that discussion it also came to light > that this > > > protocol is going to be used without IKEv2. This leaves an > > > interoprability unaddressed. > > > > > > I do not see any mention of IKE option and SN, but maybe you can > > > refresh my memory. > > > > Without signaling that this is going to use large jumps in the SN, the > > other end would drop packets outside of its replay window. If there is > > no IKE, how is the peer going to know about this? eg you write: > > > > Note that standard receivers are generally configured with > > incrementing counters and, if not appropriately configured, the use > > of a significantly larger SN than the previous packet can result in > > that packet falling outside of the peer's receiver window which could > > cause that packet to be discarded. > > I think this description is incorrect. Any kind of jumps in the SN > will NOT cause any packets to be dropped unless there is reordering > happening between the incoming packets. > > It you are using the time based sequence numbers then the difference > between sequence numbers will be large if there has been lots of time > between two packets, and reordering which causes one packet to be > delayed for that long is uncommon. > > I.e. if properly implemented IPsec implementation gets sequence > number which is much larger than previous sequence the recipient will > simply move the replay window there and will drop only frames which > has old sequence numbers that are older than this last received > sequence number - replay window size. > > To receive such frame would require reordering of frames, and to cause > issues the delayed frame needs to be delayed for time based sequnce > number interval * replay window size. > > This all of course assumes that the sequence number is not trying to > jump forward more than 2^31... > > > What you wrote is "this is a problem". Instead, I think you should state > > something like "Using time based SN should only be used when it is known > > that the remote peer supports this or when it is known that anti-replay > > windows are disabled". > -- > kivi...@iki.fi > -- Daniel Migault Ericsson
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
