One document matched: draft-ietf-netconf-call-home-00.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 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">
]>
<?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-00"
updates="4253">
<front>
<title>NETCONF 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, which enables a
NETCONF server to initiate a secure connection to the NETCONF
client. NETCONF Call Home supports both the SSH and TLS
transports, and does so in a way that preserves the SSH and
TLS roles when compared to standard NETCONF over SSH or TLS
connections.</t>
</abstract>
</front>
<middle>
<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 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.</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 network element may be deployed behind a firewall
that doesn't allow management access to the internal
network.</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 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>Having call home for NETCONF is particularly useful as
NETCONF is the recommended protocol for configuration
<xref target="iesg-statement"/>, which is needed for
provisioning workflows.</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 section 3. However,
these techniques SHOULD only be used for a NETCONF
server to initiate a connection to a NETCONF
client, as described in this document.</t>
<t>The reason for this restriction is that different
protocols have different security assumptions.
The NETCONF transport specifications require
NETCONF clients and servers to verify the
identity of the other party before starting the
NETCONF protocol (section 6 of <xref target="RFC6242"/>).</t>
<t>This contrasts with the base SSH and TLS protocols, which
do not require programmatic verification of the
other party (e.g., section 9.3.4 of <xref target="RFC4251"/>
and section 4 of <xref target="RFC4252"/>). 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
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 by removing the restriction
in Section 4 (Connection Setup) of <xref target="RFC4253"/>
that the SSH client initiates the connection. Security
implications related to this change are discussed
in Security Considerations (<xref target="sec-con"/>).</t>
</section>
<section title="Overview">
<t>The same technique is used to enabled call home for both
the SSH and TLS transports. The technique is to have the
network element initiate a TCP connection to its remote peer.
The remote peer then uses the established TCP connection to
initiate either the SSH or TLS protocols. In this way, the
network element is always the SSH or TLS server, regardless
if call home is used or not.</t>
<t>Enabling the network element to maintain the role of SSH
or TLS server is both necessary and desirable. It is
necessary for the SSH protocol, as SSH channels and subsystems
can only be opened on the SSH server. It 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>
<section title="Operation">
<t>The NETCONF server's perspective (e.g., the network element)
<list style="symbols">
<t>The NETCONF server initiates a TCP connection to
the NETCONF client on one of the IANA-assigned ports
for NETCONF Call Home (YYYY or ZZZZ).</t>
<t>The TCP connection is accepted and a TCP session is
established.</t>
<t>Using this TCP connection, the NETCONF server
immediately starts either the SSH-server or TLS-server
protocol. That is, the next message sent on the TCP
stream is the initial message defined for these protocols,
per <xref target="RFC4253"/> or <xref target="RFC5246"/>.</t>
<t>The NETCONF protocol proceeds normally for SSH and TLS,
as defined in <xref target="RFC4253"/> and
<xref target="RFC5539"/> respectively.</t>
</list>
</t>
<t>The NETCONF client's perspective (e.g., the management system)
<list style="symbols">
<t>The NETCONF client listens for TCP connections
on one or both of the IANA-assigned ports for NETCONF
Call Home port (YYYY and/or ZZZZ).</t>
<t>The NETCONF client accepts an incoming TCP
connection and a TCP session is established.</t>
<t>Using this TCP connection, the NETCONF client immediately
starts either the SSH-server or TLS-server protocol. That
is, the next message sent on the TCP stream is the initial
message defined for these protocols, per
xref target="RFC4253"/> or <xref target="RFC5246"/>.</t>
<t>The NETCONF protocol proceeds normally for SSH and TLS,
as defined in <xref target="RFC4253"/> and
<xref target="RFC5539"/> respectively.</t>
</list>
</t>
</section>
<section title="NETCONF Server Identification and Verification" anchor="svr-id-and-ver">
<t>Under normal circumstances, a management system initiates
the NETCONF connection to the network element. This action
provides essential input to verify the network element'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 NETCONF Call Home connection,
the management system does not have an expectation for the
connection to be from a specific network element, and thus
must derived the network element's identity using
information provided by the network and the network element
itself. This section describes
strategies a management system can use to identify a
network element.</t>
<t>In addition to identifying a network element, a management
system must also be able to verify the network element's
credentials.
Verifying a network element's credentials is of course
necessary under normal circumstances, but due to call home
being commonly used for newly deployed network elements, how to verify
its credentials the very first time becomes a critical concern.
Therefore, this section also describes strategies a management
system can use to verify a network element's credentials.</t>
<t>The first information a management system learns from a
NETCONF Call Home connection is the IP address of the remote peer,
as provided as the source address of the TCP connection.
This IP address could be used as an identifier,
but it can only work in networks that use known static addresses,
in which case having the management system initiate the NETCONF
connection to the network element would have worked just as well.
Due to its limited use, it is not recommended to identify a network
element based on its source IP address.</t>
<t>The next information a management system learns is
provided by the network element 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 network element
using it (e.g., a fingerprint), since each network element
is assumed to have a statistically unique public key, even
in virtualized environments. This strategy also provides
a mechanism to verify the network element, in that
a secure connection can only be established with the network
element having the matching private key. This strategy is
commonly implemented by SSH clients, but could be used equally
well by TLS-based clients, such as may be required when the
network elements have self-signed certificates. This strategy
is viable and useful when the network elements 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 network element
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 trust anchor known to
the management application. This strategy enables a
management application to transparently authenticate
network elements, thus eliminating the need for manual
authentication, as required by the previously discussed
strategy. Elimination of manual steps is needed to achieve
scalable solutions, however one can claim that this merely
pushes equivalent work to provisioning the network elements
with signed credentials. This assessment is accurate in
general, but not in the case where the manufacturer itself
provisions the credentials, such as is described by
<xref target="Std-802.1AR-2009"/>. When network elements
are pre-provisioned this way, management applications can
transparently authenticate network elements using just the
manufacturer's trust anchor and a list of expected network
element identifiers, which could be provided along with
shipping information.</t>
<t>TLS uses X.509 certificates by default. To use X.509
certificates with SSH, implementations should reference
<xref target="RFC6187"/>.</t>
</section>
<section title="Configuration Data Model">
<t>How to configure a network element to initiate a NETCONF
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 configuring NETCONF Call Home
is provided in <xref target="draft-ietf-netconf-server-model"/>.</t>
</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"/> and
<xref target="RFC5246"/>, 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>For SSH, not having the SSH client initiate the TCP
connection means that it does not have a preconceived
notion of the SSH server's identity, and therefore must
dynamically derive one from information provided by the
network or the SSH server itself. Security Considerations
for strategies for this are described in
<xref target="svr-id-and-ver"/>.</t>
<t>An attacker could DoS the management application 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">
<t>This document requests that IANA assigns two TCP port numbers
in the "Registered Port Numbers" range with the service names
"netconf-ch-ssh" and "netconf-ch-tls". These ports will be the
default ports for NETCONF Call Home protocol when using SSH and
TLS respectively. 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: YYYY
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: ZZZZ
]]></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, Sean Turner, Bert Wijnen.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc4251;
&rfc4252;
&rfc4253;
&rfc5246;
&rfc5539;
&rfc6020;
&rfc6187;
&rfc6242;
&rfc6335;
</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>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 11:02:13 |