Hi Pablo, Florian, On Fri, 1 Mar 2019, Pablo Neira Ayuso wrote: > 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! The only problem I see is this part: > > If the peer sends a challenge ack, connection timeout will be reset. RFC5961 does not discuss the issue of the timeout when the challenge ack is sent and get lost, never reaches the destination. Like in this case: non RFC5961 client firewall our firewall RFC5961 server in-window RST -> ct dropped ct kept, CLOSED timeout <- challenge ack ct kept, ESTABLISHED timeout ack dropped I think we should keep the CLOSED timeout when the challenge ack is detected, which probably needs a new flag (IP_CT_EXP_CHALLENGE_ACK is for SYN ACK challenges). In my opinion it was a very bad design decision of RFC5961 that there's no TCP option/flag to signal to the peer that the sender speaks the RFC5961 flavour. Best regards, Jozsef - E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxxxxxx PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary
