Hi Yacan, No worries, this is a fair question! I guess the point of the standard is that tsval makes sense only within the context of segment validation. Still, moving the update to tcp_rcv_ack should be possible, at least for testing purposes. But making something that’s not rfc compliant default would require a lot of testing …
Regards, Florin > On Apr 1, 2021, at 6:40 PM, liuyacan <liuya...@corp.netease.com> wrote: > > Hi Florin, > > Yes, subsequent packets are dropped with PAWS errors. According to > RFC7323, the ACK filed check is indeed after saving SEG.TSval in TS.Recent.. > Em.....It seems that even if the ACK bit is off, TS.Recent will still be > updated. > Well, I will stop here. > > BR， > Yacan > On 4/1/2021 12:38，Florin Coras<fcoras.li...@gmail.com> > <mailto:fcoras.li...@gmail.com> wrote： > Hi Yacan, > > Ah, I’m assuming subsequent packets are dropped with paws errors? Question > then is, if an attacker manages to pass all segment validation checks, > including tstamp, should we ignore tsval if the ack is not valid, although > tsval is only used to validate segments (not acks)? As far as I can remember, > RFC7323[1] recommends accepting the tsval update, although I haven’t re-read > this carefully recently. > > Independent of this, really glad to hear you’re doing this type of testing! > Let me know if you hit any other issues as I’ve only done Codenomicon > testing. > > Regards, > Florin > > [1] https://tools.ietf.org/html/rfc7323#appendix-D > <https://tools.ietf.org/html/rfc7323#appendix-D> > >> On Mar 31, 2021, at 8:45 PM, liuyacan <liuya...@corp.netease.com >> <mailto:liuya...@corp.netease.com>> wrote: >> >> Hi Florin, >> >> when we use packetdrill to inject a bad packet with high tsval which ACK >> sequence is above SNDNXT, we found that subsequent normal packet are not >> accepted. >> >> BR, >> yacan >> On 4/1/2021 11:29，Florin Coras<fcoras.li...@gmail.com> >> <mailto:fcoras.li...@gmail.com> wrote： >> Hi Yacan, >> >> We only update tc->tsval_recent if the segment is fine and tc->tsval_recent >> is less than rcv_opts.tsval, i.e., the new tsval moves forward. Even if the >> ack is dropped, we only use tsval_recent in paws check. On the other hand >> rcv_opts.tsecr is not used unless the ack is valid. >> >> Did you hit any issue in particular? >> >> Regards, >> Florin >> >>> On Mar 31, 2021, at 7:00 PM, liuyacan <liuya...@corp.netease.com >>> <mailto:liuya...@corp.netease.com>> wrote: >>> >>> Hi, >>> >>> For ESTABLISHED tcp connection, its timestamp is updated in >>> tcp_segment_validate()->tcp_options_parse(), >>> but if after this , the ACK field check failed, then the packet would >>> be dropped. >>> Do we need to restore the timestamp of the connection ? >>> >>> Thanks, >>> Yacan >>> >> >> > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19092): https://lists.fd.io/g/vpp-dev/message/19092 Mute This Topic: https://lists.fd.io/mt/81766692/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
