2.9. 流量选择器协商
2.9. 流量选择器协商
当符合 RFC 4301 的 IPsec 子系统接收到与其安全策略数据库 (SPD) 中某个 "protect" 选择器相匹配的 IP 数据包时, 该子系统使用 IPsec 保护该数据包。当尚不存在 SA 时, 创建 SA 是 IKE 的任务。系统 SPD 的维护超出了 IKE 的范围, 尽管某些实现可能会结合 IKE 的运行来更新其 SPD (场景示例见第 1.1.3 节)。
流量选择器 (TS) 载荷允许端点将其 SPD 中的某些信息传递给对端。这些信息必须 (MUST) 从 SPD 传递给 IKE (例如, PF_KEY API [PFKEY] 使用 SADB_ACQUIRE 消息)。TS 载荷指定将通过新建立的 SA 转发的包的选择标准。在某些场景中, 这可用作一致性检查, 以确保 SPD 是一致的。在其他场景中, 它指导 SPD 的动态更新。
在创建 Child SA 对 (pair) 的交换消息中, 每条消息都出现两个 TS 载荷。每个 TS 载荷包含一个或多个流量选择器。每个流量选择器由一个地址范围 (IPv4 或 IPv6), 一个端口范围和一个 IP 协议 ID 组成。
两个 TS 载荷中的第一个称为 TSi (Traffic Selector-initiator, 发起方流量选择器)。第二个称为 TSr (Traffic Selector-responder, 响应方流量选择器)。TSi 指定从 Child SA 对的发起方转发的流量的源地址 (或转发到发起方的流量的目的地址)。TSr 指定转发到 Child SA 对的响应方的流量的目的地址 (或从响应方转发的流量的源地址)。例如, 如果原始发起方请求创建 Child SA 对, 并希望将发起方一侧子网 198.51.100.* 上的所有流量隧道传输到响应方一侧子网 192.0.2.* 上, 发起方将在每个 TS 载荷中各包含一个流量选择器。TSi 将指定地址范围 (198.51.100.0 - 198.51.100.255), TSr 将指定地址范围 (192.0.2.0 - 192.0.2.255)。假设该提议被响应方接受, 它将返回相同的 TS 载荷。
IKEv2 允许响应方选择发起方提议的流量的一个子集。这可能发生在两个端点的配置正在更新但只有一端收到了新信息时。由于两个端点可能由不同的人配置, 即使没有错误, 这种不兼容也可能持续很长一段时间。它还允许有意的不同配置, 例如一端配置为隧道传输所有地址, 并依赖另一端拥有最新的列表。
当响应方选择发起方提议的流量的子集时, 它将流量选择器缩小到发起方提议的某个子集 (前提是该集合不变成空集)。如果提议的流量选择器类型未知, 响应方忽略该流量选择器, 以便未知类型不会在缩小后的集合中返回。
为了在这种情况下使响应方能够选择适当的范围, 如果发起方由于数据包而请求了 SA, 发起方应该 (SHOULD) 在 TSi 和 TSr 中各自包含一个非常具体的流量选择器作为第一个流量选择器, 其中包括触发请求的数据包中的地址。在该示例中, 发起方将在 TSi 中包含两个流量选择器: 第一个包含地址范围 (198.51.100.43 - 198.51.100.43) 以及来自数据包的源端口和 IP 协议, 第二个包含 (198.51.100.0 - 198.51.100.255), 所有端口和所有 IP 协议。发起方将在 TSr 中类似地包含两个流量选择器。如果发起方不是响应到达的数据包创建 Child SA 对, 而是 (例如) 在启动时创建, 那么发起方可能没有任何它比其他地址更偏好的用于初始隧道的特定地址。在这种情况下, TSi 和 TSr 中的第一个值可以是范围而不是特定值。
响应方按如下方式执行缩小:
o 如果响应方的策略不允许它接受提议的流量选择器的任何部分, 它将以 TS_UNACCEPTABLE 通知消息作出响应。
o 如果响应方的策略允许 TSi 和 TSr 所涵盖的全部流量, 则无需缩小, 响应方可以 (MAY) 返回相同的 TSi 和 TSr 值。
o 如果响应方的策略允许它接受 TSi 和 TSr 的第一个选择器, 那么响应方必须 (MUST) 将流量选择器缩小到包含发起方第一选择的子集。在上面的示例中, 响应方可能以 TSi 为 (198.51.100.43 - 198.51.100.43), 所有端口和所有 IP 协议来响应。
o 如果响应方的策略不允许它接受 TSi 和 TSr 的第一个选择器, 响应方缩小到 TSi 和 TSr 的一个可接受的子集。
当进行缩小操作时, 可能存在多个可接受的子集, 但它们的并集不可接受。在这种情况下, 响应方任意选择其中一个, 并且可以 (MAY) 在响应中包含一个 ADDITIONAL_TS_POSSIBLE 通知。ADDITIONAL_TS_POSSIBLE 通知断言响应方缩小了提议的流量选择器, 但其他流量选择器本来也是可接受的, 尽管只能在单独的 SA 中。此通知类型没有关联的数据。这种情况只会在发起方和响应方的配置彼此不同时发生。如果发起方和响应方就隧道的粒度达成一致, 发起方将永远不会请求比响应方愿意接受的更宽的隧道。
响应方的策略可能包含多个较小的范围, 全部被发起方的流量选择器所涵盖, 并且响应方的策略是这些范围中的每一个都应该通过不同的 SA 发送。继续上面的示例, 响应方可能有一个策略, 愿意向发起方隧道传输这些地址, 但可能要求每一对地址位于单独协商的 Child SA 上。如果发起方不是基于数据包生成其请求, 而是 (例如) 在启动时生成, 就不会有帮助响应方选择正确的范围的非常具体的第一个流量选择器。响应方将无法确定哪对地址应该包含在此隧道中, 它将不得不猜测或者用 SINGLE_PAIR_REQUIRED 通知拒绝请求。
SINGLE_PAIR_REQUIRED 错误表示 CREATE_CHILD_SA 请求不可接受, 因为其发送方只愿意接受指定单对地址的流量选择器。请求方应通过仅为它试图转发的特定流量请求 SA 来作出响应。
很少有实现的策略要求为每个地址对使用单独的 SA。因此, 如果只有发起方提议的 TSi 和 TSr 的某些部分被响应方接受, 响应方应该 (SHOULD) 将选择器缩小到可接受的子集, 而不是使用 SINGLE_PAIR_REQUIRED。
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, 并且包含的 TSr 含有 (198.51.100.0-198.51.100.255), 这将被主机 B 接受。现在, 主机 B 也可以使用该 SA 从 198.51.100.66 发送流量, 但这些数据包将被 A 丢弃, 因为它要求对此流量使用 AES。即使主机 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。
一般来说, 如果 (1) 发起方提出 "对流量 X (TSi/TSr), 执行 SA" 的提议, 并且 (2) 对于 X 的某个子集 X', 发起方实际上不接受用 SA 传输流量 X', 并且 (3) 发起方愿意用某个 SA' (!=SA) 接受流量 X', 那么有效流量可能会被不必要地丢弃, 因为响应方可以对流量 X' 应用 SA 或 SA'。