Re: statement regarding keepalives

Joe Touch <> Sat, 18 August 2018 01:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3D4D5130F72; Fri, 17 Aug 2018 18:07:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YjMa6rG5VdPP; Fri, 17 Aug 2018 18:07:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7C1D6130F1F; Fri, 17 Aug 2018 18:07:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=HEuc1zrb8YIEXrL+NiPrXC+Jn/SD1BDEiEo65pAchB4=; b=2ds+A6JnYyeOiYbHgxEqr0eOZ f3X1rjAoYyeUES0VLm9dq28IV6YTqIGZXCnWCX173wXI62F+zBqwBBKjJywSB07krKydL9+Flhwix 6tNapnhclavS46u/gRoVpREWpYGh3TFUUxXoaS1pmrF9Yxmec5l036b59hZ4YmyUlLwQAcI3tsxtl DNWLsbtIGLHycgfiEuKH1mrPbQ1L0NjPNX+huMqzY7deqymED4yANvyHxNH+5uTRtXnk5lmLIWThh W1gEfTlZUMf/2uoPvrWgvYm+PF8osurTbkyBbn7AAK8r6k28Z1p45/YN27ngOGRzd9o1mFhznedMJ toiuPbjAw==;
Received: from ([]:53680 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <>) id 1fqphg-002w6t-QQ; Fri, 17 Aug 2018 21:06:57 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Subject: Re: statement regarding keepalives
From: Joe Touch <>
In-Reply-To: <>
Date: Fri, 17 Aug 2018 18:06:55 -0700
Cc: Benjamin Kaduk <>,,, " >>" <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Tom Herbert <>
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
Archived-At: <>
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF Transport and Services Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 18 Aug 2018 01:07:03 -0000

> On Aug 17, 2018, at 4:53 PM, Tom Herbert <> wrote:
> ...
> Joe,
> I agree to the extent that keepalives are run only at one layer with
> one keepalive control loop. If they are simultaneously done at
> multiple layers without consideration that can be problematic.

They are equally problematic to try to coordinate those control loops.

> It's
> also probably a good general recommendation to do keepalives only at
> the application (highest layer) if at all possible.

That makes sense ONLY if the application layer is the layer at which the keepalives are needed; application layer keepalives aren’t a good way to keep a TLS session active, nor necessarily to keep NAT state. 

> Most modern
> application protocols support them (HTTP, RPC protocols, etc). There
> are still protocols like telnet ssh would need TCP keepalives.

Sorry, why does Telnet need a TCP keepalive? I agree telnet through a NAT might, but telnet itself wouldn’t timeout any more than TCP would or should when idle.

> keepalives are a weaker signal and have become increasingly prone to
> false positives.

TCP keepalives are a great way to make sure TCP is kept active - the primary purposes of which are to take down any associated state (or let it be taken down) when it cannot be re-established. 

They’re not ‘weak’ at all. They’re TCP.

> For instance, if a connection goes through a
> transparent proxy, a TCP keepalive would only verify the liveness of a
> connection to the proxy, not TCP all the way to the peer unbeknownst
> to the user.

Agreed - again, you’re confirming the point. Use keepalives at EVERY layer that they are meaningfully needed. Don’t expect any other layer to solve that problem.