要約

  • IPFIX の フィールド定義番号 は転送セッションと Observation Domain の組み合わせで意味を持つ。観測ドメインの番号はエクスポート処理内の識別子であり、世界共通の装置、拠点、契約者の番号ではない。
  • 記録を復号できることと、対象の通信を漏れなく正しく測ったことは別である。選別、集約、中継、バッファ損失、時刻の意味を捨てれば、整った集計ほど誤解を招く。

再接続で終わる約束

あるエクスポータが最初の TCP 接続で、フィールド定義番号 256 に送受信アドレス、ポート、カウンタの並びを割り当てたとする。その接続が終了し、次の接続では同じ番号を別の並びに割り当てる。収集側が古い定義を持ち越すと、長さが合う組み合わせでは値がもっともらしく見える。項目名と単位だけが違うという、検知しにくい状態になりうる。

これは実装を考えるための仮想例であり、特定製品の不具合を述べたものではない。RFC 7011 が要求する境界は明確だ。同じエクスポート処理から届いても、前の転送セッションで受け取った定義を、新しいセッションの Data Set に使ってはならない。

データが保存されてから問題が分かると、影響は解析器で止まらない。トラフィック報告、障害調査、利用量計算が同じ誤った列を参照し、後から正しい意味を復元するには、その時点の定義と接続履歴が必要になる。

観測した場所と、報告した主体

IPFIX の構成要素は役割を分けている。Observation Point はパケットを観測できる位置、Metering Process は分類や時刻付与、流の記録を担う処理、Exporting Process はメッセージを送る処理、Collecting Process は受け取る処理だ。

Observation Domain は、一つの計量処理がフロー情報を集約できる最大の観測点集合を表す。その 32 ビット番号は Exporting Process 内で一意になる。RFC 7011 は装置内でも一意にすることを推奨するが、世界全体の一意性を定めてはいない。

二つの装置がともにドメイン 17 を報告しても、同じ拠点を測ったことにはならない。逆に、同じ拠点で番号が変わっても契約主体が変わったとはいえない。顧客や設備との対応は別の台帳で管理する必要がある。

収集基盤が維持すべき最小の文脈は、送信元の装置と処理、転送セッション、観測ドメイン、フィールド定義番号 と有効な定義だ。SCTP を使う場合、シーケンスの管理にはストリームの区別も加わる。番号だけを列の共通キーにする設計は、この局所性を消してしまう。

読み方が決まっても、値の正しさは決まらない

フィールド定義 は Information Element と長さを順番に並べた定義である。Data Set の Set ID がその定義を指し、収集側はバイト列の区切りと解釈を知る。

Information Element の意味は RFC 7012 と IANA の登録情報に依存する。企業独自の要素では企業番号も識別に必要だ。同じ数値の要素番号を持つからといって、異なる企業の定義を一つにまとめられない。RFC 5610 の型情報の伝達や RFC 7013 の定義・審査指針も、意味の共有を助けるものであり、測定結果を認証するものではない。

収集側が八つのバイトを正しくカウンタとして読めても、測定対象のインターフェースが正しいか、Flow Keys が目的に合うか、カウンタが実際のパケットを正しく数えたかは分からない。構文上の成功を実世界の正確さへ拡張してはならない。

定義には寿命がある

接続型の転送では、定義を撤回し、適切な順序で番号を再利用できる。収集側は撤回された定義を、その後の Data Set に適用し続けてはならない。どの時点の記録にどの定義が有効だったかを履歴として残す必要がある。

UDP では事情が異なる。接続の終了で状態が自然に区切られず、定義を伝えるメッセージ自体が失われたり順序を変えたりする。更新、置換、有効期限の管理を別途行う。対応する定義より先に記録が着いたときは、保留したのか、破棄したのか、後からどの定義で解釈したのかを明示する。別のドメインの定義を借りる理由にはならない。

RFC 6313 が定める入れ子のリストや構造化レコードにも同じ原則が及ぶ。構造が整っていることは、各値が実際に観測されたことを保証しない。

欠番がない、の狭い意味

IPFIX の Sequence Number は、その観測ドメインの当該ストリームで送った Data Records の数を、2^32 を法として数える。フィールド定義レコード と オプション定義レコード は数に入らない。SCTP のストリームごとに別の計数となる。

不連続は記録の欠落、重複、順序の入れ替わりを調べる手掛かりになる。しかし、欠けたパケット数ではない。観測点に届かなかった通信、流の生成前に選別されたパケット、記録にされなかった対象は、このカウンタの外にある。

TCP の信頼性も測定全体へは延長できない。収集側が遅い場合や混雑時にはエクスポータのバッファが満杯になり、記録が捨てられうる。規格はこの損失を計上するよう求める。転送に欠番がないという結果と、エクスポート前の損失統計を合わせて見る必要がある。

時刻も区別したい。ヘッダの Export Time はメッセージがエクスポート処理を出る時刻だ。フロー開始、終了、観測点の時刻とは異なる。遅延や集約窓、時計の同期を無視して、輸出時刻を通信発生時刻として扱うことはできない。

集計の前に母集団を問う

パケットの選別はフロー生成より前に行われることがある。さらに RFC 7014 のフロー選択が、できあがった流の一部だけを採用する。ある段階で「完全なフロー」と呼べても、それ以前のパケット選別を通過した集合に対して完全であるだけかもしれない。

RFC 7015 の集約は複数の記録をまとめる。RFC 6183 の中継処理は受信、選択、変換、再エクスポートを行える。下流に届いた記録は新たな報告文脈に属する。元のエクスポータ、観測ドメイン、適用した変換を用途に応じて保持しなければ、派生値が直接の観測値として流通する。

抽出率だけでは足りない。どの段階で、何を対象に、どの規則と計数で選んだかが分母を決める。出力された記録数から、元のパケット総数へ無条件に戻ることはできない。

暗号化した通路にも測定誤差は通る

適切な TLS や DTLS は機密性、完全性、通信する処理の認証に役立つ。定義の偽造は多くの記録の解釈を汚染でき、フロー情報そのものも機微な通信関係を明かしうるため、保護は重要だ。

ただし、本物のエクスポータが間違ったインターフェース対応や未申告の抽出設定で測った値を送ることは可能だ。認証は「誰から届いたか」を強めるが、「どう測ったか」を代替しない。

検証では、再接続後の番号再利用、異なる送信元とドメインの同番号、撤回と再定義、UDP 定義の欠落を試す。さらに記録損失、バッファあふれ、選別、中継を一つずつ加える。最後に認証済みの通路で誤ったカウンタを送ってみる。受信元の認証成功と測定の不整合を、別々の結果として示せることが重要だ。