要約

  • OPSAWGの草案は、QUICのヘッダー、パケット番号、フレーム種別、Stream IDを表す七つのIPFIX情報要素を提案する。第00版の要素番号は未定で、保護された値の取得には復号が要る。
  • 草案自身がいうflowはIPFIX上のflowであり、QUIC接続ではない。五つ組は変化し、Connection IDは交代し、意図的な移行を受動観測だけで結べない場合がある。
  • Daniel Kadeは、各フィールドに観測点、取得方式、復号の権限、損失範囲、利用可能な判断を結び付ける記録を提案する。これは編集上の提案であり、IETF要件ではない。

ネットワーク運用では、空欄よりも埋まった表が好まれる。バージョン、接続ID、パケット番号、フレーム種別、Stream IDが一行に揃えば、障害調査も容量分析も容易に見える。そこで行に「QUIC接続」という名前を付けたくなる。

だが、その行は一つの目が見たものではないかもしれない。バージョンは経路上で見えた。短いヘッダーのConnection IDは設定済みの長さで切り出した。フレームはInitial secretで開いた。Stream IDはサーバーが1-RTTを復号して出した。さらに二つのObservation Domainを相関器が結んだ。

すべての値が正しくても、結合の結論は別の証拠である。

まず草案の現在地を固定する

draft-ietf-opsawg-ipfix-quic-header-00 は2026年9月にOPSAWGのWG Documentとなった。Datatrackerには、目標とするRFC status、document shepherd、担当Area Director、telechatがまだ記録されていない。状態はI-D Existsであり、IETF承認済み仕様ではない。

提案される要素は quicHeaderFlag、quicVersion、quicDestinationConnectionID、quicSourceConnectionID、quicPacketNumber、quicFrameType、quicStreamID である。第00版のElement IDはTBD1からTBD7のままだ。IANA登録が済んだ番号として扱ってはならない。

一方、共通語彙の必要性は明確だ。QUICではTCPで経路装置に見えていた多くの情報が保護される。複数ベンダーのexporterが、実際に得た範囲を同じ型と名称で送れれば比較が容易になる。ここで標準化されるのはフィールドの意味であり、あらゆる観測者に同じ視界を与えることではない。

可視・設定・復号を混ぜない

長いQUICヘッダーではversionとSource/Destination Connection IDが見える。先頭オクテットには見えるbitと保護されたbitが混在する。短いヘッダーにはDestination Connection IDの長さがないため、中間装置は長さを事前設定するか、以前の文脈から知る必要がある。

したがって同じ quicDestinationConnectionID でも、明示された長さで読んだ値と、ローカル設定で切り出した値がある。設定版を保存しなければ、後から同じパケットを同じように解釈できない。

RFC 9001 では、パケット番号と先頭オクテットの一部がheader protectionを受け、フレームは暗号化されたpayloadに入る。草案もpacket number、frame type、Stream IDはendpointまたはQUICを復号できる装置から得るとしている。

復号にも層がある。RFC 9312 によれば、Initial packetのsecretはversionごとの定数とクライアントの最初のDestination Connection IDから導出できる。経路上の観測者にも開ける場合がある。Handshakeや1-RTTはendpoint間で確立された鍵を使う。Initialを開けた事実から、1-RTTのStream IDまで取得できるとはいえない。

取得区分は少なくとも、wire-visible、configured-match、initial-secret-derived、endpoint-decrypted、inferredに分けるべきだ。非空の値というだけでは権限も再現性も分からない。

IPFIXのflowには観測場所がある

RFC 7011 は、一定時間にObservation Pointを通り、共通属性を持つpacketまたはframeの集合をFlowと呼ぶ。Flow Recordはその観測集合の性質を記録する。QUIC IPFIX草案も、自らのflowはIPFIXの意味でありQUICの意味ではないと明記する。

Observation Pointは回線、router port、論理interface、複数interfaceの集合になり得る。Observation Domain IDはExporting Processの中でローカルに一意である。Metering Processがrecordを作り、Exporterが送り、Collectorがtemplateを用いて解釈する。

QUIC connectionはendpointが持つ状態である。一つのconnectionが複数の五つ組を移動し、多数のstreamと複数のpacket-number spaceを持つ。旧経路のsensorは新経路を見ない。endpointは暗号状態を知るが、上流のどこでdatagramが捨てられたかは知らない場合がある。両者は補完的だが、同一ではない。

Connection IDは永久IDではない

