要約
- RFC 3554 は SCTP のマルチホーム・アドレス集合を IPsec のセレクタとして扱う。Phase 1 で有効なピアでも、列挙した各アドレスで受信する権限を別に検証しなければならない。
- 最終集合は IKE の訂正履歴、SPD への投入、すべての宛先から同一 SA を引く SAD、実際の SCTP 経路まで一貫して初めて運用上の完了となる。
一つのアソシエーションという抽象は簡潔だが、ネットワークでは複数のルーティング可能な主張になる。アドレスが同じサブネットに収まらなければ、単純な範囲では表せない。全組合せに SPD エントリを作れば明示的だが、数は急増する。
2003 年 7 月に Proposed Standard として公表された RFC 3554 は、集合を一つのセレクタとして表す方法を示した。SAD では、合意したどの宛先アドレスを用いても、同じ SPI とセキュリティプロトコルなら同一の SA に到達すべきだとする。
認証は主体を示し、アドレス権限は範囲を示す
IKE Phase 1 の成功は相手のアイデンティティを支える。しかし RFC 3554 は、それだけでは不十分だと明記する。応答側には、開始側が列挙したすべてのアドレスでトラフィックを受け取る権限を持つという証拠が必要である。
その根拠は Phase 1 の証明書や ID、あるいは帯域外ポリシーから得られる。複数の subject alternative name を持つ一枚の証明書や、同じ公開鍵を共有する複数証明書も使える。だが、方式が何であれ各メンバーの適用範囲を判断する工程は残る。
有効なピアであることだけを許可条件にすると、そのピアが別のピアのアドレスを名乗れる。SA は正しく、パケットは暗号化済みでも、宛先の決定は誤っている。暗号ログから後で権限を推測することはできない。
したがって「ピア認証済み」と「アドレス集合承認済み」を別イベントにする。後者には集合バージョン、各アドレスの根拠、判断者、有効期限、拒否理由を含める。
応答側による再提案は知識の修復である
最初の Quick Mode を始める側が、応答側の全アドレスを知っているとは限らない。RFC 3554 は、不正確または不足したセレクタを応答側が見つけたとき、役割を反転して新しい Quick Mode を開始し、自分側の集合を訂正する手順を求める。
これは同じ要求の再送ではない。データをよりよく知る当事者が提案者になる。実装は元の SA とセレクタの文脈を引き継ぎつつ差分を出す。
監査記録が最後の成功だけを残すと、初回の不足も訂正理由も消える。元提案、診断、差分、メンバー別検証、最終承認を一つの系列として保持する必要がある。
ID_LIST は複数の Identification Payload を一つの集合として運び、入れ子を禁止する。構文を単純にしても、所有権や完全性までは証明しない。
合意した集合を実装で分裂させない
最終セレクタが SPD に入ったという記録と、各宛先で同一 SA を検索できたという SAD の記録は別である。さらに SCTP が実際に選んだ経路も別に観測する。
IKE には全メンバーがあるのに SPD が一つ欠ける、主アドレスでは検索できるのに予備では失敗する、古い優先規則が残って別ポリシーを選ぶ、といった分裂はハンドシェイク成功と共存できる。
集合ハッシュと版、SPD エントリ、全宛先の SAD 検索結果を保存し、計画的なフェイルオーバーを行う。集合外アドレスが拒否される負の試験も必要だ。平常時に眠る経路ほど、本番の障害時に初めて試すべきではない。
アドレス変更は新しい承認判断である
当時の基礎 SCTP は稼働中の集合変更を持たなかったが、RFC 3554 は将来の変更とリダイレクト攻撃を想定した。攻撃者が自分のアドレスを既存関係に加えれば、後続トラフィックを受け取れる可能性がある。
後の RFC 5061 は Dynamic Address Reconfiguration と認証付き制御チャンクを定めた。これは隣接する仕様であり、特定実装の存在や安全性を示さない。認証付き追加要求も、誰が要求したかを示すだけで、そのアドレスを所有する証明ではない。
追加・削除のたびに集合を版上げし、メンバー権限を再判定し、SCTP と IPsec の状態を同期し、旧版の廃止を確認する。「更新受理」は移行完了の受領証ではない。
復元可能な証拠列
Phase 1 について証明書チェーン、ID、鍵、ポリシー、検証時刻を保存する。各アドレスには権限根拠と判断を付ける。SCTP アソシエーションにはローカル・リモート集合と版を付ける。
Phase 2 は初期提案、ID_LIST、ポート、プロトコル、SPI、変換方式と提案者を保存する。役割反転は元取引に結び付ける。SPD/SAD の投入結果、パケットが使った経路と SA、意図した相手の復号結果を後段の受領証にする。
RFC 2960 と RFC 4960 は SCTP の時代境界、RFC 2401・2409・2407 は当時の IPsec/IKE、RFC 4301 は後続の構造を示す。いずれも実装率や事故を証明しない。
証拠の限界
本稿は事業者、製品、証明書、アドレス、SA、攻撃、被害者を特定せず、導入率、観測攻撃、実測負荷を主張しない。例は仕様上の可能性と統治上の推論である。
Heng Lu の Running-Code Primacy と Minimum Initial Specification は、仕様、導入、観測結果を分けるための明示した編集視点であり、RFC 著者の意図やネットワーク事実の証拠ではない。
結論は限定できる。IKE が本物のピアを認証しても、各アドレスの権限までは自動的に証明しない。集合の各メンバーを許可し、全層に同じ版を投影し、経路で観測して初めて完了する。
Sources
- https://www.rfc-editor.org/rfc/rfc3554.html
- https://www.rfc-editor.org/info/rfc3554
- https://datatracker.ietf.org/doc/rfc3554/
- https://www.rfc-editor.org/rfc/rfc2960.html
- https://www.rfc-editor.org/rfc/rfc4960.html
- https://www.rfc-editor.org/rfc/rfc5061.html
- https://www.rfc-editor.org/rfc/rfc2401.html
- https://www.rfc-editor.org/rfc/rfc4301.html
- https://www.rfc-editor.org/rfc/rfc2409.html
- https://www.rfc-editor.org/rfc/rfc2407.html
- https://www.rfc-editor.org/rfc/rfc8174.html
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
