Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php on line 456
Network Working Group M. Wasserman Request for Comments: 4742 ThingMagic Category: Standards Track T. Goddard ICEsoft Technologies, Inc. December 2006 セキュアシェル (SSH) 上での NETCONF 設定プロトコルの利用 このメモの位置づけ この文書は, インターネットコミュニティに対するインターネットの標準トラックプロトコルを定義している. また, 改善のための議論と示唆を求めている. このプロトコルの標準化の状態と状況は "Internet Official Protocol Standards" (STD 1) の現在の版を参照してほしい. このメモの配布は制限しない. 著作権情報 Copyright (C) The IETF Trust (2006). 訳者: 春山 征吾 . 概要 この文書は, セキュアシェル (SSH)のサブシステムとして SSH のセッション内で Network Configuration Protocol (NETCONF) を呼び出し実行する方法を記述する. 目次 1イントロダクション ..........................................2 2. 要件に関する用語 ........................................2 3. SSH 上での NETCONF の起動 .......................................2 3.1. 機能の交換 ......................................3 4. SSH 上での NETCONF の利用 ..........................................5 5. NETCONF サブシステムの終了 .................................6 6. セキュリティの考察 .........................................6 7. IANA の考慮 .............................................7 8. Acknowledgements ................................................7 9. References ......................................................8 9.1. Normative References .......................................8 9.2. Informative References .....................................8 Wasserman & Goddard Standards Track [Page 1]  RFC 4742 NETCONF over SSH December 2006 1イントロダクション NETCONF プロトコル [RFC4721] は, ネットワーク機器の設定を管理するのに使われる XML ベースのプロトコルだ. NETCONF は セッション層とトランスポート独立に定義されており, 複数のセッション層とトランスポートプロトコルへのマッピングが可能だ. この文書は, SSH トランスポートプロトコル [RFC4253] 上のSSH コネクションプロトコル [RFC4254] を用いてセキュアシェル (SSH) のセッション中で NETCONFをどのように利用できるかを定義する. このマッピングで, ユーザやアプリケーションによるSSHセッションから NETCONF を実行できるようになる. この文書を通して, 用語"クライアント" と "サーバ" は SSH トランスポート接続の両端を差すのに用いる. クライアントが能動的にSSHの接続を開き, サーバは受動的にSSHの接続を待ち受ける. 用語 "マネージャ" と "エージェント" は, NETCONF プロトコルセッションの両端を差すのに用いる. マネージャは, NETCONF リモートプロシージャコール (RPC) コマンドを発行し, エージェントはそれらのコマンドに応答する. この文書で定義されたマッピングを用いて SSH の上で NETCONF を動作させる場合は, クライアントは常にマネージャでサーバは常にエージェントだ. 2. 要件に関する用語 この文書でのキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" は, RFC 2119 [RFC2119] で記述されているように解釈される. 3. SSH 上での NETCONF の起動 SSH上でNETCONFを実行するのに, クライアントはまずSSHトランスポート接続をSSHトランスポートプロトコルを用いて確立し, クライアントとサーバはメッセージ完全性と暗号化のための鍵を交換する. クライアントは SSH 認証プロトコル [RFC4252] に記述されているようにユーザを認証するため "ssh-userauth" サービスを起動する. ユーザが認証に成功したら, クライアントは SSHコネクションプロトコルとして知られている "ssh-connection" サービスを起動する. ssh-connection サービスが確立したら, クライアントは SSHのセッションとなる "session" タイプのチャンネルを開始する. SSHのセッションが確立したら, ユーザ(ないしアプリケーション)は, "netconf" SSHサブシステムとして NETCONF を起動する. サブシステムのサポートは,SSH バージョン 2 (SSHV2) の機能で, SSHv1 には含まれていない. SSHのサブシステムとして NETCONFを実行すると, シェルプロンプトをスクリプトが認識する必要や (シェルの起動時に送られるシステムメッセージのような)余計な情報をスクリプトがスキップする必要がなくなる. しかし, サブシステムを用いても, いくつかの余計なメッセージがユーザの起動スクリプトによって表示される可能性はある. Wasserman & Goddard Standards Track [Page 2]  RFC 4742 NETCONF over SSH December 2006 実装は, 'xml' の開始ディレクティブを探してこれらのメッセージをスキップしなければならない. この後には 'NETCONF' 名前空間の 要素が続いていなければならない. NETCONF のトラフィックを容易に識別しファイアウォールや他のネットワークデバイスでフィルタするために, NETCONF サーバは, IANA に割り当てられた TCP ポート <830> を用いて SSH のセッションが確立された場合のみ "netconf" SSH サブシステムへのアクセスを提供するのをデフォルトとしなければならない. サーバは, 他のポート上の netconf SSH サブシステムへのアクセス許可を設定可能にする必要がある. ユーザ(やアプリケーション)は, IANAに割り当てられたポート上の SSH サブシステムとして NETCONF を, 次のコマンドラインを用いて起動できる. [user@client]$ ssh -s server.example.org -p <830> netconf 注意: -s オプションは, SSHのサブシステムとしてコマンド("netconf")を起動させる. 3.1. 機能の交換 サーバは, NETCONFのセッションが確立したらすぐに 要素を含む XML 文書を送ってその機能を示さなければならない. ユーザ(もしくはアプリケーション)はこのメッセージをパースして, どの NETCONF 機能がサーバでサポートされているかを判断できる. クライアントも サーバにクライアントの機能を示すために 要素を含む XML 文書を送らなければならない. 要素を含む文書は, NETCONF セッションが確立したあとにクライアントが送る最初の XML 文書でなければならない. 以下で機能の交換の例を示す. クライアントから送られるメッセージには "C:" を, サーバから送られるメッセージには "S:" を付けている. Wasserman & Goddard Standards Track [Page 3]  RFC 4742 NETCONF over SSH December 2006 S: S: S: S: S: urn:ietf:params:xml:ns:netconf:base:1.0 S: S: S: urn:ietf:params:ns:netconf:capability:startup:1.0 S: S: S: 4 S: S: ]]>]]> C: C: C: C: C: urn:ietf:params:xml:ns:netconf:base:1.0 C: C: C: C: ]]>]]> 例では メッセージのサーバの送信に続いてクライアントのメッセージが続いているが, NETCONF サブシステムが開始されたらすぐに, おそらく同時に, どちらの側からもメッセージが送られる. 前出の例が示すように, 特殊な文字列, ]]>]]> を NETCONF 交換でのそれぞれの XML文書の後で クライアントもサーバも送らなければならない. この文字列は, XML 文書で正当に現われることはないので, 現在の文書の終端を識別するのに間違いなく利用できる. これにより XML の文法やパースのエラー時に NETCONF 交換を再実行できる. Wasserman & Goddard Standards Track [Page 4]  RFC 4742 NETCONF over SSH December 2006 4. SSH 上での NETCONF の利用 SSHセッション上の NETCONF は, マネージャとエージェントの完全な XML 文書の交換で構成される. セッションが確立され機能が交換されたら, マネージャは 要素を含む 完全な XML 文書をサーバに送る. そして エージェントは 要素を含む完全な XML 文書で応答する. 上記の例に続いて, 設定情報の集合を取得する SSH セッション上の NETCONF は次のようになる: C: C: C: C: C: C: C: C: C: C: ]]>]]> S: S: S: S: S: rootsuperuser S: fredadmin S: barneyadmin S: S: S: S: ]]>]]> Wasserman & Goddard Standards Track [Page 5]  RFC 4742 NETCONF over SSH December 2006 5. NETCONF サブシステムの終了 NETCONF の終了は, 操作を用いて行なわれる. エージェントは, マネージャから送られる RPC メッセージを受け取った順に処理する. エージェントが コマンドを処理する場合は, エージェントは応答し SSH のセッションチャンネルを終了する必要がある. エージェントは, コマンドの後で現在のセッションで受け取ったすべての RPC コマンドを処理してはならない. 前の節で利用した例に続いて, 既存の NETCONF サブシステムを終了する例は以下だ: C: C: C: C: C: ]]>]]> S: S: S: S: S: ]]>]]> 6. セキュリティの考察 NETCONF は, 設定や状態の情報にアクセスし, 設定情報を変更する. このため, このプロトコルにアクセスする能力は, エージェントの設定や状態を閲覧したりエージェントの設定を変更する権限のあるユーザやシステムに制限される必要がある. サーバの識別情報は, パスワードベースの認証データや設定や状態のデータをサーバに送ったりサーバから受け取ったりする前に, ローカルなポリシーに基づいてクライアントが検証し認証されなければならない. クライアントの識別情報も, 設定や状態の情報をクライアントに送ったりクライアントから受け取ったりする前に, 受け取ったクライアントの要求が正当なものであることを保証するために, ローカルなポリシーに基づいて, サーバにより検証し認証されなければならない. クライアントもサーバも, 未知の, もしくは, 予期しない, 不正解な相手側の識別情報による SSH 接続上の NETCONF を確立してはならない. 設定や状態のデータは, ユーザ名やセキュリティ鍵などの重要な情報を含む場合がある. それゆえ, NETCONF は, データの秘密性に対して強い暗号化を提供する通信チャンネル上でのみ利用されなければならない. Wasserman & Goddard Standards Track [Page 6]  RFC 4742 NETCONF over SSH December 2006 この文書は, 強い暗号化と認証のサポートを提供する SSH マッピング上の NETCONF を定義する. この文書は, この目的のために IANA に割り当てられた特定の TCP ポートのみで "netconf" SSH サブシステムへのアクセスを許すのをデフォルトとするようサーバに要求する. これは, SSH トラフィック上の NETCONF を, ファイアウォールや他のネットワークノードで容易の識別しフィルタするのを可能にする. しかし, SSH トラフィック上の NETCONFを攻撃者もより容易に識別できるようになる. この文書は, 他のポートでの "netconf" SSH サブシステムへのアクセスをサーバが設定可能にすることも推奨する. ファイアウォールやネットワークデバイスの設定を対応して変更することなしにこの設定項目を利用すると, "netconf" SSH サブシステムへのアクセスを得ようとする ファイアウォールや他の管理境界の外にあるノードの接続に意図しない影響を与える可能性がある. 7. IANA の考慮 IANA は, この文書で定義する SSH セッション上の NETCONF のデフォルトポートとして TCP ポート番号を割り当てる. IANA は, この目的のためにポート <830> を割り当てた. IANA は, [RFC4250] で定義された SSH Service Name として, 次のように "netconf" を割り当てるよう要求された. Service Name Reference ------------- --------- netconf RFC 4742 8. 謝辞 This document was written using the xml2rfc tool described in RFC 2629 [RFC2629]. 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, and Bert Wijnen. Wasserman & Goddard Standards Track [Page 7]  RFC 4742 NETCONF over SSH December 2006 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006. [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006. [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006. [RFC4721] Enns, R., Ed., "NETCONF Configuration Protocol", RFC 4721, December 2006. 9.2. Informative References [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. Wasserman & Goddard Standards Track [Page 8]  RFC 4742 NETCONF over SSH December 2006 Authors' Addresses Margaret Wasserman ThingMagic One Broadway, 5th Floor Cambridge, MA 02142 USA Phone: +1 781 405-7464 EMail: margaret@thingmagic.com URI: http://www.thingmagic.com Ted Goddard ICEsoft Technologies, Inc. Suite 300, 1717 10th St. NW Calgary, AB T2M 4S2 Canada Phone: +1 403 663-3322 EMail: ted.goddard@icesoft.com URI: http://www.icesoft.com Wasserman & Goddard Standards Track [Page 9]  RFC 4742 NETCONF over SSH December 2006 Full Copyright Statement Copyright (C) The IETF Trust (2006). 訳者: 春山 征吾 . This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Wasserman & Goddard Standards Track [Page 10]