3.3. Outbound Packet Processing (送信パケット処理)

トランスポートモードでは, 送信者は次の層のプロトコル情報を ESP ヘッダーと ESP トレーラーフィールドの間にカプセル化し, 指定された IP ヘッダー (および IPv6 コンテキストでの IP 拡張ヘッダー) を保持します。トンネルモードでは, 外部と内部の IP ヘッダー/拡張はさまざまな方法で相互に関連付けることができます。カプセル化プロセス中の外部 IP ヘッダー/拡張の構築については, セキュリティアーキテクチャ文書で説明されています。

3.3.1. Security Association Lookup (セキュリティアソシエーション検索)

ESP は, IPsec 実装がパケットが ESP 処理を必要とする SA に関連付けられていると判断した後でのみ, 送信パケットに適用されます。送信トラフィックにどの IPsec 処理が適用されるか (もしあれば) を決定するプロセスは, セキュリティアーキテクチャ文書で説明されています。

3.3.2. Packet Encryption and Integrity Check Value (ICV) Calculation (パケット暗号化と ICV 計算)

このセクションでは, フォーマットへの影響のため, 常に暗号化が適用されるという観点で説明します。これは, NULL 暗号化アルゴリズム (RFC 2410) を使用することによって「機密性なし」が提供されることを理解した上で行われます。いくつかのアルゴリズムオプションがあります。

3.3.2.1. Separate Confidentiality and Integrity Algorithms (独立した機密性と完全性アルゴリズム)

独立した機密性と完全性アルゴリズムが使用される場合, 送信者は次のように進めます:

(ESP Payload フィールドに) カプセル化する:
- トランスポートモードの場合 -- 元の次の層のプロトコル情報のみ。
- トンネルモードの場合 -- 元の IP データグラム全体。
必要なパディングを追加する -- オプションの TFC パディングと (暗号化) パディング
SA に指定されたキー, 暗号化アルゴリズム, アルゴリズムモード, および必要な暗号同期データを使用して結果を暗号化します。
- 明示的な暗号同期データ (例えば IV) が示されている場合, アルゴリズム仕様に従って暗号化アルゴリズムに入力され, Payload フィールドに配置されます。
- 暗黙的な暗号同期データが使用される場合, アルゴリズム仕様に従って構築され, 暗号化アルゴリズムに入力されます。
- 完全性が選択されている場合, 完全性アルゴリズムが適用される前に暗号化が最初に実行され, 暗号化は ICV フィールドを含みません。この処理順序により, 受信者はパケットを復号化する前に, 再生または偽のパケットを迅速に検出して拒否することができ, それにより拒否サービス (DoS) 攻撃の影響を潜在的に減らすことができます。また, 受信者でのパケットの並列処理の可能性も可能にします, つまり復号化は完全性チェックと並行して行うことができます。ICV は暗号化によって保護されていないため, ICV を計算するためには鍵付き完全性アルゴリズムを使用しなければならないことに注意してください。
ESP パケットから ICV フィールドを除いたものに対して ICV を計算します。したがって, ICV 計算には SPI, シーケンス番号, ペイロードデータ, パディング (存在する場合), パディング長, および次のヘッダーが含まれます。(暗号化が最初に実行されるため, 最後の 4 つのフィールドは暗号文の形式になることに注意してください。) SA に対して ESN オプションが有効になっている場合, この計算の目的でシーケンス番号の上位 32 ビットが次のヘッダーフィールドの後に追加されますが, 送信されません。

