2.9. Traffic Selector Negotiation (トラフィックセレクタの交渉)

RFC4301 準拠の IPsec サブシステムが SPD (Security Policy Database) の "protect" セレクタに一致する IP パケットを受信すると, そのパケットを IPsec で保護する. SA がまだなければ IKE が作成する. システム SPD の維持は IKE の範囲外だが, 一部実装は IKE 実行中に SPD を更新しうる (例は 1.1.3 節).

Traffic Selector (TS) ペイロードは端点が SPD の一部をピアに伝えることを可能にする. これらは SPD から IKE に渡されなければならない (例: PF_KEY API [PFKEY] の SADB_ACQUIRE). TS ペイロードは新設 SA 上で転送されるパケットの選択基準を指定する.

一部シナリオでは SPD の一貫性確認に使える. 他では SPD の動的更新を導く.

Child SA 対を作成する交換の各メッセージに TS ペイロードが 2 つ現れる. 各 TS ペイロードは 1 つ以上の Traffic Selector を含む. 各 Traffic Selector はアドレス範囲 (IPv4 または IPv6), ポート範囲, IP プロトコル ID からなる.

2 つのうち最初が TSi (Traffic Selector-initiator), 2 番目が TSr (Traffic Selector-responder) である. TSi は Child SA 対の initiator から転送されるトラフィックのソースアドレス (または initiator へ転送されるトラフィックの宛先) を指定する. TSr は responder へ転送されるトラフィックの宛先 (または responder から転送されるトラフィックのソース) を指定する. 例: 元 initiator が Child SA 対の作成を求め, initiator 側サブネット 198.51.100.* から responder 側 192.0.2.* への全トラフィックをトンネルしたい場合, 各 TS ペイロードに 1 つの Traffic Selector を入れる. TSi は (198.51.100.0 - 198.51.100.255), TSr は (192.0.2.0 - 192.0.2.255) とする. responder が受け入れれば同一 TS を返す.

IKEv2 は responder が initiator の提案トラフィックの部分集合を選べる. 設定更新が片端だけに届いているときなどに起こりうる. 両端が別管理者ならエラーがなくても不整合が長引きうる. 意図的な差異 (一方が全アドレスをトンネルし他方が最新リストを持つ) も許容する.

responder が部分集合を選ぶと, initiator 提案のある部分集合に Traffic Selector を狭める (空集合になってはならない). 提案 TS の型が未知なら responder はその TS を無視し, 未知型は狭めた集合に返さない.

responder が適切な範囲を選べるよう, データパケットが原因で SA を要求した場合 initiator は TSi と TSr それぞれの最初の TS に, 要求を引き起こしたパケットのアドレスを含む非常に具体的な TS を入れるべきである. 例では TSi に 2 つ: 最初が (198.51.100.43 - 198.51.100.43) とパケットのソースポートと IP プロトコル, 2 番目が (198.51.100.0 - 198.51.100.255) で全ポート・全プロトコル. TSr にも同様に 2 つ. 到着パケットに応じず (例: 起動時に) Child SA 対を作る場合, 特定アドレスの優先がないかもしれず, TSi/TSr の最初は具体値ではなく範囲でもよい.

responder の絞り込み:

提案 TS のいかなる部分もポリシーが許さなければ TS_UNACCEPTABLE Notify で応答する.
TSi と TSr が覆うトラフィック全体がポリシーで許されれば絞り込み不要で同じ TSi/TSr を返せる.
TSi と TSr の最初のセレクタが許されれば, initiator の第一希望を含む部分集合に狭めなければならない. 上の例では TSi を (198.51.100.43 - 198.51.100.43) かつ全ポート・全プロトコルにしてよい.
最初のセレクタが許されなければ, TSi/TSr の許容部分集合に狭める.

絞り込み時, それぞれは許容だが和集合は許容でない部分集合が複数ありうる. responder は任意に 1 つ選び, 応答に ADDITIONAL_TS_POSSIBLE を含めてもよい. この通知は responder が TS を狭めたが, 別 SA でなら他の TS も許容だったことを示す. データはない. initiator と responder の設定が異なる場合のみ起こる. トンネル粒度で一致していれば initiator は responder が受け入れる幅より広いトンネルを要求しない.

responder ポリシーが initiator の TS に含まれる複数の小範囲を持ち, 各範囲を別 SA で送るべきとする場合もある. initiator がパケットではなく起動などで要求を生成した場合, responder が正しい範囲を選ぶのに非常に具体的な最初の TS がない. どのアドレス対を含めるか決められず推測するか SINGLE_PAIR_REQUIRED Notify で拒否する.

SINGLE_PAIR_REQUIRED は, 送信者が単一アドレス対のみの TS しか受け入れないため CREATE_CHILD_SA が受け入れられないことを示す. 要求者は転送しようとしている具体トラフィックのみの SA を要求することが期待される.

アドレス対ごとに別 SA を要するポリシーの実装は少ない. したがって initiator の TSi/TSr の一部のみが許容なら, responder は SINGLE_PAIR_REQUIRED ではなく許容部分集合に狭めるべきである.

2.9.1. 自ポリシーに反するトラフィックセレクタ

新 SA 作成時 initiator は自ポリシーに反する TS を提案してはならない. 守らなければ正当トラフィックが落ちうる. [IPSECARCH] の decorrelated ポリシーを使えばこの違反は起きない.

例: ホスト A のポリシーが 198.51.100.66 へのトラフィックを B 経由 AES で, 198.51.100.0/24 の他ホストは B 経由 3DES で送るとする. B は AES と 3DES の任意の組を受け入れる.

A が 3DES の SA を提案し TSr に (198.51.100.0 - 198.51.100.255) を含めれば B は受理する. B は 198.51.100.66 からのトラフィックにもこの SA を使え, A は AES を要求するためそれらを落とす. A が 198.51.100.66 専用に AES の新 SA を作っても B は最初の SA を使い続けうる. A は提案時に自ポリシーに従い, TSr を ((198.51.100.0 - 198.51.100.65), (198.51.100.67 - 198.51.100.255)) とすべきだった.

一般に (1) initiator が "トラフィック X (TSi/TSr) に SA" と提案し, (2) X の部分集合 X' について initiator は実際には SA で X' を受け入れず, (3) initiator は別の SA' で X' を受け入れるなら, responder が X' に SA または SA' を適用しうるため正当トラフィックが無駄に落ちうる.

2.9.2. 再鍵化におけるトラフィックセレクタ

再鍵化は既存 Child SA を別のものに置き換える. 新 SA が元より狭いセレクタ集合を許されれば, 旧 SA で許されたトラフィックが新 SA で落ち, "置換" の考えに反する. したがって新 SA は元より狭いセレクタを持ってはならない. 再鍵化 SA が現在使用中より狭い範囲を必要とするなら, ポリシー変更で現行 SA がポリシーに反するはずであり, 変更後に既に削除されていなければならない.

initiator が Child SA を再鍵化しようとするとき, 提案 TS は旧 Child SA で使ったものと同一かその超集合であるべきである. つまり現在有効な (decorrelated) ポリシーと同一か超集合である. responder は現在使用中の範囲より狭く TS を狭めてはならない.

再鍵化 SA は現在使用中より狭くなりえないため, パケット由来のセレクタは不要であり, 送るべきではない.