3.4. 受信パケット処理

本節では、受信した ESP パケットの処理を説明する。

3.4.1. 再構成

必要な場合、再構成は ESP 処理の前に行う。ESP 処理に渡されたパケットが IP フラグメントと思われる、すなわち OFFSET フィールドがゼロでないか MORE FRAGMENTS フラグが設定されている場合、受信者はそのパケットを MUST 破棄する。これは監査可能なイベントである。このイベントの監査ログ項目には、SPI 値、受信日時、送信元アドレス、宛先アドレス、シーケンス番号、および IPv6 ではフロー ID を含めることが SHOULD である。

注: パケット再構成について、現行の IPv4 仕様は OFFSET フィールドをゼロにすることも MORE FRAGMENTS フラグをクリアすることも要求していない。再構成済みパケットを見かけ上のフラグメントとして破棄せず IPsec で処理するためには、IP コードがパケット再構成後にこの二つを行わなければならない。

3.4.2. セキュリティアソシエーションの検索

ESP ヘッダを含むパケットを受信すると、受信者は SAD 内の検索により適切な（単方向の）SA を決定する。ユニキャスト SA では、2.1 節で説明するように、この決定は SPI、または SPI とプロトコルフィールドに基づく。実装がマルチキャストトラフィックをサポートする場合、2.1 節で説明するように、検索には SPI に加えて宛先アドレスも使用し、送信者アドレスも使用してよい。（この処理は Security Architecture 文書でより詳しく説明されている。）SA の SAD エントリは、シーケンス番号フィールドを検査するかどうか、SA で 32 ビットまたは 64 ビットのシーケンス番号を使用するかどうか、（明示的な）ICV フィールドが存在すべきかどうか、および存在する場合のサイズも示す。さらに SAD エントリは、復号および該当する場合の ICV 計算に使用するアルゴリズムと鍵を指定する。

このパケットに有効な Security Association が存在しない場合、受信者はそのパケットを MUST 破棄する。これは監査可能なイベントである。このイベントの監査ログ項目には、SPI 値、受信日時、送信元アドレス、宛先アドレス、シーケンス番号、および IPv6 では平文のフロー ID を含めることが SHOULD である。

（IKE パケットなどの SA 管理トラフィックは SPI に基づいて処理する必要はない。たとえば Next Protocol フィールドおよび Port フィールドに基づき、このトラフィックを別個に多重分離できることに留意する。）

3.4.3. シーケンス番号の検証

すべての ESP 実装はアンチリプレイサービスを MUST サポートする。ただし、その使用は受信者が SA ごとに有効化または無効化してよい。このサービスは、その SA に対して ESP 完全性サービスも有効になっている場合を除き、MUST 有効化してはならない。そうでなければシーケンス番号フィールドが完全性保護されないためである。アンチリプレイはユニキャスト SA とマルチキャスト SA の双方に適用される。しかし本標準は、複数送信者 SA（ユニキャストまたはマルチキャスト）にアンチリプレイを提供する機構を規定しない。このような SA についてアンチリプレイ機構のネゴシエーション（または手動設定）がない場合、下記のとおり、送信者と受信者による SA のシーケンス番号検査をネゴシエーションまたは手動設定で無効化することが推奨される。

受信者が SA に対してアンチリプレイを有効化しない場合、シーケンス番号に対する受信側検査は行わない。しかし送信者側では、既定として受信者がアンチリプレイを有効化していると仮定する。送信者が不要なシーケンス番号監視と SA 設定（3.3.3 節を参照）を行わないよう、SA 確立プロトコルを使用する場合、受信者がアンチリプレイ保護を提供しないなら、受信者は SA 確立中に送信者へ通知することが SHOULD である。

受信者がこの SA に対してアンチリプレイサービスを有効化している場合、SA 確立時にこの SA の受信パケットカウンタをゼロに MUST 初期化する。受信パケットごとに、受信者は、そのパケットのシーケンス番号が当該 SA の存続期間中に受信した他のパケットのシーケンス番号と重複しないことを MUST 検証する。重複パケットの拒否を迅速にするため、これはパケットが SA と照合された後に適用する最初の ESP 検査であることが SHOULD である。

ESP はパケットシーケンス番号の二段階検証を許す。この機能は、ESP 実装（通常はその暗号モジュール部分）が、保護されていないネットワークへのインターフェースと同じ速度で復号および／または完全性検査を実行できない場合に重要である。実装がこのような「回線速度」の処理を実行できる場合、以下に説明する予備検証段階を実行する必要はない。