一部の完全性アルゴリズムでは, ICV 計算が実行されるバイト文字列は, アルゴリズムによって指定されたブロックサイズの倍数でなければなりません。ESP パケットの長さ (上記のように) がアルゴリズムのブロックサイズ要件と一致しない場合, ESP パケットの末尾に暗黙的なパディングを追加しなければなりません。(ESN が選択されている場合, このパディングは次のヘッダーフィールドの後, またはシーケンス番号の上位 32 ビットの後に追加されます。) ブロックサイズ (したがってパディングの長さ) は, 完全性アルゴリズム仕様によって指定されます。このパディングはパケットとともに送信されません。完全性アルゴリズムを定義するドキュメントを参照して, 上記のように暗黙的なパディングが必要かどうかを判断しなければなりません。ドキュメントがこの質問に対する答えを指定していない場合, デフォルトでは暗黙的なパディングが必要であると仮定します (パケット長をアルゴリズムのブロックサイズに一致させるために必要に応じて。) パディングバイトが必要であるがアルゴリズムがパディング内容を指定していない場合, パディングオクテットはゼロの値を持たなければなりません。

3.3.2.2. Combined Confidentiality and Integrity Algorithms (組み合わせられた機密性と完全性アルゴリズム)

組み合わせられた機密性/完全性アルゴリズムが使用される場合, 送信者は次のように進めます:

ESP Payload Data フィールドにカプセル化する:
- トランスポートモードの場合 -- 元の次の層のプロトコル情報のみ。
- トンネルモードの場合 -- 元の IP データグラム全体。
必要なパディングを追加する -- オプションの TFC パディングと (暗号化) パディングを含みます。
SA に指定されたキーと複合モードアルゴリズム, および必要な暗号同期データを使用して, 結果を暗号化し完全性保護します。
- 明示的な暗号同期データ (例えば IV) が示されている場合, アルゴリズム仕様に従って複合モードアルゴリズムに入力され, Payload フィールドに配置されます。
- 暗黙的な暗号同期データが使用される場合, アルゴリズム仕様に従って構築され, 暗号化アルゴリズムに入力されます。
- シーケンス番号 (または適切な場合は拡張シーケンス番号) と SPI はアルゴリズムへの入力です, それらは完全性チェック計算に含まれなければならないためです。これらの値がこの計算に含まれる方法は, 使用される複合モードアルゴリズムの関数であり, したがってこの標準では指定されていません。
- 複合モードアルゴリズムが使用される場合, (明示的な) ICV フィールドは ESP パケット形式の一部でもよい (MAY) です。使用されない場合, 通常は類似のフィールドが暗号文ペイロードの一部になります。完全性フィールドの場所, およびシーケンス番号と SPI が完全性計算に含まれる方法は, 複合モードアルゴリズムを ESP で使用することを定義する RFC で定義されなければなりません。

3.3.3. Sequence Number Generation (シーケンス番号生成)

SA が確立されると, 送信者のカウンタは 0 に初期化されます。送信者はこの SA のシーケンス番号 (または ESN) カウンタをインクリメントし, 値の下位 32 ビットをシーケンス番号フィールドに挿入します。したがって, 特定の SA を使用して送信される最初のパケットには, シーケンス番号 1 が含まれます。

アンチリプレイが有効になっている場合 (デフォルト), 送信者はシーケンス番号フィールドに新しい値を挿入する前に, カウンタがサイクルしていないことを確認します。言い換えれば, そうすることでシーケンス番号がサイクルする場合, 送信者は SA 上でパケットを送信してはなりません。シーケンス番号のオーバーフローを引き起こすパケットを送信しようとする試みは, 監査可能なイベントです。このイベントの監査ログエントリには, SPI 値, 現在の日付/時刻, 送信元アドレス, 宛先アドレス, および (IPv6 の場合) クリアテキストフロー ID を含めるべきです (SHOULD)。

送信者は, 受信者から別途通知されない限り (セクション 3.4.3 を参照), デフォルトでアンチリプレイが有効になっていると想定します。したがって, ESP 実装の典型的な動作では, シーケンス番号 (または ESN) がサイクルするとき, またはこの値がサイクルすることを予想して, 送信者が新しい SA を確立することが求められます。

