Re: statement regarding keepalives

"Eggert, Lars" <> Thu, 16 August 2018 06:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D54A130E66; Wed, 15 Aug 2018 23:23:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.091
X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id x7zzHGHyqutI; Wed, 15 Aug 2018 23:22:59 -0700 (PDT)
Received: from ( [IPv6:2620:10a:4005:8000:2306::a]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 07DA1130DDD; Wed, 15 Aug 2018 23:22:58 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.53,246,1531810800"; d="asc'?scan'208";a="294779310"
Received: from ([]) by with ESMTP; 15 Aug 2018 23:22:58 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 15 Aug 2018 23:22:58 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 15 Aug 2018 23:22:58 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 15 Aug 2018 23:22:57 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=caIeW728PIhkIjZYSMIgEXyujBZ/0Hmwe35udUqfduU=; b=DDXXYi6zSjhwnKoWvGMT1D5dtN9rhwvH/5Jf2izQcMh/ziwv10xCJW/HUIO1h0Mk41YlaE9Y2WjdgZozJdIdx0NOwHQ7sZQPXSoO5C/vZWwaX8W4FVdiRu0Z4cKL64lojEdCxx0b3IZiVG7h/9FxxfSZQ5+mHaOLrE6finGXyQk=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1038.25; Thu, 16 Aug 2018 06:22:54 +0000
Received: from ([fe80::191f:29ab:29f4:65a3]) by ([fe80::191f:29ab:29f4:65a3%6]) with mapi id 15.20.1038.023; Thu, 16 Aug 2018 06:22:54 +0000
From: "Eggert, Lars" <>
To: Kent Watsen <>
CC: Joe Touch <>, "" <>, "" <>, "" <>, "" <>
Subject: Re: statement regarding keepalives
Thread-Topic: statement regarding keepalives
Thread-Index: AQHUGkG/LZoJEIu3uky/qk612ULG36SYCm6A///2yoCAAGpcgIAomY+AgAEZeYA=
Date: Thu, 16 Aug 2018 06:22:54 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-mailer: Apple Mail (2.3445.9.1)
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR06MB3310; 6:/uy4UO/WKIcQBr2TeLErMgNmb3kvNJppgaX0/LG1c7gLoauYE7jCqzQXZSEkFhD33Ds8a2ok2VxZ7ogov7EA+MHlM76gkFuJFl7aoXaakgUURXaEAEYOlwwuEykk03TaJFLf7WhRpRJyRp6uS03lRdvedH/iU4YELp5QEXuJhqlMVZIgxAIRbNOZfdP/6tYCetnBlCpju1ekoiLqwjcoxqJb51OB7QWuUkfnbwW9B3leJUGer8NToqMLKhLpp99WaPgm3N5CP24C1jihwF2zZYomI0PXKypG2zGShsbn1O06mZIwxv1RvuVzKZBmEFrjhpwu1oC2aeIeMwlnZ84OIO7qJxFJrxK8P9EqXlgsEEvFG9AraZTPgL2giYggi6BCPhuJNowHrnSvw/AbJmdcrIdPG6WaVL22vuORsQPfvTUvgrlRKU/7/TQkyZmn66Nfji7RhgXj6RM0VVl/o7v7qg==; 5:JzU93VA3Q141j2xeb5sYuWGXRpneigCglOBJQ1dPx3p7oFy8GnYVUTJGo7DxhTDz2zduOVK2O3A8h4X/POqUAh6kiOkFxqPTGNEvdzbhsaxR7PmbgQ/tJccqq5QSJBFHB8ooPGJ0UxDnHsT6djrvbMWWp138pdSC8FeMqwxhNsE=; 7:AZNXi5T/01pv0UujVtbRGrK9DsyPcsFcQ7FrPp5RtGXLIA3VGZ99UQ7hoe6BS5RVcoU8ftrx0qCxCMfqzf9DBbyaQCM0wD0XgCxT0zQL06SuPbbOfIbQjZ301J+nyhv78SQXwYDNA1lsOb8oIjI7pK9+W9TABgKWUn6fg6A2o1BxHreCqMYLBt/JUuwM0XwaKo0bFYBoUFQEF+O9bBFINzAQpKfKTxIBpe9fhzLVsVfr9z2Yz0LDby4DPjn4cbfr
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: c6504101-573a-4d4a-e165-08d60340b3b0
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(49563074)(7193020); SRVR:MWHPR06MB3310;
x-ms-traffictypediagnostic: MWHPR06MB3310:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(35073007944872)(138986009662008)(265273979862326);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231311)(944501410)(52105095)(3002001)(6055026)(149027)(150027)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123560045)(201708071742011)(7699016); SRVR:MWHPR06MB3310; BCL:0; PCL:0; RULEID:; SRVR:MWHPR06MB3310;
x-forefront-prvs: 07665BE9D1
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(376002)(136003)(366004)(346002)(189003)(199004)(6486002)(2900100001)(6436002)(1941001)(106356001)(99936001)(8936002)(50226002)(3480700004)(68736007)(6512007)(93886005)(5660300001)(53936002)(305945005)(82746002)(6916009)(86362001)(81166006)(7736002)(7116003)(25786009)(4326008)(81156014)(8676002)(83716003)(6246003)(105586002)(229853002)(36756003)(99286004)(6506007)(66066001)(97736004)(14454004)(478600001)(102836004)(14444005)(486006)(53546011)(256004)(476003)(76176011)(54906003)(3846002)(2906002)(26005)(6116002)(4001150100001)(316002)(57306001)(11346002)(2616005)(446003)(186003)(33656002)(5250100002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR06MB3310;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: aIDsM0woLj2ZMdRGDMwFssxGBKcECQPFlvK/Dw65tOnVJ89luQk7FAounYt9wbmNNKHn9rJEsC0TkB8UFmZZTotim7nVRE/G70kacb4RrSWZB8LV1etM/bsFNZtjychqbdyIe2QXgQYUK67DgbRMAbTxZeO3S1RvEdsttSPF0eIME4Dbju6Wi3S36LRtfMuEhuxsjeKe+Ra5Z0fRR0QgZQ6pVoitUjaCRBfb5HwHnI5PnYqMJpC7s8m+C5iRqwAgcJcgWfpeaQS8AyWFYM+KVlocO12m32Mjx+DriithM7QK0SGSP+GevwSDCByLacScdJnzXfTepmvcftlHBfm2aMc1MwBk5XFvO9LS2aSQ3nw=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; boundary="Apple-Mail=_AA30FC57-95F2-40BC-8534-96B0A069D6FF"; protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: c6504101-573a-4d4a-e165-08d60340b3b0
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2018 06:22:54.4285 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR06MB3310
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: Thu, 16 Aug 2018 06:23:01 -0000


you might want to also look at Section 3,5 of RFC8086, which specifies the current BCPs for keepalives for UDP.


> On 2018-8-15, at 20:35, 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
> 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.
> 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.