Re: statement regarding keepalives

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Thu, 19 July 2018 21:07 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
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 4DEFF130F73 for <tsv-area@ietfa.amsl.com>; Thu, 19 Jul 2018 14:07:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 2AI2f-WL-VpJ for <tsv-area@ietfa.amsl.com>; Thu, 19 Jul 2018 14:07:06 -0700 (PDT)
Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A645131078 for <tsv-area@ietf.org>; Thu, 19 Jul 2018 14:07:06 -0700 (PDT)
Received: by mail-yb0-x233.google.com with SMTP id c3-v6so3825654ybi.13 for <tsv-area@ietf.org>; Thu, 19 Jul 2018 14:07:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=K2WCkigqLBJsUD5/QcSUstH6EG/GHuaNq5tzGxVCDqU=; b=NB8NtybGhwSBahX9CDVTDiiCr/q4ldvG2DDEmgyubNx/oYPw3PVnFYKSyDMOVbqfQE uYfWN7+SuSAuANLACf1CmmTgDi7b9qiF9M4WLgn6HgsAMVVvQeNlArIk9nb+6FDfAvkR LUJr4boh3mS8yAlgeUKyS9D8zcvpvJQImY9xqg6JTQXJyn25Tlu62JhFDM7Mc9caHPGY u+wgGAFVG6o1WVEiklqfcNLB8POaw0IQA8+OlPAJtSCrJ3bjtTImGCUenJ28OYsyfDGP 6/Vw0d8fpxAipmzoiqBTIjVFknmfmnLnzmgrka3BZHaPdAIZWnRYt7mTnnIy/BmWan1z aGMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=K2WCkigqLBJsUD5/QcSUstH6EG/GHuaNq5tzGxVCDqU=; b=TZ0HVoMQ75kXQRYAZwwA3iBCSi61ddf3xNKa1R1JT4nyCTKl9+u2nuOxZ9LwirfYXx vvfm3we5v0BIEBMK2i8Nrvp3u/XO61zgBzd3fBGT/zFieSRZFrUPaKNuIzey9t6SXzNi 0eH3WAKREy9QPKbv0Rkq7Ocqc4qdqQjXsPa520Zst6oEEGiGQMKdS4DqaikToNMkkxMD xNkvBErtilSzp2Jtwzh5c0wMgAAI0QuBw1c+4VQ+sUibmYKREaTCFIFm5plw+wWP/yj9 IMp6yERMbxL7xHReqPtSJ6zsPXjg/7emJVBLOaJ6PEAg4Eg83zY/Ig37pK6RdjA6Xd3b AbAQ==
X-Gm-Message-State: AOUpUlHhnS2drw6oGeGxn7VSBOj0IsBRLh5hY0XRgrx8AWwqRnA94Akq t0pgoGmpMfapOZ4ki40ZMP+nAtxJCztOqCEZU+3PTQ==
X-Google-Smtp-Source: AAOMgpexe90rldBCDJRVQynYBavwZBj7zF9zUHmjFfDJ8fhJayKfQHNjJivVhOov2UbXHzkqSB8lt6+U1mqdqW+Ipcg=
X-Received: by 2002:a25:dac5:: with SMTP id n188-v6mr6416294ybf.471.1532034425359; Thu, 19 Jul 2018 14:07:05 -0700 (PDT)
MIME-Version: 1.0
References: <D3326DE0-3F31-4045-B945-82B3F417BE4B@juniper.net> <4f7e0b1c-79d5-bd22-4c02-c066cc7cfa03@mti-systems.com> <CE03DB3D7B45C245BCA0D24327794936301D252B@MX307CL04.corp.emc.com>
In-Reply-To: <CE03DB3D7B45C245BCA0D24327794936301D252B@MX307CL04.corp.emc.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Thu, 19 Jul 2018 16:06:52 -0500
Message-ID: <CAKKJt-fm04gJAVhHdb85RibXq-Cmo1azGt4PtrgCw9wkPb2m4g@mail.gmail.com>
Subject: Re: statement regarding keepalives
To: "Black, David" <David.Black@dell.com>
Cc: Wesley Eddy <wes@mti-systems.com>, "tsv-area@ietf.org >> tsv-area@ietf.org" <tsv-area@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b5132b0571608fc5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-area/n6q_Mx9I6UKSCqxmEF9yWSfX7oI>
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, 19 Jul 2018 21:07:20 -0000

Dear All,

Top-posting ... thank yous to David and Wes for your feedback.

I'd like to report back to the SEC ADs about our discussion tomorrow when
the IESG and IAB meet (immediately after the final meeting session).

If you have any other comments, they will be appreciated at any point in
time, but would be most useful if they arrive before then.

Thanks,

Spencer

On Fri, Jul 13, 2018 at 9:38 AM Black, David <David.Black@dell.com> wrote:

> +1 on Wes's comments, especially that "layers of functionality" is better
> than "aliveness" ;-).
>
> Thanks, --David
>
> > -----Original Message-----
> > From: tsv-area [mailto:tsv-area-bounces@ietf.org] On Behalf Of Wesley
> > Eddy
> > Sent: Thursday, July 12, 2018 9:06 PM
> > To: tsv-area@ietf.org
> > Subject: Re: statement regarding keepalives
> >
> > 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
> > footnote.
> >
> >
> >
> > On 7/12/2018 8:37 PM, Kent Watsen wrote:
> > > Dear TSVAREA,
> > >
> > > 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]
> > https://mailarchive.ietf.org/arch/msg/netconf/MOzcZKp2rSxPVMTGdmmrVI
> > nwx2M
> > >
> > > 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.
> > >
> > >
>
>