Re: statement regarding keepalives

Benjamin Kaduk <kaduk@mit.edu> Thu, 16 August 2018 22:11 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: tsv-area@ietfa.amsl.com
Delivered-To: tsv-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D09130DEA; Thu, 16 Aug 2018 15:11:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v08N61BBHlgS; Thu, 16 Aug 2018 15:11:13 -0700 (PDT)
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18E5612F295; Thu, 16 Aug 2018 15:11:12 -0700 (PDT)
X-AuditID: 1209190d-347ff700000014bb-bf-5b75f67e46f1
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id BA.1B.05307.F76F57B5; Thu, 16 Aug 2018 18:11:11 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w7GMB5Yo015564; Thu, 16 Aug 2018 18:11:06 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w7GMAxWc010989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 16 Aug 2018 18:11:02 -0400
Date: Thu, 16 Aug 2018 17:10:59 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Kent Watsen <kwatsen@juniper.net>
Cc: Joe Touch <touch@strayalpha.com>, HMikael Abrahamsson <swmike@swm.pp.se>, "tsv-area@ietf.org" <tsv-area@ietf.org>, "tsvwg-ads@tools.ietf.org" <tsvwg-ads@tools.ietf.org>, "tls-ads@ietf.org" <tls-ads@ietf.org>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>
Subject: Re: statement regarding keepalives
Message-ID: <20180816221059.GG40887@kduck.kaduk.org>
References: <D3326DE0-3F31-4045-B945-82B3F417BE4B@juniper.net> <alpine.DEB.2.20.1807201340240.14354@uplift.swm.pp.se> <B50DC954-CBB6-41C5-BE3A-F1DECD6046A5@juniper.net> <717202c9c6c6b3d083bfa4c8a9925e45@strayalpha.com> <6377766E-9A03-41BA-A4D4-8796F46278BD@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6377766E-9A03-41BA-A4D4-8796F46278BD@juniper.net>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRmVeSWpSXmKPExsUixG6nrlv/rTTaYFezlcWBOewWE+4VWrxc upXN4v3uX8wWq14/YbFY8GYxs8WHGb3MDuweS5b8ZPK43nSV3eNm6wVWj7+THjJ5fLn8mS2A NYrLJiU1J7MstUjfLoErY3/XBdaCnQYV53pusjcwrlPrYuTgkBAwkTj2M7iLkYtDSGAxk8Tf 1gZ2CGcjo8Tq1k9sEM5VJonz188BZTg5WARUJb7/6GEEsdkEVCQaui8zg9giQPG1hw4zgjQw C6xhkmg6Mo8FJCEsoC3RM3stmM0LtO7i62YmEFtIYCqTxN71lRBxQYmTM5+A1TALaEnc+PeS CeQ8ZgFpieX/OEDCnAL2Eu3rvoLtFRVQltjbd4h9AqPALCTds5B0z0LoXsDIvIpRNiW3Sjc3 MTOnODVZtzg5MS8vtUjXSC83s0QvNaV0EyMo5DkleXcw/rvrdYhRgINRiYd3wtrSaCHWxLLi ytxDjJIcTEqivF/agUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeGeeB8rxpiRWVqUW5cOkpDlY lMR579WERwsJpCeWpGanphakFsFkZTg4lCR4tb4CNQoWpaanVqRl5pQgpJk4OEGG8wAN//wF ZHhxQWJucWY6RP4Uoy7Hn/dTJzELseTl56VKifO2gwwSACnKKM2DmwNKVRLZ+2teMYoDvSXM Ox+kigeY5uAmvQJawgS0ZJoA2JKSRISUVAPjU9vlRbzuN+Zme1+d/XqKn9qVhqZvJ67kHtCL VnjLoN82uZbrvU17znquJtPG0HWnzNUM2M4VRnWc76nn0WA+bFpmxTH9WEGB8/VXrxa88rnP xqdqynWnZctkCfWgR5EnLQ5OW8843+ANW5TeU8Ovcb2sy0o77fRNAypqF1x3UN+0SmrbvSwl luKMREMt5qLiRABO0xGJMAMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-area/u8zSafniEjERY3NA2c9BnWG2pQc>
X-BeenThere: tsv-area@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF Transport and Services Area Mailing List <tsv-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-area/>
List-Post: <mailto:tsv-area@ietf.org>
List-Help: <mailto:tsv-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-area>, <mailto:tsv-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Aug 2018 22:11:15 -0000

It's great to see the good discussion happening here.  I'll note a couple
things online, and also that given the discussion of the tradeoffs that go
into making these decisions, Tom is probably right that shoving this into
an I-D would be helpful.

