要約

  • RFC 1701 は四オクテットの Key を送信元認証に使える可能性を示したが、生成、配布、保護、検証の方法を何も定めなかった。
  • RFC 2890 は Key をトンネル内の論理トラフィックフロー識別子と定義し直し、名称に反して安全性には関与しないと明記した。Sequence Number も「不確実だが順序付き」の配送を支えるだけである。
  • 任意の Sequence 値を注入できる相手は受信状態を先へ進め、後続の正規パケットを古いものとして捨てさせられる。K/S を信頼するには、GRE ヘッダーとペイロードを覆う独立した完全性保護が要る。

仕様が埋められなかった「鍵穴」

1994年の RFC 1701 は、あるネットワーク層プロトコルを別のネットワーク層で運ぶ汎用形式として GRE を記述した。配送用ヘッダーの内側に GRE ヘッダーがあり、その先にペイロードがある。GRE には Checksum、Routing、Key、Sequence Number を任意で置けた。

問題は Key の説明にある。受信側がパケットの送信元を認証するために利用できる、としながら、真正性を判断する技術は仕様外とされた。どこから値を得るのか、どの対向点へ結び付けるのか、複製や改変をどう見つけるのか、いつ失効するのかがない。四オクテットが一致しても、それを資格として扱う共通手順は成立しない。

Sequence Number も、送信順の確認に利用できるとだけ書かれ、採番と受信時の意味は外へ残された。場所は予約されたが、二つの実装が同じ判断をする状態機械はまだなかった。

最初に合意されたのは、より小さい GRE だった

2000年3月の RFC 2784 は、複数ベンダーで実際に展開されていた GRE の共通部分を Proposed Standard とした。基本ヘッダーには Checksum-present、Version、Protocol Type が残った。Protocol Type は内側のプロトコルを識別するが、パケットをトンネルへ入れる権限までは与えない。

旧形式の第1～5ビットは、意味を推測する場所ではなく互換境界になった。RFC 1701 を実装していない受信側は、そこが非ゼロのパケットを破棄する。基本仕様だけの送信側はゼロにする。新旧の相互運用は別節で明示された。

ここには最小共通仕様の規律がある。既存の名前や装置の評判ではなく、受信コードが理解すると宣言したビットだけが実行可能な意味を持つ。

Key は権限を失って識別子になった

同年9月の RFC 2890 は、RFC 2784 を更新して K と S を復活させた。K が立てば四オクテットの Key、S が立てば四オクテットの Sequence Number が続く。ビット位置は RFC 1701 と互換だが、用途は具体化された。

Key はカプセル化側が挿入する。その取得方法は依然として仕様外である。受信側は、内側データだけでは欠けている文脈を補い、一本のトンネルに含まれる個別の論理トラフィックフローを見分ける。同じフローには同じ値を使う。

つまり Key は、特定の外側エンドポイントとローカル設定の中でだけ意味を持つ。世界共通の所有者名でも、資格証明でもない。値を知る者が、そのフローを選ぶ正当性まで持つとは限らない。

RFC 2890 の Security Considerations は曖昧さを残さない。名称に反して、Key フィールドはいかなる安全性にも関与しない。名称を変更せず、主張できる範囲を変更したのである。

Sequence が保証するのは、届いたものの扱い方

S があると、送信側は0から始まる32ビットのカウンターを使い、2^32で周回する。受信側は最後に正常にデカプセル化した番号を保持する。K もある場合、この履歴は Key ごとのフローに属する。

直後の値なら順序内である。十分に古い値や重複は順序外として静かに捨てる。先へ飛んだ値は欠落を示すので、受信側は小さなフロー別バッファーで遅着を待てる。待ち時間または容量の限界に達すれば、欠番を飛ばして先へ進める。

ここでいう配送は「unreliable but in-order」である。Sequence は失われたペイロードを再送しない。欠番を永遠に待つこともしない。上位層が順序を必要とする場面で、有限の待機と破棄を選べるだけだ。

また、S のないパケットは S 付きと混在できる。複数 Key なら履歴も複数である。したがって、一つの Sequence はトンネル全体の時計ではない。

認証されていない未来は、現在を古くできる

受信側が最後に40を受け入れたとする。攻撃者が同じ Key と大きく先の番号を持つパケットを送り込み、それが先に処理されれば、受信側の記憶が偽の未来へ進む。その後の正規パケットは古いと判定され、順序規則そのものによって破棄される。

RFC 2890 は、任意の Sequence を注入する DoS を明記し、GRE ヘッダーとトンネル化されたペイロードを別の IP セキュリティ機構で保護するよう求めた。重要なのは、受信状態を動かす K/S まで完全性の対象に入ることである。

このため Sequence は、それ単体ではリプレイ防止にならない。先にパケットの来歴が認証されて初めて、番号窓は受け入れ済み履歴として意味を持つ。認証がなければ、攻撃者が判定基準を書き換えられる。

暗号化も別の性質である。Key はペイロードを隠さず、Sequence も通信量の特徴を消さない。完全性だけか、機密性も必要かは外側の保護方式と運用方針が決める。

ECN の更新は別の責任を追加した

2024年の RFC 9601 は、RFC 2784 に対するもう一つの更新である。IP ヘッダー間の shim として GRE を使う場合に ECN をどう伝播し、IPv4/IPv6 外側ヘッダーの入口をどう安全に設定するかを扱う。

これは Key や Sequence を強化する文書ではない。ECN は輻輳情報、Key はフロー文脈、Sequence は局所的な順序、保護層は送信元と完全性を扱う。責任は同じトンネルに共存しても、互いに代用できない。

RFC 9601 は GRE 自体に動的なトンネル設定機構がないことも述べる。静的設定や別の制御プロトコルが関係を作る。キャプチャーに K/S が見えても、その値を割り当てた合意や対向点の権限までは見えない。

実運用では三つの台帳を分ける

調査すべきなのは「Key が合ったか」だけではない。外側エンドポイントと Key の名前空間、ローカルなフローマッピング、S の必要性、直前に受け入れた値、欠番・周回・再起動の扱い、そして GRE ヘッダーを覆う認証保護を別々に確認する必要がある。

順序外破棄の増加も、原因を一つには絞れない。再順序化、重複、バッファー不足、状態リセット、設定不一致、注入のどれでも起こる。カウンターは受信側が下した判断の証拠であって、原因の証明ではない。

GRE の歴史が残した教訓は、強そうな名前に権限を足さないことだ。Key は文脈を選び、Sequence は受信順を管理する。安全性は、その二つを含むパケット全体について検証可能な別の仕組みが担う。

出典