要約

  • RFC 2401 は、順序を持つセキュリティポリシーデータベースと、稼働中のセキュリティ関連を保持するデータベースを区別した。前者は破棄、IPsec迂回、IPsec適用を決め、後者は一方向の関連に必要な状態を持った。
  • 規則も関連も、個々のパケットの処理証明ではない。送信側は指定されたAHまたはESPを実行し、受信側は暗号処理に加えて、使われた関連とその順序が適用可能なポリシーに合うことを確認する必要があった。

RFC 2401 の設計には、方向の違う二つの関門がある。外へ出るパケットは、まずポリシーから処遇を割り当てられる。内へ入るIPsecパケットは、関連を使った処理を受けた後、もう一度ポリシーとの整合性を問われる。入口と出口の間には関連状態があるが、それだけで関門を通過したことにはならない。

1998年11月に公開されたこの文書は、IPv4とIPv6のためのセキュリティアーキテクチャをまとめた。対象はIP層のアクセス制御、コネクションレス完全性、データ起源認証、リプレイ防止、機密性、限定的なトラフィックフロー秘匿である。ただし、これらが常に一括して提供されるとは述べていない。AH、ESP、トランスポート／トンネルモード、アルゴリズム、鍵管理の組み合わせによって主張できる内容は変わる。

最初の関門を構成するのがSecurity Policy Database、SPDだった。IPsecを使わない通信も含め、すべての入出力IPトラフィックに処遇を与える。各項目はアドレスや上位層のフィールドをセレクターとして持ち、全順序で並ぶ。一致した項目は、破棄、IPsecを使わない迂回、またはIPsec保護の適用を選ぶ。保護の場合は、プロトコルまたはバンドル、モード、アルゴリズム、入れ子の条件も示す。

この順序は表示上の都合ではない。広い規則が狭い規則より前にあれば、狭い規則へ到達する前に処遇が決まる。方向も証拠の一部である。送信側で保護を選ぶ手続きと、受信側で適合を確かめる手続きは鏡像ではない。規則の文面だけでなく、版、投入先、方向、セレクター、実際に一致した順位が必要になる。

中間の状態を保持するのがSecurity Association Database、SADである。セキュリティ関連は一方向だけに働くsimplexな論理接続で、通常の双方向保護には二つ必要だった。関連はSecurity Parameters Index、宛先IPアドレス、AHかESPかというプロトコル識別子で特定される。項目には、シーケンスとリプレイ防止状態、アルゴリズムと鍵、有効期間、モード、経路MTU状態などが入る。

しかし、項目の存在は使用の証明ではない。特定のパケットがその関連を選んだとも、相手へ届いたとも、アプリケーションが受理したともいえない。先行するRFC 2367はPF_KEYによって鍵と関連の管理面を公開した。RFC 2401は、その状態をポリシーからパケット処理へ続く、より長い契約の中に置いた。

送信時、実装はパケットをSPDと照合する。破棄ならそこで終わる。迂回ならIPsecを使わず通常の送信へ進む。保護なら、適切な既存の関連を選ぶか、必要な関連またはバンドルの作成を始める。その後で初めて、指定順序のAHまたはESP処理が行われ、転送または送信へ進む。保存された意図と稼働中の状態は、どちらも変換より手前にある。

受信時には第二の関門が現れる。宛先アドレス、セキュリティプロトコル、SPIで関連を検索し、AHまたはESP固有の処理を行う。完全性と起源の検証、リプレイ処理、該当する場合の復号が成功しても、認可判断は終わらない。

IPsecヘッダー処理後のパケットを受信SPDと照合し、実際に使った関連とその順序がポリシー要求を満たすかを確認する。候補が一致しなければ、ほかの適用可能な項目も検討する。成功して初めてトランスポート層へ渡すか転送できる。関連の下で暗号学的に妥当であることと、ポリシー上許されることは別の受領証だった。

AHとESPも同じ主張をしない。1998年版AHは完全性とデータ起源認証、任意のリプレイ防止を提供するが、機密性は提供しない。ESPは機密性を提供でき、認証と完全性を任意に加えられるが、保護範囲はAHと異なる。「IPsecで暗号化した」という一文では、認証だけの経路も、明示的な迂回も説明できない。

RFC 2401自身も、実装品質、OSの安全性、乱数源、管理実務に全体の安全性が左右されると認めた。RFC 3168は後にECN処理を更新し、RFC 4301は2005年にこの文書を置き換え、ポリシーモデル、セレクター、断片、相手認可などを改めた。したがって、1998年の必須アルゴリズムを現在の運用助言として読むことはできない。

歴史的に残るのは、ポリシー意図、導入済み状態、パケット上の実行を別の現実層に置いた点である。Lu Hengの稼働コード、局所検証、現実層に関する議論は、この分離を読む後世の分析枠であり、RFC自身の言葉ではない。その枠から見える証拠列は、出典と版、規則の投入、順序付き一致、要求保護、現行関連、実処理、受信側ポリシー照合、ネットワーク／トランスポート境界への受け渡し、相手の受信、アプリケーション処理、サービス結果である。前段は後段の代わりにならない。

出典