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). > 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). I think we can even reuse the EXP_CHALLENGE_ACK for this. > 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. I think its fine, we would have the same problem if the RST was lost before reaching us.
