[要約] RFC 6242は、SSHを介してNETCONFプロトコルを使用するためのガイドラインです。その目的は、セキュアな通信チャネルを確立し、ネットワークデバイスの設定や管理を効率的かつ安全に行うことです。
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)
Secure 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.
このドキュメントでは、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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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
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はセッション層であり、輸送が独立していると定義されているため、複数のセッションレイヤーまたはトランスポートプロトコルに対してマッピングを定義できます。このドキュメントでは、SSH輸送プロトコル[RFC4253]を介してSSH接続プロトコル[RFC4254]を使用して、セキュアシェル（SSH）セッション内でNetConfを使用する方法を定義しています。このマッピングにより、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].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は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 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.
SSHを介してNetConfを実行するために、SSHクライアントは最初にSSHトランスポートプロトコルを使用してSSHトランスポート接続を確立し、SSHクライアントとSSHサーバーはメッセージの整合性と暗号化とキーを交換します。SSHクライアントは、SSH認証プロトコル[RFC4252]に記載されているように、「SSH-USERAUTH」サービスを呼び出してユーザーを認証します。ユーザーが正常に認証されると、SSHクライアントはSSH Connectionプロトコルとしても知られる「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のユーザー名として利用できるようになります。ユーザー名がユーザー名[RFC6241]のNetConf要件に準拠していない場合、つまり、XMLでユーザー名が表されない場合、SSHセッションを削除する必要があります。SSHサーバーによって作成されたSSHクライアントの認証されたIDに適用される変換（たとえば、認証サービスまたはシステムアカウントへのマッピングを介して）は、このドキュメントの範囲外です。
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クライアントはタイプ「セッション」のチャネルを開き、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」と呼ばれるSSHサブシステムとしてNetConfを呼び出します。サブシステムサポートは、SSHバージョン2（SSHV2）の機能であり、SSHV1には含まれていません。SSHサブシステムとしてNetConfを実行すると、スクリプトがシェルプロンプトを認識したり、シェルスタートアップで送信されたシステムメッセージなどの無関係な情報をスキップする必要性を回避します。
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:
ユーザー（またはアプリケーション）は、次のコマンドラインを使用して、IANAが割り当てられたポートのSSHサブシステムとして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クライアントは<hello>要素を含むXMLドキュメントも送信して、NetConfクライアントの機能を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: ]]>]]>
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.
SSHセッションのNetConfは、完全な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>メッセージをメッセージレイヤーに渡します。：ベース：1.1機能が両方のピアによって宣伝されている場合、NetConfセッションの残りの部分にチャンクされたフレーミングメカニズム（セクション4.2を参照）が使用されます。それ以外の場合、古いメッセージベースのメカニズム（セクション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
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
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.
チャンクサイズのフィールドは、Chunk-Dataのオクテットの数を示す小数桁の文字列です。主要なゼロは禁止されており、最大許容チャンクサイズの値は4294967295です。
As an example, the message:
例として、メッセージ：
<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
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.
上記の2番目と3番目のチャンクでは、各ラインはラインフィードで終了します。すべての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.
チャンクサイズとチャンクサイズの値がそれぞれ無効である場合、またはデコードプロセス中にエラーが発生した場合、ピアは対応する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.
このメカニズムは、このドキュメントの以前のバージョンの実装との逆方向の互換性のために存在します。これは、リモートピアがチャンキングエンコードをサポートするベースプロトコルバージョン、つまりネットコンフの実装のみをサポートする場合にのみ宣伝していない場合にのみ使用されます。ベース：1.0。
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 Exchangeの各メッセージ（XMLドキュメント）の後にNetConfクライアントとNetConfサーバーの両方から送信する必要があります。概念的には、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:
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: ]]>]]>
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
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サーバーのIDは、パスワードベースの認証データまたは構成または状態データがSSHサーバーに送信または受信される前に、ローカルポリシーに従ってSSHクライアントによって検証および認証される必要があります。SSHクライアントの身元も、ローカルポリシーに従ってSSHサーバーによって検証および認証されなければなりません。これは、SSHクライアントに設定または状態データが送信または受信される前に、着信SSHクライアント要求が合法であることを確認する必要があります。どちらの側も、反対側に未知の、予期しない、または誤ったアイデンティティを持つSSH接続を介してネットコンを確立する必要はありません。
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には、データプライバシーの強力な暗号化を提供する通信チャネルが必要です。このドキュメントでは、強力な暗号化と認証のサポートを提供するSSHマッピングを介したNetConfを定義しています。
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サーバーがデフォルトで「NetConf」SSHサブシステムへのアクセスを許可する必要があります。この目的のためにIANAによって割り当てられた特定のTCPポートを使用する場合のみです。これにより、SSHトラフィックを介したNetConfを簡単に識別し、ファイアウォールやその他のネットワークノードでフィルタリングできます。ただし、SSHトラフィックを介したNetConfを攻撃者によってより簡単に識別できるようになります。
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は、誤ったXMLドキュメントに誤解されていることが判明したために、誤ったXMLドキュメントに表示されないことが判明していることがわかりました。EOMシーケンスは、RPCメッセージで意図的に送信された場合、攻撃のために運用上の問題とオープンスペースを引き起こす可能性があります。しかし、関連する脅威はそれほど高くないと考えられています。このドキュメントでは、既存の実装との互換性を回避するために、初期<hello>メッセージにEOMシーケンスを使用しています。両方のピアがベースを実装する場合：1.1機能、適切なフレーミングプロトコル（チャンクフレーミングメカニズム、セクション4.2を参照）がNetConfセッションの残りの部分に使用され、注入攻撃を避けます。
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はSSHセッションのNetConfのデフォルトポートとしてTCPポート830を割り当てました。
IANA had also assigned "netconf" as an SSH Subsystem Name, as defined in [RFC4250], as follows:
IANAは、[RFC4250]で定義されているように、次のように「NetConf」をSSHサブシステム名として割り当てていました。
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.
Andy Bierman、Weijing Chen、Rob Enns、Wes Hardaker、David Harrington、Eliot Lear、Simon Leinen、Phil Shafer、Juergen Schoenwaelder、Steve Waldbusserなど、NetConfデザインチームの他のメンバーから広範な入力が受けられました。次の人々はこの文書をレビューし、貴重な情報を提供しました：Olafur Gudmundsson、Sam Hartman、Scott Hollenbeck、Bill Sommerfeld、Balazs Lengyel、Bert Wijnen、Mehmet Ersue、Martin Bjorklund、Lada Lothka、Kent Watsen、Tom Petch。
[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、「Secure Shell（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、「The Secure Shell（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、「The Secure Shell（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、「The Secure Shell（SSH）接続プロトコル」、RFC 4254、2006年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。、Schoenwaelder、J.、ed。、およびA. Bierman、ed。、「Network Configuration Protocol（NetConf）」、RFC 6241、2011年6月。
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[RFC2629] Rose、M。、「XMLを使用したI-DSおよびRFCの書き込み」、RFC 2629、1999年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について検証された統合Errata。http://www.rfc-editor.orgのRFC 4742のErrataを参照してください。
Author's Address
著者の連絡先
Margaret Wasserman Painless Security, LLC 356 Abbott Street North Andover, MA 01845 USA
マーガレット・ワッサーマンの痛みのないセキュリティ、LLC 356アボットストリートノースアンドーバー、マサチューセッツ州01845 USA
Phone: +1 781 405-7464
EMail: mrw@painless-security.com
URI: http://www.painless-security.com