要約

  • RFC 2385 は共有秘密で保護対象の TCP セグメントを検証し、失敗したセグメントを応答せずに破棄することで、BGP セッションへの偽造 RST 注入を難しくした。
  • 18 バイトの形式にはアルゴリズム識別子も鍵識別子もなく、正しいダイジェストが示すのは一つのセグメントとローカル設定の一致までで、鍵の世代、経路の権限、転送結果までは示さない。

小さな RST が消すもの

BGP は順序付きで信頼できるストリームを TCP から得た。同時に、TCP の状態遷移にも依存した。攻撃者が接続の両端とシーケンス番号を推測し、もっともらしい RST を注入できれば、接続は閉じる。ルータは再接続を試み、学習済み経路をいったん撤回することもある。偽造セグメントの大きさと、その影響範囲は釣り合わなかった。

RFC 2385 はその入口に Kind 19 を置いた。オプションは Kind、Length、16 バイトの MD5 ダイジェストで構成される。計算対象は IPv4 疑似ヘッダ、オプションを除きチェックサムをゼロとした TCP ヘッダ、データ、そして両端があらかじめ共有する秘密である。

受信側は同じ計算を行う。値が違えばセグメントを捨て、返答してはならない。ログは勧められたが、送信側が受け取る失敗証明ではない。この沈黙は攻撃者に手掛かりを与えにくい一方、設定不一致の理由もネットワーク上では語らない。

IESG Note は範囲を明記した。これは一部の単純な攻撃に対する既存の実践であり、組織的な攻撃には弱点がある。RFC 2385 は BGP 全体を認証したのではなく、TCP 状態機械へ入れてよいセグメントを狭くした。

「署名」が証明しないこと

ダイジェストが一致すれば、受信したバイト列、疑似ヘッダのアドレス、ローカルに選ばれた秘密が同じ計算結果になったと分かる。そこから運用会社の法的同一性は分からない。AS がプレフィックスを広告する権限も、UPDATE がインポートポリシーを通ったことも、RIB や FIB に入ったことも、パケットが届いたことも分からない。

鍵の名前さえワイヤ上にはない。二つの運用記録が「現在の鍵」について食い違っても、セグメント自身は裁定できない。実装が選んだローカル状態で成功するか、失敗するだけである。

したがって、送信、オプションの存在、鍵選択、ダイジェスト検証、TCP 受理、BGP セッション継続、UPDATE 受理、経路選択、ハードウェア投入、配送は別々の受領証だ。RFC 2385 が閉じるのはその前半だけである。

協議しないという強さと負担

このオプションを使うかどうかは TCP 内で交渉しない。サイトポリシーとアプリケーションが決める。SYN/ACK に署名がなくても、保護を要求する側は自動的に降格しない。未署名の応答を無視し、接続を成立させない。認証されていない相手に防御解除の権限を渡さない設計だった。

しかし、両端は外部で利用要件、秘密、生効時刻を合わせる必要がある。RFC は接続中のパスワード変更を、同期できる場合には認めた。それでも再送セグメントが問題になると警告する。旧秘密で作ったセグメントが、受信側の切替後に着くからだ。KeyID がなければ、そのセグメントがどの世代に属するかを示せない。

検証式は決定的でも、式へ渡す「現在の鍵」は移植可能な共通状態ではなかった。

40 バイトの中で消えた選択肢

TCP ヘッダ全体は最大 60 バイトで、固定部分を除くとオプションは 40 バイトしかない。RFC の SYN 例では、MSS、ウィンドウスケール、タイムスタンプ、MD5、パディングで 40 バイトを使い切る。

MD5 オプションは 18 バイトだった。公開時には MD5 の衝突探索への懸念が知られていたが、すでに運用配備された形式にはアルゴリズム種別がなかった。RFC は理由も記録している。1 バイト追加すると 19 バイトとなり、多くの実装では整列のため 20 バイトになる。狭い予算では実質 2 バイトが重かった。

当時の装置で防御を動かすには合理性があった。将来の代価は、同じ Kind 19 の中で別アルゴリズムを選べないことだった。移行には別のオプションと、新しい互換性契約が必要になった。

Held Errata 4432 は「32-byte words」を「32-bit words」へ直した。RFC 6691 は MSS の扱いを訂正し、受信側がオプション分を公告値から引くのではなく、送信側が実際のオプション分だけデータ長を減らすとした。どちらも 40 バイト制約と、存在しないアルゴリズム欄は変えなかった。

パケット外へ移った鍵の寿命

RFC 3562 は、12～24 バイトの鍵、複数ピアリング間での共有制限、少なくとも 90 日ごとの変更を勧告した。これは Kind 19 が表現しなかった運用作業である。短い秘密は推測されうる。使い回しは漏えいの被害範囲を広げる。時刻のずれた変更は正当なセグメントを偽物と同じように落とす。

RFC 5925 の TCP-AO は TCP MD5 を廃止し、拡張可能なアルゴリズム、KeyID、次に受信する鍵の識別、接続ごとの鍵導出、リプレイ防御を導入した。ただし主鍵の配布は行わず、経路を承認する仕組みにもならない。

BTW の既存記事には TCP-AO の鍵エポックを扱う別稿がある。本稿はそこを重ねない。焦点は、その前の形式が「共有状態に合う」と言えても、どの交換可能な状態なのかを言えなかった点にある。

実装可能性と交換可能性

RFC 2385 は後世の基準に届かなかったから無価値なのではない。1998 年の装置と攻撃面に合わせ、狭い問題へ実装可能な防御を与えた。遠端の無署名な合図で降格しない点も重要だった。

歴史的な教訓は、最小共通仕様に何を残すかである。共通層は小さくあるべきだが、独立した実装が現在の状態を検証し、後継へ移れるだけの情報は必要だ。アルゴリズムと鍵の同一性が完全に設定へ隠れると、今日の成功は証明できても、明日の互換性を運べない。

RFC 2385 はセグメントを守った。欠けた選択欄は、その防御を置き換えるために別のプロトコル面を必要とした。

出典