要約

  • RFC 5343 の localEngineID は受信側のローカル既定コンテキストを選び、snmpEngineID.0 を読むための既知値である。実際の EngineID として使うことは禁止されている。
  • EngineID は管理情報の場所を名付ける。主体は securityName とセキュリティモデル、権限は VACM、操作結果は PDU と状態観測がそれぞれ証明する。
  • EngineID に埋め込まれた MAC、IP、管理文字列は情報開示になり得るが、現行ロケータ、物理機器、所有権、認証済み主体を自動的に証明しない。

既知値が解いたのは循環参照だった

SNMP の管理対象は輸送先だけでは決まらない。contextEngineID と contextName がコンテキストを選び、オブジェクト型とインスタンスが OID になる。ところが最初の要求を作る時点で、管理アプリケーションが遠隔エンジンの識別子を知らない場合がある。

RFC 5343 は企業番号ゼロ、形式 6 の五オクテット値 8000000006 を localEngineID として予約した。対応する command responder は通常の EngineID に加え、この値にも PDU 型を登録する。値の意味は常に「この受信エンジンのローカル既定コンテキスト」である。

手順は、既知の適切な値を再利用し、次に USM などセキュリティモデル自身の発見を使い、それもなければ localEngineID 宛てに snmpEngineID.0 を読む。成功すれば候補が得られ、失敗すればエラーになる。

この値を snmpEngineID.0 や USM の msgAuthoritativeEngineID に入れてはならない。固定された案内札と、案内先の名前は別物である。

MAC を含む名前は MAC の所有証明ではない

EngineID の形式には IPv4、IPv6、MAC、管理テキスト、管理オクテットがある。形式は生成方法を説明する。具体値が現在も同じインターフェースを表すこと、応答した輸送先がそのハードウェアであること、現在の運用者が値を割り当てたことまでは説明しない。

RFC 3411 の一意性は管理ドメイン内の約束であり、ドメイン連合には調整が要る。グローバル資産台帳がこの範囲を落とすと、局所的な名前を世界的な物理 ID に昇格させてしまう。

プロキシでは差が正当になる。contextEngineID は輸送アドレスが変わったり、プロトコル変換が入ったりしても、エンドツーエンドの管理コンテキスト名として残せる。輸送先と EngineID の不一致は調査材料だが、直ちに偽装ではない。

access control は contextEngineID を本人確認に使わない

RFC 3411 は securityName を主体を表す文字列として分離する。セキュリティモデルが固有の識別子を securityName に変換し、securityLevel とともに処理へ渡す。VACM は securityModel と securityName をグループへ写し、contextName、レベル、ビュー型、変数に基づいて許否を決める。

RFC 5343 が強調するように、isAccessAllowed() の入力に contextEngineID はない。localEngineID を知っていることは、VACM の能力を一切増やさない。発見は後続 PDU を宛先指定可能にするだけで、許可済みにしない。

noAuthNoPriv では、securityName 自体が暗号学的に認証されていない。EngineID を未認証で読ませる運用上の利点はあり得るが、その応答を「認証済みデバイス」と表示することはできない。

発見は情報開示の選択でもある

RFC 5343 は、EngineID がルータ、ファイアウォール、NAT の背後で直接見えないアドレスや管理情報を露出し得ると説明し、交換の保護を推奨する。一方で、正当なツールのため noAuthNoPriv 読み出しを許す既定例も認めている。

したがって公開範囲は明示的な政策であるべきだ。どの形式を使い、何が埋め込まれ、誰がどの securityLevel で読めるかを記録する。RFC 5591 の Transport Security Model は後の保護手段の文脈になるが、規格の存在だけで個別交換の暗号化を証明しない。

GET の成功から SET の成功は導けない

発見要求には sysObjectID.0 や snmpSetSerialNo.0 を追加できる。往復を減らしても、返値の証拠範囲は増えない。次の OID が VACM ビューに入り、書き込み PDU が成功し、対象状態が変わり、サービス結果が生じたことは別々に確認する必要がある。

監査では輸送先、時刻、securityModel、securityName、securityLevel、contextEngineID、contextName、OID、request-id、応答を分離する。そうすれば「名前を発見した」「主体を認証した」「操作を許可した」「効果を観測した」を混同しない。

現在の IANA 表は過去の実装表ではない

RFC 5343 は形式 1〜5 を明記し、形式 6 を local engine に割り当て、128〜255 を enterprise specific とし、管理範囲の新規割当てに仕様を要求した。現在の IANA SNMP Number Spaces は今日の管理状態を示す。

しかし現在行は、古い agent が形式 6 を知っていたことも、現行製品が対応することも証明しない。観測時刻、参照した登録表の版、peer で確認した能力を一緒に保存すべきである。

情報源と証拠の限界

証拠は RFC 5343、SNMP の architecture、dispatch、USM、VACM、operation、MIB、後続 TSM、IANA 登録表と公開済み統治資料である。特定製品、実装、公開 endpoint、不正取得、成功した変更、障害、普及率は示していない。