netdev - Re: [PATCH net-next v2 2/2] tcp: Add sysctl to configure TIME-WAIT reuse delay

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: <CANn89iLTfnFeqhpkC87pLg-u1Yqnao6NyidezZA0gYZCONnoMw@mail.gmail.com>
Date: Tue, 10 Dec 2024 09:21:23 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: Jakub Sitnicki <jakub@...udflare.com>
Cc: netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	Jason Xing <kerneljasonxing@...il.com>, Adrien Vasseur <avasseur@...udflare.com>, 
	Lee Valentine <lvalentine@...udflare.com>, kernel-team@...udflare.com
Subject: Re: [PATCH net-next v2 2/2] tcp: Add sysctl to configure TIME-WAIT
 reuse delay

On Mon, Dec 9, 2024 at 8:38 PM Jakub Sitnicki <jakub@...udflare.com> wrote:
>
> Today we have a hardcoded delay of 1 sec before a TIME-WAIT socket can be
> reused by reopening a connection. This is a safe choice based on an
> assumption that the other TCP timestamp clock frequency, which is unknown
> to us, may be as low as 1 Hz (RFC 7323, section 5.4).
>
> However, this means that in the presence of short lived connections with an
> RTT of couple of milliseconds, the time during which a 4-tuple is blocked
> from reuse can be orders of magnitude longer that the connection lifetime.
> Combined with a reduced pool of ephemeral ports, when using
> IP_LOCAL_PORT_RANGE to share an egress IP address between hosts [1], the
> long TIME-WAIT reuse delay can lead to port exhaustion, where all available
> 4-tuples are tied up in TIME-WAIT state.
>
> Turn the reuse delay into a per-netns setting so that sysadmins can make
> more aggressive assumptions about remote TCP timestamp clock frequency and
> shorten the delay in order to allow connections to reincarnate faster.
>
> Note that applications can completely bypass the TIME-WAIT delay protection
> already today by locking the local port with bind() before connecting. Such
> immediate connection reuse may result in PAWS failing to detect old
> duplicate segments, leaving us with just the sequence number check as a
> safety net.
>
> This new configurable offers a trade off where the sysadmin can balance
> between the risk of PAWS detection failing to act versus exhausting ports
> by having sockets tied up in TIME-WAIT state for too long.
>
> [1] https://lpc.events/event/16/contributions/1349/
>
> Signed-off-by: Jakub Sitnicki <jakub@...udflare.com>

Reviewed-by: Eric Dumazet <edumazet@...gle.com>

Thanks !