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. I wouldn't make too many assumptions about guys writing RFCs, given that I'm one of them. ;-) There is a history here, and initially NATs were viewed as breaking the Internet architecture, and if NATs should be specified at all, the overriding concern was to make them as transparent to applications as possible. Given the centralisation of the Internet and the level of packet mangling/middleboxes we now have, combined with the run-out of IPv4 addresses, applications have been forced to adapt. I don't think you can expect long-lived TCP sessions to survive at all anymore. The main concern about RST was to recover from a 3rd party sending RSTs into the session. >>>> 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? Neither I think, I'm concerned about a nefarious 3rd party trying to attack the session table. Yes, somewhat depending on how the NAT is configured the attacker has to be on the inside. Depending on the 3-way handshake also ensures the NAT state is better synchronised with the client and server state, than just using the 2-way. Do you see this causing issues? >>>> (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”. Yes, that would be good to know. Best regards, Ole
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21064): https://lists.fd.io/g/vpp-dev/message/21064 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] -=-=-=-=-=-=-=-=-=-=-=-
