要約

  • RFC 2784は、配送用ヘッダー、GREヘッダー、ペイロードを分離する。4オクテットの基本部は内側のプロトコルを識別できるが、なぜトンネルが必要か、誰が利用できるか、開封後の通信が安全かまでは決めない。
  • Tony Liは、1994年のGRE文書と2000年の標準化文書の双方に共同著者として名を連ねる。後続RFCが示した運用上の負債も重要だ。Keyは秘密鍵ではなく文脈のラベルであり、Sequence Numberは状態とサービス拒否の危険を生み、IPv6の運搬には両端による継続的なMTUと完全性の判断が要る。

一つのパケットに二つの宛先が生まれる

GREの入口では、元のパケットがペイロードになる。その前にGREヘッダーを置き、さらに外側へ配送用ヘッダーを付ける。基盤ネットワークは外側の宛先を読み、構造全体を出口まで運ぶ。出口が外側の層を取り除くと、内側の宛先が再び転送を決める。

この手順は単なる包装ではない。三つの独立した記録を生む。配送用ヘッダーはトンネルの両端を示す。GREヘッダーは中身のプロトコルと使用する追加機能を示す。内側のパケットは、送信元、宛先、寿命、上位層での意味を保つ。外側の経路が通ることは、封筒が届く証明にすぎない。開封後の宛先が到達可能か、通信が許可されているか、正しい安全装置を通るかは証明しない。

2000年3月にStandards Trackとして公開されたRFC 2784には、Dino Farinacci、Tony Li、Stan Hanks、David Meyer、Paul Trainaが著者として並ぶ。その前身であるInformational RFC 1701は、Hanks、Li、Farinacci、Trainaの共同著作だ。IETF DatatrackerのTony Liページは、公開された本人情報、RFC一覧、記録凍結時点の役職を示す。これらが裏づけるのは集団での著作であり、単独発明や現在の雇用関係、実際に動くトンネルへの個人的支配ではない。

人物に即して言えることは、もっと限定的だ。Liは、汎用封筒の初期記述と、後にその共通核を意図的に小さくした仕様の両方に現れる。長く残った設計判断は、あらゆる用途を命令することではなく、余分な判断を共通ヘッダーへ持ち込まないことだった。

専用方式の組合せ表を一つの封筒へ置き換える

それぞれのペイロード用プロトコルを、それぞれの配送用プロトコルで運ぶたびに専用方式を作れば、組合せは行列のように増える。RFC 2784はこれをO(n²)の問題として説明し、ペイロード、共通のGRE、配送という三層に分けて扱おうとした。

ただし、汎用性は万能ではない。文書は、個々のプロトコル特有の事情を無視しているため、特定のX over Y方式のほうが適する場合があると明記する。さらに重要なのは、いつパケットをカプセル化すべきかを定めていないことだ。GREが与えるのは文法であり、利用の正当性ではない。

企業が離れた私設網を結ぶことも、事業者が基盤ネットワーク越しにサービスを運ぶことも、研究所が基盤側の未対応プロトコルを試すこともできる。しかし、形式がGREに従うだけでは、どの目的にも許可を与えない。所有者、両端、許可するペイロード、容量、安全境界、終了条件は、導入者が別に定めなければならない。

共通の封筒は実装費と調整費を減らすが、経路漏れ、ブラックホール、検査の空白、忘れられた依存関係まで引き受けない。GREの再利用で節約した当事者は、その運用結果についても責任を負う。

4オクテットは相手が知るべきことだけを書く

任意のチェックサムを使わない場合、RFC 2784の基本ヘッダーは二つの16ビット語から成る。最初の語にはチェックサム有無を示すビット、予約ビット、版番号が入り、次の語には内側のプロトコルを示すEtherTypeであるProtocol Typeが入る。基本形式の版番号は0だ。

そこには、世界共通のトンネル識別子、所有者、方針、経路、暗号化の宣言、サービス保証はない。次のバイト列をどう読めばよいかだけを相手へ伝える。未知のProtocol Typeは破棄すべきであり、予約ビットは0で送る。旧形式の意味を実装していない受信側は、特定の拡張位置が0でないパケットを推測で受け入れず、破棄しなければならない。

