From: Eric Dumazet <eric.dumazet@gmail.com>
To: "Juan José Echevarria" <juanjose.echevarria@gmail.com>
Cc: netdev@vger.kernel.org
Subject: Re: SYN cookies: validity range
Date: Tue, 06 Jun 2017 16:10:35 -0700 [thread overview]
Message-ID: <1496790635.736.19.camel@edumazet-glaptop3.roam.corp.google.com> (raw)
In-Reply-To: <CACBbrCDcgxDirTvrM39o5ZX8gmr2O3WJhkxyCzwN0LMLhcdwKw@mail.gmail.com>
On Wed, 2017-06-07 at 00:12 +0200, Juan José Echevarria wrote:
> Hi,
>
> This is my first post, hope I'm not using the mailing list wrongly.
>
> As proposed in an old thread
> (https://www.spinics.net/lists/netdev/msg329144.html), when we send
> SYN cookies and then exit this mode, tcp_synq_no_recent_overflow()
> returns false if cookies are received until 2 minutes later
> (TCP_SYNCOOKIE_VALID).
>
> Despite the rest of the SYN cookie code allows ACKs be aged up to 2
> minutes, we should not accept cookies for that long if the SYN cookie
> episode is over. As we dont keep state, an ACK with a previous cookie
> will be assumed as a valid third packet of a TCP connection.
>
> In this scenario, the validity range allows a client not to wait for a
> SYN-ACK most of the time. A client could intentionally send the
> required number of packets to fill the queue (eg, with a spoofed IP
> address). Then, it could open a connection, collect the cookie, and
> reuse it to speed up the opening of successive connections for 2
> minutes. This cheat -specially attractive in low-end devices, where
> the SYN queue is rather small- may behave similarly to TCP Fast Open,
> but without the awareness of the server.
No idea why someone would use this unreliable convoluted way, instead of
Fast Open ;)
>
> Decreasing TCP_SYNCOOKIE_VALID would prevent the replay of cookies.
It will also prevent connections from innocent users with RTT of say 30
seconds (seen in real world conditions)
prev parent reply other threads:[~2017-06-06 23:10 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-06 22:12 SYN cookies: validity range Juan José Echevarria
2017-06-06 23:10 ` Eric Dumazet [this message]
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=1496790635.736.19.camel@edumazet-glaptop3.roam.corp.google.com \
--to=eric.dumazet@gmail.com \
--cc=juanjose.echevarria@gmail.com \
--cc=netdev@vger.kernel.org \
/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