4.4.1.1. セレクタ (Selectors)
SA は、SA のトラフィックセットを定義するために使用されるセレクタに応じて、細粒度または粗粒度にすることができます。たとえば、2 つのホスト間のすべてのトラフィックは単一の SA を介して伝送され、統一されたセキュリティサービスのセットが提供される場合があります。あるいは、ホストのペア間のトラフィックは、使用されているアプリケーション（次層プロトコルおよび関連フィールド（ポートなど）によって定義される）に応じて複数の SA に分散される場合があり、異なる SA によって異なるセキュリティサービスが提供されます。同様に、セキュリティゲートウェイのペア間のすべてのトラフィックは単一の SA で伝送されるか、通信するホストペアごとに 1 つの SA が割り当てられる場合があります。
SA 粒度の制御を容易にするために、すべての IPsec 実装は以下のセレクタパラメータをサポートしなければなりません (MUST)。ローカルアドレスとリモートアドレスの両方は IPv4 または IPv6 のいずれかである必要がありますが、アドレスタイプを混在させることはできません。また、ローカル/リモートポートセレクタ（および ICMP メッセージタイプとコード、モビリティヘッダータイプ）は、パケットのフラグメンテーションによりこれらのフィールドにアクセスできない状況に対応するために OPAQUE とラベル付けされる場合があります。
リモート IP アドレス (Remote IP Address(es))
タイプ: IPv4 または IPv6
これは IP アドレス範囲のリスト（ユニキャスト、ブロードキャスト（IPv4 のみ））です。この構造により以下の表現が可能です:
- 単一の IP アドレス（自明な範囲経由）
- アドレスのリスト（それぞれが自明な範囲）
- アドレスの範囲（低い値と高い値、境界を含む）
- 範囲のリスト
アドレス範囲は、セキュリティゲートウェイの背後など、同じ SA を共有する複数のリモートシステムをサポートするために使用されます。
ローカル IP アドレス (Local IP Address(es))
タイプ: IPv4 または IPv6
これは IP アドレス範囲のリスト（ユニキャスト、ブロードキャスト（IPv4 のみ））です。この構造により以下の表現が可能です:
- 単一の IP アドレス（自明な範囲経由）
- アドレスのリスト（それぞれが自明な範囲）
- アドレスの範囲（低い値と高い値、境界を含む）
- 範囲のリスト
アドレス範囲は、セキュリティゲートウェイの背後など、同じ SA を共有する複数のソースシステムをサポートするために使用されます。ローカルとは、この実装（またはポリシーエントリ）によって保護されているアドレスを指します。
注意: SPD にはマルチキャストアドレスエントリのサポートは含まれていません。マルチキャスト SA をサポートするには、実装は [RFC3740] で定義されているグループ SPD (Group SPD, GSPD) を使用する必要があります。GSPD エントリには異なる構造が必要です。つまり、ユニキャスト SA のローカルおよびリモートアドレス値に関連付けられた対称関係をマルチキャストコンテキストで使用することはできません。具体的には、SA 上のマルチキャストアドレスに向けられたアウトバウンドトラフィックは、マルチキャストアドレスをソースとする対応するインバウンド SA で受信されません。
次層プロトコル (Next Layer Protocol)
ソース: IPv4 "プロトコル" フィールドまたは IPv6 "次ヘッダー" フィールド
値: 個別のプロトコル番号、ANY、または（IPv6 のみ）OPAQUE
次層プロトコルは、存在する IP 拡張ヘッダーの後に来るものです。次層プロトコルの場所を簡単にするために、スキップする IPv6 拡張ヘッダーを設定するメカニズムがあるべきです (SHOULD)。
デフォルトでスキップする IPv6 拡張ヘッダー:
- 0 (ホップバイホップオプション Hop-by-hop options)
- 43 (ルーティングヘッダー Routing Header)
- 44 (フラグメンテーションヘッダー Fragmentation Header)
- 60 (宛先オプション Destination Options)
注意: デフォルトリストには 51 (AH) または 50 (ESP) は含まれていません。セレクタルックアップの観点から、IPsec は AH と ESP を次層プロトコルとして扱います。
次層プロトコル依存セレクタ
いくつかの追加のセレクタは次層プロトコル値に依存します:
ポート (Ports - TCP, UDP, SCTP など)
次層プロトコルが 2 つのポートを使用する場合（TCP、UDP、SCTP など）、ローカルポートとリモートポートのセレクタがあります。これらのセレクタのそれぞれには値範囲のリストがあります。
重要: フラグメント化されたパケットを受信した場合、またはポートフィールドが IPsec によって保護されている（暗号化されている）場合、ローカルポートとリモートポートは利用できない場合があります。したがって、OPAQUE 値もサポートしなければなりません (MUST)。
フラグメンテーション処理:
- 非初期フラグメントでは、ポート値は利用できません。
- ポートセレクタが ANY または OPAQUE 以外の値を指定している場合、非初期フラグメントのパケットと一致できません。
- SA が ANY または OPAQUE 以外のポート値を必要とする場合、ポートのない到着フラグメントは破棄されなければなりません (MUST)。（セクション 7「フラグメントの処理」を参照）
モビリティヘッダータイプ (Mobility Header Type)
次層プロトコルがモビリティヘッダーの場合、IPv6 モビリティヘッダーメッセージタイプ (MH type) のセレクタがあります。これは特定のモビリティメッセージを識別する 8 ビット値です。
注意: フラグメント化されたパケットを受信した場合、MH タイプは利用できない場合があります。（セクション 7「フラグメントの処理」を参照）
IKE の場合: IPv6 モビリティヘッダーメッセージタイプ (MH type) は、16 ビットローカル「ポート」セレクタの最上位 8 ビットに配置されます。
ICMP タイプとコード (ICMP Type and Code)
次層プロトコル値が ICMP の場合、ICMP メッセージタイプとコードの 16 ビットセレクタがあります。
構造:
- メッセージタイプ (Message Type): ICMP メッセージのタイプを定義する単一の 8 ビット値、または ANY
- ICMP コード (ICMP Code): ICMP メッセージの特定のサブタイプを定義する単一の 8 ビット値
IKE の場合:
- メッセージタイプは 16 ビットセレクタの最上位 8 ビットに配置されます
- コードは最下位 8 ビットに配置されます
許可される組み合わせ:
- 単一のタイプとコードの範囲
- 単一のタイプと ANY コード
- ANY タイプと ANY コード
マッチングアルゴリズム: タイプの範囲（T-start から T-end）とコードの範囲（C-start から C-end）を持つポリシーエントリ、およびタイプ t とコード c を持つ ICMP パケットが与えられた場合、実装は次の方法でマッチをテストしなければなりません (MUST):
(T-start*256) + C-start <= (t*256) + c <= (T-end*256) + C-end
注意: フラグメント化されたパケットを受信した場合、ICMP メッセージタイプとコードは利用できない場合があります。（セクション 7「フラグメントの処理」を参照）
名前 (Name)
重要: これは上記の他のセレクタのようなセレクタではありません。パケットから取得されるものではありません。名前は、IPsec ローカルまたはリモートアドレスのシンボリック識別子として使用できます。
名前付き SPD エントリは 2 つの方法で使用されます:
ユースケース 1: レスポンダ（ロードウォリアーのアクセス制御）
名前付き SPD エントリは、IP アドレスがリモート IP アドレスセレクタに適していない場合（例：「ロードウォリアー」）のアクセス制御をサポートするために、レスポンダ（イニシエータではない）によって使用されます。
プロセス:
- このフィールドにマッチするために使用される名前は、IKE ネゴシエーション中に ID ペイロードで伝達されます。
- イニシエータのソース IP アドレス（トンネルモードの内部 IP ヘッダー）は、IKE ネゴシエーションによって作成された SAD エントリのリモート IP アドレスにバインドされます。
- このアドレスは、この方法で SPD エントリが選択された場合、SPD のリモート IP アドレス値を上書きします。
要件: すべての IPsec 実装はこの名前の使用をサポートしなければなりません (MUST)。
サポートされる名前形式:
- 完全修飾ドメイン名 (Fully Qualified Domain Name, FQDN)
- 識別名 (Distinguished Name, DN)
- RFC 822 電子メールアドレス
- キー ID (Key ID)
ユースケース 2: イニシエータ（マルチユーザー識別）
名前付き SPD エントリは、IPsec SA が作成されるユーザー（またはトラフィックがバイパスされる可能性のあるユーザー）を識別するためにイニシエータによって使用される場合があります。イニシエータの IP ソースアドレス（トンネルモードの内部 IP ヘッダーから）は、作成された場合に以下を置き換えるために使用されます:
- SPD キャッシュエントリのローカルアドレス
- アウトバウンド SAD エントリのローカルアドレス
- インバウンド SAD エントリのリモートアドレス
サポート: この使用は、マルチユーザーネイティブホスト実装ではオプションであり、他の実装には適用されません。
注意: この名前はローカルでのみ使用されます。キー管理プロトコルによって伝達されません。また、上記のケース 1（レスポンダ）で使用される名前形式以外の名前形式も、イニシエータコンテキストで適用できます。
SPD エントリ内の名前
SPD エントリには、名前（または名前のリスト）と、ローカルまたはリモート IP アドレスの値の両方を含めることができます。
ケース 1（レスポンダ）の場合: 名前付き SPD エントリで使用される識別子は、DNS 名、識別名、または RFC 822 電子メールアドレスです。
ケース 2（イニシエータ）の場合: 名前形式はケース 1 と同じである場合もあれば、ユーザー ID (UID) または他のローカル命名規則である場合もあります。
重要な命名規則:
- すべての SPD エントリは、レスポンダ使用のために上記で定義された名前形式に対応できなければなりません (MUST)。
- 実装がイニシエータ使用のためにローカルに有効な名前形式を使用して SPD エントリを作成できるようにする場合、これはローカルな問題です。
- 名前を含む SPD エントリは、名前がローカルまたはリモート IP アドレスに解決される場合、または IKE ネゴシエーション中に ID ペイロードをマッチするために名前が使用される場合にのみ使用できます。