5. IPトラフィック処理 (IP Traffic Processing)

セクション4.4.1「セキュリティポリシーデータベース (The Security Policy Database, SPD)」で述べたように、IPsec管理トラフィックを含む、IPsec保護境界を越えるすべてのトラフィックの処理中に、SPD(または関連するキャッシュ)を参照しなければなりません(MUST)。パケットに一致するポリシーがSPDで見つからない場合(インバウンドまたはアウトバウンドトラフィックのいずれの場合も)、そのパケットを破棄しなければなりません(MUST)。処理を簡素化し、非常に高速なSA検索を可能にするため(SG/BITS/BITWの場合)、本文書では、すべてのアウトバウンドトラフィック用のSPDキャッシュ(SPD-O plus SPD-S)の概念と、インバウンドの非IPsec保護トラフィック用のキャッシュ(SPD-I)を導入しています。(前述のように、SADは、SAに到着するインバウンドIPsec保護トラフィックのセレクタをチェックするためのキャッシュとして機能します。)SPDごとに名目上1つのキャッシュがあります。本仕様の目的上、各キャッシュエントリは正確に1つのSAにマップされると想定されています。ただし、異なる優先度のトラフィック(例えば、異なるDSCP値で示される)を運ぶために複数のSAを使用するが、同じセレクタを持つ場合、例外が発生することに注意してください。また、SADにSPD内に対応するエントリがないSAのエントリが存在する状況がいくつかあることにも注意してください。本文書では、SPDが変更されたときにSADを選択的にクリアすることを義務付けていないため、SADエントリを作成したSPDエントリが変更または削除されても、SADエントリは残る可能性があります。また、手動でキー設定されたSAが作成された場合、このSAに対するSADエントリが存在する可能性がありますが、そのエントリはどのSPDエントリにも対応していません。

SPDエントリは重複する可能性があるため、一般的にこれらのエントリを安全にキャッシュすることはできません。単純なキャッシングは、キャッシュエントリとの一致をもたらす可能性がありますが、SPDの順序付き検索では、異なるエントリとの一致をもたらしたはずです。ただし、SPDエントリが最初に非相関化されている場合、結果のエントリは安全にキャッシュできます。各キャッシュエントリは、一致するトラフィックを適切にバイパスまたは破棄する必要があることを示します。(注意:元のSPDエントリは、例えばPFPのために、複数のSAをもたらす可能性があります。)特に明記されていない限り、以下の「SPD」または「SPDキャッシュ」または「キャッシュ」へのすべての参照は、非相関化されたSPD(SPD-I、SPD-O、SPD-S)または非相関化されたSPDからのエントリを含むSPDキャッシュを指します。

注意: ソケットベースのホストIPsec実装では、新しいソケットが作成されるたびにSPDが参照され、そのソケット上を流れるトラフィックにどのようなIPsec処理を適用するか(もしあれば)が決定されます。これは暗黙的なキャッシングメカニズムを提供し、キャッシングに対処する前述の議論の部分は、そのような実装では無視できます。

注意: 相関したSPDから始めることが想定されています。これは、ユーザーと管理者がこれらの種類のアクセス制御リストまたはファイアウォールフィルタルールを管理することに慣れている方法だからです。次に、非相関化アルゴリズムが適用されて、キャッシュ可能なSPDエントリのリストが構築されます。非相関化は管理インターフェースでは見えません。

インバウンドIPsecトラフィックの場合、SPIによって選択されたSADエントリは、AHまたはESP処理が実行された後、到着したIPsecパケットと照合されるセレクタのキャッシュとして機能します。

5.1. アウトバウンドIPトラフィック処理 (Outbound IP Traffic Processing)

まず、保護されたインターフェース経由で実装に入り、保護されていないインターフェース経由で出るトラフィックのパスを考えます。

                     保護されていないインターフェース
                              ^
                              |
       (ネストされたSA)   +----------+
      -------------------|転送       |<-----+
      |                  +----------+      |
      |                        ^           |
      |                        | バイパス  |
      V                     +-----+        |
  +-------+                 | SPD |     +--------+
...| SPD-I |.................|キャッシュ|.....|処理    |...IPsec
   |  (*)  |                 | (*) |---->|(AH/ESP)|   境界
   +-------+                 +-----+     +--------+
      |        +-------+     /  ^
      |        |破棄   | <--/   |
      |        +-------+        |
      |                         |
      |                 +-------------+
      |---------------->|SPD選択      |
                        +-------------+
                               ^
                               |     +------+
                               |  -->| ICMP |
                               | /   +------+
                               |/
                               |
                               |
                       保護されたインターフェース

    図2.  アウトバウンドトラフィックの処理モデル
               (*) = SPDキャッシュがここに示されています。キャッシュミスがある場合、
                     SPDがチェックされます。キャッシュミスがある場合に実装が
                     パケットをバッファリングする要件はありません。

IPsecは、アウトバウンドパケットを処理するときに次の手順を実行しなければなりません(MUST):

