摘要

  • 2026 年 9 月 3 日，IESG 就《Segment Routing IPv6 Security Considerations》第 16 版启动最终征求意见，截止日期为 9 月 17 日，拟发布为 Informational RFC。这不是批准、正式发布或部署证明。
  • SRH 的存在与否都不能单独判定 SRv6 边界：SID 处理可以不带 SRH，带 SRH 的报文也可能只是过境。可信域必须由目的与源地址范围、入口和节点双层过滤、封装来源及实际硬件行为共同证明。

“可信域”很容易被理解成机房、专线或同一家公司。第 16 版把它定义为逻辑和运行结构：即使连接在同一物理网络上，主机没有纳入相关控制就不属于域内；同一管理实体名下的两个 SR 实例，也可能在彼此模型中仍是外部对象。

这一区分解释了为什么按 SRH 过滤会失败。SRH 很醒目，却不是 SID 处理的必备条件。一个 IPv6 目的地址就能代表单个 segment。反过来，含 SRH 的报文可能只是穿越当前网络，并不以这里的 SID 为终点。看到 SRH 就丢弃，会破坏合法互通；看不到就放行，又会漏掉真正指向内部行为的报文。

草案把控制点移到地址契约。第一层在入口：外部接口收到、且目的为域内 SID 的报文必须丢弃。第二层在每个实现 SID 的节点：目的为本地 SID、源却不在许可范围的报文也必须丢弃。入口配置错误时，节点控制仍可兜底；两层同时失效，就进入 fail-open，原本假设只能由内部攻击者实施的行为可能从外部触发。

地址规划于是成为安全输入。RFC 9602 分配的专用 SID 前缀可以缩短规则，使域边界更容易核对，但前缀本身不会执行任何保护，也不是唯一选择。使用其他前缀意味着要维护更复杂的清单、路由与例外，漏配或泄漏的概率随之上升。

在可信入口重新封装报文，可以让外层 IPv6 头和可选 SRH 由内部节点生成，而不是直接相信不受信接口提供的字段。这能改善来源边界，却不能取代过滤。错误放行的报文披上一层内部外壳，错误仍然存在。

SRH HMAC 提供的是另一种有限凭据。它覆盖 segment list、flags、Last Entry 和源地址，但它是可选机制，预共享密钥可能被人为复用，有效报文可在密钥生命周期内被重放，而且 Segments Left 不在覆盖范围。标签验证成功不等于新鲜、获准进入或最终路径安全。

中间设备面对的是动态目的地址。segment 逐步执行时，IPv6 头里的活跃目的会变化，最终目的可能要从 SRH 其他位置推导。不理解 SRv6 的防火墙可能把双向流量拆成两条无关连接，或把策略施加在错误端点上。统一封杀扩展头不能解决问题：域内丢弃 Routing Type 4 会破坏 SRv6，而无 SRH 的 SID 报文仍可能存在。

规则最后还要落到有限硬件。TCAM 与 ACL 空间常同 VLAN、路由表和 MAC 表共享，设备的解析深度也有限。控制器接受一份规则，并不证明芯片能在当前规模执行。资源耗尽时若默认放行，策略文件没有变化，可信域却已经打开。

按照 Heng Lu 的方法，应把文件状态、配置状态、转发状态和结果状态分别保存。IETF 征求意见只说明协调程序走到某一步；草案描述威胁和缓解；实际边界只能由已装载规则、计数器、抓包、探测和服务侧证据共同确认。

来源

  1. IESG 最终征求意见公告
  2. SRv6 安全草案第 16 版
  3. Datatracker 文件记录
  4. RFC 8402：Segment Routing 架构
  5. RFC 8754：SRH
  6. RFC 8986：SRv6 网络编程
  7. RFC 9602：SID 专用地址块
  8. RFC 9288：IPv6 扩展头过滤
  9. RFC 7872：扩展头丢包测量
  10. RFC 8200：IPv6
  11. RFC 9098：IPv6 扩展头安全
  12. RFC 9099：IPv6 运行安全
  13. RFC 9259：SRH 中的 OAM
  14. RFC 4381：可信域运行建议
  15. RFC 3552：安全考量写作原则
  16. Heng Lu：运行代码优先
  17. Heng Lu：最小初始规范
  18. Heng Lu：现实层次