Re: [PATCH nf-next] netfilter: conntrack: tcp: only close if RST matches exact sequence

[Florian Westphal <fw@strlen.de>]

Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> 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.