RE: statement regarding keepalives

["Black, David" <[e-mail]>]

+1 on Wes's comments, especially that "layers of functionality" is better than "aliveness" ;-).

Thanks, --David

> -----Original Message-----
> From: tsv-area [mailto:[e-mail]] On Behalf Of Wesley
> Eddy
> Sent: Thursday, July 12, 2018 9:06 PM
> To: [e-mail]
> 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.
> >
> >