要約

  • RFC 9565はtcpControlBitsをIANAのTCP Header Flags登録簿に結び付け、割当済みか未割当かを問わず、観測した制御ビットをそのまま輸出するよう求める。
  • 出力はFlow内のパケットをまたぐ論理和である。各ビットは「一度でも見えた」ことしか表さず、順序、方向、回数、同一パケット上の組合せを保存しない。
  • TCP状態を論じるには、Templateとフィールド長、観測時代、輸出装置の能力、方向情報に加え、パケット列または端点の証拠が必要になる。

監視装置の更新後、それまで「予約済み」と表示されていた位置に値が現れた。故障として消すべきか、新しい割当として読むべきか。答えはローカルなラベルだけでは決まらない。どの時点のIANA登録簿を参照し、どの輸出コードとTemplateがその値を作ったのかを知らなければならない。

RFC 9565が修正したのは、まさにこの時間差である。IPFIX Information Element 6の静的なフラグ表を権威あるIANA TCP Header Flags登録簿へ接続し、unsigned16のflags型として、未割当位置を含めて観測どおり輸出する。将来の変更や予期しない利用を、古い語彙の都合で消さないための設計だ。

ただし、保存されるのはビットであり、出来事の並びではない。

論理和が消すもの

あるFlowに属するどれか一つのパケットで制御ビットが立っていれば、輸出値の対応位置も立つ。これは効率のよい存在確認だが、どのパケットだったか、何回だったか、同じパケットに別のビットもあったか、どちらの端点が送ったかを失う。

SYNとACKが共存しても、三者間ハンドシェイクの成立は証明されない。FINとRSTの双方が見えても、どちらが先か、正常終了後の遅延パケットか、観測点が片方向だけだったかは分からない。Flowはキーとタイムアウト、Observation Point、方向規則による測定上の区切りであり、端点のTCP状態機械ではない。

従って、この値は珍しいフラグを含むFlowの探索には向く。一方、「接続が成立した」「相手が拒絶した」「送信者に特定の意図があった」という判定には、それだけでは足りない。探索条件と確定証拠を同じ欄に入れてはならない。

一オクテットのゼロは、未観測かもしれない

IPFIXではTemplateがData Recordの要素と長さを定める。RFC 9565はReduced-Size Encodingを認めるが、一オクテットのtcpControlBitsが表すのはビット位置8から15だけで、4から7については何も主張しない。全幅を扱えないMetering Processは、この縮小形を用いて能力限界を正直に表す。

収集側が元の長さを捨て、常に十六ビット整数へゼロ拡張すれば、「測れなかった」が「測って存在しなかった」に変わる。Templateの識別情報、Observation Domain、輸出装置の版、適用期間を残さなければ、後から区別できない。

位置0から3はTCP Data Offsetに当たるため、tcpControlBitsではゼロまたは無視すべき領域である。ヘッダー長はtcpHeaderLengthが担う。十六位置を同格のフラグとして表示する実装は、見やすさと引き換えに誤った意味を作る。

古いゼロと新しいビット

RFC 9293は現在よく知られた制御フラグを示し、RFC 8311は以前NSの実験用途と結び付いていた位置の扱いを変えた。RFC 7125系の古い定義では、現在なら観測を保持したい位置をゼロにする規則もあった。この履歴のため、ゼロは単純な不在ではない。旧実装、縮小幅、観測漏れ、または本当の不在が候補になる。

反対に、古い収集器が未知とするセット済みビットは、現行登録簿では正当かもしれない。先に値を保持し、時点に合う登録簿で解釈するのがRFC 9565の方向である。

Heng Luの現実レイヤーに沿えば、IANAは記号の権威、RFCは交換契約、稼働コードは観測行為、端点はTCP状態の主体である。Flow recordはそれらを結ぶ圧縮された受領書にすぎず、上位の権威を代行しない。