2.9. トラフィック・セレクタのネゴシエーション
2.9. トラフィック・セレクタのネゴシエーション
RFC 4301 準拠の IPsec サブシステムは, そのセキュリティ・ポリシー・データベース (SPD) 内の "protect" セレクタに一致する IP パケットを受信したとき, そのパケットを IPsec で保護します。SA がまだ存在しない場合, それを作成するのは IKE の任務です。システムの SPD の保守は IKE の範囲外ですが, いくつかの実装は IKE の実行に関連して SPD を更新するかもしれません (シナリオ例はセクション 1.1.3 参照)。
トラフィック・セレクタ (TS) ペイロードにより, エンドポイントはその SPD からの情報の一部をピアに伝達できます。これらは SPD から IKE に伝達されなければなりません (MUST) (例えば, PF_KEY API [PFKEY] は SADB_ACQUIRE メッセージを使用します)。TS ペイロードは, 新しくセットアップされた SA を介して転送されるパケットの選択基準を指定します。これはいくつかのシナリオで, SPD が整合していることを保証するための整合性チェックとして機能します。他のシナリオでは, SPD の動的更新を導きます。
Child SA ペアを作成する交換メッセージでは, 各メッセージに 2 つの TS ペイロードが現れます。各 TS ペイロードは 1 つ以上のトラフィック・セレクタを含みます。各トラフィック・セレクタは, アドレス範囲 (IPv4 または IPv6), ポート範囲, および IP プロトコル ID から構成されます。
2 つの TS ペイロードの最初のものは TSi (Traffic Selector-initiator) と呼ばれます。2 番目は TSr (Traffic Selector-responder) と呼ばれます。TSi は, Child SA ペアのイニシエータから転送されるトラフィックの送信元アドレス (またはイニシエータに転送されるトラフィックの宛先アドレス) を指定します。TSr は, Child SA ペアのレスポンダに転送されるトラフィックの宛先アドレス (またはレスポンダから転送されるトラフィックの送信元アドレス) を指定します。たとえば, 元のイニシエータが Child SA ペアの作成を要求し, イニシエータ側のサブネット 198.51.100.* からレスポンダ側のサブネット 192.0.2.* へのすべてのトラフィックをトンネリングしたい場合, イニシエータは各 TS ペイロードに 1 つのトラフィック・セレクタを含めます。TSi はアドレス範囲 (198.51.100.0 - 198.51.100.255) を指定し, TSr はアドレス範囲 (192.0.2.0 - 192.0.2.255) を指定します。その提案がレスポンダに受け入れられたと仮定すると, それは同一の TS ペイロードを返します。
IKEv2 は, レスポンダがイニシエータの提案したトラフィックのサブセットを選択することを許可します。これは, 2 つのエンドポイントの設定が更新されているが, 一方の端のみが新しい情報を受信したときに起こり得ます。2 つのエンドポイントは異なる人物によって設定される可能性があるため, エラーがなくてもこの非互換性は長期間持続する可能性があります。また, 意図的な異なる設定も許可されます。たとえば, 一方の端がすべてのアドレスをトンネリングするように設定され, 最新のリストを持つもう一方の端に依存する場合などです。
レスポンダがイニシエータの提案したトラフィックのサブセットを選択する場合, それはトラフィック・セレクタをイニシエータの提案のサブセットに絞り込みます (ただし, その集合が空集合にならないことが条件です)。提案されたトラフィック・セレクタのタイプが不明な場合, レスポンダはそのトラフィック・セレクタを無視するため, 不明なタイプは絞り込まれた集合に返されません。
この場合にレスポンダが適切な範囲を選択できるようにするため, イニシエータがデータ・パケットに起因して SA を要求した場合, イニシエータは TSi および TSr の各々の最初のトラフィック・セレクタとして, 要求をトリガーしたパケット内のアドレスを含む, 非常に具体的なトラフィック・セレクタを含めるべきです (SHOULD)。この例では, イニシエータは TSi に 2 つのトラフィック・セレクタを含めます。1 つ目はアドレス範囲 (198.51.100.43 - 198.51.100.43) とパケットからの送信元ポートおよび IP プロトコルを含み, 2 つ目は (198.51.100.0 - 198.51.100.255) ですべてのポートおよびすべての IP プロトコルを含みます。イニシエータは同様に TSr に 2 つのトラフィック・セレクタを含めます。イニシエータが到着したパケットに応答して Child SA ペアを作成するのではなく, たとえば起動時に作成する場合, イニシエータには初期トンネル用により他のアドレスを好む特定のアドレスがないかもしれません。その場合, TSi および TSr の最初の値は特定の値ではなく範囲になり得ます。
レスポンダは次のように絞り込みを行います:
o レスポンダのポリシーが提案されたトラフィック・セレクタのいかなる部分の受け入れも許可しない場合, それは TS_UNACCEPTABLE 通知メッセージで応答します。
o レスポンダのポリシーが TSi および TSr でカバーされるトラフィックの全体を受け入れを許可する場合, 絞り込みは不要であり, レスポンダは同一の TSi および TSr 値を返してもかまいません (MAY)。
o レスポンダのポリシーが TSi および TSr の最初のセレクタの受け入れを許可する場合, レスポンダはトラフィック・セレクタを, イニシエータの最初の選択を含むサブセットに絞り込まなければなりません (MUST)。上記の例では, レスポンダは TSi を (198.51.100.43 - 198.51.100.43), すべてのポートおよびすべての IP プロトコルとして応答するかもしれません。
o レスポンダのポリシーが TSi および TSr の最初のセレクタの受け入れを許可しない場合, レスポンダは TSi および TSr の受け入れ可能なサブセットに絞り込みます。
絞り込みが行われる場合, 受け入れ可能な複数のサブセットが存在するが, それらの和集合は受け入れられないことがあります。この場合, レスポンダはそれらのうちの 1 つを任意に選択し, 応答に ADDITIONAL_TS_POSSIBLE 通知を含めてもかまいません (MAY)。ADDITIONAL_TS_POSSIBLE 通知は, レスポンダが提案されたトラフィック・セレクタを絞り込んだが, 他のトラフィック・セレクタもまた別個の SA でのみ許容されたであろうことを主張します。この通知タイプに関連するデータはありません。このケースは, イニシエータとレスポンダが互いに異なる設定になっている場合にのみ発生します。イニシエータとレスポンダがトンネルの粒度について合意していれば, イニシエータはレスポンダが受け入れるより広いトンネルを要求することは決してありません。
レスポンダのポリシーは, イニシエータのトラフィック・セレクタによってすべて包含される複数のより小さな範囲を含み得ます。また, レスポンダのポリシーは, それらの範囲の各々が異なる SA を介して送信されるべきであるというものです。上記の例を続けると, レスポンダはこれらのアドレスをイニシエータとの間でトンネリングすることを許可するポリシーを持っているかもしれませんが, 各アドレス・ペアが別個にネゴシエートされた Child SA 上になければならないことを要求するかもしれません。イニシエータがパケットに基づいて要求を生成せず, (たとえば) 起動時に生成した場合, レスポンダが正しい範囲を選択するのを助ける非常に具体的な最初のトラフィック・セレクタは存在しません。レスポンダがこのトンネルにどのアドレス・ペアを含めるべきかを決定する方法はなく, 推測するか, SINGLE_PAIR_REQUIRED 通知で要求を拒否しなければならないでしょう。
SINGLE_PAIR_REQUIRED エラーは, その送信側が単一のアドレス・ペアを指定するトラフィック・セレクタのみを受け入れることを望んでいるため, CREATE_CHILD_SA 要求が受け入れられないことを示します。要求側は, 転送しようとしている特定のトラフィックのみの SA を要求することで応答することが期待されます。
各アドレス・ペアに別個の SA を必要とするポリシーを持つ実装はほとんどありません。このため, イニシエータの提案した TSi および TSr の一部のみがレスポンダに受け入れられる場合, レスポンダは SINGLE_PAIR_REQUIRED を使用するのではなく, セレクタを許容されるサブセットに絞り込むべきです (SHOULD)。
2.9.1. 自身のポリシーに違反するトラフィック・セレクタ
新しい SA を作成するとき, イニシエータは自身のポリシーに違反するトラフィック・セレクタを提案しないようにする必要があります。このルールに従わない場合, 有効なトラフィックが破棄される可能性があります。 [IPSECARCH] の非相関 (decorrelated) ポリシーを使用する場合, この種のポリシー違反は発生しません。
これは例で最もよく説明されます。ホスト A に, 198.51.100.66 宛てのトラフィックがホスト B を介して AES で暗号化して送信され, 198.51.100.0/24 内の他のすべてのホスト宛てのトラフィックも B を介して送信されるが, 3DES を使用しなければならないという効果を持つポリシーがあると仮定します。また, ホスト B は AES と 3DES の任意の組み合わせを受け入れると仮定します。
ホスト A が今, 3DES を使用する SA を提案し, (198.51.100.0-198.51.100.255) を含む TSr を含めた場合, これはホスト B に受け入れられます。ここで, ホスト B はこの SA を使用して 198.51.100.66 からトラフィックを送信することもできますが, それらのパケットは, このトラフィックに AES の使用を要求しているため, A によって破棄されます。ホスト A が 198.51.100.66 専用の AES を使用する新しい SA を作成したとしても, ホスト B はそのトラフィックに最初の SA を自由に使い続けるかもしれません。この状況では,
SA を提案するとき, ホスト A は自身のポリシーに従い, 代わりに ((198.51.100.0-198.51.100.65),(198.51.100.67-198.51.100.255)) を含む TSr を含めるべきです (SHOULD)。
一般的に, (1) イニシエータが 「トラフィック X (TSi/TSr) に対して SA を行う」 という提案を行い, (2) X のサブセット X' のうち, イニシエータが実際に SA によるトラフィック X' を受け入れず, (3) イニシエータが何らかの SA' (!=SA) でトラフィック X' を受け入れる意思がある場合, レスポンダがトラフィック X' に SA または SA' のいずれかを適用できるため, 有効なトラフィックが不必要に破棄される可能性があります。