One document matched: draft-ietf-netconf-call-home-06.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 rfc4254 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4254.xml">
<!ENTITY rfc5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY rfc6020 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml">
<!ENTITY rfc6125 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6125.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 rfc6520 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6520.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-06"
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 RFC presents NETCONF Call Home and RESTCONF Call Home,
which enable a NETCONF or RESTCONF server to initiate a secure
connection to a NETCONF or RESTCONF client respectively.</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-rfc5539bis</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 RFC presents NETCONF Call Home and RESTCONF Call Home,
which enable a NETCONF or RESTCONF server to initiate a secure
connection to a NETCONF or RESTCONF client respectively.</t>
<t>NETCONF Call Home supports both of the secure transports used
by the NETCONF protocol <xref target="RFC6241"/>, SSH and TLS.
The NETCONF protocol's binding to SSH is defined in <xref target="RFC6242"/>.
The NETCONF protocol's binding to TLS is defined in
<xref target="draft-ietf-netconf-rfc5539bis"/>.</t>
<t>RESTCONF Call Home only supports TLS, the same as the RESTCONF protocol
<xref target="draft-ietf-netconf-restconf"/>. The RESTCONF protocol's
binding to TLS is defined in <xref target="draft-ietf-netconf-restconf"/>.</t>
<t>The SSH protocol is defined in <xref target="RFC4253"/>. The TLS
protocol is defined in <xref target="RFC5246"/>. Both the SSH and TLS
protocols are layered on top of the TCP protocol, which is defined in
<xref target="RFC793"/>.</t>
<t>Both NETCONF Call Home and RESTCONF Call Home preserve all but one
of the client/server roles in their respective protocol stacks, as
compared to standard NETCONF and RESTCONF connections. The one and only
role reversal that occurs is at the TCP layer; that is, which peer is
the TCP-client and which is the TCP-server.</t>
<t>For example, a network element is traditionally the TCP-server.
However, when calling home, the network element becomes the TCP-client.
The network element's secure transport layer roles (SSH-server,
TLS-server) and its application layer roles (NETCONF-server,
RESTCONF-server) both remain the same.</t>
<t>Having consistency in both the secure transport layer (SSH, TLS) and
application layer (NETCONF, RESTCONF) roles conveniently enables deployed
network management infrastructure to support call home also. For instance,
existing certificate chains and user authentication mechanisms are
unaffected by call home.</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, but does not register
its assigned IP address to a mapping service.</t>
<t>The network element may be deployed behind a firewall
that implements network address translation (NAT)
for all internal network IP addresses.</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>
</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 are only defined 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. This requirement
is specified for the NETCONF protocol in Section 2.2 of
<xref target="RFC6241"/>, and is specified for the RESTCONF
protocol in 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 statement "The client
initiates the connection" made in Section 4 (Connection Setup).
Assuming the reference to client means "SSH client" and
the reference to connection means "TCP connection", this statement
doesn't hold true in call home, where the network element is the
SSH server and yet still initiates the TCP connection. Security
implications related to this change are discussed in Security
Considerations (<xref target="sec-con"/>).</t>
</section>
<section title="The NETCONF/RESTCONF Convention">
<t>Throughout the remainder of this document, the term "NETCONF/RESTCONF"
is used as an abbreviation in place of the text "the NETCONF or the RESTCONF".
The NETCONF/RESTCONF abbreviation is not intended to require or
to imply that a client or server must implement both
the NETCONF standard and the RESTCONF standard.</t>
</section>
</section>
<section title="The NETCONF or RESTCONF Client">
<section title="Protocol Operation">
<t>
<list style="format C%d">
<t>The NETCONF/RESTCONF client listens for TCP connection requests
from NETCONF/RESTCONF servers. The client SHOULD listen for connections
on the IANA-assigned ports defined in section <xref target="iana-con"/>,
but MAY be configured to use a non-standard 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 either the SSH-client <xref target="RFC4253"/> or the TLS-client
<xref target="RFC5246"/> protocol. For example, assuming the use of the
IANA-assigned ports, the SSH-client protocol is started when the connection
is accepted on port PORT-X and the TLS-client protocol is started when the
connection is accepted on either port PORT-Y or PORT-Z.</t>
<t>If using TLS, the NETCONF/RESTCONF client MUST advertise
"peer_allowed_to_send", as defined by <xref target="RFC6520"/>. This is
required so NETCONF/RESTCONF servers can depend on it being there for
call home connections, when keep-alives are needed the most.</t>
<t>As part of establishing an SSH or TLS connection, the NETCONF/RESTCONF
client MUST validate the server's presented host key or certificate.
This validation MAY be accomplished by certificate path validation or by
comparing the host key or certificate to a previously trusted or
"pinned" value.</t>
<t>If certificate path validation is used, the NETCONF/RESTCONF client
MUST ensure that the certificate has a valid chain of trust to a
preconfigured trust anchor and that the certificate encodes a reference
identifier that the client had awareness of prior to the connection
attempt. How reference identifiers are encoded in certificates MAY be
determined by a policy associated with the certificate's trust anchor.
For instance, a given trust anchor may be associated with a policy of
using IDevID certificates <xref target="Std-802.1AR-2009"/> that are
known to encode a unique identifier (e.g, serial number) in the X.509
certificate's "CommonName" field.</t>
<t>After the server's host key or certificate is validated, the SSH or TLS
protocol proceeds as normal to establish a SSH or TLS connection.</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.
Assuming the use of the IANA-assigned ports, the NETCONF-client protocol is
started when the connection is accepted on either port PORT-X or PORT-Y and
the RESTCONF-client protocol is started when the connection is accepted
on port PORT-Z.</t>
</list>
</t>
</section>
<section title="Configuration Data Model">
<t>How a NETCONF or RESTCONF client is configured is outside the
scope of this document. This includes configuration that might
be used to enable listening for call home connections, configuring
trust anchors, or configuring reference identifiers for expected
connections.</t>
</section>
</section>
<section title="The NETCONF or RESTCONF Server">
<section title="Protocol Operation">
<t>
<list style="format S%d">
<t>The NETCONF/RESTCONF server initiates a TCP connection request to
the NETCONF/RESTCONF client. The server SHOULD connect to
one of the IANA-assigned ports defined in section <xref target="iana-con"/>,
but MAY be configured to use a non-standard port. Using the IANA-assigned
ports, the server connects to port PORT-X for NETCONF over SSH, port
PORT-Y for NETCONF over TLS, and port PORT-Z for RESTCONF over TLS.</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 after connecting to the remote port PORT-X and the TLS-server protocol
is used after connecting to one of the remote ports PORT-Y or PORT-Z.</t>
<t>As part of establishing the SSH or TLS connection, the NETCONF/RESTCONF
server will send its host key or certificate to the client. If a certificate
is sent, the server MUST also send any intermediate certificates leading
up to the trust anchor the clients are expected use to authenticate it.
How to send a list of certificates is defined for SSH in <xref target="RFC6187"/>
Section 2.1, and for TLS in <xref target="RFC5246"/> Section 7.4.2.</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 after connecting to remote
port PORT-X or PORT-Y, and the RESTCONF-server protocol is used after
connecting to remote port PORT-Z.</t>
<t>If a persistent connection is desired, the NETCONF/RESTCONF server,
as the connection initiator, SHOULD actively test the aliveness of
the connection using a keep-alive mechanism. For TLS based connections,
the NETCONF/RESTCONF server
SHOULD send HeartbeatRequest messages, as defined by <xref target="RFC6520"/>.
For SSH based connections, per section 4 of <xref target="RFC4254"/>, the
NETCONF/RESTCONF server SHOULD send a SSH_MSG_GLOBAL_REQUEST message
with the purposely nonexistent "request name" value "keepalive@ietf.org"
and the "want reply" value set to '1'.</t>
</list>
</t>
</section>
<section title="Configuration Data Model">
<t>How a NETCONF or RESTCONF server is configured is outside the
scope of this document. This includes configuration that might
be used to specify hostnames, IP addresses, ports, algorithms,
or other relevant parameters.</t>
<t>A YANG <xref target="RFC6020"/> model for configuring both
NETCONF and RESTCONF servers, including call home, is provided in
<xref target="draft-ietf-netconf-server-model"/>.</t>
</section>
</section>
<section anchor="sec-con" title="Security Considerations">
<t>The security considerations described in
<xref target="RFC6242"/> and <xref target="draft-ietf-netconf-rfc5539bis"/>,
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. This reversal
is incongruous with <xref target="RFC4253"/>, which says "the client
initiates the connection" and also <xref target="RFC6125"/>, which says
"the client MUST construct a list of acceptable reference identifiers,
and MUST do so independently of the identifiers presented by the service."
To account for these variances, this RFC requires that the
NETCONF/RESTCONF client validate the SSH host key or certificate via
certificate path validation to a preconfigured trust anchor or by
comparing the host key or certificate to a previously trusted or
"pinned" value. Furthermore, if certificate path validation is used,
this RFC requires that the client be able to match a reference identifier
encoded in the certificate with one that the client was preconfigured
to expect.</t>
<t>An attacker could launch a denial of service (DoS) attack
on 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 RFC 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 the 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,
Juergen Schoenwaelder, Peter Saint-Andre, Joe Touch,
Hannes Tschofenig, Sean Turner, and Bert Wijnen.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC793" target="https://www.ietf.org/rfc/rfc793.txt">
<front>
<title>TRANSMISSION CONTROL PROTOCOL</title>
<author initials="J." surname="Postel" fullname="J. Postel">
<organization/>
</author>
<date year="1981" month="September"/>
</front>
<seriesInfo name="STD" value="7"/>
</reference>
&rfc2119;
&rfc4251;
&rfc4252;
&rfc4253;
&rfc4254;
&rfc5246;
&rfc6020;
&rfc6125;
&rfc6187;
&rfc6241;
&rfc6242;
&rfc6335;
&rfc6520;
<reference anchor="draft-ietf-netconf-rfc5539bis" target="https://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis">
<front>
<title>
Using the NETCONF Protocol over Transport Layer Security (TLS)
with Mutual X.509 Authentication
</title>
<author initials="M." surname="Badra" fullname="M. Badra">
<organization/>
</author>
<author initials="A." surname="Luchuk" fullname="A. Luchuk">
<organization/>
</author>
<author initials="J." surname="Schoenwaelder" fullname="J. Schoenwaelder">
<organization/>
</author>
<date year="2015" month="April"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-netconf-rfc5539bis-10"/>
</reference>
<reference anchor="draft-ietf-netconf-restconf" target="https://tools.ietf.org/html/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="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 title="04 to 05">
<t>
<list style="symbols">
<t>Applied many suggestions from WGLC</t>
<t>Removed essay like "Server Identification and Verification" section</t>
<t>Added text about keep-alives</t>
<t>Added Configuration Data Model section for client protocol</t>
<t>Improved Security Considerations section</t>
</list>
</t>
</section>
<section title="05 to 06">
<t>
<list style="symbols">
<t>Addressed comments raised by Alan Luchuk.</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:22 |