RFC 9000 では、各endpointが自分へ送るpacketに相手が使うConnection IDを発行する。一つのconnectionに複数のactive IDがあり得る。古いIDはretireされ、新しいIDが供給され、送信側は使うIDを変えられる。zero-length IDも条件付きで認められる。

この仕組みにより、NAT rebindingやmigrationで五つ組が変わっても接続を保てる。同時に、意図しないlinkabilityを減らす。RFC 9312は、新しいIDが新しいconnectionを意味するとは限らず、同じIDが別の五つ組に現れても継続性を必ず証明するわけではないと警告する。意図的なmigrationではIDも変わるため、受動観測者はwire imageだけで前後を結べない。

五つ組だけで集約すれば移行したconnectionを分割し、同じaddress/portを共有する複数connectionを混ぜる可能性がある。IDだけで集約すればrotationで分割する。別経路で同じIDを見たという理由だけで結べば誤結合する。必要なのは万能鍵ではなく、相関規則と反証可能性の保存である。

endpointの知識をexportする責任

endpointが保護された情報を必要なcollectorへ出す設計は、経路装置にtraffic secretを配るより安全になり得る。しかしframe typeやStream IDがIPFIXへ出た時点で、情報公開の境界はendpointの外へ移る。

RFC 7011はIPFIX転送の機密性、完全性、認証を求め、flow dataが個人識別やprivacyに関わり得るとする。暗号化されたexport channelは必要だが、tenant間共有、分析者権限、保存期間、自動判断への投入までは決めない。

packet numberは暗号nonceに関係し、frame typeはtransport動作を示し、Stream IDはconnection内のstreamと発起側・方向を示す。application payloadではなくても、組合せれば受動経路からは見えなかった構造が分かる。telemetryという名称は開示判断を不要にしない。

endpoint-decrypted値にはclient/serverの役割と承認目的を付ける。Initial-derivedは別区分にする。configured-matchは設定版を残す。inferenceは測定値の外観を持たせない。secret key自体はprovenanceに記録しない。

exportの連続性とpacketの完全性

IPFIX Sequence Numberは、一つのexport streamとObservation Domainで送られたData Recordsを数える。Collectorは不連続からrecordの欠落や並べ替えを検知できる。しかしObservation Pointへ来なかったQUIC packet、samplingで除外したpacket、metering policyが作らなかったrecord、復号に失敗したfieldまでは示さない。

Templateも不可欠だ。Data Recordのbytesは適用されるTemplate Recordがあって初めて意味を持つ。templateを失えば、recordは届いても解釈できない。export timeはcapture timeではない。Collectorによる正規化はraw measurementではない。

「完全」という主張には範囲が必要だ。exporter Eがdomain Dで送ったsequence区間にrecord gapがない。point Pでpolicy Mが観測したpacketを処理した。endpoint Rが受信したpacketのprotected fieldを開いた。この三つを足しても、end-to-end connectionを全部見たとは限らない。

フィールド単位の観測provenance

私が提案するのはフィールド単位の観測provenance記録である。七つのInformation Elementを変更せず、IPFIXをQUIC connection台帳にも変えない。

各値にexporter、Observation Domain、正確なObservation Point、capture/export時刻、方向、五つ組、header form、version、IEとtemplateの版、raw valueまたは明示的なabsence、取得区分を結ぶ。

protected fieldには復号を行ったendpoint roleと権限を付け、鍵は付けない。Connection IDには長さ、その根拠、発行側、方向、rotation/retirementを観測できた範囲を付ける。packet numberにはspaceを、frameとstreamには実際のpacket occurrenceを残す。

さらにsampling/metering policy、capture loss、export suppression、Sequence Number gap、template変更、Collector変換を記録する。最後に許可consumer、retention、aggregation、利用可能なdecision、矛盾、owner、expiryを置く。

これはDaniel Kadeの編集提案であり、第00版、OPSAWG、IANAの要件ではない。狙いは、正しいfield同士が一行に並んだだけで、誰も観測していない完全なconnectionへ昇格するのを防ぐことだ。

主張を一段ずつ上げる

「Pでlong-header versionを観測」はwire claimである。「configuration Cでshort-header IDを抽出」は設定依存である。「version-derived Initial secretでframe typeを得た」は限定的なcryptographic claimである。「server EがStream IDをexportした」はendpoint claimである。「これらのflowは同じconnectionに属する」はcorrelationの結論である。

標準フィールドは比較を可能にする。比較可能性を全知に変えないことが、運用上の信頼を作る。

情報源