Internet Engineering Task Force (IETF) M. Wasserman
Request for Comments: 6242 Painless Security, LLC
Obsoletes: 4742 June 2011
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) M. Wasserman
Request for Comments: 6242 Painless Security, LLC
Obsoletes: 4742 June 2011
Category: Standards Track
ISSN: 2070-1721
Using the NETCONF Protocol over Secure Shell (SSH)
通过安全Shell（SSH）使用NETCONF协议
Abstract
摘要
This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742.
本文档描述了在安全Shell（SSH）会话中作为SSH子系统调用和运行网络配置协议（NETCONF）的方法。本文件废除了RFC 4742。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第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/rfc6242.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6242.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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
2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 2
3. Starting NETCONF over SSH . . . . . . . . . . . . . . . . . . 2
3.1. Capabilities Exchange . . . . . . . . . . . . . . . . . . 3
4. Using NETCONF over SSH . . . . . . . . . . . . . . . . . . . . 4
4.1. Framing Protocol . . . . . . . . . . . . . . . . . . . . . 5
4.2. Chunked Framing Mechanism . . . . . . . . . . . . . . . . 5
4.3. End-of-Message Framing Mechanism . . . . . . . . . . . . . 7
5. Exiting the NETCONF Subsystem . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Changes from RFC 4742 . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 2
3. Starting NETCONF over SSH . . . . . . . . . . . . . . . . . . 2
3.1. Capabilities Exchange . . . . . . . . . . . . . . . . . . 3
4. Using NETCONF over SSH . . . . . . . . . . . . . . . . . . . . 4
4.1. Framing Protocol . . . . . . . . . . . . . . . . . . . . . 5
4.2. Chunked Framing Mechanism . . . . . . . . . . . . . . . . 5
4.3. End-of-Message Framing Mechanism . . . . . . . . . . . . . 7
5. Exiting the NETCONF Subsystem . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Changes from RFC 4742 . . . . . . . . . . . . . . . . 11
The NETCONF protocol [RFC6241] is an XML-based protocol used to manage the configuration of networking equipment. NETCONF is defined to be session-layer and transport independent, allowing mappings to be defined for multiple session-layer or transport protocols. This document defines how NETCONF can be used within a Secure Shell (SSH) session, using the SSH connection protocol [RFC4254] over the SSH transport protocol [RFC4253]. This mapping will allow NETCONF to be executed from a secure shell session by a user or application.
NETCONF协议[RFC6241]是一种基于XML的协议，用于管理网络设备的配置。NETCONF被定义为会话层和传输独立，允许为多个会话层或传输协议定义映射。本文档定义了如何在安全Shell（SSH）会话中使用NETCONF，通过SSH传输协议[RFC4253]使用SSH连接协议[RFC4254]。此映射将允许用户或应用程序从安全shell会话执行NETCONF。
Although this document gives specific examples of how NETCONF messages are sent over an SSH connection, use of this transport is not restricted to the messages shown in the examples below. This transport can be used for any NETCONF message.
尽管本文档给出了如何通过SSH连接发送NETCONF消息的具体示例，但此传输的使用并不限于以下示例中所示的消息。此传输可用于任何NETCONF消息。
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]中所述进行解释。
To run NETCONF over SSH, the SSH client will first establish an SSH transport connection using the SSH transport protocol, and the SSH client and SSH server will exchange keys for message integrity and encryption. The SSH client will then invoke the "ssh-userauth" service to authenticate the user, as described in the SSH
要通过SSH运行NETCONF，SSH客户端将首先使用SSH传输协议建立SSH传输连接，SSH客户端和SSH服务器将交换消息完整性和加密的密钥。然后，SSH客户端将调用“SSH userauth”服务对用户进行身份验证，如SSH中所述
authentication protocol [RFC4252]. Once the user has been successfully authenticated, the SSH client will invoke the "ssh-connection" service, also known as the SSH connection protocol.
认证协议[RFC4252]。一旦用户成功通过身份验证，SSH客户端将调用“SSH连接”服务，也称为SSH连接协议。
The username provided by the SSH implementation will be made available to the NETCONF message layer as the NETCONF username without modification. If the username does not comply to the NETCONF requirements on usernames [RFC6241], i.e., the username is not representable in XML, the SSH session MUST be dropped. Any transformations applied to the authenticated identity of the SSH client made by the SSH server (e.g., via authentication services or mappings to system accounts) are outside the scope of this document.
SSH实现提供的用户名将作为NETCONF用户名提供给NETCONF消息层，无需修改。如果用户名不符合NETCONF对用户名[RFC6241]的要求，即用户名不能用XML表示，则必须删除SSH会话。SSH服务器（例如，通过身份验证服务或到系统帐户的映射）对SSH客户端的身份验证进行的任何转换都不在本文档的范围内。
After the ssh-connection service is established, the SSH client will open a channel of type "session", which will result in an SSH session.
建立ssh连接服务后，ssh客户端将打开一个类型为“session”的通道，这将导致一个ssh会话。
Once the SSH session has been established, the NETCONF client will invoke NETCONF as an SSH subsystem called "netconf". Subsystem support is a feature of SSH version 2 (SSHv2) and is not included in SSHv1. Running NETCONF as an SSH subsystem avoids the need for the script to recognize shell prompts or skip over extraneous information, such as a system message that is sent at shell start-up.
一旦建立了SSH会话，NETCONF客户端将调用NETCONF作为名为“NETCONF”的SSH子系统。子系统支持是SSH版本2（SSHv2）的一项功能，不包含在SSHv1中。将NETCONF作为SSH子系统运行，避免了脚本识别shell提示或跳过无关信息（如shell启动时发送的系统消息）的需要。
In order to allow NETCONF traffic to be easily identified and filtered by firewalls and other network devices, NETCONF servers MUST default to providing access to the "netconf" SSH subsystem only when the SSH session is established using the IANA-assigned TCP port 830. Servers SHOULD be configurable to allow access to the netconf SSH subsystem over other ports.
为了允许防火墙和其他网络设备轻松识别和过滤NETCONF流量，NETCONF服务器必须默认为仅在使用IANA分配的TCP端口830建立SSH会话时提供对“NETCONF”SSH子系统的访问。服务器应可配置为允许通过其他端口访问netconf SSH子系统。
A user (or application) could use the following command line to invoke NETCONF as an SSH subsystem on the IANA-assigned port:
用户（或应用程序）可以使用以下命令行调用NETCONF作为IANA分配端口上的SSH子系统：
[user@client]$ ssh -s server.example.org -p 830 netconf
[user@client]$ ssh -s server.example.org -p 830 netconf
Note that the -s option causes the command ("netconf") to be invoked as an SSH subsystem.
注意，-s选项导致命令（“netconf”）作为SSH子系统调用。
As specified in [RFC6241], the NETCONF server indicates its capabilities by sending an XML document containing a <hello> element as soon as the NETCONF session is established. The NETCONF client can parse this message to determine which NETCONF capabilities are supported by the NETCONF server.
如[RFC6241]中所述，NETCONF服务器通过在NETCONF会话建立后立即发送包含<hello>元素的XML文档来指示其功能。NETCONF客户端可以解析此消息，以确定NETCONF服务器支持哪些NETCONF功能。
As [RFC6241] states, the NETCONF client also sends an XML document containing a <hello> element to indicate the NETCONF client's capabilities to the NETCONF server. The document containing the <hello> element is the first XML document that the NETCONF client sends after the NETCONF session is established.
正如[RFC6241]所述，NETCONF客户机还向NETCONF服务器发送一个包含<hello>元素的XML文档，以指示NETCONF客户机的功能。包含<hello>元素的文档是NETCONF客户端在NETCONF会话建立后发送的第一个XML文档。
The following example shows a capability exchange. Data sent by the NETCONF client are marked with "C:", and data sent by the NETCONF server are marked with "S:".
下面的示例显示了一个功能交换。NETCONF客户端发送的数据标记为“C:”，NETCONF服务器发送的数据标记为“S:”。
S: <?xml version="1.0" encoding="UTF-8"?>
S: <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
S: <capabilities>
S: <capability>
S: urn:ietf:params:netconf:base:1.1
S: </capability>
S: <capability>
S: urn:ietf:params:ns:netconf:capability:startup:1.0
S: </capability>
S: </capabilities>
S: <session-id>4</session-id>
S: </hello>
S: ]]>]]>
S: <?xml version="1.0" encoding="UTF-8"?>
S: <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
S: <capabilities>
S: <capability>
S: urn:ietf:params:netconf:base:1.1
S: </capability>
S: <capability>
S: urn:ietf:params:ns:netconf:capability:startup:1.0
S: </capability>
S: </capabilities>
S: <session-id>4</session-id>
S: </hello>
S: ]]>]]>
C: <?xml version="1.0" encoding="UTF-8"?>
C: <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
C: <capabilities>
C: <capability>
C: urn:ietf:params:netconf:base:1.1
C: </capability>
C: </capabilities>
C: </hello>
C: ]]>]]>
C: <?xml version="1.0" encoding="UTF-8"?>
C: <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
C: <capabilities>
C: <capability>
C: urn:ietf:params:netconf:base:1.1
C: </capability>
C: </capabilities>
C: </hello>
C: ]]>]]>
Although the example shows the NETCONF server sending a <hello> message followed by the NETCONF client's <hello> message, both sides will send the message as soon as the NETCONF subsystem is initialized, perhaps simultaneously.
尽管该示例显示NETCONF服务器发送一条<hello>消息，然后是NETCONF客户端的<hello>消息，但双方都会在NETCONF子系统初始化后立即发送消息，可能是同时发送。
A NETCONF over SSH session consists of a NETCONF client and NETCONF server exchanging complete XML documents. Once the session has been established and capabilities have been exchanged, the NETCONF client will send complete XML documents containing <rpc> elements to the server, and the NETCONF server will respond with complete XML documents containing <rpc-reply> elements.
NETCONF over SSH会话由交换完整XML文档的NETCONF客户端和NETCONF服务器组成。建立会话并交换功能后，NETCONF客户端将向服务器发送包含<rpc>元素的完整XML文档，NETCONF服务器将使用包含<rpc reply>元素的完整XML文档进行响应。
The previous version of this document defined the character sequence "]]>]]>" as a message separator, under the assumption that it could not be found in well-formed XML documents. However, this assumption is not correct. It can legally appear in XML attributes, comments, and processing instructions. In order to solve this problem, and at the same time be compatible with existing implementations, this document defines the following framing protocol.
本文档的早期版本将字符序列“]]>]]]>”定义为消息分隔符，假设在格式良好的XML文档中找不到该字符序列。然而，这种假设是不正确的。它可以合法地出现在XML属性、注释和处理指令中。为了解决这个问题，同时与现有的实现兼容，本文档定义了以下帧协议。
The <hello> message MUST be followed by the character sequence ]]>]]>. Upon reception of the <hello> message, the receiving peer's SSH Transport layer conceptually passes the <hello> message to the Messages layer. If the :base:1.1 capability is advertised by both peers, the chunked framing mechanism (see Section 4.2) is used for the remainder of the NETCONF session. Otherwise, the old end-of-message-based mechanism (see Section 4.3) is used.
<hello>消息后面必须跟字符序列]]>]]>。接收到<hello>消息后，接收对等方的SSH传输层概念上将<hello>消息传递给消息层。如果：base:1.1功能由两个对等方发布，则块帧机制（参见第4.2节）将用于NETCONF会话的其余部分。否则，将使用旧的基于消息端的机制（参见第4.3节）。
This mechanism encodes all NETCONF messages with a chunked framing. Specifically, the message follows the ABNF [RFC5234] rule Chunked-Message:
此机制使用分块帧对所有NETCONF消息进行编码。具体而言，该消息遵循ABNF[RFC5234]规则分块消息：
Chunked-Message = 1*chunk
end-of-chunks
Chunked-Message = 1*chunk
end-of-chunks
chunk = LF HASH chunk-size LF
chunk-data
chunk-size = 1*DIGIT1 0*DIGIT
chunk-data = 1*OCTET
chunk = LF HASH chunk-size LF
chunk-data
chunk-size = 1*DIGIT1 0*DIGIT
chunk-data = 1*OCTET
end-of-chunks = LF HASH HASH LF
end-of-chunks = LF HASH HASH LF
DIGIT1 = %x31-39
DIGIT = %x30-39
HASH = %x23
LF = %x0A
OCTET = %x00-FF
DIGIT1 = %x31-39
DIGIT = %x30-39
HASH = %x23
LF = %x0A
OCTET = %x00-FF
The chunk-size field is a string of decimal digits indicating the number of octets in chunk-data. Leading zeros are prohibited, and the maximum allowed chunk-size value is 4294967295.
区块大小字段是一个十进制数字字符串，指示区块数据中的八位字节数。禁止前导零，允许的最大块大小值为4294967295。
As an example, the message:
例如，消息：
<rpc message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<close-session/>
</rpc>
<rpc message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<close-session/>
</rpc>
could be encoded as (using '\n' as a visible representation of the LineFeed character):
可以编码为（使用“\n”作为换行符的可见表示）：
C: \n#4\n
C: <rpc
C: \n#18\n
C: message-id="102"\n
C: \n#79\n
C: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">\n
C: <close-session/>\n
C: </rpc>
C: \n##\n
C: \n#4\n
C: <rpc
C: \n#18\n
C: message-id="102"\n
C: \n#79\n
C: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">\n
C: <close-session/>\n
C: </rpc>
C: \n##\n
Conceptually, the SSH Transport layer encodes messages sent by the Messages layer, and decodes messages received on the SSH channel before passing them to the Messages layer.
从概念上讲，SSH传输层对消息层发送的消息进行编码，并在将消息传递到消息层之前对SSH通道上接收到的消息进行解码。
The examples for the chunked framing mechanism show all LineFeeds, even those that are not used as part of the framing mechanism. Note that the SSH transport does not interpret the XML content; thus, it does not care about any optional XML-specific LineFeeds.
分块成帧机制的示例显示了所有换行，即使是那些未用作成帧机制一部分的换行。请注意，SSH传输不会解释XML内容；因此，它不关心任何可选的特定于XML的换行符。
In the second and third chunks quoted above, each line is terminated by a LineFeed. For all the XML lines (except the last one), this example treats the LineFeed as part of the chunk-data and so contributing to the chunk-size.
在上面引用的第二个和第三个块中，每一行都以换行符终止。对于所有XML行（最后一行除外），本例将换行视为块数据的一部分，从而影响块大小。
Note that there is no LineFeed character after the <rpc> end tag in this message. The LineFeed required by the start of the end-of-chunks block immediately follows the last '>' character in the message.
请注意，此消息中的<rpc>end标记后没有换行符。块结尾块的开头所需的换行符紧跟在消息中最后一个“>”字符之后。
If the chunk-size and the chunk-size value respectively are invalid or if an error occurs during the decoding process, the peer MUST terminate the NETCONF session by closing the corresponding SSH channel. Implementations MUST ensure they are not vulnerable for a buffer overrun.
如果chunk size和chunk size值分别无效或解码过程中出现错误，则对等方必须通过关闭相应的SSH通道来终止NETCONF会话。实现必须确保它们不会受到缓冲区溢出的攻击。
This mechanism exists for backwards compatibility with implementations of previous versions of this document. It is only used when the remote peer does not advertise a base protocol version supporting chunked encoding, i.e., a NETCONF implementation only supporting :base:1.0.
此机制的存在是为了与本文档以前版本的实现向后兼容。它仅在远程对等方不公布支持分块编码的基本协议版本（即仅支持：base:1.0的NETCONF实现）时使用。
When this mechanism is used, the special character sequence ]]>]]>, MUST be sent by both the NETCONF client and the NETCONF server after each message (XML document) in the NETCONF exchange. Conceptually, the SSH Transport layer passes any data found in between the ]]>]]> characters to the Messages layer.
使用此机制时，NETCONF客户端和NETCONF服务器必须在NETCONF交换中的每条消息（XML文档）之后发送特殊字符序列]]]>]]]>。从概念上讲，SSH传输层将在]]>]]]>字符之间找到的任何数据传递给消息层。
A NETCONF over SSH session, using the backwards-compatible end-of-message framing to retrieve a set of configuration information, might look like this:
NETCONF over SSH会话使用向后兼容的消息帧结尾来检索一组配置信息，可能如下所示：
C: <?xml version="1.0" encoding="UTF-8"?>
C: <rpc message-id="105"
C: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
C: <get-config>
C: <source><running/></source>
C: <config xmlns="http://example.com/schema/1.2/config">
C: <users/>
C: </config>
C: </get-config>
C: </rpc>
C: ]]>]]>
C: <?xml version="1.0" encoding="UTF-8"?>
C: <rpc message-id="105"
C: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
C: <get-config>
C: <source><running/></source>
C: <config xmlns="http://example.com/schema/1.2/config">
C: <users/>
C: </config>
C: </get-config>
C: </rpc>
C: ]]>]]>
S: <?xml version="1.0" encoding="UTF-8"?>
S: <rpc-reply message-id="105"
S: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
S: <config xmlns="http://example.com/schema/1.2/config">
S: <users>
S: <user><name>root</name><type>superuser</type></user>
S: <user><name>fred</name><type>admin</type></user>
S: <user><name>barney</name><type>admin</type></user>
S: </users>
S: </config>
S: </rpc-reply>
S: ]]>]]>
S: <?xml version="1.0" encoding="UTF-8"?>
S: <rpc-reply message-id="105"
S: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
S: <config xmlns="http://example.com/schema/1.2/config">
S: <users>
S: <user><name>root</name><type>superuser</type></user>
S: <user><name>fred</name><type>admin</type></user>
S: <user><name>barney</name><type>admin</type></user>
S: </users>
S: </config>
S: </rpc-reply>
S: ]]>]]>
Exiting NETCONF is accomplished using the <close-session> operation. A NETCONF server will process NETCONF messages from the NETCONF client in the order in which they are received. When the NETCONF server processes a <close-session> operation, the NETCONF server SHALL respond and close the SSH session channel. The NETCONF server MUST NOT process any NETCONF messages received after the <close-session> operation.
退出NETCONF是使用<close session>操作完成的。NETCONF服务器将按照接收顺序处理来自NETCONF客户端的NETCONF消息。当NETCONF服务器处理<close session>操作时，NETCONF服务器应响应并关闭SSH会话通道。NETCONF服务器不得处理<close session>操作后收到的任何NETCONF消息。
To continue the example used in Section 4.2, an existing NETCONF subsystem session could be closed as follows:
为了继续第4.2节中使用的示例，可以按如下方式关闭现有NETCONF子系统会话：
C: \n#140\n
C: <?xml version="1.0" encoding="UTF-8"?>\n
C: <rpc message-id="106"\n
C: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">\n
C: <close-session/>\n
C: </rpc>
C: \n##\n
C: \n#140\n
C: <?xml version="1.0" encoding="UTF-8"?>\n
C: <rpc message-id="106"\n
C: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">\n
C: <close-session/>\n
C: </rpc>
C: \n##\n
S: \n#139\n
S: <?xml version="1.0" encoding="UTF-8"?>\n
S: <rpc-reply id="106"\n
S: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">\n
S: <ok/>\n
S: </rpc-reply>
S: \n##\n
S: \n#139\n
S: <?xml version="1.0" encoding="UTF-8"?>\n
S: <rpc-reply id="106"\n
S: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">\n
S: <ok/>\n
S: </rpc-reply>
S: \n##\n
NETCONF is used to access configuration and state information and to modify configuration information, so the ability to access this protocol should be limited to users and systems that are authorized to view the NETCONF server's configuration and state or to modify the NETCONF server's configuration.
NETCONF用于访问配置和状态信息以及修改配置信息，因此访问此协议的能力应限于有权查看NETCONF服务器的配置和状态或修改NETCONF服务器配置的用户和系统。
The identity of the SSH server MUST be verified and authenticated by the SSH client according to local policy before password-based authentication data or any configuration or state data is sent to or received from the SSH server. The identity of the SSH client MUST also be verified and authenticated by the SSH server according to local policy to ensure that the incoming SSH client request is legitimate before any configuration or state data is sent to or received from the SSH client. Neither side should establish a NETCONF over SSH connection with an unknown, unexpected, or incorrect identity on the opposite side.
在向SSH服务器发送或从SSH服务器接收基于密码的身份验证数据或任何配置或状态数据之前，SSH客户端必须根据本地策略验证和身份验证SSH服务器的身份。SSH服务器还必须根据本地策略验证和身份验证SSH客户端的身份，以确保传入的SSH客户端请求在向SSH客户端发送或从SSH客户端接收任何配置或状态数据之前是合法的。任何一方都不应使用对方未知、意外或不正确的标识通过SSH建立NETCONF连接。
Configuration or state data may include sensitive information, such as usernames or security keys. So, NETCONF requires communications channels that provide strong encryption for data privacy. This document defines a NETCONF over SSH mapping that provides for support of strong encryption and authentication.
配置或状态数据可能包括敏感信息，如用户名或安全密钥。因此，NETCONF需要为数据隐私提供强加密的通信通道。本文档定义了NETCONF over SSH映射，该映射提供了对强加密和身份验证的支持。
This document requires that SSH servers default to allowing access to the "netconf" SSH subsystem only when using a specific TCP port assigned by IANA for this purpose. This will allow NETCONF over SSH traffic to be easily identified and filtered by firewalls and other network nodes. However, it will also allow NETCONF over SSH traffic to be more easily identified by attackers.
本文档要求SSH服务器默认仅在使用IANA为此指定的特定TCP端口时才允许访问“netconf”SSH子系统。这将允许防火墙和其他网络节点轻松识别和过滤通过SSH的NETCONF流量。但是，它还允许攻击者更容易地识别NETCONF over SSH流量。
This document also recommends that SSH servers be configurable to allow access to the "netconf" SSH subsystem over other ports. Use of that configuration option without corresponding changes to firewall or network device configuration may unintentionally result in the ability for nodes outside of the firewall or other administrative boundaries to gain access to the "netconf" SSH subsystem.
本文档还建议对SSH服务器进行配置，以允许通过其他端口访问“netconf”SSH子系统。使用该配置选项而不对防火墙或网络设备配置进行相应更改可能会无意中导致防火墙或其他管理边界之外的节点能够访问“netconf”SSH子系统。
RFC 4742 assumes that the end-of-message (EOM) sequence, ]]>]]>, cannot appear in any well-formed XML document, which turned out to be mistaken. The EOM sequence can cause operational problems and open space for attacks if sent deliberately in RPC messages. It is however believed that the associated threat is not very high. This document still uses the EOM sequence for the initial <hello> message to avoid incompatibility with existing implementations. When both peers implement base:1.1 capability, a proper framing protocol (chunked framing mechanism; see Section 4.2) is used for the rest of the NETCONF session, to avoid injection attacks.
RFC 4742假定消息结束（EOM）序列]]>]]>不能出现在任何格式良好的XML文档中，这被证明是错误的。如果故意在RPC消息中发送，EOM序列可能会导致操作问题，并为攻击打开空间。然而，据信相关的威胁不是很高。本文档仍然使用EOM序列作为初始<hello>消息，以避免与现有实现不兼容。当两个对等方都实现base:1.1功能时，NETCONF会话的其余部分将使用适当的帧协议（分块帧机制；参见第4.2节），以避免注入攻击。
Based on the previous version of this document, RFC 4742, IANA assigned the TCP port 830 as the default port for NETCONF over SSH sessions.
根据本文档的早期版本RFC 4742，IANA将TCP端口830指定为NETCONF over SSH会话的默认端口。
IANA had also assigned "netconf" as an SSH Subsystem Name, as defined in [RFC4250], as follows:
IANA还将“netconf”指定为SSH子系统名称，如[RFC4250]中所定义，如下所示：
Subsystem Name Reference
-------------- ---------
netconf RFC 4742
Subsystem Name Reference
-------------- ---------
netconf RFC 4742
IANA updated these allocations to refer to this document.
IANA更新了这些分配以参考本文件。
Ted Goddard was a co-author on earlier versions of this document.
Ted Goddard是本文件早期版本的共同作者。
This document was written using the xml2rfc tool described in RFC 2629 [RFC2629].
本文档使用RFC 2629[RFC2629]中描述的xml2rfc工具编写。
Extensive input was received from the other members of the NETCONF design team, including: Andy Bierman, Weijing Chen, Rob Enns, Wes Hardaker, David Harrington, Eliot Lear, Simon Leinen, Phil Shafer, Juergen Schoenwaelder, and Steve Waldbusser. The following people have also reviewed this document and provided valuable input: Olafur Gudmundsson, Sam Hartman, Scott Hollenbeck, Bill Sommerfeld, Balazs Lengyel, Bert Wijnen, Mehmet Ersue, Martin Bjorklund, Lada Lothka, Kent Watsen, and Tom Petch.
NETCONF设计团队的其他成员提供了广泛的意见，包括：安迪·比尔曼、陈伟晶、罗布·恩斯、韦斯·哈达克、大卫·哈林顿、艾略特·李尔、西蒙·莱宁、菲尔·沙弗、尤尔根·舍恩瓦德和史蒂夫·瓦尔德布瑟。以下人员也审阅了该文件并提供了宝贵的意见：奥拉弗尔·古德蒙德森、萨姆·哈特曼、斯科特·霍伦贝克、比尔·索末菲尔德、巴拉兹·伦杰尔、伯特·维宁、迈赫迈特·厄苏、马丁·比约克隆德、拉达·洛特卡、肯特·沃特森和汤姆·佩奇。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006.
[RFC4250]Lehtinen，S.和C.Lonvick，“安全外壳（SSH）协议分配编号”，RFC 4250，2006年1月。
[RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006.
[RFC4252]Ylonen，T.和C.Lonvick，“安全外壳（SSH）认证协议”，RFC 4252，2006年1月。
[RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[RFC4253]Ylonen，T.和C.Lonvick，“安全外壳（SSH）传输层协议”，RFC 4253，2006年1月。
[RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006.
[RFC4254]Ylonen，T.和C.Lonvick，“安全外壳（SSH）连接协议”，RFC 42542006年1月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011.
[RFC6241]Enns，R.，Ed.，Bjorklund，M.，Ed.，Schoenwaeld，J.，Ed.，和A.Bierman，Ed.“网络配置协议（NETCONF）”，RFC 62412011年6月。
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[RFC2629]Rose，M.，“使用XML编写I-D和RFC”，RFC 26292999年6月。
This section lists major changes between this document and RFC 4742.
本节列出了本文件与RFC 4742之间的主要变更。
o Introduced the new chunked framing mechanism to solve known security issues with the EOM framing.
o 引入了新的分块成帧机制，以解决EOM成帧的已知安全问题。
o Extended text in Security Considerations; added text on EOM issues.
o 安全考虑中的扩展文本；添加了关于EOM问题的文本。
o Added examples to show new chunked encoding properly; highlighted the location of new lines.
o 添加示例以正确显示新的分块编码；突出显示新行的位置。
o Added text for NETCONF username handling following the requirements on usernames in [RFC6241].
o 根据[RFC6241]中对用户名的要求，添加了NETCONF用户名处理文本。
o Changed use of the terms "client/server" and "manager/agent" to "SSH client/server" and "NETCONF client/server".
o 将术语“客户机/服务器”和“管理器/代理”的用法更改为“SSH客户机/服务器”和“NETCONF客户机/服务器”。
o Consistently used the term "operation", instead of "command" or "message".
o 一贯使用术语“操作”，而不是“命令”或“消息”。
o Integrated errata verified for RFC 4742 as of the date of publication of this document. See errata for RFC 4742 at http://www.rfc-editor.org.
o 截至本文件发布之日，已验证RFC 4742的综合勘误表。参见RFC 4742勘误表http://www.rfc-editor.org.
Author's Address
作者地址
Margaret Wasserman Painless Security, LLC 356 Abbott Street North Andover, MA 01845 USA
Margaret Wasserman无痛安全有限责任公司，地址：美国马萨诸塞州安多弗市阿伯特北街356号，邮编：01845
Phone: +1 781 405-7464
EMail: mrw@painless-security.com
URI: http://www.painless-security.com
Phone: +1 781 405-7464
EMail: mrw@painless-security.com
URI: http://www.painless-security.com