2.9. Traffic Selector Negotiation (流量选择子协商)

当符合 RFC4301 的 IPsec 子系统收到与 Security Policy Database (SPD, 安全策略数据库) 中 "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 载荷. 每个 TS 载荷包含一个或多个 Traffic Selector. 每个 Traffic Selector 由地址范围 (IPv4 或 IPv6), 端口范围与 IP 协议 ID 组成.

两个 TS 载荷中第一个称为 TSi (Traffic Selector-initiator). 第二个称为 TSr (Traffic Selector-responder). TSi 规定从 Child SA 对发起方转发来的流量的源地址 (或转发到发起方的流量的目的地址). TSr 规定转发到响应方的流量的目的地址 (或从响应方转发出的流量的源地址). 例如, 若原始发起方请求创建 Child SA 对, 并希望将发起方侧子网 198.51.100.* 的全部流量隧道到响应方侧子网 192.0.2.*, 发起方会在每个 TS 载荷中各包含一个 Traffic Selector. TSi 规定地址范围 (198.51.100.0 - 198.51.100.255), TSr 规定 (192.0.2.0 - 192.0.2.255). 若响应方接受该提议, 将回送相同的 TS 载荷.

IKEv2 允许响应方选取发起方提议流量的子集. 这可能发生在两端配置正在更新但仅一端收到新信息时. 由于两端可能由不同人员配置, 即使无错误, 不兼容也可能长期存在. 也允许有意不同的配置, 例如一端配置为隧道所有地址并依赖另一端维护最新列表.

当响应方选取发起方提议的子集时, 将 Traffic Selector 收窄为发起方提议的某一子集 (集合不得为空). 若提议的 Traffic Selector 类型未知, 响应方忽略该 Traffic Selector, 使未知类型不出现在收窄后的集合中.

为使响应方在此情形下能选取合适范围, 若发起方因数据分组而请求 SA, 发起方应该在 TSi 与 TSr 中各自把第一个 Traffic Selector 设为非常具体的值, 包含触发请求的分组中的地址. 在上例中, 发起方在 TSi 中包含两个 Traffic Selector: 第一个为地址范围 (198.51.100.43 - 198.51.100.43) 以及分组中的源端口与 IP 协议, 第二个为 (198.51.100.0 - 198.51.100.255) 且端口与 IP 协议为任意. 发起方在 TSr 中同样包含两个 Traffic Selector. 若发起方创建 Child SA 对并非响应到达的分组, 例如启动时, 则可能没有相对其他地址更偏好的具体地址. 此时 TSi 与 TSr 中的首项可以是范围而非具体值.

响应方按如下方式收窄:

若策略不允许接受提议 Traffic Selector 的任何部分, 则以 TS_UNACCEPTABLE Notify 响应.
若策略允许 TSi 与 TSr 所覆盖的全部流量, 无需收窄, 可返回相同的 TSi 与 TSr.
若策略允许 TSi 与 TSr 的第一个选择子, 则响应方必须将 Traffic Selector 收窄为仍包含发起方首选的子集. 在上例中, 响应方可能以 TSi 为 (198.51.100.43 - 198.51.100.43) 且端口与 IP 协议为任意来响应.
若策略不允许 TSi 与 TSr 的第一个选择子, 则响应方收窄为 TSi 与 TSr 的可接受子集.

收窄时可能存在多个可接受子集, 但其并集不可接受. 此时响应方任意选取其一, 并可以在响应中包含 ADDITIONAL_TS_POSSIBLE 通知. ADDITIONAL_TS_POSSIBLE 断言响应方收窄了提议的 Traffic Selector, 但其他 Traffic Selector 本也可接受, 仅能通过单独的 SA. 此 Notify 类型无关联数据. 仅当发起方与响应方配置不一致时才会出现. 若双方对隧道粒度达成一致, 发起方永远不会请求宽于响应方可接受的隧道.

响应方策略可能包含多个更小的范围, 全部被发起方的 Traffic Selector 覆盖, 且策略要求各范围经不同 SA 发送. 延续上例, 响应方可能愿意将那些地址与发起方隧道往返, 但要求每对地址各占单独协商的 Child SA. 若发起方并非基于分组生成请求而是 (例如) 启动时生成, 则不会有非常具体的首个 Traffic Selector 帮助响应方选取正确范围. 响应方无法确定本隧道应包含哪对地址, 只能猜测或以 SINGLE_PAIR_REQUIRED Notify 拒绝.

SINGLE_PAIR_REQUIRED 错误表示 CREATE_CHILD_SA 请求不可接受, 因为发送方仅愿意接受指定单对地址的 Traffic Selector. 期望请求方仅为其试图转发的具体流量请求 SA.

很少有实现的策略要求每对地址各占单独 SA. 因此, 若发起方提议的 TSi 与 TSr 只有部分可被响应方接受, 响应方应该将选择子收窄为可接受子集, 而不是使用 SINGLE_PAIR_REQUIRED.

2.9.1. 违反自身策略的流量选择子

创建新 SA 时, 发起方须避免提议违反自身策略的 Traffic Selector. 若不遵守, 合法流量可能被丢弃. 若使用 [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 也可用该 SA 从 198.51.100.66 发送流量, 但这些分组会被 A 丢弃, 因为 A 要求该流量使用 AES. 即使 A 仅为 198.51.100.66 创建使用 AES 的新 SA, B 仍可能继续使用第一条 SA 发送流量. 此情形下 A 在提议 SA 时应遵循自身策略, TSr 应含 ((198.51.100.0 - 198.51.100.65), (198.51.100.67 - 198.51.100.255)).

一般地, 若 (1) 发起方提议 "对流量 X (TSi/TSr) 使用 SA", (2) 对 X 的某子集 X', 发起方实际上不接受用 SA 承载 X', (3) 发起方愿意用某个与 SA 不同的 SA' 接受 X', 则合法流量可能被不必要地丢弃, 因为响应方可以对流量 X' 应用 SA 或 SA'.

2.9.2. 重密钥中的流量选择子

重密钥用于用另一条 Child SA 替换已有的. 若新 SA 允许比原 SA 更窄的选择子集合, 则原 SA 上允许的流量在新 SA 上会被丢弃, 违背 "替换" 的含义. 因此新 SA 绝对不能比原来的选择子更窄. 若重密钥后的 SA 需要比当前使用的更窄, 意味着策略已变更到当前 SA 违反策略的程度. 该情形下应在策略生效后已删除该 SA.

当发起方尝试重密钥 Child SA 时, 提议的 Traffic Selector 应该与旧 Child SA 使用的相同或是其超集. 即与当前活动 (decorrelated) 策略相同或是其超集. 响应方绝对不能将 Traffic Selector 收窄到小于当前使用范围.

由于重密钥后的 SA 绝不能比当前使用的更窄, 不需要来自分组的选择子, 故不应发送那些选择子.