> On 18 Mar 2022, at 11:22, otr...@employees.org wrote: > > Thanks for quick replies Klement! > >>> Following up on this thread. >>> The changes in 34877 led to some undesired behaviour in the "real >>> world(tm)". >>> In the close pattern below it left sessions in established state, and with >>> a relatively low cps >>> would consume the whole session table. >>> >>> The change here https://gerrit.fd.io/r/c/vpp/+/35692 nat: tweak rfc7857 tcp >>> connection tracking >>> proposes to move the needle somewhat more towards protecting the session >>> table. >>> Views? Miklos, Klement? >>> >>> The RFC7857 state machine introduced in 56c492a is a trade-off. >>> It tries to retain sessions as much as possible and also offers >>> some protection against spurious RST by re-establishing sessions if data >>> is received after the RST. From experience in the wild, this algorithm is >>> a little too liberal, as it leaves too many spurious established sessions >>> in the session table. >>> >>> E.g. a oberserved pattern is: >>> client server >>> <- FIN, ACK >>> ACK -> >>> ACK -> >>> RST, ACK -> >> >> So why not just add a new state change where RST+half-closed moves to TRANS >> instead of throwing everything away? > > What do you mean by "throwing everything away"? > Reset the state flags? Now it goes to transitory, and it will stay in > transitory as long as packets are flowing.
Assuming the guys writing RFC gave it a thorough thought and that current state tracking is mostly done with RFC in mind, then changing it dramatically feels like it might not cover corner cases which we are currently not aware of. Feels like instead of doing one tweak let’s rewrite the whole thing approach. > >>> With the current state machine this would leave the session in >>> established state. >>> >>> These proposed changes do: >>> - require 3-way handshake to establish session. >> >> How does this help? Would you also need to track sequence numbers as was >> done before? > > It helps in the case where someone would spoof a a SYN, then RFC would leave > the spurious session in established. > The proposed state machine will leave it in transitory (the client to server > ACK would never be seen). Ah, so you are assuming a legitimate client is connecting to a nefarious server, which cannot produce it’s own SYN (or ACK) packet, but has the capability to spoof a SYN packet, yes? Or is it a nefarious client which is unable to produce a SYN packet, but capable of spoofing a SYN packet? > >>> (current requires only to see SYNs from both sides) >>> - Any FIN or RST will move session to transitory without recovery to >>> established >> >> Right, so if one side says “FIN” a.k.a. I’m done with sending data to you, >> while the other party still has data to send, then you just cut it off. Not >> sure how often this occurs in real world... > > > Agree, I was also concerned about this. No idea how prevalent this is. I > could add a counter I suppose that would count number of packets in > transitory state. Or packets hitting a non garbage collected entry within the > time window between established and transitory. > I also have another patch that expands on the syslog session logging, which > could be used to do post session analysis to learn better how well the state > machine fares. > > In half-closed packets are still allowed to pass, just with a transitory > timeout instead of established. > So if one side sends FIN, and the other sends a packet an hour later, that > will not work. But if the other side sent it 3 minutes later it would. > Assuming default timers. Maybe Miklos can provide some insight into this as they seem to do a lot of “device is rarely communicating”. > > Best regards, > Ole
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21063): https://lists.fd.io/g/vpp-dev/message/21063 Mute This Topic: https://lists.fd.io/mt/88218698/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