On Wed, Aug 15, 2018 at 05:35:28PM +0000, Kent Watsen wrote:
> 
> Below is an updated version of some text that we might roll into
> a statement or an I-D of some sort.  Kindly review and provide 
> suggestions for improvement, or support for the text as is, if
> that is the case.  ;)
> 
> This update accommodates comments from:
>   - Wesley Eddy & David Black
>      - removed "layers of functionality" verbiage
>      - moved footnote into the body of the document (this had
>        a cascading effect, and why it looks so different now)
>   - Joe Touch
>      - keepalives should occur at *all* layers that benefit
>      - keepalives at a layer should be suppressed in the 
>        presence of sufficient traffic from higher layers
>      - keepalives at a layer should not be interpreted as
>        implying state at any other layer
> 
> This update does not accommodate comments from:
>   - Michael Abrahamsson & Tom Herbert
>      - no statement added to promote TCP keepalives
>         * note: I believe this to be unnecessary because 
>           the current text doesn't ever say to not use TCP.
>      - no statement added for tuning params (e.g., timeouts).
>         * note: we could add this, but it will increase the
>           scope of the document - do we want to do this?
> 
> Cheers!
> Kent
> 
> 
> ===== START =====
> 
> # Connection Strategies for Long-lived Connections
> 
> A networked device may have an ongoing need to interact with a remote
> device. Sometimes the need arises from wanting to push data to the
> remote device, and sometimes the need arises from wanting to check if
> there is any data the remote device may have pending to deliver to
> it.
> 
> There are two fundamental network connection strategies that can be
> used to accomplish this goal: 1) a single long-lived connection and
> 2) a sequence of short-lived connections.
> 
> A single long-lived connection is most common, as it is
> straightforward to implement and directly answers the question of 
> if the "connection" is established. However, long-lived connections
> require more system resources, which may affect scalability, and
> require the initiator of the connection to periodically test the
> aliveness of the remote device, discussed further in the next 
> section.
> 
> A sequence of short-lived connections is less common, as there is an
> additional implementation effort, as well as concerns such as: 1) the
> delay of the remote device needing to wait until the connection is
> reestablished in order to deliver pending data, and 2) the additional
> latency incurred from starting new connections, especially when
> cryptology is involved. However, short-lived connections do not

(nit: "cryptography" is probably better than "cryptology")

> require keepalives and are arguably more secure, as each device is
> forced to re-authenticate the other and reload all related
> access-control policies on each connection.
> 
> For networking sessions that are primarily quiet, and the use case
> can cope with the additional latency of waiting for and starting new
> connections, it is RECOMMENDED to use a sequence of short-lived
> connections, instead of maintaining a single long-lived connection
> using aliveness checks.
> 
> 
> # Keepalives for Persistent Connections
> 
> When the initiator of a networking session needs to maintain a
> long-lived connection, it is necessary for it to periodically test
> the aliveness of the remote device. In such cases, it is RECOMMENDED
> that the aliveness check happens at the highest protocol layer
> possible that is meaningful to the application, in order to maximize
> the depth of the aliveness check.
> 
> For example, for an HTTPS connection to a simple webserver,
> HTTP-level keepalives would test more layers of functionality than
> TLS-level keepalives. However, for a webserver that is accessed via a
> load-balancer that terminates TLS connections, TLS-level aliveness
> checks may be the most meaningful check that can be performed.
> 
> More generally, it is RECOMMENDED that applications be able to
> perform the aliveness checks at all protocol levels that benefit, but
> suppress the aliveness checks at lower protocol layers from occurring
> when there is sufficient activity at higher protocol layers.
> Keepalives at a layer SHOULD NOT be interpreted as implying state at
> any other layer.

What's going on here in the last sentence is probably a bit subtle -- a
keeaplive both does not indicate "real" protocol activity but also can
serve to exercise the lower protocol layers (and, even, per the previous
sentence, suppresses their keepalives).  Though I'm not sure it's correct
to change this to just "at higher layers", since (as was pointed out
downthread), different layers may have different requirements on what to
track, and do not necessarily have good interfaces to communicate with each
other).

-Benjamin

> In order to ensure aliveness checks can occur at any given protocol
> layer, it is RECOMMENDED that protocol designers always include an
> aliveness check mechanism in the protocol and, for client/server
> protocols, that the aliveness check can be initiated from either
> device, as sometimes the "server" is the initiator of the underlying
> networking connection (e.g., RFC 8071).
> 
> Some protocol stacks have a secure transport protocol layer (e.g.,
> TLS, SSH, DTLS) that sits on top of a cleartext protocol layer (e.g.,
> TCP, UDP). In such cases, it is RECOMMENDED that the aliveness check
> occurs within protection envelope afforded by the secure transport
> protocol layer; the aliveness checks SHOULD NOT occur via the
> underlying cleartext protocol layer, as an adversary can block
> aliveness check messages in either direction and send fake aliveness
> check messages in either direction.
> 
>