Internet Engineering Task Force (IETF) K. Watsen
Request for Comments: 8071 Juniper Networks
Category: Standards Track February 2017
ISSN: 2070-1721
Internet Engineering Task Force (IETF) K. Watsen
Request for Comments: 8071 Juniper Networks
Category: Standards Track February 2017
ISSN: 2070-1721
NETCONF Call Home and RESTCONF Call Home
NETCONF呼叫总部和RESTCONF呼叫总部
Abstract
摘要
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.
此RFC提供NETCONF呼叫总部和RESTCONF呼叫总部，这使NETCONF或RESTCONF服务器能够分别启动到NETCONF或RESTCONF客户端的安全连接。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8071.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8071.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Terminology . . . . . . . . . . . . . . . . 3
1.3. Applicability Statement . . . . . . . . . . . . . . . . . 4
1.4. Relation to RFC 4253 . . . . . . . . . . . . . . . . . . 4
1.5. The NETCONF/RESTCONF Convention . . . . . . . . . . . . . 4
2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5
3. The NETCONF or RESTCONF Client . . . . . . . . . . . . . . . 5
3.1. Client Protocol Operation . . . . . . . . . . . . . . . . 5
3.2. Client Configuration Data Model . . . . . . . . . . . . . 7
4. The NETCONF or RESTCONF Server . . . . . . . . . . . . . . . 7
4.1. Server Protocol Operation . . . . . . . . . . . . . . . . 7
4.2. Server Configuration Data Model . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Terminology . . . . . . . . . . . . . . . . 3
1.3. Applicability Statement . . . . . . . . . . . . . . . . . 4
1.4. Relation to RFC 4253 . . . . . . . . . . . . . . . . . . 4
1.5. The NETCONF/RESTCONF Convention . . . . . . . . . . . . . 4
2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5
3. The NETCONF or RESTCONF Client . . . . . . . . . . . . . . . 5
3.1. Client Protocol Operation . . . . . . . . . . . . . . . . 5
3.2. Client Configuration Data Model . . . . . . . . . . . . . 7
4. The NETCONF or RESTCONF Server . . . . . . . . . . . . . . . 7
4.1. Server Protocol Operation . . . . . . . . . . . . . . . . 7
4.2. Server Configuration Data Model . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
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.
此RFC提供NETCONF呼叫总部和RESTCONF呼叫总部，这使NETCONF或RESTCONF服务器能够分别启动到NETCONF或RESTCONF客户端的安全连接。
NETCONF Call Home supports both of the secure transports used by the Network Configuration Protocol (NETCONF) [RFC6241], Secure Shell (SSH), and Transport Layer Security (TLS). The NETCONF protocol's binding to SSH is defined in [RFC6242]. The NETCONF protocol's binding to TLS is defined in [RFC7589].
NETCONF呼叫总部支持网络配置协议（NETCONF）[RFC6241]、安全Shell（SSH）和传输层安全性（TLS）使用的两种安全传输。NETCONF协议与SSH的绑定在[RFC6242]中定义。[RFC7589]中定义了NETCONF协议与TLS的绑定。
RESTCONF Call Home only supports TLS, the same as the RESTCONF protocol [RFC8040]. The RESTCONF protocol's binding to TLS is defined in [RFC8040].
RESTCONF回拨仅支持TLS，与RESTCONF协议[RFC8040]相同。RESTCONF协议与TLS的绑定在[RFC8040]中定义。
The SSH protocol is defined in [RFC4253]. The TLS protocol is defined in [RFC5246]. Both the SSH and TLS protocols are layered on top of the TCP protocol, which is defined in [RFC793].
The SSH protocol is defined in [RFC4253]. The TLS protocol is defined in [RFC5246]. Both the SSH and TLS protocols are layered on top of the TCP protocol, which is defined in [RFC793].translate error, please retry
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 client-initiated 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.
与客户端启动的NETCONF和RESTCONF连接相比，NETCONF回拨和RESTCONF回拨在各自的协议栈中保留除一个以外的所有客户端/服务器角色。唯一的角色转换发生在TCP层；也就是说，哪个对等方是TCP客户端，哪个是TCP服务器。
For example, a network element is traditionally the TCP server. However, when calling home, the network element initially assumes the role of the TCP client. The network element's secure transport-layer roles (SSH server, TLS server) and its application-layer roles (NETCONF server, RESTCONF server) all remain the same.
例如，传统上，网元是TCP服务器。但是，在呼叫总部时，网元最初承担TCP客户端的角色。网元的安全传输层角色（SSH服务器、TLS服务器）及其应用层角色（NETCONF服务器、RESTCONF服务器）都保持不变。
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.
安全传输层（SSH、TLS）和应用层（NETCONF、RESTCONF）角色的一致性使部署的网络管理基础设施能够方便地支持呼叫总部。例如，现有的证书链和用户身份验证机制不受回拨的影响。
Call home is generally useful for both the initial deployment and ongoing management of networking elements. Here are some scenarios enabled by call home:
呼叫总部通常对网络元素的初始部署和持续管理都很有用。以下是呼叫总部启用的一些场景：
o The network element may proactively "call home" after being powered on for the first time in order to register itself with its management system.
o 网元可在第一次通电后主动“呼叫总部”，以便在其管理系统中注册自身。
o 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 (e.g., dynamic DNS).
o 网元可以以动态地向其分配IP地址的方式访问网络，但不将其分配的IP地址注册到映射服务（例如，动态DNS）。
o The network element may be deployed behind a firewall that implements Network Address Translation (NAT) for all internal network IP addresses.
o 网元可以部署在防火墙后面，防火墙为所有内部网络IP地址实现网络地址转换（NAT）。
o The network element may be deployed behind a firewall that does not allow any management access to the internal network.
o 网元可以部署在防火墙后面，防火墙不允许对内部网络进行任何管理访问。
o The network element may be configured in "stealth mode", and thus does not have any open ports for the management system to connect to.
o 网元可以在“隐形模式”下配置，因此没有任何可供管理系统连接的开放端口。
o 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.
o 运营商可能更愿意让网元启动管理连接，认为在数据中心中保护一个开放端口比在网络中的每个网元上拥有一个开放端口更容易。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The techniques described in this document are suitable for network management scenarios such as the ones described in Section 1.1. However, these techniques are only defined for NETCONF Call Home and RESTCONF Call Home, as described in this document.
本文档中描述的技术适用于网络管理场景，如第1.1节中描述的场景。但是，这些技术仅针对NETCONF呼叫总部和RESTCONF呼叫总部定义，如本文档所述。
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 [RFC6241], and is specified for the RESTCONF protocol in Sections 2.4 and 2.5 of [RFC8040].
这种限制的原因是不同的协议具有不同的安全性假设。NETCONF和RESTCONF协议要求客户端和服务器验证另一方的身份。[RFC6241]第2.2节中规定了NETCONF协议的这一要求，[RFC8040]第2.4节和第2.5节中规定了RESTCONF协议的这一要求。
This contrasts with the base SSH and TLS protocols, which do not require programmatic verification of the other party (Section 9.3.4 of [RFC4251], Section 4 of [RFC4252], and Section 7.3 of [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 risk assessment. A risk assessment for this RFC is in the Security Considerations section (Section 5).
这与基本SSH和TLS协议不同，后者不需要另一方的程序验证（RFC4251第9.3.4节、[RFC4252第4节、[RFC5246]第7.3节）。在这种情况下，允许SSH/TLS服务器联系SSH/TLS客户端将打开新的漏洞。任何将SSH/TLS呼叫总部用于NETCONF或RESTCONF之外的目的都需要进行彻底的上下文风险评估。本RFC的风险评估见安全注意事项部分（第5节）。
This document uses the SSH Transport Layer Protocol [RFC4253] with the exception that the statement "The client initiates the connection" made in Section 4 of RFC 4253 does not apply. Assuming the reference to the client means "SSH client" and the reference to the 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 Section 5.
本文档使用SSH传输层协议[RFC4253]，但RFC 4253第4节中的“客户端启动连接”语句不适用。假设对客户端的引用意味着“SSH客户端”，而对连接的引用意味着“TCP连接”，则此语句在呼叫总部中不成立，因为网元是SSH服务器，但仍然启动TCP连接。第5节讨论了与此更改相关的安全影响。
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.
在本文件的其余部分，术语“NETCONF/RESTCONF”被用作文本“NETCONF或RESTCONF”的缩写。NETCONF/RESTCONF的缩写并不要求或暗示客户机或服务器必须同时实现NETCONF标准和RESTCONF标准。
The diagram below illustrates call home from a protocol-layering perspective:
下图从协议分层的角度说明了呼叫总部：
NETCONF/RESTCONF NETCONF/RESTCONF
Server Client
| |
| 1. TCP |
|----------------------------------->|
| |
| |
| 2. SSH/TLS |
|<-----------------------------------|
| |
| |
| 3. NETCONF/RESTCONF |
|<-----------------------------------|
| |
Note: Arrows point from the "client" to
the "server" at each protocol layer.
NETCONF/RESTCONF NETCONF/RESTCONF
Server Client
| |
| 1. TCP |
|----------------------------------->|
| |
| |
| 2. SSH/TLS |
|<-----------------------------------|
| |
| |
| 3. NETCONF/RESTCONF |
|<-----------------------------------|
| |
Note: Arrows point from the "client" to
the "server" at each protocol layer.
Figure 1: Call Home Sequence Diagram
图1：呼叫总部序列图
This diagram makes the following points:
此图说明了以下几点：
1. The NETCONF/RESTCONF server begins by initiating a TCP connection to the NETCONF/RESTCONF client.
1. NETCONF/RESTCONF服务器首先启动到NETCONF/RESTCONF客户端的TCP连接。
2. Using this TCP connection, the NETCONF/RESTCONF client initiates an SSH/TLS session to the NETCONF/RESTCONF server.
2. 使用此TCP连接，NETCONF/RESTCONF客户端向NETCONF/RESTCONF服务器发起SSH/TLS会话。
3. Using this SSH/TLS session, the NETCONF/RESTCONF client initiates a NETCONF/RESTCONF session to the NETCONF/RESTCONF server.
3. 使用此SSH/TLS会话，NETCONF/RESTCONF客户端向NETCONF/RESTCONF服务器发起NETCONF/RESTCONF会话。
The term "client" is defined in [RFC6241], Section 1.1. In the context of network management, the NETCONF/RESTCONF client might be a network management system.
术语“客户”的定义见[RFC6241]第1.1节。在网络管理上下文中，NETCONF/RESTCONF客户机可能是一个网络管理系统。
C1 The NETCONF/RESTCONF client listens for TCP connection requests from NETCONF/RESTCONF servers. The client MUST support accepting TCP connections on the IANA-assigned ports defined in Section 6, but MAY be configured to listen to a different port.
C1 NETCONF/RESTCONF客户端侦听来自NETCONF/RESTCONF服务器的TCP连接请求。客户端必须支持在第6节中定义的IANA分配端口上接受TCP连接，但可以配置为侦听其他端口。
C2 The NETCONF/RESTCONF client accepts an incoming TCP connection request and a TCP connection is established.
C2 NETCONF/RESTCONF客户端接受传入的TCP连接请求，并建立TCP连接。
C3 Using this TCP connection, the NETCONF/RESTCONF client starts either the SSH client [RFC4253] or the TLS client [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 4334 and the TLS client protocol is started when the connection is accepted on either port 4335 or port 4336.
C3使用此TCP连接，NETCONF/RESTCONF客户端启动SSH客户端[RFC4253]或TLS客户端[RFC5246]协议。例如，假设使用IANA分配的端口，SSH客户端协议在端口4334上接受连接时启动，TLS客户端协议在端口4335或端口4336上接受连接时启动。
C4 When using TLS, the NETCONF/RESTCONF client MUST advertise "peer_allowed_to_send", as defined by [RFC6520]. This is required so that NETCONF/RESTCONF servers can depend on it being there for call home connections, when keep-alives are needed the most.
C4当使用TLS时，NETCONF/RESTCONF客户端必须公布[RFC6520]定义的“允许发送的对等方”。这是必需的，这样NETCONF/RESTCONF服务器就可以在最需要保持有效性的时候依靠它进行呼叫总部连接。
C5 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. If a certificate is presented and it contains revocation-checking information, the NETCONF/RESTCONF client SHOULD check the revocation status of the certificate. If it is determined that a certificate has been revoked, the client MUST immediately close the connection.
C5作为建立SSH或TLS连接的一部分，NETCONF/RESTCONF客户端必须验证服务器提供的主机密钥或证书。此验证可通过证书路径验证或将主机密钥或证书与以前受信任或“固定”的值进行比较来完成。如果提供了一个证书，并且该证书包含吊销检查信息，则NETCONF/RESTCONF客户端应检查证书的吊销状态。如果确定证书已被吊销，客户端必须立即关闭连接。
C6 If certificate path validation is used, the NETCONF/RESTCONF client MUST ensure that the presented certificate has a valid chain of trust to a preconfigured issuer certificate, and that the presented certificate encodes an "identifier" [RFC6125] that the client was aware of before the connection attempt. How identifiers are encoded in certificates MAY be determined by a policy associated with the certificate's issuer. For instance, a given issuer may be known to only sign IDevID certificates [Std-802.1AR-2009] having a unique identifier (e.g., a serial number) in the X.509 certificate's "CommonName" field.
C6如果使用证书路径验证，NETCONF/RESTCONF客户端必须确保所提供的证书与预配置的颁发者证书具有有效的信任链，并且所提供的证书编码了客户端在连接尝试之前知道的“标识符”[RFC6125]。标识符在证书中的编码方式可由与证书的颁发者相关联的策略确定。例如，已知给定的颁发者可能仅签署在X.509证书的“CommonName”字段中具有唯一标识符（例如，序列号）的IDevID证书[Std-802.1AR-2009]。
C7 After the server's host key or certificate is validated, the SSH or TLS protocol proceeds as normal to establish an SSH or TLS connection. When performing client authentication with the NETCONF/RESTCONF server, the NETCONF/RESTCONF client MUST only use credentials that it had previously associated for the NETCONF/RESTCONF server's presented host key or server certificate.
C7验证服务器的主机密钥或证书后，SSH或TLS协议将正常进行以建立SSH或TLS连接。在使用NETCONF/RESTCONF服务器执行客户端身份验证时，NETCONF/RESTCONF客户端必须仅使用它以前与NETCONF/RESTCONF服务器提供的主机密钥或服务器证书关联的凭据。
C8 Once the SSH or TLS connection is established, the NETCONF/ RESTCONF client starts either the NETCONF client [RFC6241] or RESTCONF client [RFC8040] protocol. Assuming the use of the IANA-assigned ports, the NETCONF client protocol is started when the connection is accepted on either port 4334 or port 4335 and the RESTCONF client protocol is started when the connection is accepted on port 4336.
C8一旦建立了SSH或TLS连接，NETCONF/RESTCONF客户端将启动NETCONF客户端[RFC6241]或RESTCONF客户端[RFC8040]协议。假设使用IANA分配的端口，当在端口4334或端口4335上接受连接时，NETCONF客户端协议启动；当在端口4336上接受连接时，RESTCONF客户端协议启动。
How a NETCONF or RESTCONF client is configured is outside the scope of this document. For instance, such a configuration might be used to enable listening for call home connections, configuring trusted certificate issuers, or configuring identifiers for expected connections. That said, YANG [RFC7950] data modules for configuring NETCONF and RESTCONF clients, including call home, are provided in [NETCONF-MODELS] and [RESTCONF-MODELS].
NETCONF或RESTCONF客户端的配置方式超出了本文档的范围。例如，这种配置可用于监听呼叫总部连接、配置可信证书颁发者或配置预期连接的标识符。也就是说，[NETCONF-MODELS]和[RESTCONF-MODELS]中提供了用于配置NETCONF和RESTCONF客户端（包括呼叫总部）的[RFC7950]数据模块。
The term "server" is defined in [RFC6241], Section 1.1. In the context of network management, the NETCONF/RESTCONF server might be a network element or a device.
术语“服务器”的定义见[RFC6241]第1.1节。在网络管理上下文中，NETCONF/RESTCONF服务器可能是一个网元或设备。
S1 The NETCONF/RESTCONF server initiates a TCP connection request to the NETCONF/RESTCONF client. The source port may be per local policy or randomly assigned by the operating system. The server MUST support connecting to one of the IANA-assigned ports defined in Section 6, but MAY be configured to connect to a different port. Using the IANA-assigned ports, the server connects to port 4334 for NETCONF over SSH, port 4335 for NETCONF over TLS, and port 4336 for RESTCONF over TLS.
S1 NETCONF/RESTCONF服务器向NETCONF/RESTCONF客户端发起TCP连接请求。源端口可以根据本地策略分配，也可以由操作系统随机分配。服务器必须支持连接到第6节中定义的IANA分配端口之一，但可以配置为连接到其他端口。使用IANA分配的端口，服务器通过SSH连接到NETCONF的端口4334，通过TLS连接到NETCONF的端口4335，通过TLS连接到RESTCONF的端口4336。
S2 The TCP connection request is accepted and a TCP connection is established.
S2接受TCP连接请求并建立TCP连接。
S3 Using this TCP connection, the NETCONF/RESTCONF server starts either the SSH server [RFC4253] or the TLS server [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 4334 and the TLS server protocol is used after connecting to either remote port 4335 or remote port 4336.
S3使用此TCP连接，NETCONF/RESTCONF服务器启动SSH服务器[RFC4253]或TLS服务器[RFC5246]协议，具体取决于其配置方式。例如，假设使用IANA分配的端口，SSH服务器协议在连接到远程端口4334后使用，TLS服务器协议在连接到远程端口4335或远程端口4336后使用。
S4 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 all intermediate certificates leading up to a well-known and trusted issuer. How to send a list of certificates is defined for SSH in [RFC6187], Section 2.1, and for TLS in [RFC5246], Section 7.4.2.
S4作为建立SSH或TLS连接的一部分，NETCONF/RESTCONF服务器将向客户端发送其主机密钥或证书。如果发送了证书，服务器还必须将所有中间证书发送给知名的可信颁发者。如何发送证书列表在[RFC6187]第2.1节中为SSH定义，在[RFC5246]第7.4.2节中为TLS定义。
S5 Establishing an SSH or TLS session requires server authentication of client credentials in all cases except with RESTCONF, where some client authentication schemes occur after the secure transport connection (TLS) has been established. If transport-level (SSH or TLS) client authentication is required, and the client is unable to successfully authenticate itself to the server in an amount of time defined by local policy, the server MUST close the connection.
S5建立SSH或TLS会话需要在所有情况下对客户机凭据进行服务器身份验证，RESTCONF除外，其中一些客户机身份验证方案在建立安全传输连接（TLS）后发生。如果需要传输级别（SSH或TLS）客户端身份验证，并且客户端无法在本地策略定义的时间内成功向服务器进行身份验证，则服务器必须关闭连接。
S6 Once the SSH or TLS connection is established, the NETCONF/ RESTCONF server starts either the NETCONF server [RFC6241] or RESTCONF server [RFC8040] 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 4334 or remote port 4335, and the RESTCONF server protocol is used after connecting to remote port 4336.
S6一旦建立SSH或TLS连接，NETCONF/RESTCONF服务器将启动NETCONF服务器[RFC6241]或RESTCONF服务器[RFC8040]协议，具体取决于其配置方式。假设使用IANA分配的端口，在连接到远程端口4334或远程端口4335后使用NETCONF服务器协议，在连接到远程端口4336后使用RESTCONF服务器协议。
S7 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 [RFC6520]. For SSH-based connections, per Section 4 of [RFC4254], the server SHOULD send an SSH_MSG_GLOBAL_REQUEST message with a purposely nonexistent "request name" value (e.g., keepalive@ietf.org) and the "want reply" value set to '1'.
S7如果需要持久连接，作为连接启动器的NETCONF/RESTCONF服务器应使用保持活动机制主动测试连接的有效性。对于基于TLS的连接，NETCONF/RESTCONF服务器应发送[RFC6520]定义的HeartbeatRequest消息。对于基于SSH的连接，根据[RFC4254]第4节，服务器应发送一条SSH_MSG_GLOBAL_请求消息，其中包含故意不存在的“请求名称”值（例如。，keepalive@ietf.org)“想要回复”的值设置为“1”。
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. That said, YANG [RFC7950] data modules for configuring NETCONF and RESTCONF servers, including call home, are provided in [NETCONF-MODELS] and [RESTCONF-MODELS].
NETCONF或RESTCONF服务器的配置方式超出了本文档的范围。这包括可用于指定主机名、IP地址、端口、算法或其他相关参数的配置。也就是说，[NETCONF-MODELS]和[RESTCONF-MODELS]中提供了用于配置NETCONF和RESTCONF服务器（包括呼叫总部）的[RFC7950]数据模块。
The security considerations described in [RFC6242] and [RFC7589], and by extension [RFC4253], [RFC5246], and [RFC8040] apply here as well.
[RFC6242]和[RFC7589]以及[RFC4253]、[RFC5246]和[RFC8040]中描述的安全注意事项也适用于此处。
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 [RFC4253], which says "the client initiates the connection" and also [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."
此RFC通过让SSH/TLS服务器启动底层TCP连接而偏离了标准SSH和TLS使用。这种逆转与[RFC4253]和[RFC6125]不一致，前者说“客户机启动连接”，后者说“客户机必须构建一个可接受的参考标识符列表，并且必须独立于服务提供的标识符来执行。”
Risks associated with these variances are centered around server authentication and the inability for clients to compare an independently constructed reference identifier to one presented by the server. To mitigate against these risks, this RFC requires that the NETCONF/RESTCONF client validate the server's SSH host key or certificate, by certificate path validation to a preconfigured issuer certificate, or by comparing the host key or certificate to a previously trusted or "pinned" value. Furthermore, when a certificate is used, this RFC requires that the client be able to match an identifier encoded in the presented certificate with an identifier the client was preconfigured to expect (e.g., a serial number).
与这些差异相关的风险集中在服务器身份验证和客户端无法将独立构造的引用标识符与服务器提供的引用标识符进行比较。为了降低这些风险，此RFC要求NETCONF/RESTCONF客户端通过对预配置的颁发者证书进行证书路径验证，或通过将主机密钥或证书与以前受信任或“固定”的值进行比较，来验证服务器的SSH主机密钥或证书。此外，当使用证书时，此RFC要求客户机能够将提交的证书中编码的标识符与客户机预配置期望的标识符（例如，序列号）匹配。
For cases when the NETCONF/RESTCONF server presents an X.509 certificate, NETCONF/RESTCONF clients should ensure that the preconfigured issuer certificate used for certificate path validation is unique to the manufacturer of the server. That is, the certificate should not belong to a third-party certificate authority that might issue certificates for more than one manufacturer. This is especially important when a client authentication mechanism passing a shared secret (e.g., a password) to the server is used. Not doing so could otherwise lead to a case where the client sends the shared secret to another server that happens to have the same identity (e.g., a serial number) as the server the client was configured to expect.
对于NETCONF/RESTCONF服务器提供X.509证书的情况，NETCONF/RESTCONF客户端应确保用于证书路径验证的预配置颁发者证书是服务器制造商独有的。也就是说，证书不应属于可能为多个制造商颁发证书的第三方证书颁发机构。当使用向服务器传递共享秘密（例如密码）的客户端身份验证机制时，这一点尤为重要。否则，不这样做可能会导致客户端将共享机密发送到另一台服务器，而该服务器恰好与客户端配置为期望的服务器具有相同的标识（例如，序列号）。
Considerations not associated with server authentication follow next.
与服务器身份验证无关的注意事项如下。
Internet-facing hosts running NETCONF Call Home or RESTCONF Call Home will be fingerprinted via scanning tools such as "zmap" [zmap]. Both SSH and TLS provide many ways in which a host can be fingerprinted. SSH and TLS servers are fairly mature and able to withstand attacks, but SSH and TLS clients may not be as robust. Implementers and deployments need to ensure that software update mechanisms are provided so that vulnerabilities can be fixed in a timely fashion.
运行NETCONF呼叫总部或RESTCONF呼叫总部的面向Internet的主机将通过扫描工具（如“zmap”[zmap]）进行指纹识别。SSH和TLS都提供了许多对主机进行指纹识别的方法。SSH和TLS服务器相当成熟，能够抵御攻击，但SSH和TLS客户端可能没有那么健壮。实施者和部署人员需要确保提供软件更新机制，以便及时修复漏洞。
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 possess a valid key. For instance, in TLS 1.3 [TLS1.3], the ClientHello message contains a Key Share value based on an expensive asymmetric key operation. Common precautions mitigating DoS attacks are recommended, such as temporarily blacklisting the source address after a set number of unsuccessful login attempts.
攻击者可以在推断攻击者不拥有有效密钥之前，通过让NETCONF/RESTCONF客户端执行计算代价高昂的操作，对其发起拒绝服务（DoS）攻击。例如，在TLS1.3[TLS1.3]中，ClientHello消息包含一个基于昂贵的非对称密钥操作的密钥共享值。建议采取缓解DoS攻击的常见预防措施，例如在多次登录尝试失败后暂时将源地址列入黑名单。
When using call home with the RESTCONF protocol, special care is required when using some HTTP authentication schemes, especially the Basic [RFC7617] and Digest [RFC7616] schemes, which convey a shared secret (e.g., a password). Implementers and deployments should be sure to review the Security Considerations section in the RFC for any HTTP client authentication scheme used.
在RESTCONF协议中使用回拨时，在使用一些HTTP身份验证方案时需要特别小心，特别是基本[RFC7617]和摘要[RFC7616]方案，它们传递共享秘密（例如密码）。实现人员和部署人员应确保查看RFC中的安全注意事项部分，以了解所使用的任何HTTP客户端身份验证方案。
IANA has assigned three TCP port numbers in the "User Ports" 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 [RFC6335].
IANA在“用户端口”范围内分配了三个TCP端口号，服务名称为“netconf ch ssh”、“netconf ch tls”和“restconf ch tls”。这些端口将是NETCONF呼叫总部和RESTCONF呼叫总部协议的默认端口。以下是遵循[RFC6335]中规则的注册模板。
Service Name: netconf-ch-ssh
Port Number: 4334
Transport Protocol(s): TCP
Description: NETCONF Call Home (SSH)
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Reference: RFC 8071
Service Name: netconf-ch-ssh
Port Number: 4334
Transport Protocol(s): TCP
Description: NETCONF Call Home (SSH)
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Reference: RFC 8071
Service Name: netconf-ch-tls
Port Number: 4335
Transport Protocol(s): TCP
Description: NETCONF Call Home (TLS)
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Reference: RFC 8071
Service Name: netconf-ch-tls
Port Number: 4335
Transport Protocol(s): TCP
Description: NETCONF Call Home (TLS)
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Reference: RFC 8071
Service Name: restconf-ch-tls
Port Number: 4336
Transport Protocol(s): TCP
Description: RESTCONF Call Home (TLS)
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Reference: RFC 8071
Service Name: restconf-ch-tls
Port Number: 4336
Transport Protocol(s): TCP
Description: RESTCONF Call Home (TLS)
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Reference: RFC 8071
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，DOI 10.17487/RFC0793，1981年9月<http://www.rfc-editor.org/info/rfc793>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, January 2006, <http://www.rfc-editor.org/info/rfc4251>.
[RFC4251]Ylonen，T.和C.Lonvick，编辑，“安全外壳（SSH）协议架构”，RFC 4251，DOI 10.17487/RFC4251，2006年1月<http://www.rfc-editor.org/info/rfc4251>.
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, January 2006, <http://www.rfc-editor.org/info/rfc4252>.
[RFC4252]Ylonen，T.和C.Lonvick，Ed.，“安全外壳（SSH）认证协议”，RFC 4252，DOI 10.17487/RFC4252，2006年1月<http://www.rfc-editor.org/info/rfc4252>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, <http://www.rfc-editor.org/info/rfc4253>.
[RFC4253]Ylonen，T.和C.Lonvick，编辑，“安全外壳（SSH）传输层协议”，RFC 4253，DOI 10.17487/RFC4253，2006年1月<http://www.rfc-editor.org/info/rfc4253>.
[RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Connection Protocol", RFC 4254, DOI 10.17487/RFC4254, January 2006, <http://www.rfc-editor.org/info/rfc4254>.
[RFC4254]Ylonen，T.和C.Lonvick，编辑，“安全外壳（SSH）连接协议”，RFC 4254，DOI 10.17487/RFC4254，2006年1月<http://www.rfc-editor.org/info/rfc4254>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施内表示和验证基于域的应用程序服务身份”，RFC 6125，DOI 10.17487/RFC6125，2011年3月<http://www.rfc-editor.org/info/rfc6125>.
[RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure Shell Authentication", RFC 6187, DOI 10.17487/RFC6187, March 2011, <http://www.rfc-editor.org/info/rfc6187>.
[RFC6187]Igoe，K.和D.Stebila，“用于安全外壳身份验证的X.509v3证书”，RFC 6187，DOI 10.17487/RFC6187，2011年3月<http://www.rfc-editor.org/info/rfc6187>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <http://www.rfc-editor.org/info/rfc6241>.
[RFC6241]Enns，R.，Ed.，Bjorklund，M.，Ed.，Schoenwaeld，J.，Ed.，和A.Bierman，Ed.，“网络配置协议（NETCONF）”，RFC 6241，DOI 10.17487/RFC6241，2011年6月<http://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, <http://www.rfc-editor.org/info/rfc6242>.
[RFC6242]Wasserman，M.“在安全外壳上使用NETCONF协议（SSH）”，RFC 6242，DOI 10.17487/RFC6242，2011年6月<http://www.rfc-editor.org/info/rfc6242>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <http://www.rfc-editor.org/info/rfc6335>.
[RFC6335]Cotton，M.，Eggert，L.，Touch，J.，Westerlund，M.，和S.Cheshire，“互联网分配号码管理局（IANA）服务名称和传输协议端口号注册管理程序”，BCP 165，RFC 6335，DOI 10.17487/RFC6335，2011年8月<http://www.rfc-editor.org/info/rfc6335>.
[RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, DOI 10.17487/RFC6520, February 2012, <http://www.rfc-editor.org/info/rfc6520>.
[RFC6520]Seggelmann，R.，Tuexen，M.和M.Williams，“传输层安全性（TLS）和数据报传输层安全性（DTLS）心跳扩展”，RFC 6520，DOI 10.17487/RFC6520，2012年2月<http://www.rfc-editor.org/info/rfc6520>.
[RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication", RFC 7589, DOI 10.17487/RFC7589, June 2015, <http://www.rfc-editor.org/info/rfc7589>.
[RFC7589]Badra，M.，Luchuk，A.，和J.Schoenwaeld，“在传输层安全（TLS）上使用NETCONF协议，并进行相互X.509身份验证”，RFC 7589，DOI 10.17487/RFC7589，2015年6月<http://www.rfc-editor.org/info/rfc7589>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <http://www.rfc-editor.org/info/rfc8040>.
[RFC8040]Bierman，A.，Bjorklund，M.，和K.Watsen，“RESTCONF协议”，RFC 8040，DOI 10.17487/RFC8040，2017年1月<http://www.rfc-editor.org/info/rfc8040>.
[NETCONF-MODELS] Watsen, K., Wu, G., and J. Schoenwaelder, "NETCONF Client and Server Models", Work in Progress, draft-ietf-netconf-netconf-client-server-01, November 2016.
[NETCONF-MODELS]Watsen，K.，Wu，G.，和J.Schoenwaeld，“NETCONF客户端和服务器模型”，正在进行的工作，草稿-ietf-NETCONF-NETCONF-Client-Server-012016年11月。
[RESTCONF-MODELS] Watsen, K. and J. Schoenwaelder, "RESTCONF Client and Server Models", Work in Progress draft-ietf-netconf-restconf-client-server-01, November 2016.
[RESTCONF-MODELS]Watsen，K.和J.Schoenwaeld，“RESTCONF客户机和服务器模型”，正在进行中的草案-ietf-netconf-RESTCONF-Client-Server-01，2016年11月。
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, <http://www.rfc-editor.org/info/rfc7616>.
[RFC7616]Shekh Yusef，R.，Ed.，Ahrens，D.，和S.Bremer，“HTTP摘要访问认证”，RFC 7616，DOI 10.17487/RFC76162015年9月<http://www.rfc-editor.org/info/rfc7616>.
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, DOI 10.17487/RFC7617, September 2015, <http://www.rfc-editor.org/info/rfc7617>.
[RFC7617]Reschke，J.“基本”HTTP认证方案”，RFC 7617，DOI 10.17487/RFC76172015年9月<http://www.rfc-editor.org/info/rfc7617>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <http://www.rfc-editor.org/info/rfc7950>.
[RFC7950]Bjorklund，M.，Ed.“YANG 1.1数据建模语言”，RFC 7950，DOI 10.17487/RFC7950，2016年8月<http://www.rfc-editor.org/info/rfc7950>.
[Std-802.1AR-2009] IEEE, "IEEE Standard for Local and metropolitan area networks - Secure Device Identity", IEEE Std 802.1AR-2009, DOI 10.1109/IEEESTD.2009.5367679, December 2009, <http://standards.ieee.org/findstds/ standard/802.1AR-2009.html>.
[Std-802.1AR-2009]IEEE，“局域网和城域网的IEEE标准-安全设备标识”，IEEE Std 802.1AR-2009，DOI 10.1109/IEEESTD.2009.536792009年12月<http://standards.ieee.org/findstds/ 标准/802.1AR-2009.html>。
[TLS1.3] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", Work in Progress, draft-ietf-tls-tls13-18, October 2016.
[TLS1.3]Rescorla，E.，“传输层安全（TLS）协议版本1.3”，正在进行的工作，草案-ietf-TLS-tls13-18，2016年10月。
[zmap] Durumeric, Z., Wustrow, E., and J. Halderman, "ZMap: Fast Internet-Wide Scanning and its Security Applications", 22nd Usenix Security Symposium, August 2013, <https://zmap.io/paper.html>.
[zmap]Durumeric，Z.，Wustrow，E.，和J.Halderman，“zmap：快速互联网范围扫描及其安全应用”，第22届Usenix安全研讨会，2013年8月<https://zmap.io/paper.html>.
Acknowledgements
致谢
The author would like to thank the following (ordered by last name) for lively discussions on the mailing list and in the halls: Jari Arkko, Andy Bierman, Martin Bjorklund, Ben Campbell, Spencer Dawkins, Mehmet Ersue, Stephen Farrell, Wes Hardaker, Stephen Hanna, David Harrington, Jeffrey Hutzelman, Simon Josefsson, Radek Krejci, Suresh Krishnan, Barry Leiba, Alan Luchuk, Kathleen Moriarty, Mouse, Russ Mundy, Tom Petch, Peter Saint-Andre, Joseph Salowey, Juergen Schoenwaelder, Martin Stiemerling, Joe Touch, Hannes Tschofenig, Sean Turner, and Bert Wijnen.
作者要感谢以下（按姓氏排序）在邮件列表上和大厅里进行的热烈讨论：贾里·阿尔科、安迪·比尔曼、马丁·比约克隆德、本·坎贝尔、斯宾塞·道金斯、迈赫迈特·厄苏、斯蒂芬·法雷尔、韦斯·哈达克、斯蒂芬·汉纳、大卫·哈林顿、杰弗里·哈泽尔曼、西蒙·约瑟夫森、拉迪克·克雷奇、苏雷什·克里希南、，巴里·莱巴、艾伦·卢丘克、凯瑟琳·莫里亚蒂、老鼠、罗斯·蒙迪、汤姆·佩奇、彼得·圣安德烈、约瑟夫·萨洛维、尤尔根·舍恩瓦埃尔德、马丁·斯蒂梅林、乔·图奇、汉内斯·茨霍芬尼、肖恩·特纳和伯特·维恩。
Author's Address
作者地址
Kent Watsen Juniper Networks
肯特沃特森刺柏网络公司
Email: kwatsen@juniper.net
Email: kwatsen@juniper.net