netdev - auto recycling of TIME

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

Message-ID: <46E11829.4090607@draigBrady.com>
Date:	Fri, 7 Sep 2007 10:21:45 +0100
From:	Pádraig Brady <P@...igBrady.com>
To:	<netdev@...r.kernel.org>
Subject: auto recycling of TIME_WAIT connections

As I see it, TIME_WAIT state is required for 2 reasons:

  to handle wandering duplicate packets
  (so a reincarnation of a connection will not be corrupted by these packets)

  To handle last ack from active closer (client) not being received by remote.
  If that happened, the server which is in LAST_ACK state would retransmit its FIN
  (which may contain data also) so the client must be in TIME_WAIT state to handle that.
  If client is not in TIME_WAIT state, then it could only indicate to the server
  that data was maybe lost (with an RST).

The first issue, requires a large timeout, and
the TIME_WAIT timeout is currently 60 seconds on linux.
That timeout effectively limits the connection rate between
local TCP clients and a server to 32k/60s or around 500 connections/second.

But that issue can't really happen when the client
and server are on the same machine can it, and
even if it could, the timeouts involved would be shorter.

Now linux does have an (undocumented) /proc/sys/net/ipv4/tcp_tw_recycle flag
to enable recycling of TIME_WAIT connections. This is global however and could cause
problems in general for external connections.

So how about auto enabling recycling for local connections?

cheers,
Pádraig.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html