パケットがサブスクライバー(保護された)インターフェースから到着したら、SPD選択関数を呼び出して、適切なSPDを選択するために必要なSPD-IDを取得します。(実装が1つのSPDのみを使用する場合、このステップは何もしません。)
ステップ1のSPD-IDで指定されたSPDのキャッシュに対してパケットヘッダーを照合します。このキャッシュには、SPD-OとSPD-Sからのエントリが含まれていることに注意してください。

3a. 一致がある場合、一致するキャッシュエントリで指定されているようにパケットを処理します。つまり、AHまたはESPを使用してバイパス(BYPASS)、破棄(DISCARD)、または保護(PROTECT)します。IPsec処理が適用される場合、SPDキャッシュエントリから関連するSADエントリ(モード、暗号化アルゴリズム、キー、SPI、PMTUなどを指定)へのリンクがあります。IPsec処理は、トンネルモードまたはトランスポートモード、およびAHまたはESPに対して、それぞれのRFC [Ken05b、Ken05a]で規定されているように、以前に定義されたとおりです。SA PMTU値と、ステートフルフラグメントチェックフラグの値(およびアウトバウンドパケットのIPヘッダー内のDFビット)が、パケットがIPsec処理の前または後にフラグメント化できる(しなければならない)かどうか、またはそれを破棄してICMP PMTUメッセージを送信しなければならないかどうかを決定することに注意してください。

3b. キャッシュに一致が見つからない場合、SPD-IDで指定されたSPD(SPD-SおよびSPD-O部分)を検索します。SPDエントリがバイパス(BYPASS)または破棄(DISCARD)を要求する場合、1つ以上の新しいアウトバウンドSPDキャッシュエントリを作成し、バイパス(BYPASS)の場合は、1つ以上の新しいインバウンドSPDキャッシュエントリを作成します。(非相関化されたSPDエントリが非相関化プロセスの副作用として作成された他のそのようなエントリにリンクされている可能性があるため、複数のキャッシュエントリが作成される可能性があります。)SPDエントリが保護(PROTECT)、つまりSAの作成を要求する場合、キー管理メカニズム(例えばIKEv2)が呼び出されてSAが作成されます。SA作成が成功した場合、新しいアウトバウンド(SPD-S)キャッシュエントリが作成され、アウトバウンドおよびインバウンドSADエントリも作成されます。それ以外の場合、パケットは破棄されます。(SPD検索をトリガーするパケットは、実装によって破棄される場合があります(MAY)、または、作成された場合は、新しく作成されたキャッシュエントリに対して処理される場合があります(MAY)。)SAはペアで作成されるため、対応するインバウンドSAのSADエントリも作成され、インバウンドSAの作成に使用されたSPDエントリ(およびPFPフラグが「true」であった場合はパケット)から派生したセレクタ値が含まれ、SAを介して配信されるインバウンドトラフィックをチェックするために使用されます。

パケットは、アウトバウンド転送機能(IPsec実装の外部で動作)に渡され、パケットが向けられるインターフェースを選択します。この機能により、ネストされたSAをサポートするなど、追加のIPsec処理のために、パケットがIPsec境界を越えて戻される場合があります。その場合、パケットのインバウンドバイパスを許可するエントリがSPD-Iデータベースに存在しなければならず(MUST)、そうでない場合、パケットは破棄されます。必要に応じて、つまり、複数のSPD-Iがある場合、ループバックされているトラフィックは、この内部インターフェースから来たものとしてタグ付けされる場合があります(MAY)。これにより、必要に応じて、「本物の」外部トラフィックとループトラフィックに異なるSPD-Iを使用できるようになります。

注意: IPv4およびIPv6トランスポートモードを除いて、SG、BITS、またはBITW実装は、IPsecを適用する前にパケットをフラグメント化できます(MAY)。(これはIPv4にのみ適用されます。IPv6パケットの場合、発信元のみがそれらをフラグメント化することが許可されています。)デバイスには、これを無効にする構成設定が必要です(SHOULD)。結果のフラグメントは、通常の方法でSPDに対して評価されます。したがって、ポート番号(またはICMPメッセージタイプとコード、またはモビリティヘッダータイプ)を含まないフラグメントは、ポート(またはICMPメッセージタイプとコード、またはMHタイプ)セレクタがOPAQUEまたはANYであるルールにのみ一致します。(詳細については、セクション7を参照してください。)

注意: SAのPMTUの決定と実施に関して、IPsecシステムはセクション8.2で説明されている手順に従わなければなりません(MUST)。

5.1.1. 破棄する必要があるアウトバウンドパケットの処理 (Handling an Outbound Packet That Must Be Discarded)

IPsecシステムが破棄する必要があると判断したアウトバウンドパケットを受信した場合、ソースにこれを示すICMPメッセージを生成して送信できるべきです(SHOULD)。ICMPメッセージタイプとコード値は、破棄の理由とIPバージョンによって異なります。ICMPメッセージは、レート制限に従って送信されるべきです(SHOULD)(セクション6を参照)。

5.1.2. トンネルモードのヘッダー構築 (Header Construction for Tunnel Mode)

このセクションでは、トンネルモードSAの外部IPヘッダー内のフィールドの処理について説明します。以下のセクションでは、IPv4とIPv6を個別に扱います。

