摘要

  • draft-ietf-spring-srv6-security-16 把信任域定义为实际执行 RFC 8402 边界过滤假设的 SR 域，并强调它是逻辑与运营结构，不是物理边界。
  • 同一行政实体名下可以存在多个彼此独立的 SR 实例。共同所有权、机房或骨干网名称，都不是共同信任的证据。
  • 规则误改或硬件能力不足可能令边界以放行方式失效；仅检查 SRH 也不够，因为 SID 处理可以没有 SRH，带 SRH 的报文也可能只是过境。
  • 运营方应保存信任域边界清单与执行回执，连接成员、范围、密钥、预期规则、已安装规则、容量和反向测试。这是 Daniel Kade 的编辑建议，不是 IETF 要求。

收购完成，不代表边界已经消失

设想两套独立建设的 SRv6 网络。它们各有自己的 SID 规划、控制器、密钥、运维权限和出入口规则。收购完成后，财务主体统一，品牌统一，网络架构图也被重新绘制。两套网络之间那道过滤规则突然显得不合时宜：既然都是“自己的网络”，为何还要把对方当外部来源？

问题恰恰藏在“自己的”三个字里。法律所有权可以在一个签约日切换，信任所需的控制不会自动跟随。第一套网络中有权插入路径指令的节点，未必在第二套网络中获得同样授权；两边使用的 SID 范围可能不同；一侧的硬件能承载完整过滤策略，另一侧却可能接近容量上限。

第 16 版《Segment Routing IPv6 Security Considerations》为此提供了清楚的边界。它沿用 RFC 8402 的前提：SR 默认在信任域内运行，并在域边界过滤流量。同时，它把信任域解释为一种逻辑和运营结构，而非物理边界。即使主机与服务器接在同一物理网络上，若没有明确纳入相应控制，也不属于该信任域。

草案还直接指出，同一行政实体之下可以有多个在逻辑或运营上彼此独立的 SR 实例。对它的威胁模型而言，来自另一个信任域的攻击仍按外部攻击处理。由此可见，运营方名称只是归属信息，不是安全凭证。

Last Call 不是网络认证

IESG 于 2026 年 9 月 3 日对第 16 版启动 Last Call，意见截止日为 9 月 17 日。截至 9 月 9 日研究截点，Datatracker 仍把它列为 SPRING 工作组的活跃 Internet-Draft，拟采用 Informational 状态；没有 telechat 日期，工作组状态还显示需要回应 WGLC 问题的修订稿。

这些流程坐标必须保留。9 月 17 日不是预定批准日，第 16 版也不是 RFC，更不是对任何运营商部署的合格证明。草案自己说明，它不定义新的安全协议或扩展。本文借用的是它对既有信任假设的澄清，不是把进行中的 IETF 讨论写成既成规范。

RFC 8402 的关键不只是一句“边界必须过滤”。它还假设，向报文加入段列表或 SRH 的节点有权这样做。这是一项实质权力：节点可以影响转发路径和处理。若成员范围仅因并购而扩大，获得该权力的主体也随之扩大，却没有相应授权记录。

因此，公司整合应触发技术重审，而不是自动扩大信任。只有当成员、地址、控制权和执行结果真的统一时，合并信任域才有事实基础。

信任不是标签，而是一组持续动作

第 16 版没有把“可信”当作静态属性。它提醒，信任域的所有边缘都依赖精确过滤。规则被错误删除或调整，就可能出现流入或流出泄漏。某些设备的表项容量、匹配复杂度或协议支持也可能不足，导致预想策略无法完整落地。

这就是放行式失效。原本被认为只有域内攻击者才能实施的行为，可能因为某个系统不再执行定义边界的规则，而从外部变得可行。

至少要区分三类证据。第一类是声明成员：哪些节点、来源、控制器和角色被允许进入。第二类是控制意图：入口、出口、SID 与源地址范围、封装点和例外如何定义。第三类是执行观察：设备实际安装了什么规则、还剩多少容量、计数器如何变化、反向测试是否真的被丢弃。

