[tcpm] New keep-alive text in draft-ietf-netconf-tcp-client-server-03

["Scharf, Michael" <[e-mail]>]

Hi all,

As outlined below, the draft draft-ietf-netconf-tcp-client-server was updated. The new version can be found at https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server-03 and a diff is available at https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-tcp-client-server-03 .

In the new version, I have tried to address comments from the last TCPM meeting. Note that this document is owned the NETCONF working group, but we try to keep TCPM in the loop.

In -03, I have drafted a new section with guidance on use of TCP keep-alives. It reuses some text from a related earlier discussion on the TSVAREA list:

<snip>
3.2.  Usage Guidelines for Configuring TCP Keep-Alives

   Network stacks may include "keep-alives" in their TCP
   implementations, although this practice is not universally accepted.
   If keep-alives are included, [RFC1122] [RFC793bis] mandates that the
   application MUST be able to turn them on or off for each TCP
   connection, and that they MUST default to off.

   Keep-alive mechanisms exist in many protocols.  Depending on the
   protocol stack, TCP keep-alives may only be one out of several
   alternatives.  Which mechanism to use depends on the use case and
   application requirements.  If keep-alives are needed by an
   application, 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.

   A TCP keep-alive mechanism should only be invoked in server
   applications that might otherwise hang indefinitely and consume
   resources unnecessarily if a client crashes or aborts a connection
   during a network failure [RFC1122].  TCP keep-alives may consume
   significant resources both in the network and in endpoints (e.g.,
   battery power).  In addition, frequent keep-alives risk network
   congestion.  The higher the frequency of keep-alives, the higher the
   overhead.

   Given the cost of keep-alives, parameters have to be configured
   carefully:

   o  The default idle interval (leaf "idle-time") MUST default to no
      less than two hours, i.e., 7200 seconds [RFC1122].  A lower value
      MAY be configured, but keep-alive messages SHOULD NOT be
      transmitted more frequently than once every 15 seconds.  Longer
      intervals SHOULD be used when possible.

   o  The maximum number of sequential keep-alive probes that can fail
      (leaf "max-probes") trades off responsiveness and robustness
      against packet loss.  ACK segments that contain no data are not
      reliably transmitted by TCP.  Consequently, if a keep-alive
      mechanism is implemented it MUST NOT interpret failure to respond
      to any specific probe as a dead connection [RFC1122].  Typically a
      single-digit number should suffice.

   o  TCP implementations may include a parameter for the number of
      seconds between TCP keep-alive probes (leaf "probe-interval").  In
      order to avoid congestion, the time interval between probes MUST
      NOT be smaller than one second.  Significantly longer intervals
      SHOULD be used.  It is important to note that keep-alive probes
      (or replies) can get dropped due to network congestion.  Sending
      further probe messages into a congested path after a short
      interval, without backing off timers, could cause harm and result
      in a congestion collapse.  Therefore it is essential to pick a
      large, conservative value for this interval.
</snip>

The lower bound of 15 seconds is taken from RFC 8085. Also, I have tried to use text from RFC 1122 as far as possible.

Any thoughts?

Thanks

Michael (as contributor)


-----Original Message-----
From: Kent Watsen <[e-mail]> 
Sent: Saturday, October 19, 2019 12:28 AM
To: [e-mail]
Cc: Scharf, Michael <[e-mail]>; Wang Haiguang <[e-mail]>; Frank Xialiang <[e-mail]>
Subject: updates to the client/server suite of drafts

Below are the change-logs for the updates just posted.

Not yet incorporated:

  1. a resolution to the "algorithms" problem in the
     crypto-types draft.  (IANA templates?)
  2. an update to the Truststore draft to add support
     for PSK and raw keys.
  3. an update to the Keystore draft to add support
     for PSK and raw keys. (Henk's response pending)
  4. an update to the SSH and TLS drafts to reflect
     the final outcome to (1).

Kent


===== change logs =====

crypto-types:

  - Added a "key-format" identity.
  - Added symmetric keys to the example in the Examples section.

truststore:

  - Editorial changes only.

keystore:

  - Updated examples to incorporate new "key-format" identities.
  - Made the two "generate-*-key" RPCs be "action" statements
    instead.

tcp-client-server: (changes from co-author Micheal Scharf)

  - Moved the common model section to be before the
    client and server specific sections.
  - Added sections "Model Scope" and "Usage Guidelines
    for Configuring TCP Keep-Alives" to the Common
    Model section.

ssh-client-server:

  - Updated examples to reflect ietf-crypto-types change
    (e.g., identities --&gt; enumerations)
  - Updated "server-authentication" and "client-authentication"
    nodes from being a leaf of type "ts:host-keys-ref" or 
    "ts:certificates-ref" to a container that uses 
    "ts:local-or-truststore-host-keys-grouping" or 
    "ts:local-or-truststore-certs-grouping".

tls-client-server:

  - Updated "server-authentication" and "client-authentication"
    nodes from being a leaf of type "ts:certificates-ref" to a
    container that uses "ts:local-or-truststore-certs-grouping".
  - Note: this update needed by the TCPM WG.

http-client-server:

  - in ietf-http-client, removed all but the "basic" 
    authentication scheme.
  - in ietf-http-client, factored out a "client-identity-grouping"
    grouping, which is now used in both the primary and proxy
    configuration models.
  - in ietf-http-server under /client-authentication/local, added
    an ability to configure authentication credentials for the
    "basic" authentication scheme.
  - Note: this update was blocking the adoption call from before.

netconf-client-server:

  - Refactored both the client and server modules similar to
    how the ietf-restconf-server module was refactored in -13 
    presented in Montreal.

restconf-client-server:

  - Refactored both the client and server modules similar to
    how the ietf-restconf-server module was refactored in -13 
    presented in Montreal.
  - Added missing "or https-listen" clause in a "must" expression.



Kent // contributor