Re: [IPsec] [Lwip] Paul Wouters' Discuss on draft-ietf-lwig-minimal-esp-08: (with DISCUSS and COMMENT)

[Daniel Migault <[e-mail]>]

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 <[e-mail]> 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".
> --
> [e-mail]
>


-- 
Daniel Migault
Ericsson