要約

  • mipAuthFailureが届かない理由には、失敗がない場合だけでなく、未実装、未有効化、アクセス制限、通知経路の障害がある。
  • 欠測を状態ゼロとして保存せず、「観測できたゼロ」と「観測不能」を別の運用状態として扱う必要がある。

ゼロ件という表示には、少なくとも二つの世界が重なる。認証検証の失敗が本当に起きなかった世界と、失敗を報告する機能や経路が機能していない世界である。RFC 2006の任意通知mipAuthFailureは、この区別を自動では解決しない。

通知の前には、実装が検証失敗を分類し、違反オブジェクトを更新し、通知を生成し、アクセスとネットワークの経路を通す工程がある。最後の受信だけを監視しても、どこで沈黙したかは分からない。管理画面には「失敗なし」と「観測能力なし」を分ける第三の状態が必要になる。

MIP-MIBがmib-2 44の下で対象を少数に絞り、移動ノード、外部エージェント、ホームエージェントごとにグループ化した設計も同じ問題を持つ。必須の基本グループと、実装・記録・報告能力に依存するグループを一律に扱うことはできない。

能力を確認してから値を読む

mipEntitiesは、装置が移動ノード、外部エージェント、ホームエージェントのどれを支援するかを示し、複数のビットを立てられる。mipEnableはMobile IPの有効・無効を要求し、mipEncapsulationSupportedは能力を列挙する。しかし、役割のビットは実際の処理量を示さず、書き込み成功は全活動の停止を保証せず、能力のビットはトンネルの合意やパケット通過を意味しない。

移動ノードのmnStateは、ホーム、登録済み、保留、孤立、不明を区別する。外部エージェント表は受信した広告で更新され、広告の失効に伴って古くなる。勧誘、広告、不正な拡張、そしてノードが移動や再起動だと「判断した」回数も数える。判断は物理的な移動の証明ではない。広告のシーケンス変化から再起動を検出しても、原因までは立証できない。

登録表は、エージェントアドレス、care-of address、フラグ、Identification、要求・残存時間、送信時刻、受理状態を結び付ける。要求送信、応答受信、再送で更新されるローカルな履歴であり、パケットキャプチャでも全ノード共通の取引台帳でもない。「受理」は管理対象が応答をどう記録したかを表すにすぎない。

ポーリングにも欠測がある

外部エージェントは、有効な要求の受信と転送、拒否コード、応答、認証失敗、形式エラーを数える。ホームエージェントはモビリティ・バインディング表と、全体またはノード別のサービス統計を持つ。双方の数字が同じでも、同じ要求群とは限らない。再送、損失、拒否、再起動、取得時刻が間に入るからだ。

バインディング行も行程全体を見ない。ホームアドレス、care-of address、受信元、フラグ、Identification、寿命をホームエージェントが保持していることは示せる。だがパケットがcare-of addressに届き、デカプセル化され、最後のリンクを渡り、アプリケーションに着いたかは見えない。

型にも境界がある。Counter32は折り返し、残存寿命のGauge32はポーリング時点の値である。TimeStampは絶対時刻ではなくsysUpTimeのエポックに結び付く。総サービス時間もホームエージェントの直近の再起動から累積される。幅、エポック、間隔を保存しなければ、差分が虚偽の連続性を作る。

届いた通知にも上限がある

セキュリティアソシエーション表は相手アドレスとSPIで索引される。鍵は管理経由で作成できるが、読み出し時は長さゼロの値を返す。空なのは秘匿のためで、鍵が存在しない証拠ではない。

違反オブジェクトは直近のアドレス、SPI、Identification、時刻、理由を保持し、任意のmipAuthFailure通知は登録要求または応答の検証失敗を知らせる。この報告だけでアドレスの背後にいる人を特定したり、侵害、偽装、古い状態を区別したり、すべての通知が届いたと証明したりはできない。エージェントの分類は調査の出発点である。

運用上の結論は、値だけでなく観測可能性の状態から作るべきだ。役割の対応、対象グループの実装、読み取り権限、直近の成功したポーリング、trapの試験送達、sysUpTimeの連続性を先に記録する。その土台が確認できた区間でのみ、表やカウンターを出来事の手掛かりとして使える。RFC 2006は「見えたもの」を整えたが、「見えなかった理由」まで一つにはしなかった。

出典