摘要

  • RFC 8955 不仅规定 FlowSpec 如何匹配流量和携带动作，还要求默认以最佳匹配的单播路由验证发起者；单播路径变化时，原有规则必须重新验证。
  • Susan Hares 是 RFC 8955 的共同作者，也是 IPv6 配套标准 RFC 8956 的编辑之一。后来放宽域内验证的 RFC 9117 由另一组作者完成，它授权的是本地管理域内的可信控制器，不是跨域的普遍过滤权。

当 BGP 更新开始携带动作

FlowSpec 的价值来自速度。遭遇 DDoS 时，运营者可以用一条 BGP 通告把精确规则分发到多个边缘设备，而不必逐台登录配置。规则能够组合目标或源前缀、协议、端口、ICMP 字段、TCP 标志、包长、DSCP 与分片条件；附带的扩展社区可以要求按字节或按包限速、采样、终止继续匹配、重定向，或改变流量标记。限速值为零时，效果就是丢弃。

这套语言也把错误的后果放大了。可达性路由主要改变下一跳，FlowSpec 规则则可能直接让合法业务消失，或者进入另一条路径、队列乃至 VPN 环境。语法正确只能证明设备看懂了请求，不能证明请求者有资格提出它。

Susan Hares 的IETF 官方档案记录了她长期参与标准工作的事实。本文聚焦其中一条明确的文件链：RFC 8955于 2020 年 12 月以 Standards Track 发布，署名 Christoph Loibl、Susan Hares、Robert Raszuk、Danny McPherson 与 Martin Bacher，并取代 RFC 5575 和 RFC 7674；RFC 8956为 IPv6 扩展，编辑为 Loibl、Raszuk 与 Hares。

这不是把 FlowSpec 归于一个人的发明故事。RFC 由共同作者、工作组审议、实现者和运营实践共同塑造。Hares 在这里的重要性，是公开记录能够把她放在“动作传播需要什么安全边界”的标准化链条上，而不是赋予她对技术或部署的个人所有权。

用已有路径约束新的权力

RFC 8955 先解决确定性：若多条规则都能命中一个包，设备需要按照规定的顺序决定哪条优先；如果一条匹配规则没有附带动作，默认是接受。可重复的排序避免两台路由器因本地习惯不同而执行相反结果。但排序仍然不回答授权问题。

默认验证借用了单播 BGP 已经表达的关系。包含目标前缀的 FlowSpec 规则，要与最佳匹配单播路由进行比对。规则发起者应与那条单播路由的发起者一致；如果另一个相邻 AS 宣告了更具体的单播前缀，原规则可能失去资格。对 EBGP 邻居，还要比较 FlowSpec 路径和单播路径最左侧的 AS。

这不是对善意的密码学证明，而是一条范围原则：某个邻居若本来就是前往目标的直接下一站，它收到流量后也有能力在自己网络里丢弃；让它请求上游更早限速或丢弃，可以节省受攻击链路的容量。规则的行动资格来自当前目的路径，而不是来自“它通过 BGP 发来”这一事实。

资格还会过期。RFC 8955 要求对应单播路由发生变化时重新验证 FlowSpec。如果最佳路径换了来源，或另一邻居出现更具体路由，昨天合理的过滤请求今天可能已经越界。自动化系统若只在接收瞬间检查一次，就把动态授权误做成了永久通行证。

中央控制器为什么需要一条窄例外

严格规则在域内控制场景会遇到矛盾。运营者可能部署一个中央路由控制器，由它统一下发缓解规则；这个控制器显然受本组织授权，却不一定处在每个目标前缀的最佳转发路径上。按原有路径测试，它恰恰会因为“不是转发节点”而失败。

RFC 9117在 2021 年 8 月更新了 RFC 8955 的验证过程。必须说清署名：该文作者是 Jeffrey Uttaro、Jorge Alcaide、Clarence Filsfils、David Smith 与 Pradosh Mohapatra，并非 Susan Hares。它之所以与本文有关，是因为它让 RFC 8955 之后的权限边界更清楚。

放宽只针对同一本地管理域。运营者可以显式信任自己的中央控制器，不再要求控制器出现在目标的最佳单播路径上。RFC 9117 也修订了路由服务器场景的 AS_PATH 处理，因为路由服务器分发路由却不承担普通转发角色。它没有授权任意远端控制器跨域发号施令，也没有取消接收网络的本地策略。

这里应当分开两种治理关系。“本组织批准这台控制器配置本组织设备”是一个域内决定；“另一个网络请求我改变去往某目标的流量处置”是跨域协调。前者可以由单一运营者建立信任清单，后者必须继续说明路径关系、允许动作与风险承担者。

规则进入硬件以后才算真的发生

RFC 8955 的安全章节提醒，放宽验证可能带来不想要的过滤、改标或重定向；重定向和标记还可能改变 VPN、转发路径与队列。损坏或遭控制的中央系统可以高速发送更新、耗尽平台规则容量，或者下发匹配范围远大于预期的规则。

接收者不能只依靠“valid”状态。边界策略应限制邻居能使用的动作子集、前缀与端口范围、最大规则数、限速值及重定向目标。控制平面接受路由，也不等于 ASIC、ACL 或 FIB 已经安装成功。反过来，规则真的进了硬件，也不等于它只命中了预期业务。

RFC 的发布更不能证明生产部署。标准说明互操作语义，不证明某厂商当前版本完整支持，也不证明某运营商开启了策略、所有设备行为一致，或者某次 DDoS 缓解成功。验证对象必须从文件回到运行中的网络。

最小共享语法，最大的本地责任

Lu Heng 在《Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption》中的框架，可以解释这套设计为何不必追求中央化授权。共享层保持最小：一致的匹配项、动作编码、规则排序，以及与单播路由相连的默认验证。接收网络保留后续决定：信任哪些会话、允许哪些动作、控制器的范围多大、容量上限多少、如何记录和撤销。

共同语法若被误当作共同控制权，协议就会越界；每家设备若又随意解释语法，协议便失去作用。可行的中间状态，是把互操作含义做窄，把实际后果留给本地可问责的策略。

《Running-Code Primacy》则把证据门槛推进到设备：检查规则是否通过验证、排序是否符合预期、是否安装进转发面、计数器命中了什么、动作产生了何种实际效果、撤销后是否恢复，并在单播路由变化时观察资格是否真的重算。这是 Sofia Ren 对两篇后续文章的分析运用，不代表 Hares 或 RFC 作者的表态。

一条强大的过滤规则只有能回答三个问题才值得信任：谁发起，它凭哪条当前路由事实取得资格，本网络的哪项策略允许它影响包。Hares 参与的标准记录之所以重要，正在于它让“能做什么”后面始终跟着“凭什么做”。

来源