要約

  • RFC 1326では、XをYで包む境界とYをXで包む境界が経路ループでつながり、出口へ届く前のパケットに外皮が重ねられた。
  • 新しい外側ヘッダーが以前のホップ数を継承しなければ、内側に残った制限は全行程を測れない。サイズがMTUに達すると、断片が同じ循環を繰り返して個数を増やす。
  • ホップ数の引き継ぎ、内側ヘッダーの検査、特定の入れ子禁止はいずれも範囲が限られる。必要なのは、すべての境界が消費する一つの再設定不能な予算だった。

有効な橋は一方向で完結する

カプセル化そのものは異種ネットワークを接続するための実用的な方法だった。X形式のパケットがYだけを理解するバックボーンを通るとき、入口ルーターはYヘッダーを付け、出口へ送る。出口はYを外し、元のXを次へ渡す。中間網は内側のプロトコルを理解しなくてよい。

RFC 1326が問題にしたのは、この関係が別の場所で逆向きにも存在する場合である。ある区間にはX over Yがあり、別の区間にはY over Xがある。文書はIP over AppleTalkとAppleTalk over IPを例に挙げ、IP、CLNP、IPX、DECNETなどが混在する環境では同様の組合せが増えると考えた。

経路が一時的に循環すると、Xはまず Y<X> になる。ところが想定した出口ではなく、X網を越える別の入口へ届く。そこではYを外さずXを加え、X<Y<X>> になる。最初の種類の境界へ戻れば、さらにYが付き Y<X<Y<X>>> となる。

各ルーターは、直後のリンクに必要な形式を正しく用意しているかもしれない。その記録が証明するのは局所変換だけだ。目的地への接近、正しい出口での解除、あるいは全体の有限性は証明しない。

内側の時計は外側を止められない

通常の転送ループはホップ数やTTLによって終わる。通過するたび値が減り、ゼロになれば破棄される。RFC 1326の危険な条件は、連続するカプセル化が前のヘッダーのホップ数を保存しないことだった。

元の値が壊れる必要はない。新しいパケットのペイロードとして残っていても、外側のネットワークはそれを転送判断に使わない。新しい外皮が新しい値を持つたび、現在有効な寿命だけが更新される。

したがって、外側の非ゼロ値は現在のトンネル内で残る距離の証拠にすぎない。内側のパケットが何回入口へ戻ったか、入れ子が何段あるかは示さない。観測できるヘッダーと運ばれる対象の履歴を同一視すると、複数の局所時計を一つの通算時計と誤認する。

異なるプロトコル間では単純な値の移送も難しい。RFC 1326はX.25やSMDSにはホップ数がないと述べ、範囲の違いも指摘した。AppleTalkの上限は16、IPは最大256を表せる。小さい側へ合わせれば循環を短くできても、16ホップを超える正当なIP経路をブラックホール化する可能性がある。変換は中立なコピーではなく、どの意味を失うかという選択になる。

断片化が個体数を変えた

一周ごとに増えるヘッダーは、最初は一つのパケットを線形に大きくする。MTUに達すると性質が変わる。リンクへ収まらない外装済みパケットが複数の断片になり、それぞれが同じ経路関係の中で再び包まれる。断片も成長し、さらに分割され得る。

RFC 1326が述べた指数的なpacket explosionは、この反復を指す。物理的爆発でも、実証された攻撃でもない。一個が複数になり、その複数が同じ増殖条件へ戻るという機構である。

リンクが埋まると、経路更新や管理パケットまで捨てられる可能性がある。すると誤ったデータ転送が、経路を自動修正するためのフィードバックを奪う。容量不足は単なる結果ではなく、回復不能を長引かせる原因にもなる。

文書はループが切れればパケットは速やかに排出されるとも述べた。しかしこれは名前のある障害や復旧時間の観測ではない。ループの解消、残存トラフィックの消失、利用者が見るサービス回復は別々に確認すべき状態である。

深く見ても全体は見えない

一つの案は、新しいヘッダーへホップ数を保存することだった。両方式に互換のフィールドがあれば有効だが、フィールドがない方式や範囲が異なる方式をまたぐと意味が崩れる。

別の案は、追加前に内側を調べ、すでに同じプロトコルがあれば捨てることだった。だが未知のヘッダー、暗号化された内側、トランスポート層の中にあるネットワークプロトコルは検査を止める。さらに同じヘッダーが二度現れる正当な入れ子もあり得る。繰り返しは警告材料であって、普遍的な無効判定ではない。

RFC 1326は、相互カプセル化を避け、入れ子の相互カプセル化を禁じ、適切な場面でホップ数保存と検査を組み合わせるという慎重な方向を示した。それはInternet StandardではなくInformationalであり、セキュリティ問題は論じていないと明記した。後世の説明が攻撃者や実事故を付け足してはならない。

転送回数と入れ子回数を分ける

後のRFC 2003はIP-in-IPについて、転送の一部としてトンネル化する際に内側TTLを一度減らし、TTLゼロのデータグラムを包むことを禁じた。送信元がカプセル化装置自身やトンネル宛先に一致する特定のループも拒否する。これは定義されたIP範囲での対策であり、あらゆる混成構成の保証ではない。

RFC 2473はIPv6トンネルで、元パケットのhop limitとTunnel Encapsulation Limitを分離した。前者は元パケットの転送を数え、後者は追加できる入れ子層を数える。後者がゼロなら、現在のトンネルを出る前に別のトンネルへ入れない。

二つの値は重複ではない。危険を生む出来事が違うからである。RFC 2473は、すでに断片化されたトンネルパケットを再び断片化すると断片数が倍になることも確認した。1998年の仕様は1992年の警告を一般論のまま残さず、入れ子専用の観測可能な制約へ変えた。

出典

これらは文書の位置付け、記述された機構、後のプロトコル上の応答を裏付ける。1992年の実事故、現在のトンネル、攻撃者、製品欠陥、普及率、損害、復旧成功を証明するものではない。