要約

  • RFC 1441が示したSNMPv2は、情報構造、表記規約、プロトコル操作、トランスポート、計測、管理枠組み、適合性宣言から成る複合体だった。認証と認可の意味は管理枠組みが担っていた。
  • 当初のparty方式は長期的な配備経路にならず、RFC 1901は新しいSNMPv2 PDUを旧来のコミュニティ管理と組み合わせた。新しいバージョン値は文法を区別したが、強いセキュリティを保証しなかった。
  • RFC 3411は、メッセージ処理、セキュリティ、アクセス制御を別々のモデルとして定義した。運用では番号ではなく、実際に選択されたモデルと設定を記録する必要がある。

一という値が二を指す理由

SNMPv2cのメッセージは、バージョン整数、コミュニティ文字列、PDUを順に収める。列挙がゼロから始まるため、ゼロがSNMPv1、一がSNMPv2cである。従って 1 が示すのは世代についての自然言語ではなく、受信側が選ぶべき処理規則だ。

隣にあるコミュニティ文字列は管理上の別の役割を持ち、PDUは読み出しや書き込みなどの操作を表す。同じ包みの中にあるからといって、一つの保証になるわけではない。番号は送信者を認証せず、操作は実際の装置状態を証明しない。

この小さな符号のずれには、部品を残し、捨て、つなぎ直した移行史が凝縮されている。教科書的な「v1からv2、そしてv3へ」という一本線よりも、現実ははるかに組み合わせ的だった。

RFC 1441は枠組みの見取り図だった

1993年4月に発行され、現在はHistoricとなったRFC 1441の書誌情報は、第二版のインターネット標準ネットワーク管理「枠組み」を紹介している。

RFC 1441本文は七つの領域を並べた。SMIは管理対象オブジェクトの記述法を、テキスト規約は基本型に付随する精密な意味を、プロトコル操作はPDUを定める。トランスポート写像は運搬方法を、計測用MIBはSNMPv2エンティティの挙動を示す。管理枠組みは認証と認可を、適合性宣言は最低要件と実装能力を扱う。

どの一項も他の六項の証拠にはならない。MIB定義は運搬路を選ばず、到達先アドレスは権限を与えず、正しいPDUは発信者を認証しない。能力宣言が現場で有効化されているとも限らない。

さらに本文は、メッセージ包みの形と意味が管理枠組みによって決まるとした。Get や Set は操作の語彙でしかない。誰が送ったのか、その主体が何を許されるのかは別の層で決まる。

最初の設計ではpartyが文脈を担った

1993年の管理設計の中心はSNMPv2 partyだった。partyとは、管理者が定めた操作の部分集合に制限された仮想実行文脈である。一つのpartyには一つの認証プロトコルと一つのプライバシープロトコルが結び付き、その性質はParty MIBに表された。

これはPDU仕様の末尾に置かれた飾りではない。操作が管理上の意味を持つための文脈そのものだった。包みとpartyを交換すれば、同じSNMPv2 PDUでも、身元と認可に関する意味は変わる。

規格文書は部品を分けて記述したが、製品名や資産台帳は再び「SNMPv2」という一語に圧縮した。全ての部品が一緒に動く間は便利でも、ある部品だけが脱落すると名称は実装を覆い隠す。

SNMPv2cは新旧を接ぎ木した

1996年1月のRFC 1901は、コミュニティ方式SNMPv2、すなわちSNMPv2cを定義した。party方式を簡略化したのではない。SNMPv1の管理枠組みを再利用し、各メッセージをコミュニティに関連付け、新しいSNMPv2のPDUとエラーを運んだ。

包みのバージョン値が 1 になったのは、新しいPDU型とエラーコードを正しく解釈する必要があったからだ。この変更は受信側の文法選択には不可欠だった。しかし、コミュニティ文字列に強い認証能力を付与したわけではない。

広いカウンター、一括取得、確認付き通知、豊かなエラー、行操作の改善といった成果は有用だった。その成果が生き残っても、当初の管理・セキュリティ方式が生き残ったことにはならない。モジュール化は投資を守り、同時にバージョン名と単一の安全姿勢との結び付きを切った。

規格上の結論と稼働中のネットワーク

2002年の回顧文書RFC 3410は、party方式のSNMPv2pを1993年から1995年ごろの試みとして扱う。その後のSNMPv2枠組みは独自の標準的セキュリティ・管理枠組みを持たず、複数案と組み合わされた。SNMPv2cはIETF内で最も支持されたがセキュリティと管理を欠き、それを備えた案は合意を得られなかった。

SNMPv3のセキュリティと管理がStandardに達すると、平文コミュニティ認証に依存するSNMPv1と実験的SNMPv2cは、その弱点を理由にHistoricとなった。他のSNMPv2案もHistoricか、そもそも標準化トラック外だった。

それでも同じ文書は、v1やv2cとv3を同時に扱う多言語エンジンが使われ続けると予想した。IETFのプロセスはベンダーと利用者の配備を支配できない。文書の地位、推奨、動作中のコードは別々の現実である。

Historicだから消滅したとは言えない。応答するから安全とも言えない。v2c応答は経路の存在を示すが、現在の推奨を示さない。規格一覧の分類も、全インターフェースからコミュニティ経路が除去された証拠にはならない。

バージョンはディスパッチの入力になった

RFC 3411は、トランスポート、メッセージ処理とディスパッチ、セキュリティ、操作、アプリケーション、アクセス制御を分けた。それぞれが定義済みの境界を介し、異なる時期に更新できる。

用語も厳密だ。枠組みは複数のサブシステムを集め、モデルは一つのサブシステムの具体設計を示し、実装は一つ以上のモデルを実体化する。しかもSNMPv2自体にはメッセージ定義がなく、SNMPv2cがv1に似た形式を追加すると明記した。

バージョン欄は通常、メッセージ処理モデルを特定する。一つのエンジンが複数モデルを同時に持てる。メッセージレベルのセキュリティは認証、暗号化、時刻検査を扱い、アクセス制御は操作が管理対象オブジェクトに届いてよいかを別に判断する。複数のセキュリティモデルも共存可能だ。

つまり先頭の整数は、エンジン内部の振り分け先を選ぶ座標であって、安全状態全体の証明書ではない。SNMPv3と読めても、実際のセキュリティモデルとレベルを確認しなければならない。

一列のバージョン欄から部品台帳へ

資産台帳の「v2c」「v3」は検索索引としては役立つが、移行証拠としては粗すぎる。一つのエンジンが複数バージョンに応じ、古いインターフェースだけコミュニティを残し、主体や文脈ごとに異なるビューを許すことがある。

記録すべきなのは、到達したトランスポート、判定されたメッセージ処理モデル、セキュリティモデルとレベル、主張または認証された主体、文脈、アクセス制御とビュー、PDUと応答、そして結果についての独立観測である。

同じ要求IDで結び付けても、代用はできない。バージョンは主体を証明せず、主体は対象オブジェクトへの権限を証明せず、許可は装置の変化を証明せず、成功応答は再起動後の持続を証明しない。

RFC 1441の一式はそのまま残らなかった。しかし部品化されていたから、価値ある情報モデルと操作を全廃せずに済んだ。選択的に残せる仕組みである以上、証拠も部品単位で残すほかない。

出典

  • RFC 1441の書誌情報と現状。
  • RFC 1441の枠組み紹介。
  • RFC 1901のコミュニティ方式補足。
  • RFC 3410の適用指針と標準化史。
  • RFC 3411のモジュール型アーキテクチャ。