任意のチェックサムを付けると4オクテット増え、通常のInternet checksumでGREヘッダーとペイロードを覆う。対象部分の偶発的な破損は検出できるが、送信者の認証、内容の秘匿、利用権限の成立はできない。正しいチェックサムは、信頼できるトンネルの証明ではない。

パケット取得画面に現れる最小共通仕様とは、こういうものだ。共通の各ビットは相互運用の問いに答える。答えていない事項は、そのプロトコルの権限外に残る。

開封後の経路は内側へ戻る

内側がIPv4の場合、RFC 2784は出口に対し、内側の宛先で転送し、内側のTTLを減らすよう求める。外側の宛先は配送を終えれば役目を失い、ペイロードの経路判断を置き換えない。

仕様は鋭いループ条件も挙げる。開封後の内側の宛先が反対側のカプセル化装置を指すと、同じ関係へ再投入される可能性があり、そのパケットは破棄しなければならない。トンネルは内側から一部の地形を隠せても、ループの結果を消せない。

障害調査では、この分離が重要になる。外側のtracerouteが出口へ届いても、内側の経路がないことはある。トンネル用インターフェースが稼働中でも、開封後にペイロードが捨てられることがある。逆に、GREの障害と見えたものが、実際には基盤経路、戻り経路、フィルター、MTUの不一致である場合もある。三つの記録を別々に観測し、同じパケットで結び直す必要がある。

1994年の選択肢は、黙って継承されず絞り込まれた

RFC 1701のヘッダーは、Routing、Key、Sequence、Strict Source Route、Recursion Controlを含み得た。RFC 2784は複数ベンダーがすでに実装していた共通部分を選び、それらを基本形式から外した。旧形式を明示的に実装していない受信側は、対応する位置が0でないパケットを破棄する。

これは、標準化が機能を積み上げた物語ではない。独立実装が、より少ない意味について、より確実に合意できるよう、共通核を小さくした。任意機能は、曖昧な予約領域を推測させるのではなく、別の仕様として戻せる。

したがって互換性とは、説明可能な拒否境界でもある。片方だけが拡張を期待する問題は、未知の配置を寛容に受け入れても直らない。運用者は両端の能力を証明し、合意した形式だけを有効にし、以前の解析契約へ戻せる切戻し手順を保つべきだ。

Keyという名前でも秘密鍵ではない

LiではなくGovindan Dommetyが著したRFC 2890は、後に任意のKeyとSequence Numberを定義した。4オクテットのKeyは、カプセル化側と解除側の間で、通信の流れや文脈を識別する。値をどう得るかは文書の範囲外だ。

仕様は名称による誤解をはっきり退ける。Keyと呼ばれていても、安全を提供する鍵ではない。地域的な合意に従って利用者、サービス、通信を区別できるが、別の保護がなければGREを作れる者が番号を複製したり偽造したりできる。文脈ラベルをパスワードとして扱えば、偽の信頼境界が生まれる。

Sequence Numberは別の負債を持ち込む。信頼性を保証しない順序付き配送に使え、受信側は最後に正常開封した値を保持し、古い値を捨て、限られた並べ替え用記憶領域を使うこともできる。順序に敏感なペイロードには役立つ一方、通信の流れごとの状態が増える。攻撃者が大きな番号を注入すれば、その後の正規パケットが古いものに見える可能性がある。

RFC 2890は、この攻撃を防ぐためIPsec AHまたはESPを求める。上位層がすでに順序を保証するか、順序の乱れを許容できるなら、GRE側で重ねて使わないようにも注意する。任意の一ビットを有効にすることは無料機能の追加ではない。両端の記憶、待ち行列、攻撃面、記録、障害時の振る舞いを変える判断だ。

中身が見える場所でフィルタリングする

RFC 2784は、経路の選別は通常のIPv4経路と同様に扱える一方、パケットの選別にはGREの内側を見るか、トンネルの両端で実施する必要があると述べる。基盤ネットワークは二つの外側アドレス間でGREだけを正しく許可しながら、内側のプロトコル、アドレス、ポートを一切知らないことがある。

