要約

  • RFC 3395 は RMON のプロトコル識別子にアプリケーション動詞を加えた。ただし動詞は、目の前の一パケットに書かれた命令ではなく、複数パケットと双方向にまたがる取引になり得た。
  • それでも各パケットは完全な一つの葉に一度だけ計上された。複数の動詞が同居すれば、プローブは標準化されていない自らの方針で一つを選ぶ必要があった。

同じ回線を二台のプローブに見せる。入力されたバイト列は同じで、登録済みの名称も同じ、どちらも仕様に適合している。それでも動詞別の数字が一致しないことがある。RFC 3395 は、この一見した矛盾を隠さなかった。複数の動詞型を含むパケットは一つに分類しなければならないが、その選び方は実装固有だったからである。

2002年9月に標準化過程の文書として公開された RFC 3395 は、RFC 2895 の Protocol Identifier Reference を更新した。RMON はプロトコルごとの通信量を捉えられたが、HTTP、SNMP、FTP という大きな箱だけでは、性質も負荷も異なる操作を区別できない。そこで文書はアプリケーション取引の共通命名法を与えた。新しい MIB モジュールや管理操作を設けたわけではない。

基礎となるディレクトリは、パケットを層の連なりとして表した。認識した層ごとに protocolDirID へ4オクテット、protocolDirParameters へ1オクテットが加わり、全体で一つの葉までのカプセル化を指した。アプリケーション動詞は、その末尾に加わる新しい層だった。

動詞層は4オクテットである。先頭は予約されたゼロ、続く24ビットがネットワークバイト順の符号なし列挙値となる。明示的な値は1から16,777,215までで、親プロトコル内で一意でなければならず、密に割り当てることが推奨された。パラメータ列には未使用のゼロが一つ加わる。情報不足ではなく、層ごとの形を保つためのゼロである。

列挙値ゼロには、すでに役割があった。すべてのアプリケーションプロトコルは、他の動詞に属さない接続確立・終了の通信を受ける暗黙の connect(0) を持つ。この値は再定義できない。一方、名前そのものは絶対予約ではない。HTTP の例には、明示的な CONNECT 操作として connect(8) もある。親、値、名前を切り離せば、異なる意味を誤って同一視する。

VERB-IDENTIFIER マクロは親プロトコル、必須の説明、権威ある文献がある場合に付けるべき参照、そして名前と値の一覧を結びつけた。名前は大文字小文字を区別し、同じ親の中で一意であり、既存の公式用語を使うことが望まれた。これで製品間の語彙は揃う。しかし語彙が同じでも、証拠を得る手順までは揃わない。

SNMP Response PDU が好例である。応答だけを見ても、それが Get と GetNext のどちらに答えたのか分からない。プローブは逆方向で先に流れた要求を保持し、応答と対応付ける必要がある。RFC の SNMP 例で Response と Report が独立した動詞にならず、元の要求取引の下に数えられるのはそのためだ。現在のパケットを分類する材料が、過去にある。

TCP では、別の形で時間が入り込む。一つのアプリケーション操作が複数セグメントに分割されるため、プローブはフローを追い、判断に足るバイト列を再構成しなければならない。動詞が分かってから捕捉を始める設計では、最初のパケットがすでに通過している。先行分を事前バッファに置かなければ、操作別と称する記録の冒頭が欠ける。

したがって、ここでいう「動詞」は単一の opcode、コマンド文字列、PDU 型と同義ではない。一つの取引が複数種類のメッセージを含むことも、複数のディレクトリエントリにまたがることもある。FTP の制御接続とデータ接続は、同じ有用な操作を構成し得る。動詞は毎パケットから写す欄ではなく、監視側が取引に与える分類だった。

それでも RMON の出力は曖昧なままにできない。各パケットは完全な葉カプセル化の下に一度だけ入り、その全長がカウンタへ加算される。認識した部分の長さだけを数えるのでも、複数動詞へ分配するのでもない。複数候補があれば一つを選ぶ。

RFC は選択例として、最初の動詞、出現回数が最多の動詞、最も多くのオクテットを占める動詞、またはプロトコル知識から最重要と判断した動詞を挙げた。だが統一規則にはしなかった。どの方法も異なる問いに答えるため、同じトレースから異なる分布が生まれても、直ちに片方が不適合とは限らない。

FTP、POP3、SNMP、HTTP、SMTP の例は登録を具体化すると同時に、証拠の限界も示す。GET という計数は、利用者の意図、身元、権限、取引成功、完全な内容の可視性を証明しない。ある時点の状態と方針を持つエージェントが、その葉へパケットを帰属させたことを示すにすぎない。

セキュリティ節も細粒度化を無害とは扱わなかった。新しい MIB 操作は増えないが、動詞別の収集結果はネットワーク上で使われているアプリケーション操作を明らかにする。その情報には追加の保護が必要になり得る。観測能力が細かくなれば、漏れる知識も細かくなる。

その後 RFC 4502 が RFC 2021 の RMON-2 MIB 仕様を置き換えた。この系譜は制度上の位置を示すが、RFC 3395 の普及や、暗号化、欠損、状態枯渇時の製品動作を証明しない。標準は試験可能な約束であり、導入実態ではない。

Lu Heng の「最小初期仕様」は、この境界を理解する助けになる。RFC は共有に必要な符号化、親、名称、予約値、能力、単一葉計上を固定した。一方、タイムアウト、バッファ、再構成、複数動詞の優先順位は、個々のプロトコルと資源制約に対応できるよう地域的な実装判断に残した。

「動くコードの優位性」に従えば、数字と一緒にプローブ版、デコーダ、状態上限、損失、再構成、選択規則を保存しなければならない。それらがなければ、共通ラベルは共通の観測過程を意味しない。

RFC 3395 の教訓は、測定が虚構だということではない。数値には生成履歴があるということだ。ネットワークがパケットを送り、プローブが取引を構成する。GET と表示された数字は、通信量だけでなく、機械が何を覚え、どこまで待ち、最後に何を選んだかも映していた。

出典