On Sun, 3 Mar 2019, Florian Westphal wrote: > Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx> wrote: > > > @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 > > > The ESTABLISHED timeout is 5 minutes because of missing ACKs > (outstanding data) in this case though (the RST has "wrong" sequence > number, so the conntrack is flagged accordingly until something acks the > data). Sorry, but I don't see where is the outstanding data. Up to the RST and the challenge ACK there's no missing ACK. The RST hasn't got wrong seq because it's in the window. The RST flag is not counted. What do I miss? > > 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). > > I think its fine as is with the unacknowledged data timeout, but it > should be easy to keep the 10 seconds using the flag you suggest). If the conntrack timeout is not the ESTABLISHED one after the challenge ACK is seen, that's perfect. Best regard, 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