責任はここで切れやすい。運搬担当は外側の経路を制限したと言い、安全担当は二つのアドレス間でGREだけを許可したと言い、サービス担当は内側の通信も両方の判断を引き継いだと考える。しかし、外側のどちらの事実も、開封後に何を受け入れるかを定めていない。

監査できる設計は、許可する内側のプレフィックスとプロトコル、開封地点、開封前後のどこでどの装置が検査するか、IPsecが配送パケットを認証または暗号化するかを記録する。「GREが稼働中」は安全状態ではない。証拠は、両層で実際に効く方針と、そこを通った実パケットから得る。

IPv6は省略された課題を起動条件に変えた

Carlos Pignataro、Ron Bonica、Suresh KrishnanによるRFC 7676は、IPv6をGREのペイロードまたは配送用プロトコルとして使う方法を後に定めた。Liの著作記録には含まれないが、薄い基本契約が新しいネットワーク層と出会った時、運用責任がどう現れるかを示す。

IPv6を内側に運ぶトンネルは、1280オクテットのIPv6パケットを、内側で断片化せず入口から出口へ運べなければならない。入口は稼働前と、その後も定期的に能力を確認し、結果に応じて有効または無効にする。GREで使えるMTUは、両端間の経路MTUから配送用ヘッダーとGREの追加分を引いた値になる。条件に該当する大きすぎるパケットは破棄し、利用可能な値を示すICMPv6 Packet Too Bigを送信元へ返す必要がある。

小さいヘッダーは、パケット寸法の問題を消していない。追加分を計算可能にし、その確認と通知を両端の責任にしただけだ。Packet Too Bigが途中で失われれば、小さな試験パケットは通るのに大きなアプリケーション通信だけが止まり、制御系は正常に見え続ける。

完全性にも境界がある。GREのチェックサムを省けば、内側の転送層がすでに検査する環境では計算を減らせる。しかしIPv6の配送用ヘッダー自体にはチェックサムがなく、GREのチェックサムを付けても外側は覆わない。RFC 7676は、破損した外側の宛先によって誤ったVPN事業者側装置へ届き、重複する私設アドレスと一致する状態のため、別のVPNへ有効なペイロードが渡るという、可能性は低いが重大な例を分析する。運用者がその危険を受け入れていない場所ではGRE over IPv6を導入すべきでなく、内側の終端間認証が緩和策になり得る。

RFCは、特定のネットワークでこの事故が起きたと主張していない。誰かが稼働前に答えるべき問いを確立している。汎用の運搬能力は、汎用の安全と同義ではない。

共通層が薄いほど、端の証拠は厚くする

Lu Hengの後年の論考Minimum Initial Specification, Localized Future Decision, and Voluntary Adoptionは、Sofia RenがGREを読むための枠組みを与える。共通層は、配置、版、ペイロード種別、任意項目、拒否時の動作に絞れる。その代わり各ネットワークは、なぜトンネルが要るか、誰が運用するか、どの内側通信を認めるか、配送をどう守るか、いつ依存を終えるかを決める自由と義務を持つ。

Running-Code Primacyは、証明の水準を上げる。設定項目は意図にすぎない。実際の証拠は、外側の経路、送出されたGREのフラグ、Protocol Type、実効追加量、任意の文脈、IPsecの関連づけ、内側の経路、フィルター判断、MTU通知、計数値、アプリケーション結果を一本につなぐ。

これらHengの文章は後年の編集上の枠組みであり、Li本人の内心や、引用したRFCを越えるIETFの合意を証明しない。価値は責任配分を明瞭にする点にある。標準は共通の封筒を担い、実装は正しい解析と状態を担い、運用者はその封筒を存在させる全理由を担う。

GREが長く使われたのは、ペイロードを支配しようとしなかったからだ。その節度が可搬性を生んだ。同時に、4オクテットのヘッダー内には、不注意な導入を救う制度が何もないことも意味する。封筒はほとんど何でも運べる。何を運ぶべきかを証明できるのは、両端だけだ。

出典