netdev - Re: [PATCH net-next 1/2] tcp: remove per-destination timestamp cache

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <58CA778D.9020208@5t9.de>
Date:   Thu, 16 Mar 2017 12:31:25 +0100
From:   Lutz Vieweg <lvml@....de>
To:     Willy Tarreau <w@....eu>, David Miller <davem@...emloft.net>
CC:     soheil.kdev@...il.com, netdev@...r.kernel.org, soheil@...gle.com,
        edumazet@...gle.com, ncardwell@...gle.com, ycheng@...gle.com,
        fw@...len.de
Subject: Re: [PATCH net-next 1/2] tcp: remove per-destination timestamp cache

On 03/15/2017 11:55 PM, Willy Tarreau wrote:
> At least I can say I've seen many people enable it without understanding its impact, confusing it
> with tcp_tw_reuse, and copy-pasting it from random blogs and complaining about issues in
> production.

I currently wonder: What it the correct advise to an operator who needs
to run one server instance that is meant to accept thousands of new,
short-lived TCP connections per minute?

The explanation text at
https://vincent.bernat.im/en/blog/2014-tcp-time-wait-state-linux
seems to provide comprehensive advise, but its summary is, after all,
somewhat disappointing:

> The universal solution is to increase the number of possible quadruplets by using, for example,
> more server ports. This will allow you to not exhaust the possible connections with TIME-WAIT
> entries.

Assuming an operator has to deal with a given server executable, which does not
provide a feature to "open many listening ports for the same purpose in parallel",
this is hardly an option. (Of course, if you can start just N instead of 1 server
instance, this becomes an option, but not everything is a simple, stateless web server.)

> On the server side, do not enable net.ipv4.tcp_tw_recycle unless you are pretty sure you will
> never have NAT devices in the mix. Enabling net.ipv4.tcp_tw_reuse is useless for incoming
> connections.

So basically both options won't help the server operator.

> On the client side, enabling net.ipv4.tcp_tw_reuse is another almost-safe solution. Enabling
> net.ipv4.tcp_tw_recycle in addition to net.ipv4.tcp_tw_reuse is mostly useless.

If you just operate the server, but not the (remote) clients, this is not relevant.

Is the final verdict that unless a server software by itself offers to open
N listen ports for the same purpose, there is no solution?

Regards,

Lutz Vieweg