Network Working Group J. Case Request for Comments: 2570 SNMP Research, Inc. Category: Informational R. Mundy TIS Labs at Network Associates, Inc. D. Partain Ericsson B. Stewart Cisco Systems April 1999 インターネット標準ネットワーク管理フレームワーク 第三版の紹介 このメモの位置付け この文書はインターネットコミュニティに情報を提供するものであって、イ ンターネット標準を規定するものではない。この文書の配布は制限されない。 Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. 要約 この文書の目的はSNMP第三版フレームワーク(SNMPv3)と呼ばれるインター ネット標準管理フレームワークの第三版の概要を提供することである。 このフレームワークは最初のインターネット標準管理フレームワーク (SNMPv1)と第二版のインターネット標準管理フレームワーク(SNMPv2)の双方 を元に作られている。 このアーキテクチャーはフレームワークを何度でも発展することができるよ うモジュラー式に設計されている 目次 1 はじめに 2 インターネット標準管理フレームワーク 2.1 基本構造とコンポーネント 2.2 インターネット標準管理フレームワークのアーキテクチャー 3 SNMPv1管理フレームワーク 3.1 SNMPv1データ定義言語 3.2 管理情報 3.3 プロトコルオペレーション 3.4 SNMPv1におけるセキュリティと運用 4 SNMPv2管理フレームワーク 5 SNMPv3ワーキンググループ 6 SNMPv3フレームワーク モジュール機能 6.1 データ定義言語 6.2 MIBモジュール 6.3 プロトコルオペレーションとトランスポートマッピング 6.4 SNMPv3におけるセキュリティと運用 7 文書要約 7.1 管理情報構造(SMI : Structure of Management Information) 7.1.1 基本SMI機能 7.1.2 文字列表記法 7.1.3 準拠宣言 7.2 プロトコルオペレーション 7.3 トランスポートマッピング 7.4 プロトコル構成 7.5 アーキテクチャー / セキュリティと運用 7.6 メッセージ処理と配送(MPD : Message Processing and Dispatch) 7.7 SNMPアプリケーション 7.8 ユーザベースセキュリティモデル(USM : User-based Security Model) 7.9 ビューベースアクセスコントロール(VACM : View-based Access Control) 7.10 SNMPv3共存と移行 8 セキュリティに関する考察 9 著者アドレス 10 参考文献 11 著作権全文 1 はじめに この文書ではSNMP第三版管理フレームワーク(SNMPv3)と呼ばれるインター ネット標準管理フレームワークと様々な目的を紹介する。 まず、SNMP第三版(SNMPv3)の仕様とSNMP初版(SNMPv1)の仕様、SNMP初版 (SNMPv1)管理フレームワーク、SNMP第二版(SNMPv2)管理フレームワーク、そ してSNMPv2におけるコミュニティによる管理フレームワークとの関係につい て述べる。 次に、関連する仕様を含む様々な文書へのロードマップを提供する。 最後に、関連する仕様の文書についての短く読みやすい要約を提供する。 この文書は完全にチュートリアルとして位置づけされており、時々、文書と して省略されすぎているという「欠点」があるだろう。ロードマップである この文書と詳細な文書との間に食い違いや矛盾がある場合には、詳細な文書 での仕様が正しいだろう。 さらに詳細な文書では、様々なコンポーネントモジュール間のインターフェー スを明確に指定するために、コンポーネントモジュール同士の分離を行おう としている。このロードマップ文書は、しかしながら、異なるアプローチを 取り、様々なコンポーネントモジュールへの統合されたビューを提供しよう としている。 2 インターネット標準管理フレームワーク インターネット標準管理フレームワーク第三版(SNMPv3フレームワーク)は、 最初のインターネット標準管理フレームワーク(SNMPv1)とインターネット標 準管理フレームワーク第二版(SNMPv2)の二つを元に作られている。 全てのバージョン(SNMPv1、SNMPv2、SNMPv3)のインターネット標準管理フレー ムワークは同じ基本構造とコンポーネント共有する。それだけでなく、イン ターネット標準管理フレームワークの全てのバージョンの仕様は同じアーキ テクチャーに従う。 2.1 基本構造とコンポーネント インターネット標準管理フレームワークを配置している企業には4つの基本コ ンポーネントがある * 複数の(多くの場合たくさんの)管理対象ノード。それぞれがSNMPエンティ ティを持ち、管理機能(伝統的にエージェントと呼ばれる)へのリモート アクセスを提供する。 * 管理アプリケーションを持つ、少なくとも一つのSNMPエンティティ(多く の場合、マネージャと呼ばれる) * 管理プロトコル。SNMPエンティティ間で管理情報を伝えるのに用いられ る。 * 管理情報 管理プロトコルはマネージャやエージェントのようなSNMPエンティティ間で 管理情報を伝えるのに用いられる。 この基本構造はインターネット標準管理フレームワークの全てのバージョン、 すなわち、SNMPv1、SNMPv2、SNMPv3に共通している。 2.2 インターネット標準管理フレームワークのアーキテクチャー インターネット標準管理フレームワークの仕様はモジュラー型のアーキテク チャーに基づいている。このフレームワークとはまさにデータ転送のための プロトコル以上のものであり、以下のものを含む。 * データ定義言語 * 管理情報(管理情報ベース、すなわちMIB)の定義 * プロトコル定義 * セキュリティと運用 時を経て、フレームワークがSNMPv1からSNMPv2、SNMPv3へと発展するにつれ、 それぞれのアーキテクチャーのコンポーネント定義はより豊富で明確に定義 されるものとなってきている。しかし、根本のアーキテクチャーは一貫した ままである。 モジュール化に意欲を持っていた最初の人は、フレームワークの絶えまない 発展が可能でなければならないとRFC 1052 [14]に記述されている。 この機能はSNMPベースのインターネット管理からOSIプロトコルベースの管理 へ容易に移行するために用いられる。そのために、このフレームワークはプ ロトコルに依存しないデータ定義言語と管理情報ベースに依存しないプロト コルに沿ったMIBによって構成されている。この分離はSNMPベースのプロトコ ルの置き換えを管理情報の再定義や再構成の必要なしに行えるように設計さ れている。歴史はこのアーキテクチャーの選択が正しい決定であったことを 示しているが、それは誤った理由によるものである。それはこのアーキテク チャーがSimple Network Management Protocolに基づく管理からの移行を容 易にするということよりもSNMPv1からSNMPv2、そしてSNMPv2からSNMPv3への 移行を容易にしたということである。 SNMPv3フレームワークは以下のアーキテクチャーの原理の上に成り立ち、拡 張している。 * 4つの基本アーキテクチャーコンポーネントの上に成り立ち、いくつかの 場合にはこれらをSNMPv2フレームワークから参照している。 * セキュリティや運営に関するアーキテクチャーについての新しい機能の 定義においても同様に階層化の原理が用いられている。 SNMPv1管理フレームワークとSNMPv2管理フレームワークのアーキテクチャー に精通している人々はSNMPv3管理フレームワークの中に同じような多くのコ ンセプトに気づくだろう。しかしながら、多くの場合、多少は用語が異なる。 3 SNMPv1管理フレームワーク インターネット標準ネットワーク管理フレームワーク初版(SNMPv1)は次の文 書に定義されている。 * STD 16、RFC 1155 [1] では、管理情報構造(SMI : Structure of Management Information)、すなわち、管理のためのオブジェクト表記とネー ミング機構を定義している。 * STD 16、RFC 1212 [2] では、さらに簡潔な管理情報オブジェクトの表記 とネーミングの表記機構を定義しており、しかもSMIとの一貫性が保たれ ている。 * STD 15、RFC 1157 [3] では、Simple Network Management Protocol (SNMP)を定義している。このプロトコルは管理オブジェクトとイベント 通知へのネットワークアクセスに用いられる。この文書では初期のイベ ント通知の仕組みも定義されていることを付け加えておく。 加えて、通常2つの文書が上記の3つの文書とセットであると考えられている。 * STD 17、RFC 1213 [13] では、管理情報の基本セットの定義を含んでい る。 * RFC 1215 [25] では、さらに簡潔なイベント通知の表記機構を定義して いる。これはSNMPv1プロトコルではトラップと呼ばれている。また、こ の文書では、RFC 1157にあるgeneric trapも簡潔な表記で指定している。 これらの文書にはSNMPフレームワークの最初のバージョンの4つの機能につい て記述されている。 3.1 SNMPv1データ定義言語 最初の2つと最後の文書ではSNMPv1データ定義言語について記述されている。 SMIがプロトコルに依存しないという最初の要求のため、SMIに関する最初の2 つの文書はイベント通知(トラップ)のための手段を提供しない。その代わり、 SNMPプロトコルについての文書には標準化されたイベント通知(generic trap)が定義され、追加のイベント通知のための手段も提供される。最後の文 書では、SNMPv1プロトコルとともに使われるイベント通知を定義するための 簡単なアプローチを示している。これが書かれた時、インターネット標準ネッ トワーク管理フレームワークでのトラップの使用には議論の余地があった。 そのようなものとして、RFC 1215が「情報の提供」という状態で提案された。 この文書は更新されなかった。なぜならSNMPフレームワークの第二版が初版 にとって代わると信じられていたからである。SNMPv1データ定義言語が時々 SMIv1として参照されることを留めておく。 3.2 管理情報 最初の2つの文書で示されたデータ定義言語は最初、今では歴史的なものとなっ たRFC 1066 [12] に規定されているMIB-Iを定義するのに用いられた。そして 続いてRFC 1213 [13] に規定されたMIB-IIを定義するのに用いられた。 そして、MIB-IIの発行の後に管理情報定義への様々なアプローチが幅広い知 識を持つ技術者達によって構成される1つの委員会の初期のアプローチからも たらされた。彼らはインターネット標準MIBを定義する1つの文書に携わって いた。確かに、多くの小さなMIB文書が並行して作られ、インターネット標準 MIBの注目された部分の機能を策定するよう公認されたグループによって配布 されたやり方とネットワーク管理からシステム管理、アプリケーション管理 までの様々な局面に渡る領域に特別な分野に専門知識を持つ策定者。 3.3 プロトコルオペレーション 3番目の文書であるSTD 15には変数バインディングのリストにあるプロトコル データユニット(PDU)によってふるまうSNMPv1プロトコルオペレーションにつ いて、SNMPv1メッセージについて記述されている。SNMPv1に定義されている オペレーションはget、get-next、get-response、set-request、trapである。 コネクションレス指向のトランスポートサービスでの典型的なSNMPの階層化 も定義されている。 3.4 SNMPv1セキュリティと運用 STD 15 ではセキュリティと運用へのアプローチについても述べられている。 これらのコンセプトの多くは先送りされた。特にセキュリティについては SNMPv3フレームワークで拡張された。 SNMPv1フレームワークではSNMPv1のPDUをSNMPエンティティ間にカプセル化し、 アプリケーションエンティティとプロトコルエンティティとは区別されてい る。SNMPv3ではそれぞれアプリケーションとエンジンに名前が変えられた。 また、SNMPv1フレームワークでは複数の認証スキーマをサポートする認証サー ビスのコンセプトが導入されている。さらに加えて、SNMPv3ではプライバシー として参照されるセキュリティ機能も定義されている。(注:セキュリティの コミュニティからの文献ではSNMPv3セキュリティ機能はデータの完全性、ソー スの出どころが正しいこと、そして機密性の提供であるとしている。) SNMPv3フレームワークのモジュール性の本質はセキュリティ機能への変更も 追加も可能であることである。 最後に、SNMPv1フレームワークはSNMP MIBビューと呼ばれるコンセプトに基 づいたアクセスコントロールを導入している。SNMPv3フレームワークではビュー ベースアクセスコントロールという、基本的に同様のコンセプトを指定して いる。この機能により、SNMPv3では管理機器の情報へのアクセス制御の方法 を提供している。 しかしながら、SNMPv1フレームワークでは多彩な認証スキーマの定義を見越 していたにも関わらず、コミュニティ文字列に基づく些細なスキーマ以外、 何一つとして定義されなかった。このことはSNMPv1フレームワークの根本的 な弱点として知られているが、当時、商用段階のセキュリティの定義は、 「セキュリティ」の意味するところが三者三様であったため、その設計にお いて論争の原因となることや承認を得ることが難しいと考えられていた。こ の終わりには、ユーザの中に強力な認証を必要としないため、SNMPv1では認 証サービスを「後日」定義されるべき分離された部分として設計されており、 さらにSNMPv3フレームワークではサブシステムを定義するのと同じようにそ のブロック内で使うことができるアーキテクチャーを提供している。 4 SNMPv2管理フレームワーク SNMPv2管理フレームワークは全て [4-9] に、SNMPv1とSNMPv2についての共存 と移行についての問題は [10] で論じられている。 SNMPv2ではSNMPv1に加えていくつかの有利な機能を提供している。 * データ型の拡張(例えば64ビットカウンタ) * 効率とパフォーマンスの改善(get-bulk) * 強固なイベント通知(inform) * エラーの扱いが増えた(エラーと例外) * setの改善、特に列の追加と削除 * データ定義言語の設定の向上 しかしながら、これらの文書に記述されているSNMPv2フレームワークは SNMPv2プロジェクトの本来の設計の目標を満たしていないという点で不完全 なものとなっている。満たされていない目標には、いわゆる「商用段階」の セキュリティを提供するための暫定的なセキュリティと運用が含まれていた。 それは、以下の通りである。 * 認証:送信元の識別、メッセージの完全性、そして再送の保護 * プライバシー:機密性 * 権限とアクセス制御 * これらの特徴に対する遠隔設定と運用機能が適切であること SNMPv3管理フレームワークでは、この文書やその他に記述されているように これらの重要な欠陥について書かれている。 5 SNMPv3ワーキンググループ この文書と一連の文書はInternet Engineering Task Force(IETF)のSNMPv3ワー キンググループによって作成された。SNMPv3ワーキンググループは次世代 SNMPの勧告の準備のために組織された。このワーキンググループの目標は次 世代SNMPの核となる機能の1つの標準を提供するのに必要な一連の文書を作成 することである。1つ、次世代にもっとも重大で必要なものは、SNMPv3を用い てネットワークやネットワークを構成するシステム、そしてシステム上のア プリケーションの管理を行いたいと考えている人々にとって有用であるSNMP ベースの管理トランザクションをセキュアにするセキュリティと運用の定義 である。これにはマネージャ-エージェント、エージェント-マネージャ、さ らにマネージャ-マネージャ間のトランザクションも含まれている。 ワーキンググループの設立の数年前から、SNMPのセキュリティやその他の改 善の実現を目標とした多くの活動があった。これらの成果には * 「SNMPセキュリティ」 1991-1992年頃 [RFC 1351 - RFC 1353] * 「SMP」 1992-1993年頃 * 「パーティベース SNMPv2」 1993-1995年頃 [RFC 1441 - RFC 1452] これらの成果が商用段階かつ産業上の強度を持ち、認証、プライバシー、権 限、ビューベースアクセス制御、そしてリモート設定可能な運用を含んだセ キュリティにまとめあげられた。 さらに、これらの成果はRFC 1902 - 1908に記述されている通り、SNMPv2管理 フレームワークの開発にも役立った。しかしながら、これらのRFCに記述され ているフレームワーク自体は、標準化に基づいたセキュリティ・運用のフレー ムワークとはならなかった。それどころか、以下の様々なセキュリティ・運 用のフレームワークと結び付いた。 * 「コミュニティベースのSNMPv2」 (SNMPv2c) [RFC 1901] * 「SNMPv2u」 [RFC 1909 - 1910] * 「SNMPv2*」 SNMPv2cはIETFの支持を得たがセキュリティも運用もなく、一方、SNMPv2uと SNMPv2*にはセキュリティはあったがIETFの支持を得られなかった。 SNMPv3ワーキンググループは次世代SNMPのため、唯一の仕様セットを作成す るために結成された。それはSNMPの発展を目的として、推奨される唯一のア プローチを提供するために結成された顧問チームによる提案のように、 SNMPv2uとSNMPv2*のコンセプトと技術的な要素の結集に基づいていた。 この過程で、ワーキンググループは以下のような目的を定義した。 * 広範囲の様々な管理要求に対して広範囲のオペレーション環境を提供す ること * 以前の様々なプロトコルからSNMPv3への移行の要求を勧めること * セットアップとメンテナンス作業を容易にすること SNMPv3ワーキンググループの最初の作業では、グループは以下のようなセキュ リティと運用に焦点をしぼっていた。 * 認証とプライバシー * 権限とビューベースアクセス制御 * これらの標準に基づいたリモート設定 SNMPv3ワーキンググループは「車輪の再発明」をするようなことはしなかっ たが、SNMPv2ドラフト標準を再利用した。例えば、RFC 1902から1908は上記 の規格の範囲外の部分である。 それどころか、SNMPv3ワーキンググループの初期の貢献者やワーキンググルー プワーキンググループ一般は非常に多くの努力を失われた環 − セキュリティ と運用 − に取り掛かることに捧げた。そして、その過程において計り知れ ないほどの管理の最先端への貢献がなされた。 彼らは階層化に重点が置かれ発展した機能を備えたモジュール型アーキテク チャーに基づいた設計を作成した。その結果、SNMPv3はSNMPv2にセキュリティ と運用機能を追加したものと考えられている。 こうして、ワーキンググループはIETFの支持を得ただけでなく、セキュリティ と運用を備えた唯一の仕様の作成という目標を達成した。 6 SNMPv3フレームワーク モジュール機能 SNMPv3管理フレームワークの仕様はいくつかの文書間でモジュール式に分割 されている。要求が変化したり、新しい理解が得られたり、新しい技術が利 用できるようになるとともに、それぞれ個々の文書の一つ一つが、あるいは 全てが適切な管理により改訂されたり、更新されたり、置き換えられたりす ることができることは、SNMPv3ワーキンググループの目的である。 適切な時はいつでも、SNMPv3管理フレームワークを定義する初期の文書セッ トはSNMPv2管理フレームワークの仕様への参照を組み入れることにより、 SNMPv2管理フレームワークを定義し実装することに対して力を入れる。 SNMPv3管理フレームワークはSNMPv3のためのセキュリティと運用の仕様によっ てそれら(SNMPv2)の仕様を充実させる。 SNMPv3管理フレームワークを規定する文書は前の版と同じアーキテクチャー に従い、説明的な目的のために大きく以下の4つのカテゴリーに分類されるで あろう。 * データ定義言語 * 管理情報ベース(MIB : Management Information Base)モジュール * プロトコルオペレーション * セキュリティと運用 最初の3つの文書はSNMPv2から取り込まれた。4番目の文書はSNMPv3には初め て登場したが、すでに述べた通り、重要な過去の関連する作業に基づいてい る。 6.1 データ定義言語 データ定義言語の仕様はSTD 58、RFC 2578「管理情報構造第二版(Structure of Management Information 2 (SMIv2)」[26]と関連する仕様を含んでいる。 これらの文書はフレームワークの他の部分から別個に発展したRFC 1902 - 1904 [4-6]の改訂であり、ドラフト標準から昇格された時にSTD 58、RFC2578 - 2580 [26-28]として再発行された。 管理情報構造(SMIv2)では、基本データ型、オブジェクトモデル、そしてMIB モジュールの記述と改訂の規約を定義している。関連する仕様はSTR 58、RFC 2579、2580を含む。改訂されたデータ定義言語は時々SMIv2として参照される。 STD 58、RFC 2579「SMIv2のための文字列表記法」[27]では、人間が便利に読 み書きするように全てのMIBモジュール内で使用可能な省略語の最初のセット を定義している STD 58、RFC 2580「SMIv2のための順応性の提示」[28]では、エージェントの 実装のための要求を示すために用いられる応諾の提示や、詳細な実装の性能 を文書で明らかにする際に用いられる性能の提示のためのフォーマットを定 義している。 6.2 MIBモジュール MIBモジュールは通常、オブジェクト定義を含んでおり、さらにイベント通 知の定義も含んでいるかもしれない。加えて、時には適切なオブジェクトと イベント通知グループの表現で指定された応諾の提示も含むかもしれない。 MIBモジュール自体は管理情報を定義する。管理情報は管理対象ノードの機器 の編成により整理され、管理エージェントによるリモートアクセスが行われ、 管理プロトコルにより転送され、管理アプリケーションにより操作される。 MIBモジュールはデータ定義言語 - 関連する仕様によって補足された主にSMI - を指定する文書の規定に従って定義される。 定期的に更新される標準プロトコルのリスト[STD 1、RFC 2400]に定義されて いるように、膨大でなお増加中の標準MIBモジュールがある。これに記述され ているように、100近くの標準に基づいたMIBモジュールがあり、10000に届く オブジェクトが定義されている。さらに加えて、様々なベンダーや研究グルー プ、コンソーシアム、そして未知であったりほとんど数えられない定義され たオブジェクトによって一方的に定義された企業特有のMIBモジュールが増え 続けている。 たいてい、あらゆるMIBモジュールに定義されている管理情報は、用いられて いるデータ定義言語のバージョンに関係なく、どのバージョンのプロトコルで も使われるだろう。例えば、SNMPv1 SMI(SMIv1)で定義されているMIBモジュー ルはSNMPv3管理フレームワークとも適合し、その中で指定されているプロト コルによって伝達されるだろう。それだけでなく、SNMPv2 SMI(SMIv2)で定義 されているMIBモジュールはSNMPv1プロトコルオペレーションと適合し、伝達 されるだろう。しかしながら、1つの注意すべき例外がある。 MIBモジュールで定義されているであろうCounter64データ型はSMIv2フォーマッ トで定義されているが、SNMPv1プロトコルエンジンでは伝送することはでき ない。 6.3 プロトコルオペレーションとトランスポートマッピング SNMPv3フレームワークのプロトコルオペレーションとトランスポートマッピ ングの仕様はSNMPv2フレームワーク文書への参照によって構成されている。 プロトコルオペレーションのための仕様はRFC 1905、「Simple Network Management Protocol 第二版(SNMPv2)のためのプロトコルオペレーション」 [7]にある。SNMPv3フレームワークはアーキテクチャーの様々な部品が個別に 発展させることができるように設計されている。例えば、プロトコルオペレー ションの新しい仕様が追加のプロトコルオペレーションを見越したフレーム ワークの範疇で定義されることが可能である。 トランスポートマッピングの仕様はRFC 1906、「Simple Network Management Protocol 第二版(SNMPv2)のためのトランスポートマッピング」[8]にある。 6.4 SNMPv3セキュリティと運用 SNMPv3ワーキンググループによって定義されたSNMPv3文書は、現在7つで構成 されている。 RFC 2570、「インターネット標準ネットワーク管理フレームワーク第三版 の紹介」はこの文書である。 RFC 2571、「SNMP管理フレームワークの説明のためのアーキテクチャー」 [15]では、アーキテクチャー全般、特にセキュリティと運用のためのアー キテクチャーを強調して解説している。 RFC 2572、「Simple Network Management Protocol (SNMP)のためのメッ セージ処理と送信」[16]では、SNMPプロトコルエンジンの一部となるであ ろう多様なメッセージ処理モデルと送信部を説明している。 RFC 2573、「SNMPアプリケーション」[17]では、SNMPv3エンジンや手続き の要素に関連する5種類のアプリケーションを説明している。 RFC 2574、「Simple Network Management Protocol (SNMPv3)のためのユー ザベースセキュリティモデル」[18]では、脅威、メカニズム、プロトコル、 そしてSNMPメッセージレベルでのセキュリティの提供をサポートしている データについて説明している。 RFC 2575、「Simple Network Management Protocol (SNMP)のためのビュー ベースアクセス制御モデル」[19]では、ビューベースアクセス制御がコマ ンド応答側と通知発生側のアプリケーションの中でどうやって適用される のかを説明している。 作業中である「インターネット標準ネットワーク管理フレームワーク初版、 第二版、そして第三版の共存」[20]では、SNMPv3管理フレームワークと SNMPv2管理フレームワーク、そして元々のSNMPv1管理フレームワークとの 共存について説明している。 7 文書概要 以降の節では、それぞれの文書について上の要約よりも少し詳しい程度の簡 潔な概要を提供する。 7.1 管理情報構造 管理情報は管理情報ベース(MIB)と呼ばれる仮想情報記憶にある管理オブジェ クトの集まりとして調べられる。関連するオブジェクトの集まりはMIBモジュー ルに定義される。これらのモジュールはSNMP MIBモジュール言語で記述され る。これはOSIの抽象シンタックス表記法 1(ASN.1)[11]という言語の要素を 含む。STD 58、RFC 2578、2579、2580、これらはMIBモジュール言語を定義し、 オブジェクトの基本データ型と、文字列表記法と呼ばれる速記仕様の核とな るセットを指定し、さらにオブジェクト識別子(OID)の値の運用上の割当てを 指定している。 SMIは3つの部分に分割されている。モジュール定義、オブジェクト定義、そ して通知定義である。 (1) モジュール定義は情報モジュールを示す際に用いられる。 MODULE-IDENTITYというASN1マクロが情報モジュールのセマンティクス を簡明に伝えるために用いられる。 (2) オブジェクト定義は管理オブジェクトを示す際に用いられる。 OBJECT-TYPEというASN1マクロが管理オブジェクトのシンタックスとセ マンティクスを簡明に伝えるために用いられる。 (3) 通知定義は一方的な管理情報の伝送を示す際に用いられる。 NOTIFICATION-TYPEというASN1マクロが通知のシンタックスとセマンティ クスを簡明に伝えるために用いられる。 7.1.1 基本SMI仕様 STD 58、RFC 2578ではMIBモジュール言語のために基本データ型を規定してい る。これにはInteger32、enumerated integers、Unsigned32、Gauge32、 Counter32、Counter64、TimeTicks、INTEGER、OCTET STRING、OBJECT IDENTIFIER、IpAddress、Opaque、BITSが含まれる。また、いくつかのオブジェ クト識別子に値を割り当てている。STD 58、RFC 2578ではさらに以下のよう なMIBモジュール言語の構成を定義している。 * IMPORTSはそのMIBモジュールで使用されるが別のMIBモジュールで定義さ れているような項目の明記を認める。 * MODULE-IDENTITYはMIBモジュールに連絡先や改訂履歴といった表記と運 用情報を示す。 * OBJECT-IDENTITYとOIDの値の割当てはOID値を示している。 * OBJECT-TYPEはデータ型やステータス、そして管理オブジェクトのセマン ティクスを示している。 * SEQUENCE型の割当ては表の行となるオブジェクトを列挙している。 * NOTIFICATION-TYPE構成はイベント通知を規定している。 7.1.2 文字列表記法 MIBモジュールを設計する時には、同じようなふるまいの一連のオブジェクト のセマンティクスを速記法で示すことはしばしば有効である。これは新しい データ型をSMIで規定された基本データ型を利用して定義することにより行わ れる。新しい型は異なった名前を持ち、基本型をさらに制限したセマンティ クスで指定する。これらの新しく定義された型は文字列表記法と呼ばれ、人 がMIBモジュールを読むのに使いやすいように利用され、また、「知的な」管 理アプリケーションによって利用される可能性がある。そのような新しい型 を定義し、全てのMIBモジュールに利用可能な最初の文字列表記法を指定する ために用いられるMIBモジュール言語のTEXTUAL-CONVENTIONの構成を定義する ことはSTD 58、RFC 2579、「SMIv2のための文字表記法」[27]の目的である。 7.1.3 準拠宣言 実装の実際のレベルに沿った、実装の受け入れ可能な下限を定義することは 有効であろう。このために使われるMIBモジュール言語の構成を定義すること はSTD 58、RFC 2580、「SMIv2のための準拠宣言」[28]の目的である。これに は二種類の構成がある。 (1) Compliance statementsはオブジェクトとイベント通知の定義に関する エージェントへの要求を示す時に用いられる。MODULE-COMPLIANCE構造 はそのような要求を簡明に伝えるために用いられる。 (2) Capability statementsはオブジェクトとイベント通知の定義に関する エージェントの能力を示す時に用いられる。AGENT-CAPABILITIES構造は そのような能力を簡明に伝えるために用いられる。 最後に、関連するオブジェクトとイベント通知の集合は一つにまとめられ、 準拠の単位の形とされる。OBJECT-GROUP構成はオブジェクトグループに含ま れるオブジェクトとオブジェクトグループのセマンティクスを簡明に伝える ために用いられる。NOTIFICATION-GROUP構成はイベント通知グループに含ま れるイベント通知とセマンティクスを簡明に伝えるために用いられる。 7.2 プロトコルオペレーション 管理プロトコルはエージェントと管理ステーション間で管理情報を伝送する ためのメッセージの交換を提供する。これらのメッセージの形式はプロトコ ルデータユニット(PDU)をカプセル化しているメッセージラッパーである。 PDUの送信・受信に関するプロトコルのオペレーションを定義することは、 RFC 1905、「SNMPv2のためのプロトコルオペレーション」[7]の目的である。 7.3 トランスポートマッピング SNMPメッセージは様々なプロトコルスイート上で用いられるだろう。SNMPメッ セージがどのようにトランスポートドメインの最初のセットにマッピングす るかを定義することは、RFC 1906、「SNMPv2のためのトランスポートマッピ ング」の目的である。他のマッピングは将来定義されるかもしれない。 いくつかのマッピングが定義されているが、UDPへのマッピングは優先される マッピングである。そのようなものとして、最大限の相互接続性のレベルを 提供するために、他のマッピングを使うことを選んだシステムでもまた、UDP マッピングのプロキシーサービスを提供するべきである。 7.4 プロトコル構成 SNMPv2エンティティのふるまいを示す管理オブジェクトを定義することは、 RFC 1907、「SNMPv2ドキュメントのための管理情報ベース」[9]の目的である。 7.5 アーキテクチャー / セキュリティと運用 SNMP管理フレームワークを特定するためのアーキテクチャーを定義すること はRFC 2571、「SNMP管理フレームワークの記述のためのアーキテクチャー」 [15]の目的である。一般的なアーキテクチャーに関する問題点を示す一方で、 セキュリティと運用に関する面に焦点を当てている。このドキュメントでは、 SNMPv3管理フレームワークを通して使われるたくさんの用語を定義し、現在 もその過程であるが、以下の名称を明確にし、拡張している。 * エンジンとアプリケーション * エンティティ(エージェントやマネージャのエンジンのようなサービスプ ロバイダ) * (サービスユーザの)識別子 * 様々な論理的コンテキストのサポートを含む管理情報 文書には、全ての正式なSNMPv3プロトコルエンジンによって実装される小さ なMIBモジュールを含んでいる。 7.6 メッセージ生成と配送(MPD : Message Processing and Dispatch) RFC 2572、「SNMPのためのメッセージ生成と配送」[16]では、SNMPアーキテ クチャ内でのSNMPメッセージ生成と配送について記述している。その中では 複数のバージョンのSNMPメッセージを可能性のある適したSNMPメッセージ生 成モデルに配送するための手続きとPDUをSNMPアプリケーションに配送するた めの手続きを定義してている。この文書ではまた、一つのメッセージ生成モ デル - SNMPv3メッセージ生成モデル - について記している。 SNMPv3プロトコルエンジンは少なくとも一つのメッセージ生成モデルをサポー トしなければならない(MUST)と期待される。SNMPv3プロトコルエンジンは一 つ以上をサポートするかもしれない(MAY)。例えば、SNMPv3とSNMPv1や SNMPv2cとの同時サポートを提供する多国語システムである。 7.7 SNMPアプリケーション SNMPエンジンと関連するであろう5種類のアプリケーションを説明することは RFC 2573、「SNMPアプリケーション」の目的である。それは、コマンド生成 機能、コマンド応答機能、通知送信機能、通知受信機能、そしてプロキシ転 送である。 この文書ではまた、管理オペレーション(通知を含む)、通知のフィルタリン グとプロキシ転送の相手を指定するためのMIBモジュールを定義している。 7.8 ユーザベースセキュリティモデル(USM : User-based Security Model) 「Simple Network Management Protocol 第三版(SNMPv3)のためのユーザベー スセキュリティモデル (USM)」では、SNMPv3のためのユーザベースセキュリ ティモデルを示している。ここでは、SNMPメッセージレベルのセキュリティ を提供するための手続きの要素を定義している。 この文書では、ユーザベースセキュリティモデルによって防がれる、第一と 第二の脅威を二つずつ記している。それは情報の改竄、なりすまし、メッセー ジストリームの改竄、そして情報の暴露である。 USMでは、データの完全性を提供するために、ダイジェスト値の計算のための ハッシュアルゴリズム[23]としてMD5[21]とセキュアハッシュアルゴリズム [22]を利用して、 * データの改竄による攻撃から直接保護する。 * 間接的にデータ元の認証を提供する。 * なりすまし攻撃から守る。 USMでは一定のメッセージストリーム改竄攻撃から守るのに、ゆるく同期した、 単調増加する時間を用いている。プロトコルに基づく自動時刻同期メカニズ ムはサードパーティの時刻の基準や付随するセキュリティに対する考慮に依 存せずに特定される。 USMでは、暴露保護が望まれるならブロック暗号モードにデータ暗号化標準 (DES : Data Encryption Standard)[24]を用いる。USMでは、特にDESのサポー トはオプションである、というのも多くの国で輸出と使用の制限が暗号技術 を含む製品の輸出と使用を困難にしているからである。 また、この文書には鍵配送や鍵管理を含むUSMのパラメータ設定のリモート監 視・管理に適したMIBも含まれている。 エンティティは様々な認証やプライバシープロトコルと同様に、様々なセキュ リティモデルの同時サポートを提供するかもしれない。USMで使われる全ての プロトコルは前もって用意された鍵、例えば秘密鍵メカニズムに基づく。 SNMPv3アーキテクチャ非対称メカニズムとプロトコル(一般的に「公開鍵暗号 方式」と呼ばれている)の使用を許しているが、この文書が書かれた現在も、 公開鍵暗号方式を利用するSNMPv3セキュリティモデルは発行されていない。 7.9 ビューベースアクセス制御(VACM : View-based Access Control Model) RFC 2575、「Simple Network Management Protocol (SNMP)のためのビューベー スアクセス制御(VACM : View-based Access Control)」の目的はSNMPアーキ テクチャでのビューアクセスコントロールモデルの利用を示すことである。 VACMでは一つのエンジンの実装において、同時に様々なメッセージ処理モデ ルやセキュリティモデルと連携することができる。 一つのエンジンの実装から多彩で様々なアクセスコントロールモデルを同時 に有効で残しておくことはアーキテクチャ的に可能である。しかし、これは 実際には「とても」稀で、多様なメッセージ生成モデルやセキュリティモデ ルの同時サポートはほとんど共通ではないことが期待されている。 7.10 SNMPv3共存と移行 「インターネット標準ネットワーク管理フレームワークの第一版、第二版、 第三版の共存」の目的はSNMPv3管理フレームワークとSNMPv2管理フレームワー ク、初版のSNMP管理フレームワークとの共存を示すことである。特に、この 文書では共存の4つの局面について述べる。 * MIB文書のSMIv1からSMIv2フォーマットへの変換 * 通知パラメータのマッピング * 多国語のネットワークでの様々なバージョンのSNMPをサポートするエン ティティ間での共存へのアプローチ、特に多国語の実装におけるプロト コルオペレーションの処理はプロキシの実装のふるまいと同様である。 * SNMPv1メッセージ処理モデルとコミュニティによるセキュリティモデル はSNMPv1とSNMPv2cをビューベースアクセスコントロールモデル (VACM)[19]に適合するメカニズムを提供する。 8 セキュリティに関する考察 この文書は主にロードマップの文書であり、セキュリティに関する新しい考 察は何も紹介しない。読者はセキュリティの考察に関する情報を求めるなら、 言及された文書の適切な節を参照することができる。 9 著者アドレス Jeffrey Case SNMP Research, Inc. 3001 Kimberlin Heights Road Knoxville, TN 37920-9716 USA Phone: +1 423 573 1434 EMail: case@snmp.com Russ Mundy TIS Labs at Network Associates 3060 Washington Rd Glenwood, MD 21738 USA Phone: +1 301 854 6889 EMail: mundy@tislabs.com David Partain Ericsson Radio Systems Research and Innovation P.O. Box 1248 SE-581 12 Linkoping Sweden Phone: +46 13 28 41 44 EMail: David.Partain@ericsson.com Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A. Phone: +1 603 654 6923 EMail: bstewart@cisco.com 10 参考文献 [1] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, May 1990. [2] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [3] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996. [5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, January 1996. [6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, January 1996. [7] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996. [8] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996. [9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1907, January 1996. [10] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework", RFC 1908, January 1996. [11] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). [12] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based Internets", RFC 1066, August 1988. [13] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II, STD 17, RFC 1213, March 1991. [14] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, April 1988. [15] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. [16] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999. [17] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 2573, April 1999. [18] Blumenthal, U. and B. Wijnen, "The User-Based Security Model for Version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999. [19] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [20] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet- standard Network Management Framework", Work in Progress. [21] Rivest, R., "Message Digest Algorithm MD5", RFC 1321, April 1992. [22] Secure Hash Algorithm. NIST FIPS 180-1, (April, 1995) http://csrc.nist.gov/fips/fip180-1.txt (ASCII) http://csrc.nist.gov/fips/fip180-1.ps (Postscript) [23] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [24] Data Encryption Standard, National Institute of Standards and Technology. Federal Information Processing Standard (FIPS) Publication 46-1. Supersedes FIPS Publication 46, (January, 1977; reaffirmed January, 1988). [25] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [26] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [27] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [28] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. 11 著作権全文 Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." 謝辞 Funding for the RFC Editor function is currently provided by the Internet Society.