Pascal, As Tero outlined, this information is typically available as the metadata to the frame being received. It is up to the implementations to ensure that such information is available when processing the frame with a delay, otherwise things won’t really work..
Mališa > On 26 Jul 2019, at 23:20, Pascal Thubert (pthubert) <pthub...@cisco.com> > wrote: > > Agreed: > > I'm wondering about the delayed security processing. That processing may be > delayed beyond the current ASN. Is the ASN of the receive time attached to > the frame as a meta of sorts to enable the delayed validation? > > All the best, > > Pascal > >> -----Original Message----- >> From: 6tisch <6tisch-boun...@ietf.org> On Behalf Of Thomas Watteyne >> Sent: vendredi 26 juillet 2019 17:08 >> To: Mališa Vučinić <malisa.vuci...@inria.fr> >> Cc: 6tisch <6tisch@ietf.org> >> Subject: Re: [6tisch] ASN replay attack -- proposed text >> >> Malisa, >> The text IMO explains both the problem and the solution very well, congrats. >> Thomas >> >>> On 26 Jul 2019, at 20:23, Mališa Vučinić <malisa.vuci...@inria.fr> wrote: >>> >>> Dear all, >>> >>> I worked on the initial version of the text describing the ASN replay attack >> and its resolution discussed during the Montreal meeting. >>> >>> The text can be found at: >>> >>> https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal- >> security/commits/4ea5f58b1a3245a1e2a2b46f95f0fd48b2f4bb31 >>> >>> Please let me know if you have any comments. >>> >>> Mališa >>> _______________________________________________ >>> 6tisch mailing list >>> 6tisch@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tisch >> _______________________________________________ >> 6tisch mailing list >> 6tisch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