ICV を計算するために使用されるキーが手動で配布される場合, 準拠した実装はアンチリプレイサービスを提供すべきではありません (SHOULD NOT)。ユーザーが手動でキー設定された SA と組み合わせてアンチリプレイを使用することを選択した場合, キーが交換されるまで, 送信者のシーケンス番号カウンタはローカルリブートなどを通じて正しく維持されなければなりません。(セクション 5 を参照。)

アンチリプレイが無効になっている場合 (上記のように), 送信者はカウンタを監視またはリセットする必要はありません。ただし, 送信者は依然としてカウンタをインクリメントし, 最大値に達すると, カウンタはゼロに戻ります。(この動作は, この標準の範囲外のアンチリプレイメカニズムが送信者と受信者の間で交渉されない限り, マルチ送信者, マルチキャスト SA に推奨されます。)

ESN (付録を参照) が選択されている場合, シーケンス番号の下位 32 ビットのみがシーケンス番号フィールドで送信されますが, 送信者と受信者の両方が完全な 64 ビット ESN カウンタを維持します。上位 32 ビットは, アルゴリズム/モード固有の方法で完全性チェックに含まれます, 例えば別個の完全性アルゴリズムが使用される場合, 上位 32 ビットは次のヘッダーフィールドの後に追加される場合があります。

注意: 受信者が SA に対してアンチリプレイを有効にしないことを選択した場合, 受信者は SA 管理プロトコルで ESN を交渉すべきではありません (SHOULD NOT)。ESN の使用により, 受信者はアンチリプレイウィンドウを管理する必要が生じます (ICV 計算で使用される ESN の上位ビットの正しい値を決定するため), これは一般的に SA に対してアンチリプレイを無効にするという概念に反します。

3.3.4. Fragmentation (フラグメンテーション)

必要に応じて, IPsec 実装内の ESP 処理後にフラグメンテーションが実行されます。したがって, トランスポートモード ESP は完全な IP データグラムにのみ適用されます (IP フラグメントには適用されません)。ESP が適用された IP パケット自体は, 経路上のルーターによってフラグメント化される可能性があり, そのようなフラグメントは受信者での ESP 処理の前に再構成されなければなりません。トンネルモードでは, ESP は IP パケットに適用されますが, これは IP データグラムのフラグメントである可能性があります。たとえば, セキュリティゲートウェイまたは「バンプインザスタック」または「バンプインザワイヤー」IPsec 実装 (セキュリティアーキテクチャ文書で定義されているように) は, このようなフラグメントにトンネルモード ESP を適用する場合があります。

注意: トランスポートモードの場合 -- セクション 3.1.1 の最後で述べたように, バンプインザスタックとバンプインザワイヤーの実装では, まずローカル IP レイヤーによってフラグメント化されたパケットを再構成し, 次に IPsec を適用し, その後結果のパケットをフラグメント化する必要がある場合があります。

注意: IPv6 の場合 -- バンプインザスタックとバンプインザワイヤーの実装では, フラグメンテーションヘッダーが存在するかどうかを判断し, したがってパケットが IPsec 処理の前に再構成を必要とするかどうかを判断するために, すべての拡張ヘッダーを調べる必要があります。

IPsec 実装によって実行されるか, IPsec ピア間のパス上のルーターによって実行されるかにかかわらず, フラグメンテーションはパフォーマンスを大幅に低下させます。さらに, ESP 受信者が再構成のためにフラグメントを受け入れる要件は, サービス拒否の脆弱性を生み出します。したがって, ESP 実装はフラグメンテーションをサポートしないことを選択してもよく (MAY), パス MTU (PMTU) 検出を容易にするために送信されたパケットに DF ビットをマークすることができます。いずれの場合も, ESP 実装はフラグメンテーションの可能性を最小限に抑えるために, ICMP PMTU メッセージ (またはネイティブホスト実装の同等の内部シグナリング) の生成をサポートしなければなりません。MTU 管理に必要なサポートの詳細は, セキュリティアーキテクチャ文書に含まれています。