Re: statement regarding keepalives

Wesley Eddy <> Fri, 13 July 2018 01:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E453130E67 for <>; Thu, 12 Jul 2018 18:05:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-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 WyNvh-X2v20V for <>; Thu, 12 Jul 2018 18:05:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4301B127333 for <>; Thu, 12 Jul 2018 18:05:39 -0700 (PDT)
Received: by with SMTP id s7-v6so9415909itb.4 for <>; Thu, 12 Jul 2018 18:05:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=YfU21AdXBvfrCsRP+J0+M+mvfGVeEIgAs/g3hoiQlCU=; b=VjZlqk+3dhQftdvA3+kwUc1hh6HU40XEqp/V09CiPq6GGgipgIwDirIzrI+ZaqMIzm RltATsJA+Z7l9gAj8y5BS/suU3Z5RFk9cFVVusoDhb4mq9blrkuf3HU+pBnjEdPeX2cS AGTlG7Yv+/sE8OhJpQE+gsxVp8tnfpqhMaKGQGZEMAKDdWTS/8xTqbe+VnGWWV6YU/8d IUe1lZu8oaH8+oZtraIXPOaAcWOeOwZgW3pKKaVvVZTgMTo3zc8T/xuqkJfKmruIMwt3 CTN0WzgkNUMWXQCMaOl6v9dMBVCznEi8Qi8FE1fSu6ZrbwYX79+IVyKXwIvQNV/TDHXR kY0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=YfU21AdXBvfrCsRP+J0+M+mvfGVeEIgAs/g3hoiQlCU=; b=WTUQS47x+i71jgHXq4uk3t2Q4gOykz8DgN2xsDKHbxCzt+BqOrkPHB8lK6cQsLuk2h CouwxyiNuga7Nfx3AKRRX2YKncM5ntUMs8X9HdVUMYvHJQNu2dkHuWwCSnoeOHJexoBC iwqga+r5Cg4cHaoCHVRsocoh3EkAr+3vVvRYlCgyZ2hnaqjNN+BifAgoQ/WdcyNpUJs3 vfQyBoZfIXSAMRLZoQ6rjvILRi0u7Fy30Srkq2R1K5pLdSegrsmcnBiU6t3ZDTIKg2QH r9x+vYd+6jdDRKDqY8c1IO/T+p4WRrO/dNWXrpH1reTw9yqmhsQVQ8jPLJLekuWkNhM0 DFaQ==
X-Gm-Message-State: AOUpUlEpNy7HyPt5UkxGcCFFtCf2nk0F5h+Z+M73ybFZd4O2T4RQbMVz Ph3R53MuWVMjt1Z8nOWMNlhuzh7tUes=
X-Google-Smtp-Source: AAOMgpcoZ0k46qsTYUwG7fg+VdKoNzc09dySY4HoXr5tMCRCPn2ya122odZ881JZADpQip6y0f9pEA==
X-Received: by 2002:a24:3243:: with SMTP id j64-v6mr3200411ita.23.1531443938520; Thu, 12 Jul 2018 18:05:38 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id p130-v6sm3821580itg.14.2018. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jul 2018 18:05:38 -0700 (PDT)
Subject: Re: statement regarding keepalives
References: <>
From: Wesley Eddy <>
Message-ID: <>
Date: Thu, 12 Jul 2018 21:05:36 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
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 01:05:42 -0000

Hi Kent, I agree with the spirit of the statement / guidance you've drafted.

You might want to tweak some of the wording, e.g. "test more aliveness" 
could be "test more layers of functionality" or something like that, but 
this is just a nit.

I think the footnote recommending short-lived connections should be more 
clear about why that's the recommendation.  What is the risk/danger/etc 
of longer-lived connections.  That recommendation seems a bit naked as 
currently described, and actually should probably be more than just a 

On 7/12/2018 8:37 PM, Kent Watsen wrote:
> 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.
> [1]
> Thanks,
> 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.