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. >> 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). >> (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. Best regards, Ole
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21062): https://lists.fd.io/g/vpp-dev/message/21062 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] -=-=-=-=-=-=-=-=-=-=-=-