5.1.2.1. IPv4: トンネルモードのヘッダー構築 (IPv4: Header Construction for Tunnel Mode)

IPv4データグラムがトンネルモードでの送信用にカプセル化される場合、外部IPヘッダーには次のフィールドが含まれます:

バージョン (Version): 4
IHL(インターネットヘッダー長): 通常は5、オプションが存在しない限り
サービスタイプ (Type of Service, TOS): 以下のトラフィッククラスマッピングを参照
全長 (Total Length): IPデータグラム全体の長さ
識別、フラグ、フラグメントオフセット (Identification, Flags, Fragment Offset): フラグメント処理を参照
生存時間 (Time to Live, TTL): 構成可能な値
プロトコル (Protocol): AH (51)またはESP (50)
ヘッダーチェックサム (Header Checksum): RFC 791に従って計算
送信元アドレス (Source Address): トンネル入口点
宛先アドレス (Destination Address): トンネル出口点

TOSフィールドの処理は、内部データグラムがIPv4かIPv6かによって異なります。IPv4-in-IPv4の場合、外部TOS値は内部TOSからコピーされるべきです(SHOULD)。IPv6-in-IPv4の場合、外部TOS値は内部トラフィッククラス(Traffic Class)フィールドから派生されるべきです(SHOULD)。

5.1.2.2. IPv6: トンネルモードのヘッダー構築 (IPv6: Header Construction for Tunnel Mode)

IPv6データグラムがトンネルモードでの送信用にカプセル化される場合、外部IPヘッダーには次のフィールドが含まれます:

バージョン (Version): 6
トラフィッククラス (Traffic Class): 以下のトラフィッククラスマッピングを参照
フローラベル (Flow Label): 構成可能
ペイロード長 (Payload Length): ペイロードの長さ
次ヘッダー (Next Header): AH (51)またはESP (50)
ホップ制限 (Hop Limit): 構成可能な値
送信元アドレス (Source Address): トンネル入口点
宛先アドレス (Destination Address): トンネル出口点

トラフィッククラスフィールドの処理は、内部データグラムがIPv4かIPv6かによって異なります。IPv6-in-IPv6の場合、外部トラフィッククラス値は内部トラフィッククラスからコピーされるべきです(SHOULD)。IPv4-in-IPv6の場合、外部トラフィッククラス値は内部TOSフィールドから派生されるべきです(SHOULD)。

5.2. インバウンドIPトラフィックの処理 (Processing Inbound IP Traffic)

インバウンドIPトラフィックの処理には、いくつかのパスが存在します。以下のサブセクションでは、次の場合の処理について説明します:

保護されていないインターフェースに到着し、保護されたインターフェースを宛先とするトラフィック
保護されたインターフェースに到着し、別の保護されたインターフェースまたは保護されていないインターフェースを宛先とするトラフィック

5.2.1. 保護されていないから保護されたへ (Unprotected-to-Protected)

このセクションでは、保護されていないインターフェースに到着し、保護されたインターフェースを宛先とするトラフィックの処理について説明します。IPsecは次の手順を実行しなければなりません(MUST):

IPsec処理 (IPsec Processing): パケットがIPsecパケット(AHまたはESP)である場合、SPIによって選択されたSADエントリを使用してIPsec処理を実行します。IPsec処理が失敗した場合、パケットを破棄します。
セレクタチェック (Selector Check): パケットがSAに到着した場合、パケットのセレクタがSAのセレクタと一致することを確認します。一致しない場合、パケットを破棄します。
SPD検索 (SPD Lookup): パケットがIPsecによって保護されていなかった(そして保護される必要がなかった)場合、または成功したIPsec処理の後、適切なSPD(SPD-I)でパケットのセレクタを検索します。一致するエントリが見つからない場合、または一致するエントリがパケットを許可しない場合、それを破棄します。
転送 (Forwarding): パケットがすべてのチェックに合格した場合、適切な保護されたインターフェースに転送します。

5.2.2. 保護されたから保護されたへ、または保護されたから保護されていないへ (Protected-to-Protected or Protected-to-Unprotected)

保護されたインターフェースから発信されたトラフィックは、セクション5.1で説明されているアウトバウンドトラフィックと同様に処理されます。

関連セクション:

5.1. アウトバウンドIPトラフィック処理 (Outbound IP Traffic Processing)​

5.1.1. 破棄する必要があるアウトバウンドパケットの処理 (Handling an Outbound Packet That Must Be Discarded)​

5.1.2. トンネルモードのヘッダー構築 (Header Construction for Tunnel Mode)​

5.1.2.1. IPv4: トンネルモードのヘッダー構築 (IPv4: Header Construction for Tunnel Mode)​

5.1.2.2. IPv6: トンネルモードのヘッダー構築 (IPv6: Header Construction for Tunnel Mode)​

5.2. インバウンドIPトラフィックの処理 (Processing Inbound IP Traffic)​

5.2.1. 保護されていないから保護されたへ (Unprotected-to-Protected)​

5.2.2. 保護されたから保護されたへ、または保護されたから保護されていないへ (Protected-to-Protected or Protected-to-Unprotected)​