要約

  • LinkType 登録の Expert Review は、公式な数値割当てとバイト配置の調整を行う。公開仕様は推奨されるが必須ではなく、非公開仕様も許容され、最低要件は連絡先である。
  • したがって登録済み番号は、受け取ったファイルの作成者、センサー、完全性、真正性、解析器の安全性を証明しない。割当てと証拠能力を分離する必要がある。

調査会社から届いたキャプチャには、正式に登録された LinkType が書かれていた。社内の読取器もその値を知っており、エラーなくフィールドを展開した。報告書には「IANA 登録形式で取得されたため、標準化された公開仕様に基づく信頼できる証拠」と記された。

その一文には三つの飛躍があった。登録されていること、仕様が公開されていること、個別ファイルが真正であることは同じ命題ではない。さらに、正しい形式を選べたことと、安全に解析できたことも同じではない。

この境界を明示するのが Link-Layer Types for PCAP-related Capture File Formats である。リビジョン18は2026年4月6日付で、10月8日に失効する。10月3日の調査時点では、Informational を予定する OPSAWG の有効な Internet-Draft であり、RFC Editor のキューで最初の編集者を待っていた。RFC 番号はまだない。手続き上の進捗は、配備済み実装の適合証明ではない。

草案は PCAP と pcapng が使う LinkType の IANA 登録簿を提案する。16ビット値は、保存されたパケットの前にあるメタデータとレイヤー2カプセル化の形式を選ぶ。読取器にとって不可欠な道標だが、その道標が語るのはバイト文法だけである。

審査が確認する範囲

0から65000までの値は RFC 8126 の Expert Review で割り当てられる。65001から65535は Experimental Use である。147から162までの歴史的な私用値は引き続き利用できるが、新しい私用には実験範囲が推奨される。

指定専門家は、安定した URL にある仕様を申請者に勧める。仕様を読むことで、既存形式との重複を見つけられる場合がある。また IPv4 や IPv6 ヘッダーを含み得る形式では、開始位置から IP ヘッダーまでのオクテットを明確に説明する必要がある。

しかし仕様そのものは必須ではない。公開されない仕様も受け入れられる。最低条件は、その LinkType の連絡先である。この設計は欠陥ではない。番号調整に必要な負担を限定し、私有技術にも正式値への道を開く。

同時に、それは登録の意味を厳密に限定する。Expert Review は透明性監査ではない。製品認証でも、セキュリティ評価でも、証拠保全制度でもない。登録項目があるからといって、受領ファイルが登録申請者によって作られたとは限らない。

適切な文法と真実の内容

LinkType が正しければ、読取器は先頭のオクテットを正しい構造として扱える。だが、ファイル内のインターフェース名、説明、方向、時刻が真実かどうかは別である。

pcapng は Interface Description Block とセクション内だけで一意な Interface ID を持つ。Enhanced Packet Block はその ID を参照できる。複数インターフェースを一つのファイルに記録できる点は、単一 LinkType しか持たない旧 PCAP より豊かである。

それでも if_name は書込み側が置いた文字列である。Interface ID 0 は別のセクションでは別の対象になり得る。Simple Packet Block は ID を持たず、最初の Interface Description Block を暗黙に使う。構造的に正しいことは、記述された由来が真正であることを意味しない。

証拠システムは「ファイルがこう主張する」と「独立した仕組みがこう確認した」を分けなければならない。センサー証明、取得時ハッシュ、署名、保管移転記録、時計検証、ミラー設定といった外部証拠が、主張を支える。

LinkType は安全な入力許可証でもない

草案は、PCAP 関連ファイルの読取器が悪意ある主体に制御された任意入力を受ける可能性を指摘し、最大限の注意を求める。スナップショット長により末尾が省かれても、パケット内部の長さフィールドは完全なサイズを主張し得る。無条件に従えば、単純なバッファオーバーリードになる。

正しい LinkType は正しい解析コード経路を選ぶ。それは、その経路に入るバイトを信用してよいという意味ではない。むしろ登録形式を増やすほど、サービスはより多くの解析器に攻撃者入力を届けられる。

旧 PCAP の草案も、ファイルヘッダー、パケットレコードヘッダー、LinkType に従って読むデータすべての検証を要求する。外部から来たファイルは意図的に壊されているかもしれない。

したがって取込み境界では、サンドボックス、境界チェック、CPU・メモリ制限、失敗の封じ込め、解析器と定義のバージョン記録が必要になる。「登録済み」は許可条件ではなく、適用すべき検証規則を選ぶ入力である。

完全性も出所も別の列に置く

PCAP と pcapng は captured length と original length を区別する。SnapLen が小さければ、末尾は保存されない。正しく解析できても、欠落部分の内容は分からない。検索対象が見つからないことは、保存範囲に存在しないことしか示さない。

旧 PCAP はファイル全体で一つの LinkType を使う。草案は、それがしばしば単一インターフェース由来を意味すると説明するが、保証ではない。複数の取得元を同じ保存表現に正規化できる。LINKTYPE_ETHERNET は Ethernet 形状のバイトを示しても、物理ポートや一台のセンサーを証明しない。

DLT との関係にも同じ注意が要る。DLT と LinkType の数値はしばしば同じだが、常に同じではない。一部の DLT は OS 固有で標準化対象ではない。整数だけを移送すると、名前空間が消える。

Minimum Initial Specification として共通化すべきなのは、形式、名前空間、値、定義版、作成ツール、変換、長さ、セクション範囲、解析結果である。真正性や行動権限を一つの登録項目に押し込む必要はない。薄い共通層は、後段の責任を可視化する。

実装試験では、登録形式の正常ファイルだけでなく、非公開定義、偽のインターフェース名、再利用された Interface ID、切断されたペイロード、衝突する実験値、OS 固有 DLT、悪意ある長さを与えるべきだ。システムが「解釈できた」から「信頼できる」へ飛ばないことを確認する。

登録番号は協調の成果である。その価値を守る最善の方法は、登録がしていない約束を登録に負わせないことだ。

出典