[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241107041506.81695-1-kuniyu@amazon.com>
Date: Wed, 6 Nov 2024 20:15:06 -0800
From: Kuniyuki Iwashima <kuniyu@...zon.com>
To: <kerneljasonxing@...il.com>
CC: <davem@...emloft.net>, <dsahern@...nel.org>, <edumazet@...gle.com>,
<horms@...nel.org>, <kernelxing@...cent.com>, <kuba@...nel.org>,
<netdev@...r.kernel.org>, <pabeni@...hat.com>, <kuniyu@...zon.com>
Subject: Re: [PATCH net-next] tcp: avoid RST in 3-way shakehands due to failure in tcp_timewait_state_process
From: Jason Xing <kerneljasonxing@...il.com>
Date: Thu, 7 Nov 2024 11:16:04 +0800
> > Here is how things happen in production:
> > Time Client(A) Server(B)
> > 0s SYN-->
> > ...
> > 132s <-- FIN
> > ...
> > 169s FIN-->
> > 169s <-- ACK
> > 169s SYN-->
> > 169s <-- ACK
>
> I noticed the above ACK doesn't adhere to RFC 6191. It says:
> "If the previous incarnation of the connection used Timestamps, then:
> if ...
> ...
> * Otherwise, silently drop the incoming SYN segment, thus leaving
> the previous incarnation of the connection in the TIME-WAIT
> state.
> "
> But the timewait socket sends an ACK because of this code snippet:
> tcp_timewait_state_process()
> -> // the checks of SYN packet failed.
> -> if (!th->rst) {
> -> return TCP_TW_ACK; // this line can be traced back to 2005
This is a challenge ACK following RFC 5961.
If SYN is returned here, the client may lose the chance to RST the
previous connection in TIME_WAIT.
https://www.rfc-editor.org/rfc/rfc9293.html#section-3.10.7.4-2.4.1
---8<---
- TIME-WAIT STATE
o If the SYN bit is set in these synchronized states, it may
be either a legitimate new connection attempt (e.g., in the
case of TIME-WAIT), an error where the connection should be
reset, or the result of an attack attempt, as described in
RFC 5961 [9]. For the TIME-WAIT state, new connections can
be accepted if the Timestamp Option is used and meets
expectations (per [40]). For all other cases, RFC 5961
provides a mitigation with applicability to some situations,
though there are also alternatives that offer cryptographic
protection (see Section 7). RFC 5961 recommends that in
these synchronized states, if the SYN bit is set,
irrespective of the sequence number, TCP endpoints MUST send
a "challenge ACK" to the remote peer:
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
---8<---
https://datatracker.ietf.org/doc/html/rfc5961#section-4
---8<---
1) If the SYN bit is set, irrespective of the sequence number, TCP
MUST send an ACK (also referred to as challenge ACK) to the remote
peer:
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
After sending the acknowledgment, TCP MUST drop the unacceptable
segment and stop processing further.
---8<---
Powered by blists - more mailing lists