draft-ietf-netconf-call-home-01.txt   draft-ietf-netconf-call-home-02.txt 
NETCONF Working Group K. Watsen NETCONF Working Group K. Watsen
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Updates: 4253 (if approved) October 10, 2014 Updates: 4253 (if approved) December 5, 2014
Intended status: Standards Track Intended status: Standards Track
Expires: April 13, 2015 Expires: June 8, 2015
NETCONF Call Home NETCONF Call Home and RESTCONF Call Home
draft-ietf-netconf-call-home-01 draft-ietf-netconf-call-home-02
Abstract Abstract
This document presents NETCONF Call Home, which enables a NETCONF This document presents NETCONF Call Home and RESTCONF Call Home,
server to initiate a secure connection to the NETCONF client. which respectively enable a NETCONF/RESTCONF server to initiate a
NETCONF Call Home supports both the SSH and TLS transports, and does secure connection to a NETCONF/RESTCONF client.
so in a way that preserves the SSH and TLS roles when compared to
standard NETCONF over SSH or TLS connections.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 13, 2015. This Internet-Draft will expire on June 8, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 14 skipping to change at page 2, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Terminology . . . . . . . . . . . . . . . . 3 1.2. Requirements Terminology . . . . . . . . . . . . . . . . 3
1.3. Applicability Statement . . . . . . . . . . . . . . . . . 3 1.3. Applicability Statement . . . . . . . . . . . . . . . . . 3
1.4. Update to RFC 4253 . . . . . . . . . . . . . . . . . . . 4 1.4. Update to RFC 4253 . . . . . . . . . . . . . . . . . . . 4
2. The NETCONF Server . . . . . . . . . . . . . . . . . . . . . 4 2. The NETCONF Server or RESTCONF Server . . . . . . . . . . . . 4
2.1. Protocol Operation . . . . . . . . . . . . . . . . . . . 4 2.1. Protocol Operation . . . . . . . . . . . . . . . . . . . 4
2.2. Configuration Data Model . . . . . . . . . . . . . . . . 5 2.2. Configuration Data Model . . . . . . . . . . . . . . . . 5
3. The NETCONF Client . . . . . . . . . . . . . . . . . . . . . 5 3. The NETCONF Client or RESTCONF Client . . . . . . . . . . . . 5
3.1. Protocol Operation . . . . . . . . . . . . . . . . . . . 5 3.1. Protocol Operation . . . . . . . . . . . . . . . . . . . 5
3.2. Server Identification and Verification . . . . . . . . . 5 3.2. Server Identification and Verification . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 11
A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 10 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 11
A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
This document presents NETCONF Call Home, which enables a NETCONF This document presents NETCONF Call Home and RESTCONF Call Home,
server to initiate a secure connection to the NETCONF client. which respectively enable a NETCONF/RESTCONF server to initiate a
NETCONF Call Home supports both the SSH and TLS transports, and does secure connection to a NETCONF/RESTCONF client. The NETCONF protocol
so in a way that preserves the SSH and TLS roles when compared to is described in [RFC6241] and the RESTCONF is described in
standard NETCONF over SSH or TLS connections. [draft-ietf-netconf-restconf].
The same technique is used to enabled call home for both the SSH and Both NETCONF Call Home and RESTCONF Call Home preserve the SSH
TLS transports. The technique is to have the NETCONF server initiate [RFC4253] and TLS [RFC5246] transport roles, as when compared to
a TCP connection to the intended NETCONF client. The NETCONF client standard NETCONF and RESTCONF connections. Specifically, regardless
then uses the established TCP connection to initiate either the SSH if call home is used or not, the NETCONF server is always the SSH or
or TLS protocols. In this way, the NETCONF server is always the SSH TLS server, and the RESTCONF server is always the TLS server.
or TLS server, regardless if call home is used or not.
Enabling the NETCONF server to maintain the role of SSH or TLS server Ensuring consistency in the SSH and TLS roles is both necessary and
is both necessary and desirable. It is necessary for the SSH desirable. Ensuring consistency is necessary, for the SSH protocol,
protocol, as SSH channels and subsystems can only be opened on the as SSH channels and subsystems can only be opened on the SSH server,
SSH server. It is desirable for both the SSH and TLS protocols as it as is needed to support NETCONF over SSH [RFC6242]. Ensuring
consistency is desirable, for both the SSH and TLS protocols, as it
conveniently leverages infrastructure that may be deployed for host- conveniently leverages infrastructure that may be deployed for host-
key or certificate verification and user authentication. key or certificate verification and user authentication.
1.1. Motivation 1.1. Motivation
Call home is generally useful for both the initial deployment and on- Call home is generally useful for both the initial deployment and on-
going management of networking elements. Here are some scenarios going management of networking elements. Here are some scenarios
enabled by call home: enabled by call home:
o The network element may proactively call home after being powered o The network element may proactively call home after being powered
skipping to change at page 3, line 32 skipping to change at page 3, line 32
o The network element may be deployed behind a firewall that doesn't o The network element may be deployed behind a firewall that doesn't
allow management access to the internal network. allow management access to the internal network.
o The network element may be deployed behind a firewall that o The network element may be deployed behind a firewall that
implements network address translation (NAT) for all internal implements network address translation (NAT) for all internal
network IP addresses, thus complicating the ability for a network IP addresses, thus complicating the ability for a
management system to connect to it. management system to connect to it.
o The operator may prefer to have network elements initiate o The operator may prefer to have network elements initiate
management connections believing it is easier to secure one open- management connections, believing it is easier to secure one open-
port in the data center than to have an open port on each network port in the data center than to have an open port on each network
element in the network. element in the network.
Having call home for NETCONF is particularly useful as NETCONF is the Having call home for the NETCONF protocol, and the RESTCONF protocol
recommended protocol for configuration [iesg-statement], which is by extension, is particularly useful as NETCONF is the recommended
needed for provisioning workflows. protocol for configuration [iesg-statement], which is needed for
provisioning workflows.
1.2. Requirements Terminology 1.2. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.3. Applicability Statement 1.3. Applicability Statement
The techniques described in this document are suitable for network The techniques described in this document are suitable for network
management scenarios such as the ones described in Section 1.1. management scenarios such as the ones described in Section 1.1.
However, these techniques SHOULD only be used for a NETCONF server to However, these techniques SHOULD only be used for NETCONF Call Home
initiate a connection to a NETCONF client, as described in this and RESTCONF Call Home, as described in this document.
document.
The reason for this restriction is that different protocols have The reason for this restriction is that different protocols have
different security assumptions. The NETCONF transport specifications different security assumptions. The NETCONF and RESTCONF protocols
require NETCONF clients and servers to verify the identity of the require clients and servers to verify the identity of the other party
other party before starting the NETCONF protocol (section 2.2 of before starting the NETCONF/RESTCONF protocol (section 2.2 of
[RFC6241]. [RFC6241] and section FIXME of [draft-ietf-netconf-restconf]).
This contrasts with the base SSH and TLS protocols, which do not This contrasts with the base SSH and TLS protocols, which do not
require programmatic verification of the other party (e.g., section require programmatic verification of the other party (section 9.3.4
9.3.4 of [RFC4251] and section 4 of [RFC4252]). In such of [RFC4251], section 4 of [RFC4252], and section 7.3 of [RFC5246]).
circumstances, allowing the SSH/TLS server to contact the SSH/TLS In such circumstances, allowing the SSH/TLS server to contact the
client would open new vulnerabilities. Any use of call home with SSH/TLS client would open new vulnerabilities. Any use of call home
SSH/TLS for purposes other than NETCONF will need a thorough, with SSH/TLS for purposes other than NETCONF or RESTCONF will need a
contextual security analysis. thorough, contextual security analysis.
1.4. Update to RFC 4253 1.4. Update to RFC 4253
This document updates the SSH Transport Layer Protocol [RFC4253] only This document updates the SSH Transport Layer Protocol [RFC4253] only
by removing the "The client initiates the connection" statement made by removing the "The client initiates the connection" statement made
in Section 4 (Connection Setup). This document assumes that the in Section 4 (Connection Setup). This document assumes that the
reference to "connection" refers to the underlying transport reference to "connection" refers to the underlying transport
connection (e.g., TCP). Security implications related to this change connection (e.g., TCP), which the server initiates in a call home
are discussed in Security Considerations (Section 4). connection. Security implications related to this change are
discussed in Security Considerations (Section 4).
2. The NETCONF Server 2. The NETCONF Server or RESTCONF Server
2.1. Protocol Operation 2.1. Protocol Operation
o The NETCONF server initiates a TCP connection to the NETCONF o The NETCONF/RESTCONF server initiates a TCP connection to the
client on one of the IANA-assigned ports for NETCONF Call Home NETCONF/RESTCONF client on one of the IANA-assigned ports for call
(YYYY for netconf-ch-ssh and ZZZZ for netconf-ch-tls). home (PORT-X for netconf-ch-ssh, PORT-Y for netconf-ch-tls, or
PORT-Z for restconf-ch-tls).
o The TCP connection is accepted and a TCP session is established. o The TCP connection is accepted and a TCP session is established.
o Using this TCP session, the NETCONF server immediately starts o Using this TCP session, the NETCONF/RESTCONF server immediately
either the SSH-server or the TLS-server protocol, depending on starts either the SSH-server or the TLS-server protocol, depending
which port is connected. The NETCONF server MUST start the SSH- on which port is connected. The server MUST start the SSH-server
server protocol when port YYYY is connected and the TLS-server protocol when port PORT-X is connected or the TLS-server protocol
protocol when port ZZZZ is connected. The SSH-server and TLS- when either port PORT-Y or PORT-Z is connected. The SSH-server
server protocols are described by [RFC4253] and [RFC5246] and TLS-server protocols are described by [RFC4253] and [RFC5246]
respectively. respectively.
o The NETCONF protocol proceeds normally for SSH and TLS, as defined o When port PORT-X or PORT-Y is connected, the NETCONF protocol
in [RFC6242] and [RFC5539] respectively. proceeds normally for SSH and TLS, as defined in [RFC6242] and
[RFC5539] respectively. When port PORT-Z is connected, the
RESTCONF protocol proceeds normally for TLS, as defined in
[draft-ietf-netconf-restconf].
2.2. Configuration Data Model 2.2. Configuration Data Model
How to configure a NETCONF server to initiate a NETCONF Call Home How to configure a NETCONF or RESTCONF server to initiate a call home
connection is outside the scope of this document, as implementations connection is outside the scope of this document, as implementations
can support this protocol using proprietary configuration data can support this protocol using proprietary configuration data
models. That said, a YANG [RFC6020] model for configuring NETCONF models. That said, a YANG [RFC6020] model for configuring both
Call Home is provided in [draft-ietf-netconf-server-model]. NETCONF Call Home and RESTCONF Call Home is provided in
[draft-ietf-netconf-server-model].
3. The NETCONF Client 3. The NETCONF Client or RESTCONF Client
3.1. Protocol Operation 3.1. Protocol Operation
o The NETCONF client listens for TCP connections on one or both of o The NETCONF/RESTCONF client listens for TCP connections on one or
the IANA-assigned ports for NETCONF Call Home (YYYY for netconf- all of the IANA-assigned ports for NETCONF Call Home (PORT-X for
ch-ssh and ZZZZ for netconf-ch-tls). netconf-ch-ssh and PORT-Y for netconf-ch-tls) or RESTCONF Call
Home (PORT-Z for restconf-ch-tls).
o The NETCONF client accepts an incoming TCP connection and a TCP o The NETCONF/RESTCONF client accepts an incoming TCP connection and
session is established. a TCP session is established.
o Using this TCP session, the NETCONF client immediately starts o Using this TCP session, the NETCONF/RESTCONF client immediately
either the SSH-client or the TLS-client protocol, depending on starts either the SSH-client or the TLS-client protocol, depending
which port is connected. The NETCONF client MUST start the SSH- on which port is connected. The client MUST start the SSH-client
client protocol when port YYYY is connected and the TLS-client protocol when port PORT-X is connected and the TLS-client protocol
protocol when port ZZZZ is connected. The SSH-client and TLS- when port PORT-Y or PORT-Z is connected. The SSH-client and TLS-
client protocols are described by [RFC4253] and [RFC5246] client protocols are described by [RFC4253] and [RFC5246]
respectively. respectively.
o The NETCONF protocol proceeds normally for SSH and TLS, as is o When port PORT-X or PORT-Y is connected, the NETCONF protocol
defined in [RFC6242] and [RFC5539] respectively. proceeds normally for SSH and TLS, as defined in [RFC6242] and
[RFC5539] respectively. When port PORT-Z is connected, the
RESTCONF protocol proceeds normally for TLS, as defined in
[draft-ietf-netconf-restconf].
3.2. Server Identification and Verification 3.2. Server Identification and Verification
Under normal circumstances, a NETCONF client initiates the NETCONF Under normal circumstances, a NETCONF/RESTCONF client initiates the
connection to the NETCONF server. This action provides essential connection to the NETCONF/RESTCONF server. This action provides
input to verify the NETCONF server's identity. For instance, when essential input to verify the NETCONF/RESTCONF server's identity.
using TLS, the input can be compared to the domain names and IP For instance, when using TLS, the input can be compared to the domain
addresses encoded in X.509 certificates. Similarly, when using SSH, names and IP addresses encoded in X.509 certificates. Similarly,
the input can be compared to information persisted previously. when using SSH, the input can be compared to information persisted
previously.
However, when receiving a NETCONF Call Home connection, the NETCONF However, when receiving a call home connection, the NETCONF/RESTCONF
client does not have any context leading it to know the connection is client does not have any context leading it to know the connection is
from a particular NETCONF server. Thus the NETCONF client must from a particular NETCONF/RESTCONF server. Thus the NETCONF/RESTCONF
derive the NETCONF server's identity using information provided by client must derive the NETCONF/RESTCONF server's identity using
the network and the NETCONF server itself. This section describes information provided by the network and the NETCONF/RESTCONF server
strategies a NETCONF client can use to identify a NETCONF server. itself. This section describes strategies a NETCONF/RESTCONF client
can use to identify a NETCONF/RESTCONF server.
In addition to identifying a NETCONF server, a NETCONF client must In addition to identifying a NETCONF/RESTCONF server, a NETCONF/
also be able to verify the NETCONF server's credentials. Verifying a RESTCONF client must also be able to verify the NETCONF/RESTCONF
NETCONF server's credentials is necessary under normal circumstances server's credentials. Verifying a NETCONF/RESTCONF server's
but, due to call home being commonly used for newly deployed NETCONF credentials is necessary under normal circumstances but, due to call
servers, how to verify its credentials the very first time becomes a home being commonly used for newly deployed NETCONF/RESTCONF servers,
prominent concern. Therefore, this section also describes strategies how to verify its credentials the very first time becomes a prominent
a NETCONF client can use to verify a NETCONF server's credentials. concern. Therefore, this section also describes strategies a
NETCONF/RESTCONF client can use to verify a NETCONF/RESTCONF server's
credentials.
The first information a NETCONF client learns from a NETCONF Call The first information a NETCONF/RESTCONF client learns from a call
Home connection is the IP address of the NETCONF server, as provided rhHome connection is the IP address of the NETCONF/RESTCONF server,
by the source address of the TCP connection. This IP address could as provided by the source address of the TCP connection. This IP
be used as an identifier directly, but doing so would only work in address could be used as an identifier directly, but doing so would
networks that use known static addresses, in which case a standard only work in networks that use known static addresses, in which case
NETCONF connection would have worked just as well. Due to this a standard NETCONF/RESTCONF connection would have worked just as
limited use, it is not recommended to identify a NETCONF server based well. Due to this limited use, it is not recommended to identify a
on its source IP address. NETCONF/RESTCONF server based on its source IP address.
The next information a NETCONF client learns is provided by the The next information a NETCONF/RESTCONF client learns is provided by
NETCONF server in the form of a host-key or a certificate, for the the NETCONF/RESTCONF server in the form of a host-key or a
SSH and TLS protocols respectively. Without examining the contents certificate, for the SSH and TLS protocols respectively. Without
of the host-key or certificate, it is possible to form an identity examining the contents of the host-key or certificate, it is possible
for the NETCONF server using it (e.g., a fingerprint), since each to form an identity for the NETCONF/RESTCONF server using it directly
NETCONF server is assumed to have a statistically unique public key, (e.g., a fingerprint), since each NETCONF/RESTCONF server is assumed
even in virtualized environments. This strategy also provides a to have a statistically unique public key, even in virtualized
mechanism to verify the NETCONF server, in that a secure connection environments. This strategy also provides a mechanism to verify the
can only be established with the NETCONF server having the matching 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, private key. This strategy is commonly implemented by SSH clients,
and could be used equally well by TLS-based clients, such as may be and could be used equally well by TLS-based clients, such as may be
required when the NETCONF servers have self-signed certificates. required when the NETCONF/RESTCONF servers have self-signed
This strategy is viable and useful when the NETCONF servers call home certificates. This strategy is viable and useful when the NETCONF/
using either SSH with standard RSA/DSA host-keys, or using TLS with RESTCONF servers call home using either SSH with standard RSA/DSA
self-signed certificates. host-keys, or using TLS with self-signed certificates.
Yet another option for identifying a NETCONF server is for its host Yet another option for identifying a NETCONF/RESTCONF server is for
key or certificate to encode its identity directly (e.g., within the its host key or certificate to encode its identity directly (e.g.,
"Subject" field). However, in order to trust the content encoded within the "Subject" field). However, in order to trust the content
within a host-key or certificate, it must be signed by a certificate encoded within a host-key or certificate, it must be signed by a
authority trusted by the NETCONF client. This strategy's use of PKI certificate authority trusted by the NETCONF/RESTCONF client. This
enables a NETCONF client to transparently authenticate NETCONF strategy's use of PKI enables a NETCONF/RESTCONF client to
servers, thus eliminating the need for manual authentication, as transparently authenticate NETCONF/RESTCONF servers, thus eliminating
required by the previously discussed strategies. Elimination of the need for manual authentication, as required by the previously
manual steps is needed to achieve scalable solutions, however one can discussed strategies. Elimination of manual steps is needed to
claim that this merely pushes equivalent work to provisioning the achieve scalable solutions, however one can claim that this merely
NETCONF servers with signed credentials. This assessment is accurate pushes equivalent work to provisioning the NETCONF/RESTCONF servers
in general, but not in the case where the manufacturer itself with signed credentials. This assessment is accurate in general, but
provisions the credentials, such as is described by not in the case where the manufacturer itself provisions the
[Std-802.1AR-2009]. When NETCONF servers are pre-provisioned this credentials, such as is described by [Std-802.1AR-2009]. When
way, NETCONF clients can transparently authenticate NETCONF servers NETCONF/RESTCONF servers are pre-provisioned this way, NETCONF/
using just the manufacturer's trust anchor and a list of expected RESTCONF clients can transparently authenticate NETCONF/RESTCONF
NETCONF server identifiers, which could be provided along with servers using just the manufacturer's trust anchor and a list of
shipping information. This strategy is recommended for all expected NETCONF/RESTCONF server identifiers, which could be provided
deployment scenarios. along with shipping information. This strategy is recommended for
all deployment scenarios.
In discussing the use of certificates, it is worth noting that TLS In discussing the use of certificates, it is worth noting that TLS
uses X.509 certificates by default. However, to use X.509 uses X.509 certificates by default. However, to use X.509
certificates with SSH, both the NETCONF client and server must certificates with SSH, both the NETCONF client and server must
support [RFC6187]. support [RFC6187].
4. Security Considerations 4. Security Considerations
The security considerations described throughout [RFC6242] and The security considerations described throughout [RFC6242] and
[RFC5539], and by extension [RFC4253] and [RFC5246], apply here as [RFC5539], and by extension [RFC4253], [RFC5246], and
well. [draft-ietf-netconf-restconf] apply here as well.
This RFC deviates from standard SSH and TLS usage by having the SSH/ This RFC deviates from standard SSH and TLS usage by having the SSH/
TLS server initiate the underlying TCP connection. For SSH, TLS server initiate the underlying TCP connection. For SSH,
[RFC4253] says "the client initiates the connection", whereas for [RFC4253] says "the client initiates the connection", whereas for
TLS, [RFC5246] says it is layered on top of "some reliable transport TLS, [RFC5246] says it is layered on top of "some reliable transport
protocol" without further attribution. protocol" without further attribution.
For SSH, not having the SSH client initiate the TCP connection means Not having the SSH/TLS client initiate the TCP connection means that
that it does not have a preconceived notion of the SSH server's it does not have a preconceived notion of the SSH/TLS server's
identity, and therefore must dynamically derive one from information identity, and therefore must dynamically derive one from information
provided by the network or the SSH server itself. Security provided by the network or the SSH/TLS server itself. Security
Considerations for strategies for this are described in Section 3.2. Considerations for strategies for this are described in Section 3.2.
An attacker could DoS the NETCONF client by having it perform An attacker could DoS the NETCONF/RESTCONF client by having it
computationally expensive operations, before deducing that the perform computationally expensive operations, before deducing that
attacker doesn't posses a valid key. This is no different than any the attacker doesn't posses a valid key. This is no different than
secured service and all common precautions apply (e.g., blacklisting any secured service and all common precautions apply (e.g.,
the source address after a set number of unsuccessful login blacklisting the source address after a set number of unsuccessful
attempts). login attempts).
5. IANA Considerations 5. IANA Considerations
This document requests that IANA assigns two TCP port numbers in the This document requests that IANA assigns three TCP port numbers in
"Registered Port Numbers" range with the service names "netconf-ch- the "Registered Port Numbers" range with the service names "netconf-
ssh" and "netconf-ch-tls". These ports will be the default ports for ch-ssh", "netconf-ch-tls", and "restconf-ch-tls". These ports will
NETCONF Call Home protocol when using SSH and TLS respectively. be the default ports for NETCONF Call Home and RESTCONF Call Home
Below is the registration template following the rules in [RFC6335]. protocols. Below is the registration template following the rules in
[RFC6335].
Service Name: netconf-ch-ssh Service Name: netconf-ch-ssh
Transport Protocol(s): TCP Transport Protocol(s): TCP
Assignee: IESG <iesg@ietf.org> Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org> Contact: IETF Chair <chair@ietf.org>
Description: NETCONF Call Home (SSH) Description: NETCONF Call Home (SSH)
Reference: RFC XXXX Reference: RFC XXXX
Port Number: YYYY Port Number: PORT-X
Service Name: netconf-ch-tls Service Name: netconf-ch-tls
Transport Protocol(s): TCP Transport Protocol(s): TCP
Assignee: IESG <iesg@ietf.org> Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org> Contact: IETF Chair <chair@ietf.org>
Description: NETCONF Call Home (TLS) Description: NETCONF Call Home (TLS)
Reference: RFC XXXX Reference: RFC XXXX
Port Number: ZZZZ 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
6. Acknowledgements 6. Acknowledgements
The author would like to thank for following for lively discussions The author would like to thank for following for lively discussions
on list and in the halls (ordered by last name): Andy Bierman, Martin on list and in the halls (ordered by last name): Andy Bierman, Martin
Bjorklund, Mehmet Ersue, Wes Hardaker, Stephen Hanna, David Bjorklund, Mehmet Ersue, Wes Hardaker, Stephen Hanna, David
Harrington, Jeffrey Hutzelman, Radek Krejci, Alan Luchuk, Mouse, Russ Harrington, Jeffrey Hutzelman, Radek Krejci, Alan Luchuk, Mouse, Russ
Mundy, Tom Petch, Peter Saint-Andre, Joe Touch, Sean Turner, Bert Mundy, Tom Petch, Peter Saint-Andre, Joe Touch, Sean Turner, Bert
Wijnen. Wijnen.
skipping to change at page 9, line 25 skipping to change at page 9, line 44
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, June 2011. Shell (SSH)", RFC 6242, June 2011.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, RFC Transport Protocol Port Number Registry", BCP 165, RFC
6335, August 2011. 6335, August 2011.
[draft-ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ieft-netconf-restconf-04 (work in
progress), 2014.
7.2. Informative References 7.2. Informative References
[Std-802.1AR-2009] [Std-802.1AR-2009]
IEEE SA-Standards Board, "IEEE Standard for Local and IEEE SA-Standards Board, "IEEE Standard for Local and
metropolitan area networks - Secure Device Identity", metropolitan area networks - Secure Device Identity",
December 2009, <http://standards.ieee.org/findstds/ December 2009, <http://standards.ieee.org/findstds/
standard/802.1AR-2009.html>. standard/802.1AR-2009.html>.
[draft-ietf-netconf-server-model] [draft-ietf-netconf-server-model]
Watsen, K. and J. Schoenwaelder, "NETCONF Server Watsen, K. and J. Schoenwaelder, "NETCONF Server
skipping to change at page 10, line 21 skipping to change at page 11, line 21
o The terms "network element" and "management system" are now only o The terms "network element" and "management system" are now only
used in the Motivation section. used in the Motivation section.
o Restructured doc a little to create an Introduction section. o Restructured doc a little to create an Introduction section.
o Fixed reference in Applicability Statement so it would work o Fixed reference in Applicability Statement so it would work
equally well for SSH and TLS. equally well for SSH and TLS.
o Fixed reported odd wording and three references. o Fixed reported odd wording and three references.
A.2. 01 to 02
o Added call home support for the RESTCONF protocol.
o Fixed paragraph 3 of Security Considerations to equally apply to
the TLS protocol.
Author's Address Author's Address
Kent Watsen Kent Watsen
Juniper Networks Juniper Networks
EMail: kwatsen@juniper.net EMail: kwatsen@juniper.net
 End of changes. 46 change blocks. 
155 lines changed or deleted 191 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/