Hi All,
A couple of companies are working on a solutions to implement devices, such as
DPUs, based on the requirements of the Broadband Forum Technical Report TR-301
issue 2 “Architecture and Requirements for Fiber to the Distribution Point”,
which requires TLS for the persistent NETCONF connection, for which the
configuration of call home is to be by means of the ‘ietf-netconf-server’
module.
TLS heartbeat cannot be supported to keep the call home connection alive,
because TLS heartbeat is not or no longer supported by many TLS libraries, such
as OpenSSL in the wake of the Heartbleed security bug. Although TCP keep-alives
are not secure, we will nevertheless be required to support TCP keepalives to
ensure that the connection remains persistent and these keepalives would also
need to be configurable. Unfortunately, the keepalive configuration implemented
in ‘ietf-netconf-server’, although not bound to the ‘transport’ choice, is
bound to the secure layer textually in the description of the data nodes
(references to “SSH/TLS client” and “SSH/TLS-level message”), which makes its
use for configuring TCP keepalives for specific implementations possible, but
obviously problematic. RFC 8071, Section 4.1, S7, also heavily implies that it
is intended to be used for the designated transport layer (e.g., SSH, TLS).
Since this issue affects the industry as a whole, we believe it would be better
to provide support for the configuration of TCP keepalives within the
‘ietf-netconf-server’ module from the beginning, rather than wait for other
SDOs or vendors to augment the module after publication as an RFC, which they
will be practicably forced to do.
Would supporting TCP keepalives in the IETF-defined module be something the WG
would agree to discuss? A possible solution, shown below, could be to add a new
container parallel to the existing ‘keep-alives’ container to explicitly
support the configuration for TCP keepalives. In addition, a feature statement
(e.g. "keep-alives") could be added to the existing ‘keep-alives’ container, as
RFC 8071 S7 says SHOULD (not MUST).
container tcp-keep-alives {
if-feature tcp-keep-alives;
description
"Configures the keep-alive policy, to
proactively test the aliveness of the TCP
peer. An unresponsive TCP peer will
be dropped after approximately max-attempts *
max-wait seconds.";
reference
"RFC 1122<https://tools.ietf.org/html/rfc8071>:
Requirements for Internet Hosts --
Communication Layers, section 4.2.3.6<http://4.2.3.6>.";
leaf max-wait {
type uint16 {
range "1..32767";
}
units seconds;
default 30;
description
"Sets the amount of time in seconds after
which if no data has been received from
the TCP peer, a TCP-level message
will be sent to test the aliveness of the
TCP peer.";
}
leaf max-attempts {
type uint8 {
range "1..127";
}
default 3;
description
"Sets the maximum number of sequential keep-
alive messages that can fail to obtain a
response from the TCP peer before
assuming the TCP peer is no longer
alive.";
}
leaf interval-between-attempts {
type uint16 {
range "1..32767";
}
units seconds;
default 30;
description
"Sets the amount of time in seconds after
which, if no reply to a keep-alive message
has been received from the TCP peer, the
next keep-alive message will be sent.";
}
}
}
What is the opinion of the list? Would this solution work?
Best regards
Nick & Yves
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
