要約

  • RFC 7112は、IPv6のFragment Offsetがゼロである先頭フラグメントに、IPv6基本ヘッダーから最初の上位層ヘッダーまでの全チェーンを含めるよう求める。ステートレスな装置は、必要なプロトコル情報を見てから規則を適用できる。
  • 先頭の完全性とデータグラムの完全性は別である。送信側の構築、パスMTU、中継装置の設定、ICMPv6 Type 4 Code 3、後続断片、重複・重なり・タイムアウト、宛先での再構成、アプリケーションの結果を別々に記録する必要がある。

ポートだけが後から届く

IPv6では、基本ヘッダーとTCPやUDPの間に複数の拡張ヘッダーを置ける。受信側はNext Headerを順にたどって次の形式を知る。チェーンが長い場合、フラグメントの切れ目がTCPヘッダーより前に来ることがある。

宛先ポートで許可・拒否を決めるファイアウォールにとって、これは単なる欠落ではない。先頭を通せば、本来拒否するポートを後から知るかもしれない。捨てれば、許可対象だった通信を止めるかもしれない。決定は今必要なのに、決定材料は別の断片にある。

各中継装置に再構成を義務づける方法も考えられる。しかし、それは状態、メモリー、待ち時間とDoS面を経路全体に増やす。RFC 7112が選んだのは薄い修正だった。送信ホストがIPv6データグラムを分割するなら、先頭にヘッダーチェーン全体を置く。

先頭断片は、内容を全部明かす必要はない。次に来るプロトコルを識別できるところまで、自己紹介を済ませればよい。

「全体」はペイロードの手前で終わる

ここでいうヘッダーチェーンは、IPv6の最初のヘッダーから始まる。ゼロ個以上のIPv6拡張ヘッダーをたどり、最初の上位層ヘッダーで終わる。一般的にはTCP、UDP、ICMPv6である。IPv6-in-IPv6なら二つ目のIPv6ヘッダーが、この定義では上位層の終点になる。ESPも同様で、後続がなければNo Next Headerが終端になる。

TCPヘッダーの後ろにあるアプリケーションデータはチェーンに含まれない。したがって、RFC 7112は大きなペイロードを禁止していない。HTTP応答全体を先頭に詰め込む規則でもない。フィルターが参照し得る上位層ヘッダーまでを、パスMTU内に収める規則である。

この境界は、セキュリティの主張も限定する。TCPポートが見えればポートACLは評価できる。後続データの意味は分からない。完全な先頭断片は、ソースアドレスの真正性も、利用権限も、悪意の有無も証明しない。

装置が得るのは「この規則を評価するために必要な欄が見えた」という証拠だけだ。その先の判断を同じ証拠に背負わせてはいけない。

ゼロは順番であって身元ではない

RFC 7112は、Fragment Offsetがゼロのものを先頭フラグメントと定義する。機械はこの値をローカルに読める。中央の認証者も、完全な再構成も必要ない。

しかし、攻撃者もゼロを設定できる。正しいチェーンを作ることもできる。見えているIPv6ソースは、それだけでは暗号学的な本人確認にならない。形式に適合することと、通信が許されることは別である。

共通仕様が与えるのは観測可能な条件だ。どのポートを通すか、互換モードを残すか、違反時に中継で落とすかは各ネットワークが決める。宛先ホストも独自の受信処理を行う。

この分離によって、仕様は必要最小限の共通層にとどまる。文書を作ったIETFも、著者も、装置ベンダーも、運用者のローカル規則の所有者にはならない。

MUST、SHOULD、MAYを一つにしない

送信側が分割するとき、全チェーンを先頭に含めるのはMUSTである。一方、違反した先頭を受け取った宛先ホストは破棄し、通常のICMPv6規則に従ってエラーを返すべきだとされる。後方互換のため、受け入れる設定を実装が用意してもよい。

ルーターやファイアウォールなどの中継システムは、違反断片を捨ててもよく、エラーを送ってもよい。その能力があるなら、破棄を有効・無効にできる設定を支援すべきだとRFCは述べる。

すべてを「必ず落とす」に言い換えると、元の責任配分が消える。逆に「設定次第だから規則はない」と言うのも誤りだ。送信側の構築条件は明確で、受信側と中継側には異なる処置範囲が定められている。

インシデント記録には、規範語の違いを反映させる必要がある。どの装置、どのインターフェース、どのソフトウェア、どの規則版、どの互換設定が、何を見てどの処置をしたか。それがなければ「RFC 7112により遮断」という文は原因ではなく肩書きにすぎない。

Code 3が残す小さな受領証

この理由で断片を破棄し、エラーも返す場合、メッセージはICMPv6 Parameter ProblemのType 4、Code 3となる。Pointerはゼロである。IANAの説明も、先頭フラグメントのIPv6ヘッダーチェーンが不完全であることを指す。

専用コードがあることで、送信側は何が問題だったかを推測だけに頼らずに済む。運用者は増加時刻をホストOSの更新やトンネル変更と照合できる。テスト担当は、上位層ヘッダーの直前で切れたパケットを意図的に作り、挙動を確認できる。

ただし、Code 3が返るとは限らない。中継装置の送信は任意であり、ICMPv6の生成制限やレート制限、返路のフィルタリングもある。送信元が偽装されていれば、別の相手へ届く可能性もある。

