摘要

  • RFC 9611 允许相同 TSi/TSr 下建立多条 Child SA，让不同 CPU 或队列各自拥有密钥和序列号空间，避免围绕一个共享计数器同步。
  • SA_RESOURCE_INFO 表示逻辑分组；可选标识只供调试，不能指挥对端 CPU。TS_MAX_QUEUE 仅拒绝这一选择器组合继续扩容，不等于拒绝其他 Child SA。
  • 协商成功只是政策回执。容量回执还要覆盖入站与出站安装、本地资源绑定、实际包分布、重放与丢包计数、rekey、删除恢复和业务侧吞吐。

管理界面里有八条绿色 SA，选择器完全一样。若把这张图直接称为“八核并行”，就把协议事实扩张成了执行事实。实际情况可能是：一端为八条入站 SA 全部建好状态，却只保留一条出站路径；另一端虽然安装八个上下文，调度器仍把绝大多数流量送到第一条。

RFC 9611 解决的原始问题很具体。单条 Child SA 的密钥、计数器和序列号状态若由多核共享，就会产生锁与同步成本。简单关掉重放保护只是在性能压力下牺牲安全。标准采用另一条路：在相同 Traffic Selectors 下建立多条正常 SA，每条独立派生密钥并维护序列空间。

因此，“相同”与“独立”同时成立。相同的是算法、TSi/TSr、模式、压缩等安全政策；独立的是 SPI、密钥、序列号与本地执行资源。前者可由 IKEv2 共同确认，后者必须由各自系统证明。

资源标识不是跨域调度权

发起方可在初始或后续 Child SA 协商中带上 SA_RESOURCE_INFO，接受这一模式的响应方也返回该通知。其可选数据最好能在同一选择器组内区分成员，但对端只能用于调试。

这个限制十分重要。若直接暴露 CPU 编号，攻击者可能据此推断哪些包落到哪些核；而且一端的“queue-7”对另一端不存在通用含义。它不是资源授权、调度指令、硬件身份证，也不能证明包真的经过了所指资源。

共同层应当只声明互操作所必需的最小事实：这些 SA 是同一政策下的并行成员。未来的资源选择继续留在本地，既避免协议绑死硬件，也避免一方把远端状态当作自己的控制面。

独立序列空间只是机制回执

RFC 4303 将 ESP 序列号与重放防护联系起来，RFC 6479 则说明接收窗口本身也有实现成本。RFC 9611 的性能价值来自多个合法的密码状态域，而不是假装一个共享状态无需协调。

标准列出过一个从单核约 5 Gbit/s 提升到 25 至 30 核约 40–60 Gbit/s 的案例。这是动机证据，不是任何产品的容量保证。处理器、NIC、算法、驱动、包长、流量组合和路径变化都会改变结果。

真正的测试应按 SA 记录双向包数与字节数，关联 CPU 或队列占用、完整性失败、重放丢弃、重排序、建立和 rekey 期间的损失，再以应用收到的吞吐与时延收尾。总带宽增长可能掩盖一个方向仍被串行化；均匀占核也可能把压力转移到重放窗口。

两个方向承担不同义务

资源较少的一端可以不安装永远不会使用的重复出站 SA，但必须安装已协商的全部入站 SA，因为它已经承诺接收对端经这些 SA 发送的流量。于是，同一份协商清单可以对应完全不同的双向安装图。

若端点自己产生受保护流量，入站与出站通常应当留在同一 CPU 上成对运行；网关面对非对称流量时可以分别移动。移动也不是免费动作：此前省略的出站半边可能需要重新创建 SAD 条目并取回已经准备销毁的密钥材料。

这些差异解释了为什么 SA 数量不能充当容量指标。计数没有告诉管理者哪一边已安装、哪一边会发包、密钥是否仍可用，以及调度是否真正选择了它。

按需建立会制造瞬时峰值

实现可以一次建完，也可由流量按需触发。在约一个往返的协商期间，一条所有 CPU 可用的通用 SA 可以继续承载包；把包转交给已有 SA 的 CPU 也能维持业务，但要付出性能成本。

两端可能同时触发新增 SA。起始包先走旧 SA，它的响应又在反方向触发建立。rekey 时，新旧集合暂时共存。因此，把上限机械地设成 CPU 数会阻塞正常过渡；RFC 9611 建议至少容纳 CPU 数的两倍。

达到某个 TSi/TSr 的上限时，应返回 TS_MAX_QUEUE。NO_ADDITIONAL_SAS 语义过宽，可能让对端误以为其他选择器也不能建立 SA。精确拒绝保留了未来选择。

删除不等于恢复

空闲资源对应的 SA 可以被删除。但若本地获取事件没有 CPU 或队列信息，系统之后可能不知道何时重建。立即重建会与持续删除它的对端形成循环；永不重建则可能让两端永久退化到第一条 SA。

RFC 2367 提供 SADB_ACQUIRE 的背景。RFC 9611 建议把资源标识加入本地触发路径。这个标识无需对外成为标准身份，只需让需求、资源与 IKE 守护进程重新接上。

功能更适合互相信任的高流量网关。大量 SA 会占用状态并拖慢 SAD 查询；在远程接入 VPN 中，低信任客户端还可能把它变成外部控制的状态放大器。因此标准不建议在远程接入中使用，也不建议默认开启。

来源