要約

  • RFC 2012 は tcpConnState を read-write とした。管理局が設定できる唯一の値 deleteTCB(12) は、該当接続の TCB を削除し、管理対象ノード上の接続を直ちに終端する。
  • IPv4 の両端アドレスとポートで行を特定し、各種カウンターで状態遷移を観測できても、誰が何の権限と理由で操作し、アプリや利用者に何が起きたかまでは記録されない。
  • RFC 4022 はこの操作を残しつつ、アドレス種別、listen 専用表、プロセス ID を追加し、書き込みを適合要件から外し、無許可の操作が DoS を起こし得ると明記した。

読み取り欄に埋め込まれた操作

RFC 2012 の大半は計測である。再送タイマーの方式と上下限、接続上限、active/passive open、接続失敗、確立後のリセット、現在の確立接続、入出力や再送、誤り、送信 RST のカウンターが並ぶ。tcpConnTable はローカルとリモートの IPv4 アドレス・ポート、そして現在状態を示す。

しかし状態列の MAX-ACCESS は read-write だった。通常状態を管理局が作ることはできず、書けるのは deleteTCB(12) だけである。これが受理されると、対応する Transmission Control Block がホストから削除され、接続は直ちに終端する。相手へ RST を送るかは実装依存であり、送っても確実には届かない。

したがって、ローカルでの削除、相手への通知、リモートアプリの認識、再試行、利用者の中断は別々の事実である。SET の成功だけでは、それらをまとめて証明できない。

消えるのは表示ではなくプロトコルの記憶

RFC 793 の TCB には、両端 socket、security と precedence、送受信バッファへのポインター、再送キューと現在セグメント、シーケンス変数が保存される。CLOSED は TCB が存在しない、つまり接続が存在しない状態を表すため「架空」と説明された。

deleteTCB は画面上のラベル変更ではない。接続を継続させるローカル状態を捨てる。一方、MIB 行が保持する識別子は四つ組であり、操作 ID、チケット、理由、実行主体、アプリ責任者、前後の永続記録はない。行自体も接続終了後には消える。

この権限の起点は 1991 年の RFC 1213 である。同文書は、TCB の削除を可能にするため tcpConnState を read-write に変えたと明記した。RFC 2012 はそのオブジェクトを SNMPv2/SMIv2 に移した。序文は認証、認可、アクセス制御、秘密性を管理フレームワークの仕事としたが、Security Considerations は詳細を論じなかった。

カウンターは原因を保持しない

操作の前後で tcpCurrEstab が減り、tcpEstabResets や tcpOutRsts が増えることはあり得る。しかし、前者は現在量、次は特定状態から CLOSED への遷移数、最後は RST フラグ付き送信セグメント数である。どれも管理操作専用の監査ログではない。

同じ変化は対向ホスト、アプリ、タイムアウト、プロトコル処理でも生じ得る。因果を残すには、観測した行と時刻、認証済み要求、security name と人の役割、context、当該インスタンスへの write view、操作理由、agent 応答、TCB 消失、アプリと相手の認識、再試行、継続時間、サービス影響を結ぶ必要がある。

後継仕様が広げた「どの接続か」

RFC 4022 は旧表を廃止対象にした。理由は IPv4 専用であることと、listen endpoint を通常接続と同じ表に混ぜていたことである。新 tcpConnectionTable は両端の InetAddressType、アドレス、ポートで索引する。RFC 4001 の zone index 付き表現は、同じスコープのアドレスだけではインターフェースを区別できない場合にも対応する。

listen は独立した表に移り、両アドレス族、単一族、特定アドレスへの待受けを区別できる。接続と listener には OS の process ID も加わり、HOST-RESOURCES-MIB などとの照合が可能になった。

これは socket とプロセスの帰属を改善するが、人の意思や事業結果までは示さない。PID はゼロの場合があり、再利用され、ホスト外では意味を失うこともある。

deleteTCB(12) 自体は残った。ただし RFC 4022 の適合宣言は、状態オブジェクトを read-only にしてよく、書き込みと deleteTCB の実装は必須でないとする。MIB 対応、操作能力、認可、実行、結果は別々に確認しなければならない。

さらに同 RFC の安全性節は、無許可の書き込みが任意の接続を終端して DoS を起こし得ると明記した。接続、listener、プロセスの読み取り情報も機微になり得る。

SNMPv3 が証明する範囲

RFC 3414 の USM はユーザー名、メッセージ完全性、適時性、必要なら秘密性を提供する。RFC 3415 の VACM は security model/name/level、context、read/write/notify view、対象インスタンスから許可を判断する。読み手と切断できる書き手を分離する基礎になる。

それでも認証されるのはメッセージが代表するユーザーであり、必ずしも操作した個人ではない。工票、判断理由、アプリ確認、相手の受信、顧客影響、復旧時間も自動では残らない。

緊急停止手段を持つこと自体が誤りなのではない。観測、認可、実行、結果検証を一つの緑色応答に縮めないことが歴史的な要点である。仕様はレバーを定義できるが、その後を生きるのは running code である。

出典

証拠の限界

出典が証明するのは文書系譜、オブジェクト、適合条件、安全モデルである。特定ベンダーの実装、実際の操作、事故、普及率、SLA 違反、現在の既定値は証明しない。