受領証として使うなら、時刻、観測点、引用されたパケット、インターフェース、ローカルの破棄カウンター、規則版を結び付ける。コードだけでは、誰が判断したかまでは分からない。

八つの欄を持つ運用記録

第一はパケットの形である。送信元・宛先、Fragment Identification、offset、Mビット、拡張ヘッダー順、到達した上位層ヘッダー、チェーン長を保存する。第二は観測位置で、カプセル化の前後では見える構造が変わり得る。

第三はパスMTUである。全チェーンは宛先までのMTUを超えられない。RFC 7112は、パスMTUを発見しないホストにチェーンを1280バイト以内へ抑えるよう求める。トンネル追加やMTUキャッシュの古さは、不完全な先頭を生む現実的な原因になる。

第四は送信実装と版。第五は処置した装置、インターフェース、パーサー版、規則、互換モード、判定。第六はCode 3の生成・制限・受信。第七は後続断片のoffset、長さ、重なり、重複、到着とタイムアウト。第八がTCPやアプリケーションの結果である。

これらは別々に変化する。パケットは正しくてもログが誤る。破棄は続いてもICMPv6だけ消える。先頭は完全でも末尾が届かない。単一の「fragment blocked」へ圧縮すると、修理対象を選べなくなる。

入口検査と再構成は別工程

RFC 8200は、RFC 7112の更新をIPv6基本仕様へ取り込んだ。各断片に必要なヘッダー、Fragmentヘッダー、先頭にのみ置かれる後続拡張ヘッダーと上位層ヘッダー、そして断片データを区別している。

宛先での再構成は、送信元・宛先・Fragment Identificationを基にグループ化し、offsetと長さから位置を求める。60秒以内に揃わなければ放棄される。長さが不正ならエラーになる。重なりがあればデータグラム全体を捨てる。完全に同じ重複断片は、他を残して捨てる実装も許される。

先頭のチェーン検査は、その入口にすぎない。合格しても残りが届くとは限らない。再構成が成功してもアプリケーションが成功するとは限らない。

ファイアウォールが先頭だけを捨て、後続を転送する場合もある。offsetゼロがなければ宛先は元のデータグラムを再構成できないため、後続の転送数を「通信を許可した証拠」にしてはいけない。

ログは三つの文章を持つべきだ。先頭チェーンは適合した。再構成は完了した。サービスは完了した。どれか一つだけ真である状況は珍しくない。

アトミックフラグメントは別の状態

Fernando Gontが単独著者となったRFC 6946は、アトミックフラグメントを扱う。Fragmentヘッダーを持つが、offsetもMビットもゼロで、他の断片を待つ必要がない完全なデータグラムである。

一部の実装は、それでも同じ送信元・宛先・Identificationを持つ断片と再構成キューで混ぜていた。攻撃者がその混同を利用できたため、RFC 6946はアトミックフラグメントを他と独立に処理するよう定めた。RFC 8200にも反映されている。

これはRFC 7112の代わりではない。不完全な先頭、アトミック、重なりは、Fragmentヘッダーを共有していても別の遷移である。offset、M、識別子、チェーン終端、断片数を残さなければ区別できない。

ワイヤー上の情報が不足しているのではない。観測基盤が一つのラベルへ潰すことで不足が生まれる。

文書化された変更と実装された変更

RFC 7112は2014年にRFC 2460を更新した。2017年のRFC 8200は旧仕様を廃止し、Fragmentヘッダー後の拡張ヘッダーと上位層ヘッダーを先頭に置く要件、欠落時の破棄とCode 3を本文へ組み込んだ。

RFC 9099は運用上の推奨として、ファイアウォールやセキュリティ装置、宛先ノードが、トランスポートヘッダーを含む全チェーンのない先頭を落とすべきだと説明する。そうしなければステートレスフィルターを回避され得る。

ここから分かるのは仕様の履歴であり、特定装置の実装状態ではない。古い互換設定、ハードウェアパーサーの深さ、ICMPv6実装差、カプセル化後の観測点は現場ごとに違う。

採用は、構成した試験パケット、両側のキャプチャ、カウンター、版管理された設定、サービス結果で示す。出版日は実装完了日ではない。

Fernando Gontの貢献を限定して読む

RFC 7112の著者はFernando Gont、Vishwas Manral、Ron Bonicaの3人である。Standards Trackという位置づけはIETFのレビューと合意を表す。Gontだけの発明や、著者が各ネットワークを支配する根拠ではない。

人物として追う理由は、方法の連続性にある。RFC 6946では混ぜる必要のないアトミック状態を分離した。RFC 7112では、判断前に必要なプロトコル境界を先頭へ出した。現在のIETFプロフィールは40本のRFCを掲載し、プロトコルセキュリティの活動を記している。

共通するのは、実装が混同していた状態を分け、ローカルに確認できる条件へ変える作業だ。文書は境界を示す。装置は処置する。宛先は再構成する。アプリケーションは結果を出す。それぞれが別の証拠を残す。

先頭フラグメントは物語全体を話す必要はない。次に何が来るかを隠さず、後続の機械が自分の問いを正しく選べるようにすればよい。

出典