One document matched: draft-ietf-netconf-call-home-04.xml
<?xml version='1.0'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc4251 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4251.xml">
<!ENTITY rfc4252 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4252.xml">
<!ENTITY rfc4253 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4253.xml">
<!ENTITY rfc5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY rfc5539 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5539.xml">
<!ENTITY rfc6020 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml">
<!ENTITY rfc6187 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6187.xml">
<!ENTITY rfc6241 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY rfc6242 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6242.xml">
<!ENTITY rfc6335 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6335.xml">
<!ENTITY rfc7230 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7230.xml">
]>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc linkmailto="no" ?>
<?rfc editing="no" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc-ext allow-markup-in-artwork="yes" ?>
<?rfc-ext include-index="no" ?>
<!--<?rfc strict="no"?> -->
<rfc category="std"
ipr="trust200902"
docName="draft-ietf-netconf-call-home-04"
updates="4253">
<front>
<title>NETCONF Call Home and RESTCONF Call Home</title>
<author initials="K.W." surname="Watsen" fullname="Kent Watsen">
<organization>Juniper Networks</organization>
<address>
<email>kwatsen@juniper.net</email>
</address>
</author>
<date/>
<area>Operations</area>
<workgroup>NETCONF Working Group</workgroup>
<keyword>call-home</keyword>
<abstract>
<t>This document presents NETCONF Call Home and RESTCONF Call Home,
which respectively enable a NETCONF/RESTCONF server to initiate a
secure connection to a NETCONF/RESTCONF client.</t>
</abstract>
<note title="Editorial Note (To be removed by RFC Editor)">
<t>This draft contains many placeholder values that need to be replaced
with finalized values at the time of publication. This note summarizes
all of the substitutions that are needed. Please note that no other
RFC Editor instructions are specified anywhere else in this document.</t>
<t>Artwork in this document contains placeholder references for this draft.
Please apply the following replacement:
<list style="symbols">
<t><spanx style="verb">XXXX</spanx> --> the assigned RFC value for this draft</t>
</list>
</t>
<t>This document contains references to other drafts in progress, both in
the Normative References section, as well as in body text throughout.
Please update the following references to reflect their final RFC assignments:
<list style="symbols">
<t>draft-ietf-netconf-restconf</t>
<t>draft-ietf-netconf-server-model</t>
</list>
</t>
<t>Artwork in this document contains placeholder values for ports pending IANA assignment
from "draft-ietf-netconf-call-home". Please apply the following replacements:
<list style="symbols">
<t><spanx style="verb">PORT-X</spanx> --> the assigned port value for "netconf-ch-ssh"</t>
<t><spanx style="verb">PORT-Y</spanx> --> the assigned port value for "netconf-ch-tls"</t>
<t><spanx style="verb">PORT-Z</spanx> --> the assigned port value for "restconf-ch-tls"</t>
</list>
</t>
<t>The following two Appendix sections are to be removed prior to publication:
<list style="symbols">
<t>Appendix A. Change Log</t>
<t>Appendix B. Open Issues</t>
</list>
</t>
</note>
</front>
<middle>
<section title="Introduction" anchor="introduction">
<t>This document presents NETCONF Call Home and RESTCONF Call Home,
which respectively enable a NETCONF/RESTCONF server to initiate a
secure connection to a NETCONF/RESTCONF client. The NETCONF protocol
is described in <xref target="RFC6241"/> and the RESTCONF is described
in <xref target="draft-ietf-netconf-restconf"/>.</t>
<t>Both NETCONF Call Home and RESTCONF Call Home preserve the
client/server roles of underlying transport, as when compared to
standard NETCONF and RESTCONF connections. Specifically, regardless
if call home is used or not, the SSH and TLS client/server roles are
the same. The SSH protocol is defined in <xref target="RFC4253"/>
and the TLS protocol is defined in <xref target="RFC5246"/>.</t>
<t>Ensuring consistency in the SSH and TLS roles is both necessary
and desirable. Ensuring consistency is necessary for the SSH protocol,
as SSH channels and subsystems can only be opened on the SSH server,
which thus must always be the NETCONF server, in order to support
NETCONF over SSH <xref target="RFC6242"/>. Ensuring consistency is
desirable, for both the SSH and TLS protocols, as it conveniently
leverages infrastructure that may be deployed for host-key or certificate
verification and user authentication.</t>
<section title="Motivation" anchor="motivation">
<t>Call home is generally useful for both the initial deployment
and on-going management of networking elements. Here are some
scenarios enabled by call home:
<list style="symbols">
<t>The network element may proactively call home after
being powered on for the first time in order to register
itself with its management system.</t>
<t>The network element may access the network in a way that
dynamically assigns it an IP address and it doesn't
register its assigned IP addressed to a mapping service,
thus complicating the ability for a management system to
connect to it.</t>
<t>The network element may be deployed behind a firewall
that implements network address translation (NAT)
for all internal network IP addresses, thus complicating
the ability for a management system to connect to it.</t>
<t>The network element may be deployed behind a firewall
that doesn't allow any management access to the internal
network.</t>
<t>The network element may be configured in "stealth mode"
and thus doesn't have any open ports for the management
system to connect to.</t>
<t>The operator may prefer to have network elements initiate
management connections, believing it is easier to secure one
open-port in the data center than to have an open port on
each network element in the network.</t>
</list>
</t>
<t>As the NETCONF and RESTCONF protocols become increasingly
popular for programatic management of networking elements,
having call home support for these two protocols is
particularly desirable.</t>
</section>
<section title="Requirements Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in RFC 2119 <xref target="RFC2119"/>.</t>
</section>
<section title="Applicability Statement">
<t>The techniques described in this document are
suitable for network management scenarios such
as the ones described in <xref target="motivation"/>. However,
these techniques SHOULD only be used for NETCONF Call Home
and RESTCONF Call Home, as described in this document.</t>
<t>The reason for this restriction is that different
protocols have different security assumptions. The NETCONF
and RESTCONF protocols require clients and servers to
verify the identity of the other party before starting the
NETCONF/RESTCONF protocol (section 2.2 of <xref target="RFC6241"/> and
sections 2.4 and 2.5 of <xref target="draft-ietf-netconf-restconf"/>).</t>
<t>This contrasts with the base SSH and TLS protocols, which
do not require programmatic verification of the other party
(section 9.3.4 of <xref target="RFC4251"/>, section 4 of
<xref target="RFC4252"/>, and section 7.3 of <xref target="RFC5246"/>).
In such circumstances, allowing the SSH/TLS server to contact the
SSH/TLS client would open new vulnerabilities. Any use of call home
with SSH/TLS for purposes other than NETCONF or RESTCONF will need
a thorough, contextual security analysis.</t>
</section>
<section title="Update to RFC 4253">
<t>This document updates the SSH Transport Layer Protocol
<xref target="RFC4253"/> only in removing the "The client
initiates the connection" statement made in Section 4 (Connection
Setup). This document assumes that the reference to
"connection" refers to the underlying transport connection
(e.g., TCP), which the NETCONF server would initiate
in a call home connection using the SSH protocol, even though
it will not take on the role of the SSH client. Security
implications related to this change are discussed in Security
Considerations (<xref target="sec-con"/>).</t>
</section>
</section>
<section title="The NETCONF or RESTCONF Server">
<section title="Protocol Operation">
<t>
<list style="symbols">
<t>The NETCONF/RESTCONF server initiates a TCP connection request (SYN) to
the NETCONF/RESTCONF client. The server SHOULD default to connecting to
one of the IANA-assigned ports defined in section <xref target="iana-con"/>,
but MAY be configured to use a non-default port.</t>
<t>The TCP connection request is accepted and a TCP connection is
established.</t>
<t>Using this TCP connection, the NETCONF/RESTCONF server MUST immediately
start using either the SSH-server <xref target="RFC4253"/> or the TLS-server
<xref target="RFC5246"/> protocol, depending on how it is configured. For
example, assuming the use of the IANA-assigned ports, the SSH-server protocol
is used for PORT-X and the TLS-server protocol is used for either port PORT-Y
or PORT-Z.</t>
<t>Once the SSH or TLS connection is established, the NETCONF/RESTCONF server
MUST immediately start using either the NETCONF-server <xref target="RFC6241"/>
or RESTCONF-server <xref target="draft-ietf-netconf-restconf"/> protocol,
depending on how it is configured. Assuming the use of the IANA-assigned
ports, the NETCONF-server protocol is used for PORT-X or PORT-Y and the
RESTCONF-server protocol is used for PORT-Z.</t>
<t>The NETCONF protocol's binding to SSH and TLS is defined in <xref target="RFC6242"/>
and <xref target="RFC5539"/> respectively. The RESTCONF protocol's binding to TLS is
is defined in <xref target="RFC7230"/>.</t>
</list>
</t>
</section>
<section title="Configuration Data Model">
<t>How to configure a NETCONF or RESTCONF server to initiate a
call home connection is outside the scope of this document,
as implementations can support this protocol using proprietary
configuration data models. That said, a YANG
<xref target="RFC6020"/> model for configuring both NETCONF Call Home
and RESTCONF Call Home is provided in
<xref target="draft-ietf-netconf-server-model"/>.</t>
</section>
</section>
<section title="The NETCONF or RESTCONF Client">
<section title="Protocol Operation">
<t>
<list style="symbols">
<t>The NETCONF/RESTCONF client listens for TCP connections from NETCONF/RESTCONF
servers. The client SHOULD default to listening for connections on the
IANA-assigned ports defined in section <xref target="iana-con"/>, but MAY be
configured to use a non-default port.</t>
<t>The NETCONF/RESTCONF client accepts an incoming TCP
connection request and a TCP connection is established.</t>
<t>Using this TCP connection, the NETCONF/RESTCONF client MUST immediately
start using either the SSH-client <xref target="RFC4253"/> or the TLS-client
<xref target="RFC5246"/> protocol, depending on how it is configured. For
example, assuming the use of the IANA-assigned ports, the SSH-client protocol
is used for PORT-X and the TLS-client protocol is used for either port PORT-Y
or PORT-Z.</t>
<t>Once the SSH or TLS connection is established, the NETCONF/RESTCONF client
MUST immediately start using either the NETCONF-client <xref target="RFC6241"/>
or RESTCONF-client <xref target="draft-ietf-netconf-restconf"/> protocol,
depending on how it is configured. Assuming the use of the IANA-assigned
ports, the NETCONF-client protocol is used for PORT-X or PORT-Y and the
RESTCONF-client protocol is used for PORT-Z.</t>
<t>The NETCONF protocol's binding to SSH and TLS is defined in <xref target="RFC6242"/>
and <xref target="RFC5539"/> respectively. The RESTCONF protocol's binding to TLS is
is defined in <xref target="RFC7230"/>.</t>
</list>
</t>
</section>
<section title="Server Identification and Verification" anchor="svr-id-and-ver">
<t>Under normal circumstances, a NETCONF/RESTCONF client initiates
the connection to the NETCONF/RESTCONF server. This action
provides essential input used to verify the NETCONF/RESTCONF server's
identity. For instance, when using TLS, the input can be
compared to the domain names and IP addresses encoded in
X.509 certificates. Similarly, when using SSH, the input
can be compared to information persisted previously.</t>
<t>However, when receiving a call home connection,
the NETCONF/RESTCONF client does not have any context
leading it to know the connection is from a particular
NETCONF/RESTCONF server. Thus the NETCONF/RESTCONF client must derive the
NETCONF/RESTCONF server's identity using information provided by
the network and the NETCONF/RESTCONF server itself. This section
describes strategies a NETCONF/RESTCONF client can use to identify
a NETCONF/RESTCONF server.</t>
<t>In addition to identifying a NETCONF/RESTCONF server, a NETCONF/RESTCONF
client must also be able to verify the server's identity.
Verifying a NETCONF/RESTCONF server's identity is
necessary under normal circumstances but, due to call home
being commonly used for newly deployed NETCONF/RESTCONF servers, how to verify
its identity the very first time becomes a prominent concern.
Therefore, this section also describes strategies a NETCONF/RESTCONF
client can use to verify a NETCONF/RESTCONF server's identity.</t>
<t>The first information a NETCONF/RESTCONF client learns from a
call home connection is the IP address of the NETCONF/RESTCONF server,
as provided by the source address of the TCP connection.
This IP address could be used as an identifier directly, but
doing so would only work in networks that use known static
addresses, in which case a standard NETCONF/RESTCONF connection would
have worked just as well. Due to this limited use, it is not
recommended to identify a NETCONF/RESTCONF server based on its source
IP address.</t>
<t>The next information a NETCONF/RESTCONF client learns is
provided by the NETCONF/RESTCONF server in the form of a host-key
or a certificate, for the SSH and TLS protocols respectively.
Without examining the contents of the host-key or certificate,
it is possible to form an identity for the NETCONF/RESTCONF server
using it directly (e.g., a fingerprint). This works because each NETCONF/RESTCONF server
is assumed to have a statistically unique public key, even
in virtualized environments. This strategy also provides
a mechanism to verify the identity of the NETCONF/RESTCONF server, in that
a secure connection can only be established with the NETCONF/RESTCONF
server having the matching private key. This strategy is
commonly implemented by SSH clients, and could be used equally
well by TLS-based clients, such as may be required when the
NETCONF/RESTCONF servers have self-signed certificates. This strategy
is viable and useful when the NETCONF/RESTCONF servers call home using
either SSH with standard RSA/DSA host-keys, or using TLS with
self-signed certificates.</t>
<t>Yet another option for identifying a NETCONF/RESTCONF server
is for its host key or certificate to encode its identity
directly (e.g., within the "Subject" field). However, in
order to trust the content encoded within a host-key or
certificate, it must be signed by a certificate authority
trusted by the NETCONF/RESTCONF client. This strategy's use of PKI
enables a NETCONF/RESTCONF client to transparently authenticate the
NETCONF/RESTCONF server's certificate, thus eliminating the need for manual
authentication, as required by the previously discussed
strategies. Elimination of manual steps is needed to achieve
scalable solutions, however one can claim that this merely
pushes equivalent work to provisioning the NETCONF/RESTCONF servers
with signed certificates. This assessment is accurate in
general, but not in the case where the manufacturer itself
provisions the certificates, such as is described by
<xref target="Std-802.1AR-2009"/>. When NETCONF/RESTCONF servers
are pre-provisioned this way, NETCONF/RESTCONF clients can
transparently authenticate NETCONF/RESTCONF servers using just the
manufacturer's trust anchor and a list of expected NETCONF/RESTCONF
server identifiers, which could be provided along with
shipping information. This strategy is recommended for
all deployment scenarios.</t>
<t>In discussing the use of certificates, it is worth noting
that TLS uses X.509 certificates by default. However, to use
X.509 certificates with SSH, both the NETCONF client and server
must support <xref target="RFC6187"/>.</t>
</section>
</section>
<section anchor="sec-con" title="Security Considerations">
<t>The security considerations described throughout
<xref target="RFC6242"/> and <xref target="RFC5539"/>,
and by extension <xref target="RFC4253"/>,
<xref target="RFC5246"/>, and <xref target="draft-ietf-netconf-restconf"/>
apply here as well.</t>
<t>This RFC deviates from standard SSH and TLS usage by
having the SSH/TLS server initiate the underlying TCP
connection. For SSH, <xref target="RFC4253"/> says
"the client initiates the connection", whereas for TLS,
<xref target="RFC5246"/> says it is layered on top of
"some reliable transport protocol" without further
attribution.</t>
<t>Not having the SSH/TLS client initiate the TCP
connection means that it does not have a preconceived
notion of the SSH/TLS server's identity, and therefore must
dynamically derive one from information provided by the
network or the SSH/TLS server itself. Security Considerations
for strategies for this are described in
<xref target="svr-id-and-ver"/>.</t>
<t>An attacker could DoS the NETCONF/RESTCONF client by
having it perform computationally expensive operations, before
deducing that the attacker doesn't posses a valid key.
This is no different than any secured service and all common
precautions apply (e.g., blacklisting the source address
after a set number of unsuccessful login attempts).</t>
</section>
<section title="IANA Considerations" anchor="iana-con">
<t>This document requests that IANA assigns three TCP port numbers
in the "Registered Port Numbers" range with the service names
"netconf-ch-ssh", "netconf-ch-tls", and "restconf-ch-tls". These
ports will be the default ports for NETCONF Call Home and RESTCONF
Call Home protocols. Below is the registration template following
the rules in <xref target="RFC6335"/>.</t>
<t>
<figure align="center">
<artwork><![CDATA[
Service Name: netconf-ch-ssh
Transport Protocol(s): TCP
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: NETCONF Call Home (SSH)
Reference: RFC XXXX
Port Number: PORT-X
Service Name: netconf-ch-tls
Transport Protocol(s): TCP
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: NETCONF Call Home (TLS)
Reference: RFC XXXX
Port Number: PORT-Y
Service Name: restconf-ch-tls
Transport Protocol(s): TCP
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: RESTCONF Call Home (TLS)
Reference: RFC XXXX
Port Number: PORT-Z
]]></artwork>
</figure>
</t>
</section>
<section title="Acknowledgements">
<t>The author would like to thank for following for
lively discussions on list and in the halls (ordered
by last name): Andy Bierman, Martin Bjorklund, Mehmet Ersue,
Wes Hardaker, Stephen Hanna, David Harrington, Jeffrey Hutzelman,
Radek Krejci, Alan Luchuk, Mouse, Russ Mundy, Tom Petch,
Peter Saint-Andre, Joe Touch, Hannes Tschofenig,
Sean Turner, Bert Wijnen.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc4251;
&rfc4252;
&rfc4253;
&rfc5246;
&rfc5539;
&rfc6020;
&rfc6187;
&rfc6241;
&rfc6242;
&rfc6335;
&rfc7230;
<reference anchor='draft-ietf-netconf-restconf'>
<front>
<title>
RESTCONF Protocol
</title>
<author initials='A.B.' surname='Bierman'
fullname='Andy Bierman'>
<organization>YumaWorks</organization>
</author>
<author initials='M.B.' surname='Bjorklund'
fullname='Martin Bjorklund'>
<organization>Tail-f Systems</organization>
</author>
<author initials='K.W.' surname='Watsen'
fullname='Kent Watsen'>
<organization>Juniper Networks</organization>
</author>
<date year='2014' />
</front>
<seriesInfo name='Internet-Draft'
value='draft-ieft-netconf-restconf-04' />
</reference>
</references>
<references title="Informative References">
<reference anchor="Std-802.1AR-2009" target="http://standards.ieee.org/findstds/standard/802.1AR-2009.html">
<front>
<title>IEEE Standard for Local and metropolitan area networks - Secure Device Identity</title>
<author fullname="WG802.1 - Higher Layer LAN Protocols Working Group">
<organization>IEEE SA-Standards Board</organization>
</author>
<date month="December" year="2009"/>
</front>
</reference>
<!--
<reference anchor="iesg-statement" target="https://www.ietf.org/iesg/statement/writable-mib-module.html">
<front>
<title>Writable MIB Module IESG Statement</title>
<author initials="IESG" fullname="Internet Engineering Steering Group"/>
<date month="March" day="2" year="2014"/>
</front>
</reference>
-->
<reference anchor="draft-ietf-netconf-server-model" target="http://tools.ietf.org/html/draft-ietf-netconf-server-model">
<front>
<title>NETCONF Server Configuration Model</title>
<author initials="K.W." surname="Watsen"
fullname="Kent Watsen">
<organization>Juniper Networks</organization>
</author>
<author initials="J.S." surname="Schoenwaelder"
fullname="Juergen Schoenwaelder">
<organization>Jacobs University</organization>
</author>
<date year="2014" />
</front>
</reference>
</references>
<section title="Change Log">
<section title="00 to 01">
<t>
<list style="symbols">
<t>The term "TCP connection" is now used throughout.</t>
<t>The terms "network element" and "management system" are now only used in the Motivation section.</t>
<t>Restructured doc a little to create an Introduction section.</t>
<t>Fixed reference in Applicability Statement so it would work
equally well for SSH and TLS.</t>
<t>Fixed reported odd wording and three references.</t>
</list>
</t>
</section>
<section title="01 to 02">
<t>
<list style="symbols">
<t>Added call home support for the RESTCONF protocol.</t>
<t>Fixed paragraph 3 of Security Considerations to equally
apply to the TLS protocol.</t>
</list>
</t>
</section>
<section title="02 to 03">
<t>
<list style="symbols">
<t>Tried to improve readability (issue #6)</t>
<t>Removed "FIXME" in section 1.3 (issue #7)</t>
<t>Added RFC Editor notes (issue #8)</t>
<t>Removed "TCP session" term (issue #9)</t>
<t>Improved language for usage of IANA-assigned ports (issue #10)</t>
</list>
</t>
</section>
<section title="03 to 04">
<t>
<list style="symbols">
<t>Replaced "verify credentials" with "verify identity" (issue #11)</t>
</list>
</t>
</section>
</section>
<section title="Open Issues">
<t>All issues with this draft are tracked using GitHub issues. Please see: https://github.com/netconf-wg/call-home/issues to see currently opened issues.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:59:17 |