From: Eric Dumazet <edumazet@google.com>
To: "Yakup Yıldız" <yakup.yildiz@b-ulltech.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: TCP - Receiving unacceptable ACK in ESTABLISHED state
Date: Thu, 13 Oct 2022 12:32:11 -0700 [thread overview]
Message-ID: <CANn89iLm4zkvS0Yht=MmFfLgY_yodA9DFfuWe7P1YhPMD6mwrg@mail.gmail.com> (raw)
In-Reply-To: <7ca43184bb5b40108b47bfcbffd7adf7@b-ulltech.com>
On Thu, Oct 13, 2022 at 12:10 PM Yakup Yıldız
<yakup.yildiz@b-ulltech.com> wrote:
>
> Hi,
>
> my name is Yakup Erdem Yildiz and I am currently working as an FPGA engineer at Bull Technology in Istanbul. We are working on a hardware TCP implementation and we are using some test scenarios to verify our hardware design.
>
> We applied the same scenarios on a Linux machine, which has the kernel release 5.4.0 and we found out that the Linux TCP does not behave properly in the following case, where "10.10.10.1" is the Linux machine under test.
>
>
>
> According to the RFC 9293, in a synchronized state TCP must send an empty ACK segment upon receiving a segment containing an unacceptable ACK number. Here in this case, no ACK is issued after receiving an unacceptable segment in ESTABLISHED state.
>
>
> -RFC 9293, p. 29
>
> "If the connection is in a synchronized state (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSEWAIT,
> CLOSING, LAST-ACK, TIME-WAIT), any unacceptable segment (out-of-window
> sequence number or unacceptable acknowledgment number) must be responded to with an
> empty acknowledgment segment (without any user data) containing the current send
> sequence number and an acknowledgment indicating the next sequence number expected to
> be received, and the connection remains in the same state."
>
We do not want to send an ACK for such a probe, coming from an attacker.
If the remote stack is that buggy, sending an ACK will not work around
the bug anyway.
I think the RFC 9293 (and RFC 793 3.9) spirit is to send ACK for old
ACKS, but not for ACK which are coming from the future (or very old
packets)
Also look for RFC 5961 recommendations if you implement a TCP stack.
> We wonder if this is a known issue, or is it an issue at all? We would be thankful if you can inform us about that.
>
> I also added the corresponding capture file as attachment.
>
> Regards,
>
> Yakup Erdem Yildiz
>
>
parent reply other threads:[~2022-10-13 19:32 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <7ca43184bb5b40108b47bfcbffd7adf7@b-ulltech.com>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANn89iLm4zkvS0Yht=MmFfLgY_yodA9DFfuWe7P1YhPMD6mwrg@mail.gmail.com' \
--to=edumazet@google.com \
--cc=netdev@vger.kernel.org \
--cc=yakup.yildiz@b-ulltech.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).