statement regarding keepalives

Kent Watsen <> Fri, 13 July 2018 00:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F06CA13122B; Thu, 12 Jul 2018 17:38:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] 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 2-GG5F2rxu8W; Thu, 12 Jul 2018 17:38:02 -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 2B308131226; Thu, 12 Jul 2018 17:38:02 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id w6CNsEQk006522; Thu, 12 Jul 2018 17:38:01 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=yDp7cZspY/FweysUG8C+hmHVBghhVxRgYFC9YPqdt/E=; b=X2hng8G9f8Ob5keMroLAALA9eQOfOvMeMCl0XtsYD/xeMZCD6qDYlAhS9juC5O6v5D31 ppeKXRCEyF0oXu4lYqxaO0SPez8izOFP82h0NU2lymsyFovM5X1IMvV/pg1waSmCgR2/ aEoOQ7aqTXnT2xjjlmre4hhAyL5iTnglhKspfstBTi2REillYizomlgn37OjlN5Imxxx GhxvuFmEc7X1FlluH6bXYw5/E9ZDPzPptlBqU8SLY1jYBmcjZCWkWJiOuyF8HVLx8d4b WRsmBG2rTMzECZjbzBk6PXHNSgS9wqxJvhd41ZfkaXZMw1QrPfKzWGgNKJP2ykh0o2+q dA==
Received: from ( []) by with ESMTP id 2k5uvrjr6b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 12 Jul 2018 17:38:01 -0700
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.12; Fri, 13 Jul 2018 00:37:59 +0000
Received: from ([fe80::959d:9fbe:90e4:3cc]) by ([fe80::959d:9fbe:90e4:3cc%4]) with mapi id 15.20.0952.017; Fri, 13 Jul 2018 00:37:59 +0000
From: Kent Watsen <>
To: "" <>
CC: "" <>, "" <>, "" <>
Subject: statement regarding keepalives
Thread-Topic: statement regarding keepalives
Thread-Index: AQHUGkG/LZoJEIu3uky/qk612ULG3w==
Date: Fri, 13 Jul 2018 00:37:59 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BYAPR05MB4438; 7:UQPQZ1QXdBMHQPiimEnJ6TVew+SJ6kez+k3RfyEs5MHySn4JEBwoBzobPeIAR7DeP+WBvm2mA6EGkdz3bHQpBmGhlw4QlWcrroM5i/q0FugyvB/jKu8AyOC6UfI2MWTglYmqft491OMNW6gzHfroceqbniwC87yZJLSvIdyq1BbhB04z+8vzF96lMMOHhvhWsNkrqlPCPmtMYpxs42zUmXg6Z08B+7AE3E0979lfQgf4S/gCztK5b8p6AYSHnmmN
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: a18d6b17-d511-4f9c-35a6-08d5e858e258
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4438;
x-ms-traffictypediagnostic: BYAPR05MB4438:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(158342451672863)(265273979862326)(100405760836317);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231311)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:BYAPR05MB4438; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4438;
x-forefront-prvs: 07326CFBC4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(366004)(376002)(136003)(346002)(199004)(189003)(486006)(305945005)(81156014)(81166006)(2906002)(8936002)(2900100001)(86362001)(8676002)(14454004)(58126008)(316002)(5250100002)(106356001)(54906003)(5640700003)(6116002)(3480700004)(2501003)(83716003)(3846002)(2616005)(105586002)(99286004)(82746002)(7736002)(6306002)(102836004)(14444005)(6512007)(66066001)(476003)(33656002)(6436002)(6916009)(53936002)(256004)(4326008)(6486002)(2351001)(36756003)(966005)(478600001)(6506007)(97736004)(413944005)(25786009)(68736007)(5660300001)(186003)(26005)(7116003)(133083001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4438;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 76aDKCf9YLwS6EgfPVWdOgtoUE1wV8xRmaIZAJfM+c8IZdQPGR/hZkUHVdXmiY32rJLwd5eiEEb6+Eaygw9zyGdLRXyqBwvP5OjCgxklU3R9WRvtmrlJX5HgbswpLkvsFnO4RJpjdU98Z329QmGMBtN4cF01ZPR+52O4kzIaS8tGt9oVgJovy+pcUe40R4N4Hmtz5aZTINhWIB40uEnV3pUxLbF4WEEnBIWzvfk47LUxfEcdjhQWbxJkXg3vtBmkepsqjGGlBHkOBEg2i8YLM7zMcck3s+UF5EWcbdmyDKCrKx6d25fT+iBkYxwxsFjglgSo1bw9X5HOp2DEU1vU2hj6ePF656On8dPL4FANWNs=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a18d6b17-d511-4f9c-35a6-08d5e858e258
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2018 00:37:59.3940 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4438
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-12_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807120253
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: Fri, 13 Jul 2018 00:38:08 -0000


The folks working with the BBF asked the NETMOD WG to consider modifying draft-ietf-netconf-netconf-client-server to support TCP keepalives [1].  However, it is unclear what IETF's position is on the use of keepalives, especially with regards to keepalives provided in protocol stacks (e.g., <some-app> over HTTP over TLS over TCP).

After some discussion with Transport ADs (Spencer and Mijra) and the TLS ADs (Eric and Ben), the following draft statement has been crafted.  Spencer and Mijra have requested TSVAREA critique it before, perhaps, developing a consensus document around it in TSVWG.

It would be greatly appreciated if folks here could review and provide comments on the draft statement below.  The scope of the statement can be increased or reduced as deemed appropriate. 


Kent (and Mahesh) // NETCONF chairs

===== STATEMENT =====

When the initiator of a networking session needs to maintain a persistent connection [1], it is necessary for it to periodically test the aliveness of the remote peer.  In such cases, it is RECOMMENDED that the aliveness check happens at the highest protocol layer possible that is most meaningful to the application, to maximize the depth of the aliveness check.  

E.g., for an HTTPS connection to a simple webserver, HTTP-level keepalives would test more aliveness 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 could be performed.

In order to ensure aliveness checks can always occur at the highest 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 peer, 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.  In such cases, the aliveness checks SHOULD NOT occur via the cleartext protocol layer, as an adversary can block aliveness check messages in either direction and send fake aliveness check messages in either direction.

[1] While reasons may vary for why the initiator of a networking session feels compelled to maintain a persistent connection.  If the session is primarily quiet, and the use case can cope with the additional latency of starting a new connection, it is RECOMMENDED to use short-lived connections, instead of maintaining a long-lived persistent connection using aliveness checks.