netdev - Re: [PATCH RFC net-next] tcp: Allow TIME-WAIT reuse after 1 millisecond

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87ed6kr51x.fsf@cloudflare.com>
Date: Mon, 19 Aug 2024 15:54:50 +0200
From: Jakub Sitnicki <jakub@...udflare.com>
To: Jason Xing <kerneljasonxing@...il.com>
Cc: netdev@...r.kernel.org,  Eric Dumazet <edumazet@...gle.com>,
  kernel-team@...udflare.com
Subject: Re: [PATCH RFC net-next] tcp: Allow TIME-WAIT reuse after 1
 millisecond

Hi Jason,

On Mon, Aug 19, 2024 at 08:27 PM +08, Jason Xing wrote:
> On Mon, Aug 19, 2024 at 7:31 PM Jakub Sitnicki <jakub@...udflare.com> wrote:

[...]

>> --- a/net/ipv4/tcp_ipv4.c
>> +++ b/net/ipv4/tcp_ipv4.c
>> @@ -116,7 +116,7 @@ int tcp_twsk_unique(struct sock *sk, struct sock *sktw, void *twp)
>>         const struct inet_timewait_sock *tw = inet_twsk(sktw);
>>         const struct tcp_timewait_sock *tcptw = tcp_twsk(sktw);
>>         struct tcp_sock *tp = tcp_sk(sk);
>> -       int ts_recent_stamp;
>> +       u32 ts_recent_stamp;
>>
>>         if (reuse == 2) {
>>                 /* Still does not detect *everything* that goes through
>> @@ -157,8 +157,7 @@ int tcp_twsk_unique(struct sock *sk, struct sock *sktw, void *twp)
>>          */
>>         ts_recent_stamp = READ_ONCE(tcptw->tw_ts_recent_stamp);
>>         if (ts_recent_stamp &&
>> -           (!twp || (reuse && time_after32(ktime_get_seconds(),
>> -                                           ts_recent_stamp)))) {
>> +           (!twp || (reuse && (u32)tcp_clock_ms() != ts_recent_stamp))) {
>
> At first glance, I wonder whether 1 ms is really too short, especially
> for most cases? If the rtt is 2-3 ms which is quite often seen in
> production, we may lose our opportunity to change the sub-state of
> timewait socket and finish the work that should be done as expected.

Good point about TW state management. Haven't thought of that.

> One second is safe for most cases, of course, since I obscurely
> remember I've read one paper (tuning the initial window to 10) saying
> in Google the cases exceeding 100ms rtt is rare but exists. So I still
> feel a fixed short value is not that appropriate...
>
> Like you said, how about converting the fixed value into a tunable one
> and keeping 1 second as the default value?

I'm also leaning toward a tunable. The adoption could then be based on
an opt-in model. We don't want to break any existing setups, naturally.

> After you submit the next version, I think I can try it and test it
> locally :) It's interesting!

Thanks for feedback,
(the other) Jakub