一次配置提交只能证明有人要求改变状态。成功响应也未必证明所有相关边缘已经安装规则，更不能证明规则在重启、升级或表项压力之后仍然有效。把意图记录当执行证明，会让“可信”变成不可审计的愿望。

并购环境更容易暴露这种差异。一边可能为 SID 预留清晰前缀，另一边采用更复杂的地址安排；一边在入口封装，另一边依赖不同控制；一套平台尚有规则空间，另一套平台的 ACL 或 TCAM 与 VLAN、路由表等功能争用。共同股东无法改变设备资源。

看到 SRH，不等于找到了边界

最直观的过滤方式是检查 SRH，但草案解释了为什么不能把它当唯一条件。SID 处理并不总是需要 SRH；反过来，带有 SRH 的报文也可能只是经过该域，并不以域内功能为目标。只按头部存在与否判断，既可能漏掉关键流量，也可能破坏合法过境。

更重要的是来源、目的地与范围之间的关系。外部报文进入时，如果目标是域内 SID，入口应将其丢弃；在启用 SRv6 的节点上，如果报文来自域外却指向本地实例化 SID，也应丢弃。两层过滤都失效时，域外主体才可能获得本应限于内部的位置。

这种控制依赖可识别的基础设施地址范围。RFC 9602 提供了专用 SRv6 SID 前缀。第 16 版指出，使用其他前缀会增加过滤复杂度，也会提高 SID 池路由泄漏与人为错误的可能性。它没有要求所有网络采用同一地址设计，但要求过滤必须理解本地设计。

入口封装是另一层措施。可信入口可以为报文添加新的外层 IPv6 头和 SRH，使域内转发不依赖不可信来源提供的字段；出口也可避免把内部段信息带出去。然而，封装只是补充，不能替代边界过滤。能够满足现有过滤条件的注入，仍需另外防范。

同一台设备也可以容纳两个密钥域

RFC 8754 定义了可选的 HMAC TLV，用来保护段列表和若干 SRH 字段。第 16 版提醒，预共享密钥由人工配置时，团队容易为了省事而复用密钥。它特别指出，不同信任域不应使用同一把密钥，即使这些信任域存在于同一节点上。

这句话把物理设备与逻辑信任彻底拆开。一台路由器可以承载两个权限边界不同的实例；共用机箱并不构成共用密钥的理由。

HMAC 的证明范围也有限。持有密钥的合法节点一旦被攻陷，在草案模型中仍是内部攻击者。没有密钥的域内主体，也可能在密钥有效期内重放此前截获的 SRH 与 HMAC。密码学可以证明特定字段与密钥关系，却不能独自回答某个主体是否有权安排某条路径。

若整合项目为了便利使用企业级统一密钥，验证成功会制造一种假象：既然报文都能通过密码检查，两边似乎已经是一个域。实际上，权限扩张可能从未被明确决定，日后分拆也会更加困难。

为真实边界建立可验证身份

运营方需要一份信任域边界清单，并在每次变更后生成执行回执。它不改变 SRv6，也不冒充 IETF 规范；它只是把经常被压缩为“内部”的多项事实重新拆开。

清单为每个域分配版本化标识，列出获准节点与角色、入口和出口、SID 与允许源范围、控制器权限、封装位置以及密钥域标识，但不公开密钥本身。跨域通道必须有责任人、理由和到期时间。

执行回执把获批意图与设备状态连接起来：各设备报告的已安装规则、可用容量、相关计数器、从域外发起的反向测试、从域内发起的允许测试，以及未解决例外。拓扑、软件、硬件、前缀、角色或密钥发生变化，旧回执便应失效或重做。

这样的记录不会宣称网络绝对安全。它能给出更窄、更诚实的结论：这个版本的信任域在这些边缘、这些设备和这些范围上，于这个时间接受过验证，尚有这些限制。

The Policy Mirror 要求人们寻找规则真正写入价值的位置。这里，规则分散在成员、地址、过滤、封装与密钥之中。Running-Code Primacy 要求它们在现实中共同执行。Reality, Not Advocacy 则约束结论：这份草案没有指控任何运营方，也没有解决跨域 SRv6；它只是清楚说明，共同所有权不能替代共同信任的证据。

来源