摘要

  • LACNIC 7 月 28 日发布的文章以一条畸形 BGP Prefix-SID 属性为开场：属性代码为 40，事件发生于 2025 年 5 月 20 日，十秒内观测到超过 15 万（150,000）条更新。
  • 文中称 IOS-XR 与 SR OS 丢弃该属性，Junos 完整转发，EOS 重置会话，多个 IXP 的 route server 也继续传递了它。
  • RFC 8669 要求丢弃并记录畸形 Prefix-SID，但规范动作并不能自动证明生产路由器当时使用的版本、容错开关或继承后的邻居策略。
  • 可复核的公开记录应把同一份脱敏 UPDATE 字节与精确版本、生效配置、会话边界、处理动作、转发字节哈希及路由状态结果绑定起来。

一条消息，三种动作

LACNIC 在 7 月 28 日刊出了一篇讨论路由安全空白区的文章。它没有把所有风险都塞进前缀劫持或路由泄漏，而是从一个很具体的协议对象出发：2025 年 5 月 20 日，一条 BGP UPDATE 携带了损坏的 Prefix-SID 属性。Prefix-SID 是可选、可传递的路径属性，代码为 40。

文章描述了一条由不同实现组成的链。Cisco IOS-XR 与 Nokia SR OS 丢弃了畸形属性并继续工作；Junos 将消息原样向下游传递；接收它的 Arista 路由器重置了 BGP 会话；若干互联网交换中心的 route server 也未过滤该属性。文中还写道，十秒内全局路由系统出现超过 15 万条更新，Starlink、Disney、Zscaler、ByteDance 等网络的路由发生抖动；Arista 从 EOS 4.28.11 起改变了行为。

这段叙述最有价值的地方，是把边界划对了。一个前缀的来源可以获得有效授权，同时 UPDATE 里的另一个属性仍可能让后续解析器进入错误路径。RPKI 检查来源授权，不负责验证每个可选属性的内部编码。因此，这不是把一切都归为 “RPKI 失败” 的故事。

但厂商对照在最关键的位置提前结束了一步。Cisco、Nokia、Juniper、Arista 是产品家族，不是运行状态。只看名称，无法知道具体 parser、补丁级别、RFC 7606 容错是否启用，也不知道 peer-group 或模板继承后真正落到邻居上的配置。更无法判断那条会话是内部连接、客户、上游、对等互联，还是 IXP 的 route server。

规范动作不等于装机事实

RFC 8669 对畸形 Prefix-SID 的处理并不含糊。该属性由 TLV 组成；如果总长度不足、TLV 长度不合法，或某个 TLV 越过属性声明的边界，接收方必须丢弃该属性并记录错误。规范将这个结果对应到 RFC 7606 的 Attribute discard。

这提供了明确的合规基线，却不会自动生成全球设备清单。

Ben Cox 在事件发生后一周发表的分析保留了一个重要条件：IOS-XR 与 SR OS 在为 RFC 7606 的 BGP 容错完成配置的前提下，会过滤这条消息。LACNIC 的文章把它压缩成更利落的句子——两种平台执行了 RFC 7606 所要求的动作。两者未必矛盾；区别在于，前一句给运维人员留下了“配置”这个可验证变量。

这不是措辞挑错。技术新闻需要简洁，综述研究也需要统一术语，而一次跨越多个自治系统的真实事件通常不会附带完美实验记录。正确的补救不是把所有结论改写成含糊的“可能”，而是把条件补成一列。

当天的 NANOG 讨论说明了这列为何必要。讨论把 EOS 行为与 bug 899981 相连，并列出四个版本分支的修复点：4.28.11、4.29.8、4.30.6 和 4.31.2。参与者同时询问，这些改动面对当天的精确报文时是否一定产生更干净的结果。Arista 后来在 JANOG 57 的演示中再次呈现 IOS XR、SR OS、Junos 与 EOS 的对照，并写出相同的 bug 和版本。证据彼此呼应，却仍不是同一测试向量、同一方法、四个平台同步复现的记录。

15 万是速率，不是受害者数量

“超过 15 万”很抓眼球，因为它揭示了控制面的放大。但必须保留单位：源图展示的是特定 collector 以十秒为窗口计算的消息速率。它不是 15 万个独立前缀、会话、路由器、网络或中断。

被点名的网络也需要同样的边界。观察到与 Starlink、Disney、Zscaler 或 ByteDance 相关的路由抖动，并不能反推出每家机构部署了什么版本、是否都从相同邻居收到相同字节，也不能证明所有用户遭遇同类服务影响。分布式控制面留下的是观察痕迹，不是设备普查。

来源 AS 的动机亦未确定。文章自己承认，这类现象可能来自错误的重分发、重复执行的脚本或厂商缺陷。研究把它放进攻击分类，是为了建立威胁模型；这不等于证明本次事件由恶意行为触发。

把配置补进证据对象

LACNIC 不需要接管厂商软件或运营商网络，也能让这条研究更可操作。它可以发布一份带日期、可修订的符合性矩阵，使用同一份脱敏测试向量复现事件的关键字节。

每行应从 UPDATE 的不可变哈希与测试向量版本开始，记录代码 40、flags、声明长度和具体 TLV 错误。然后写平台、精确软件版本、修复标识，以及经过 group、template 和 neighbor 继承后真正生效的容错配置。

会话边界不能省略。内部 BGP、客户、上游、普通 peer 与 route server 可能适用不同策略。route server 也不是某个统一产品的代名词；不同 IXP 可以运行不同软件、过滤器和变更制度。

输出列要说明实际动作：会话重置、停用某个 AFI/SAFI、treat-as-withdraw、丢弃属性、接受，或其他由规范定义的处理。若消息继续发出，应公布脱敏后的转发字节哈希；若没有发出，则明确记录未转发。随后把动作与会话结果、Adj-RIB-In、Loc-RIB 和 FIB 的变化连接起来，只报告受控试验中的路由数量。

公开矩阵无需披露邻居 IP、客户名称、凭据、私有拓扑或完整生产配置。原始抓包可以受控保存；脱敏向量、方法版本、采集丢失状态、汇总结果、纠错历史和复测日期可以公开。

这样也能把责任重新放回各自的控制点。RFC 作者定义要求；厂商实现并修复 parser；运营商选择版本与策略；route server 运营者决定哪些属性穿过服务；LACNIC 的角色是保存清晰的区域性研究记录并提供复现方法，而不是替任何网络作路由决定。

现有证据没有说什么

没有来源证明 LACNIC 发出了这条 UPDATE、运行了受影响 route server，或有能力直接阻止事件。公开材料也没有给出完整会话数、受影响用户群或所有网络相同的中断时长，更没有证明任何厂商永远只会执行一种动作。

事件也不削弱 RPKI 在既定范围内的价值。来源验证回答“某个 AS 是否获准发布某个前缀”；畸形可选属性的 parser 安全属于另一个控制。若把两者混为一谈，反而会扩大中心化安全设施的想象权力，并掩盖本地软件和策略责任。

因此，新闻点不是密码学失效，而是 LACNIC 已经公开了一个非常适合做可复现实验的差异。文章给出了“丢弃、转发、重置”三个动词；下一份记录必须给出每个动词成立时的版本与配置。

来源