要約

  • RFC 2407はDOI 1、Situation、ID形式、プロトコル、変換、SA属性、通知に共通の意味を与えた。番号が一致したことは、提案の採用、SAの導入、パケット処理の結果とは別だった。
  • 文書は具体的なセキュリティポリシーをホスト側へ残した。運用証跡には、認証されたID、ローカル規則、応答側選択、カーネル導入、受信側判断、実トラフィックを結ぶ必要があった。

Proposalは選択肢を運ぶ。実行結果は運ばない。ESPというProtocol ID、あるTransform ID、認証方式、鍵長、寿命、カプセル化モードが整然と並んでも、それは応答側が読める候補である。採用後の状態を作るのは別の処理である。

1998年11月のRFC 2407は、ISAKMPをIPsecに使うためのDomain of Interpretationを定めた。ISAKMPが交換と汎用payloadを提供し、IPsec DOIが番号空間と内容の解釈を与えた。DOI番号は1だった。

この分離により、異なる実装が同じ値を同じ意味で読めた。プロトコル、AH/ESP/IPComp変換、SA属性、ID形式、通知、ラベル領域は登録表に置かれた。協力する私的システムのための予約範囲もあった。

ところが、RFCは共通番号をローカル判断へ昇格させなかった。複数のPhase IIプロトコルスイートを同時に提案できたが、どの組合せを一緒に協商するかはホストポリシーの判断だった。登録表は候補を説明し、許可表は別に存在した。

Transform IDも単独では不完全だった。認証アルゴリズム属性など、特定の属性との組合せで初めて定義される方式があり、別の組合せは未定義とされた。寿命は秒またはキロバイトで指定され、鍵長、ラウンド数、グループ、モードも別属性だった。

したがって「ESPが選ばれた」は広すぎる。どの変換と属性か、応答側が何を選んだか、通知で寿命が変わったか、鍵管理が導入に成功したか、selectorが期待する通信を拾ったかを分けなければならない。

Situationは、提案を読む前提を運んだ。SIT_IDENTITY_ONLYは必須で、Phase IにIdentification Payloadが全くなければ中止だった。秘密性または完全性ラベルを主張する場合は、Labeled Domain Identifier、level、categoryが続いた。

その領域番号は、levelとcategoryの名前空間を示すだけだった。RFCのIANA規則では、公開文書なしでも番号を付与できた。番号衝突を防ぐ仕組みであり、ラベルの政策内容や執行責任を承認する制度ではない。

RFC 2407はさらに、IPsec DOIが特定のセキュリティポリシーを課さず、ホストポリシーを範囲外とした。住所とマスクの静的表から、ワイルドカード名、方向、代理firewallを含む規則まで想定したが、共通の決定方式にはしなかった。

Identification PayloadにはIPv4/IPv6、subnet、range、FQDN、user FQDN、ASN.1名、Key IDがあった。これらはポリシー選択の入力になった。証明力は形式ではなく認証との結合に依存した。

証明書で交換を認証する場合、ポリシーに使うIDは証明書に含まれるべきだとされた。payloadの名前と証明書の主体が離れていれば、形式的には両方有効でも判断根拠が切れる。ID_KEY_IDはさらに不透明で、ベンダー固有の事前共有鍵選択に使えた。

通知は応答側の実際の選択を別の情報として示した。RESPONDER-LIFETIMEは採用寿命を、REPLAY-STATUSはanti-replayを有効または無効にした判断を伝えた。送信側がsequence numberを付ける事実だけでは、受信側窓の状態は分からない。

INITIAL-CONTACTは、送信側がこれを最初のSAだと告げるものだった。受信側は再起動を推定し、古いSAを消すことができた。認証された通知は発言者を確かめても、再起動を外部観測したわけではない。状態削除はローカルな危険判断として記録すべきだった。

通知の置き場所も重要だった。Aggressive Modeでは交換への結合が弱いためstatus messageは禁止された。Main Modeの一部は部分保護、Quick Modeは通知全体をhashへ含めた。同じコードでも周囲の証拠が違った。

Lu Hengの最小仕様という視点では、この設計は境界が明快である。共有層は相互運用に必要な名前を定める。将来の選択は、費用と危険を負うローカル主体へ残す。番号を結果と呼び替えた瞬間に、責任の境界が崩れる。

現実の層も分かれる。登録値、payload、認証binding、policy match、proposal selection、SA installation、packet treatment、application outcomeは別々である。running codeを優先するなら、最後に問うのは「何が提案されたか」ではなく「どの規則で何が導入され、どのパケットに働いたか」になる。

RFC 4306は2005年にRFC 2407、2408、2409をIKEv2へ統合して置き換えた。2023年には、広いIKEv2導入、長期のIKEv1更新停止、増幅攻撃などの問題を理由に旧三文書がHistoricとなった。現在の標準はRFC 7296系である。

RFC 2407の価値は古いアルゴリズムではない。共通語彙と実行証拠を混同しない設計にある。提案は選ばれた。それでも、SAが動いた証拠は別に必要だった。

出典