On Thu, Feb 21, 2019 at 05:09:31PM +0100, Florian Westphal wrote: > TCP resets cause instant transition from established to closed state > provided the reset is in-window. Endpoints that implement RFC 5961 > require resets to match the next expected sequence number. > RST segments that are in-window (but that do not match RCV.NXT) are > ignored, and a "challenge ACK" is sent back. > > Main problem for conntrack is that its a middlebox, i.e. whereas an end > host might have ACK'd SEQ (and would thus accept an RST with this > sequence number), conntrack might not have seen this ACK (yet). > > Therefore we can't simply flag RSTs with non-exact match as invalid. > > This updates RST processing as follows: > > 1. If the connection is in a state other than ESTABLISHED, nothing is > changed, RST is subject to normal in-window check. > > 2. If the RSTs sequence number either matches exactly RCV.NXT, > connection state moves to CLOSE. > > 3. The same applies if the RST sequence number aligns with a previous > packet in the same direction. > > In all other cases, the connection remains in ESTABLISHED state. > If the normal-in-window check passes, the timeout will be lowered > to that of CLOSE. > > If the peer sends a challenge ack, connection timeout will be reset. > > If the challenge ACK triggers another RST (RST was valid after all), > this 2nd RST will match expected sequence and conntrack state changes to > CLOSE. > > If no challenge ACK is received, the connection will time out after > CLOSE seconds (10 seconds by default), just like without this patch. Applied, thanks. @Jozsef, if you could also have a look to confirm if you see any issue, this looks fine to me and we, of course, can revert this in this this tightening in RST tracking has any side issue. Thanks!
