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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