予備シーケンス番号検査は ESP ヘッダ内のシーケンス番号値を用いて実施し、完全性検査および復号の前に行う。この予備検査が失敗した場合、パケットを破棄するため、受信者による暗号処理を不要にできる。予備検査が成功しても、この時点ではシーケンス番号の完全性が検証されていないため、受信者はまだローカルカウンタを変更できない。

重複はスライディング受信ウィンドウを使用して拒否する。ウィンドウの実装方法はローカルな事項であるが、以下の本文は実装が示さなければならない機能を説明する。

ウィンドウの「右」端は、この SA で受信して検証済みの最大シーケンス番号値を表す。シーケンス番号がウィンドウの「左」端より小さいパケットは拒否する。ウィンドウ内に入るパケットは、ウィンドウ内で受信済みのパケット一覧と照合する。SA に ESN オプションを選択した場合、シーケンス番号の下位 32 ビットだけを明示的に送信するが、受信者は受信シーケンス番号を受信ウィンドウと照合する際、示された SA の上位 32 ビット（ローカルカウンタから得る）を用いて計算した完全なシーケンス番号を使用する。完全なシーケンス番号を構成する際、パケットに格納された下位 32 ビットが受信者のシーケンス番号の下位 32 ビットより小さい場合、受信者は上位 32 ビットが増加して新たなシーケンス番号部分空間に移ったとみなす。（このアルゴリズムは、単一 SA について最大 2**32-1 パケットの受信欠落を許容する。より大きな欠落が発生した場合、付録で説明するとおり、受信者シーケンス番号カウンタを再同期するための追加のヒューリスティック検査を MAY 使用してよい。）

受信パケットがウィンドウ内にあり重複でない場合、またはパケットがウィンドウの右側にある場合で、別個の完全性アルゴリズムを使用しているなら、受信者は完全性検証へ進む。結合モードアルゴリズムを使用する場合、完全性検査は復号とともに行う。いずれの場合も、完全性検査が失敗した場合、受信者は受信 IP データグラムを無効として MUST 破棄する。これは監査可能なイベントである。このイベントの監査ログ項目には、SPI 値、受信日時、送信元アドレス、宛先アドレス、シーケンス番号、および IPv6 ではフロー ID を含めることが SHOULD である。受信ウィンドウは完全性検証が成功した場合にのみ更新する。（結合モードアルゴリズムを使用する場合、完全性保護されたシーケンス番号もアンチリプレイ保護に使用したシーケンス番号と一致しなければならない。）

32 ビットのシーケンス番号を使用する場合、最小ウィンドウサイズ 32 パケットを MUST サポートする。ウィンドウサイズ 64 が望ましく、既定値として使用することが SHOULD である。受信者は最小値より大きい別のウィンドウサイズを選んでも MAY よい。（受信者はウィンドウサイズを送信者へ通知しない。）保証上の問題にかかわらず、高速な環境では受信ウィンドウサイズを増加させるべきである。非常に高速な（例: 毎秒数ギガビットの）装置に対する最小および推奨受信ウィンドウサイズの値は、本標準では規定しない。

3.4.4. 完全性検査値の検証

送信処理と同様、使用するアルゴリズムの特性に基づき、受信処理には複数の選択肢がある。

3.4.4.1. 機密性アルゴリズムと完全性アルゴリズムを分離する場合

機密性アルゴリズムと完全性アルゴリズムを別個に使用する場合、処理は次のように進む。

完全性を選択した場合、受信者は指定された完全性アルゴリズムを用い、ICV を除く ESP パケットに対して ICV を計算し、それがパケットに格納された ICV と同一であることを検証する。計算の詳細は以下に示す。

計算した ICV と受信した ICV が一致すれば、データグラムは有効であり受け入れる。検査が失敗した場合、受信者は受信 IP データグラムを無効として MUST 破棄する。これは監査可能なイベントである。ログデータには、SPI 値、受信日時、送信元アドレス、宛先アドレス、シーケンス番号、および IPv6 では平文のフロー ID を含めることが SHOULD である。

実装上の注意:

実装は、以下の手順と同じ結果になる任意の手順群を使用できる。まず ICV フィールドを取り除いて保存する。次に ICV フィールドを除いた ESP パケット全体の長さを検査する。完全性アルゴリズムのブロックサイズに基づいて暗黙のパディングが必要なら、Next Header フィールドの直後、または ESN を選択した場合はシーケンス番号の上位 32 ビットの直後の ESP パケット末尾に、ゼロで埋めたバイトを追加する。ICV を計算し、アルゴリズム仕様で定義された比較規則を用いて結果を保存した値と比較する。
受信者は、SA が示す鍵、暗号化アルゴリズム、アルゴリズムモード、および暗号同期データ（存在する場合）を使用して、ESP Payload Data、Padding、Pad Length、Next Header を復号する。3.3.2 節と同様、フォーマット上の意味合いから、ここでは暗号化が常に適用されるものとして述べる。これは NULL 暗号化アルゴリズム（RFC 2410）を使用して「機密性なし」を提供できることを理解した上での表現である。
- IV などの明示的な暗号同期データが示されている場合、Payload フィールドから取得し、アルゴリズム仕様に従って復号アルゴリズムへ入力する。
- 暗黙の暗号同期データが示されている場合、IV のローカル版を構成し、アルゴリズム仕様に従って復号アルゴリズムへ入力する。
受信者は、暗号化アルゴリズム仕様で規定された方法で Padding を処理する。既定のパディング方式（2.4 節を参照）を使用した場合、復号したデータを次の層へ渡す前にパディングを削除するが、その前に受信者は Padding フィールドを検査することが SHOULD である。
受信者は Next Header フィールドを検査する。値が「59」（次のヘッダなし）の場合、（ダミー）パケットは追加処理をせずに破棄する。
受信者は、次のものから元の IP データグラムを再構成する。
- トランスポートモード: 外側 IP ヘッダと ESP Payload フィールド内の元の次層プロトコル情報
- トンネルモード: ESP Payload フィールド内の IP データグラム全体
元のデータグラムを再構成する正確な手順はモード（トランスポートまたはトンネル）に依存し、Security Architecture 文書に記載されている。少なくとも IPv6 の文脈では、受信者は、Next Header フィールドで識別されたプロトコルの処理を容易にするため、復号データが 8 バイト境界に揃っていることを確認することが SHOULD である。この処理により、トラフィックフロー機密性のため追加された（任意の）TFC パディングを「破棄」する。（存在する場合、これは IP データグラム（またはトランスポート層フレーム）の後、Padding フィールドの前に挿入されている。2.4 節を参照。）

完全性検査と暗号化を並列に行う場合、復号済みパケットを以降の処理へ渡す前に完全性検査を MUST 完了する。この処理順序により、受信者はパケットを復号する前にリプレイされたパケットまたは偽造パケットを迅速に検出・拒否でき、サービス拒否攻撃の影響を低減できる可能性がある。

注: 受信者が完全性検査と並列に復号を行う場合、パケットへのアクセスおよび復号済みパケットの抽出に関する競合状態の可能性を避けるよう注意しなければならない。

3.4.4.2. 機密性アルゴリズムと完全性アルゴリズムを結合する場合

機密性と完全性を結合したアルゴリズムを使用する場合、受信者は次のように処理する。

SA が示す鍵、アルゴリズム、アルゴリズムモード、および暗号同期データ（存在する場合）を使用して、ESP Payload Data、Padding、Pad Length、Next Header を復号および完全性検査する。ESP ヘッダの SPI と、（受信者の）パケットカウンタ値（3.4.3 節で説明した処理により必要に応じて調整する）は、完全性検査に必要なため、このアルゴリズムへの入力となる。
- IV などの明示的な暗号同期データが示されている場合、Payload フィールドから取得し、アルゴリズム仕様に従って復号アルゴリズムへ入力する。
- IV などの暗黙の暗号同期データが示されている場合、IV のローカル版を構成し、アルゴリズム仕様に従って復号アルゴリズムへ入力する。
結合モードアルゴリズムによる完全性検査が失敗した場合、受信者は受信 IP データグラムを無効として MUST 破棄する。これは監査可能なイベントである。ログデータには、SPI 値、受信日時、送信元アドレス、宛先アドレス、シーケンス番号、および IPv6 では平文のフロー ID を含めることが SHOULD である。
アルゴリズムがまだ処理していない場合、暗号化アルゴリズム仕様に規定された方法で Padding を処理する。
受信者は Next Header フィールドを検査する。値が「59」（次のヘッダなし）の場合、（ダミー）パケットは追加処理をせずに破棄する。
ESP Payload Data フィールドから、元の IP データグラム（トンネルモード）またはトランスポート層フレーム（トランスポートモード）を取り出す。これにより、トラフィックフロー機密性のために追加された（任意の）パディングを暗黙に破棄する。（存在する場合、TFC パディングは IP ペイロードの後、Padding フィールドの前に挿入されている。2.4 節を参照。）