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 > On Mar 31, 2021, at 8:45 PM, liuyacan <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 (#19083): https://lists.fd.io/g/vpp-dev/message/19083 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] -=-=-=-=-=-=-=-=-=-=-=-
