2010 年 RIPE-Duke BGP 实验与路由问责测试

摘要

一个有效的可选传递 BGP 属性在受影响的 IOS XR 系统传播时遭到破坏，导致下游会话重置和更广泛的路由不稳定。
问责遵循不同的控制点：实验范围和监测、产品行为与修复、运营商连续性控制以及协议错误处理。

2010 年 8 月 27 日，负责运营路由信息服务（RIS）的 RIPE NCC 工作人员与 Duke University 的一个研究小组合作开展了一项实时边界网关协议（BGP）实验。研究人员正在研究一种安全路由设计，该设计在可选传递路径属性中携带认证信息。UTC 时间 08:41，RIPE NCC 通过 AMS-IX 和 GN-IX 的连接，从 RIS AS12654 宣告了 93.175.144.0/24。该路由按计划于 UTC 时间 09:08 撤回。[1]

这次宣告不同寻常，因为该属性在公共互联网上是全新的。然而，不同寻常并不意味着格式错误。RIPE NCC 和 Cisco 都将最初的属性描述为有效或符合标准的。[1][2] 这一区分决定了应如何分析该事件。实验并不仅仅表明路由器会拒绝无效输入。它表明，一个符合标准的输入可以通过形式检查，遇到已部署软件中的缺陷，在传播过程中遭到破坏，然后在其他位置触发严重的错误处理。

Cisco 报告称，受影响的 IOS XR 系统在转发该有效但未被识别的传递属性时处理不当。相邻路由器可能收到由此产生的损坏 UPDATE，并重置 BGP 对等会话。由于 BGP 会话承载许多路由，对一个有缺陷 UPDATE 的响应可能暂时移除无关的有效可达性信息。如果负责出口损坏的路由器没有检测到自身错误，它可能在会话恢复后再次宣告有问题的信息，使不稳定再次发生。[2][3]

RIPE NCC 的测量支持一个有边界但重要的影响结论。事件产生的更新速率最高达到周围基线的 20 倍。RIPE 估计，额外有 0.5% 的前缀在比正常更长时间内完全不可达。不稳定前缀占比峰值为 1.4%，代表近 4500 个前缀，约为事件周围观测到的通常水平的 9 倍。结果因采集器和位置而异，Vienna 采集器的更新活动尤其剧烈。[1]

这些数字很重要，但不能据此声称已知比例的用户、路由器、网络或流量消失了。控制平面观测统计的是路由行为，而不是人。RIPE 的 DNSMON 分析未发现根服务器故障。它确实发现部分被监测域名的查询丢失有限，且.si 和.fr 权威基础设施的部分区域出现更明显的问题，而冗余服务器继续应答。[1] 当时的运营商评论提到了访问问题和交换流量变化，但这些报告不能构成完整的量化记录。[4][6]

因此，问责的教训比某个行为者“搞垮互联网”的故事更窄，也更有用。RIPE NCC 控制着其测量基础设施是否宣告互联网可见的实验路由，以及时间、通知、监测和撤回。Duke 研究人员控制研究设计和研究侧实现。Cisco 控制着 IOS XR 对未识别有效属性的处理、产品测试、披露和维护修复。网络运营商控制其安装的软件、路由策略、对等保护、监测以及自身网络内的恢复。当时的协议规则提供了一种放大机制，允许一个格式错误的 UPDATE 导致会话级故障。

修复也分属不同层面。Cisco 在事件当天发布了通告，并准备了维护升级。[2] RIPE NCC 保留了证据，向厂商提供了信息，发布了分析报告，并承诺对未来的合作实验采取更严格的控制。[1] 其执行委员会随后支持继续研究，同时强调适当的沟通。[5] 产品更正降低了实现风险；更强的实验治理降低了不必要地通过广泛的公共故障域发现未知交互的风险。

后来的标准有助于解释行业如何从这类故障中学习，但不能作为 2010 年 8 月已部署或要求内容的证明。RFC 7606 后来倡导更窄地处理格式错误的 BGP UPDATE，因为重置整个会话可能丢弃许多有效路由。[13] 关于明确外部策略、路由泄漏预防、源验证、RPKI 和 BGPsec 的运营建议阐明了相邻的控制措施，但没有一个能追溯性地确立过失，也没有一个能单独纠正此事件所暴露的精确出口损坏缺陷。[14][15][16][17][18][19][20]

核心结论是克制的：一个有效的实验性宣告触发了一个链条，其中实现缺陷破坏了信息，会话级错误处理放大了这种损坏，而对实时实验的控制边界不足使该交互暴露在公共互联网上。问责遵循控制权的分配，而不是第一个可见触发因素的简单性。

1. 为什么此事件需要窄口径分析

BGP 事件常被压缩为泄漏、劫持、中断或配置错误等标签。当证据符合这些标签时，它们可能有用，但也可能抹去真正重要的机制。此事件需要更精确的边界。

本文主题仅为 2010 年 8 月 27 日的 RIPE NCC–Duke University 实验，不涉及后来的路由泄漏、后来的劫持或每一次后续的 BGP 故障。RFC 7908 后来提出的路由泄漏分类法有助于区分类别，但不能在没有证据表明指定泄漏条件发生的情况下，将本实验重新标记为常规路由泄漏。[16]

实验故意构造了一条携带新的可选传递属性的路由。其公开可见性是有意的，产生的不稳定却不是。这种组合产生了三个不应合并的问题：

最初的 BGP UPDATE 是否有效？
哪个组件将有效信息变成了损坏信息？
哪些控制使由此产生的故障超出了严格受限的测试范围？

现有记录对前两个问题的回答置信度相对较高。RIPE NCC 和 Cisco 都将原始属性描述为有效或符合标准，而 Cisco 认定 IOS XR 存在传播过程中损坏信息的漏洞。[1][2] NVD 将该产品问题记录为 CVE-2010-3035。[3]

第三个问题是分布式的。研究人员无法控制每一台已部署的路由器。Cisco 没有决定由 RIS 宣告实验路由。单个运营商既未设计实验，也未设计受影响实现。互联网交换连接的存在本身并不能证明其中携带的每个属性都获得了批准。因此，归因必须遵循实际的控制点。

此事件重要，因为它打破了那个容易但不安全的假设：源头的标准符合性足以在异构路由系统中确立运行安全。符合性是必要的，但已部署行为决定了一个数据包或 UPDATE 能否在与运行代码的接触中幸存。实验通过了一类有效性边界，却在另一类边界上失败。

RIS 的存在本身就是为了从多个观测点收集并公开路由信息。[7][8] RIPEstat 和 RIPE Database 记录为 AS12654 提供了识别上下文，但自治系统记录无法揭示传播路径上遇到的每一种软件行为。[9][10] 像 RIS 和 Route Views 这样的路由采集器系统之所以有价值，恰恰是因为没有任何单一注册记录、对等声明或本地日志能描述整个域间路由系统。[11]

教训不是标准无关紧要，而是标准描述的是要求的行为，而问责需要证据证明实现、部署和运营控制在真实条件下确实产生了该行为。

2. 时间线：从计划宣告到意外扰动

08:41 UTC 之前：设计与宣告前检查

Duke 研究小组正在研究一种安全路由设计，其中认证信息将携带在可选传递 BGP 路径属性中。Duke 在研究工作中提供了修改过的 Quagga 实现。宣告前检查确定该属性具有可接受的协议形式，并且第二个 Quagga 实例未重现后来在受影响已部署设备中观察到的行为。[1]

该结果有参考价值但不完整。它表明初始实现和一个相似的接收环境能够处理该属性，但并不表明公共互联网上的每一个路由器系列、软件版本或转发路径都能正确保留该属性。

这就是关键的检测缺口。测试路径评估了形式结构和有限的实现行为，但没有重现传递属性可能经过的异构已安装基础。最重要的是，它没有暴露一个缺陷：路由器接受一个有效的未知属性，却在转发时将其损坏。

公共记录没有确立完整的批准过程、每一项被考虑的风险或事件前讨论过的每一项控制。因此，编造一个没有记录的决策过程是不合适的。可以确定的是，宣告前所使用的控制未能检测到产生公共扰动的交互。

08:41 UTC：路由变得可见

2010 年 8 月 27 日 UTC 时间 08:41，RIS AS12654 开始宣告 93.175.144.0/24，并携带实验性可选传递属性。该宣告经由 RIPE NCC 在 AMS-IX 和 GN-IX 的连接传播。[1]

这一刻是触发事件。然而，“触发”并不等于“根本原因”。触发是激活潜在条件的事件。如果一个有效输入遇到了有缺陷的实现，有效输入启动观察到的序列，但缺陷解释的是序列为何偏离指定行为。

路由的公开可见性也造成了实验治理暴露。在封闭或紧密受限系统上测试可以发现缺陷，而不会让缺陷穿越大量自治网络。一旦路由进入普通域间传播，结果就取决于发起方无法直接控制的软件和策略。

传播期间：有效信息遭到损坏

受影响的 IOS XR 系统收到了它们无法识别的属性。在 BGP 的可选传递设计下，无法识别本身并不是拒绝该属性的理由。相关行为应是保留并传播它。

Cisco 的说明指出了该传播路径上的一个故障：受影响系统在向邻居发送时损坏了原本有效的属性。[2] 现有证据不支持为每条受影响路径凭空编造精确的字节级变异。可靠发现是功能性的：有效的陌生信息进入受影响实现，损坏信息在传播时出现。

这一区分比说路由器仅仅“不支持”实验特性更准确地定位了产品缺陷。可选传递性的存在，就是为了让路由器无需理解完整语义即可携带属性。符合规范的实现无需对认证信息采取行动，但如果传播该属性，就必须正确保留它。

随后损坏跨越了实现边界。下游邻居收到的 UPDATE 已不再等同于实验宣告的那个有效 UPDATE。

下游接收：一个 UPDATE 威胁整个会话

在当时的错误处理规则关联的标准基线下，格式错误的路径属性可能引发 UPDATE Message Error 并关闭 BGP 会话。[12] 这种响应从设计上就很严厉：无法安全解释路由信息的路由器通过终止会话来保护自己。

运营副作用很广。BGP 会话通常承载许多路由，而不仅是实验前缀。关闭会话可能因此撤回从该对等体学到的无关有效路由。网络随后会寻找替代路径、交换新 UPDATE 并重新收敛。

进一步的重复机制也是可能的。损坏出站属性的路由器不一定能识别自己就是损坏源。邻近会话恢复后，同一路由可能再次被宣告。同样的损坏可能再次发生，下游系统可能再次重置，路由不稳定可能重新出现。[2]

因此，故障链比实验前缀更大：

一个有效但陌生的属性进入受影响路由器。
路由器在向前传播时损坏了它。
邻居收到了格式错误的 UPDATE。
邻居可能终止 BGP 会话。
与实验无关的路由可能从该邻接关系中消失。
重新收敛产生更大更新量。
重复宣告可能重复该序列。

这就是事件变成问责测试而非单纯互操作好奇的原因。每个阶段都由不同组件或组织控制。

09:08 UTC：计划撤回

RIPE NCC 按计划于 UTC 时间 09:08 撤回了实验宣告。[1] 因此该路由的宣告时间约为 27 分钟。

撤回是必要的，但撤回并不是瞬间橡皮擦。BGP 是分布式的。已经接受或传播的更新必须经过其他会话，同时路由器重新计算路径并恢复邻接关系。计划撤回可以停止发起点的继续宣告，但无法立即取消每一个副本、排队更新、重置或已经进行的重新收敛过程。

RIPE 将意外运营影响描述为持续约 30 分钟。大多数不稳定在实验后约 20 分钟回归正常，而不是在撤回的精确时刻结束。[1] 这些描述应被视为测量得到的运营区间，不应被转换为所有受影响路径同时恢复的断言。

撤回之后：运营商响应与证据收集

运营商从各自网络观察并响应。当时的邮件列表讨论包括访问问题、路由变化和交换流量影响的报告。[4][6] 这些评论是扰动在运营上可见的有用证据，但有严格限制。它们无法列出每一个受影响的自治系统，无法跨地点归一化观测，也无法提供完整丢失流量计数。

RIPE NCC 保留了实验数据，并向 Cisco 提供了收集到的证据。这种保留之所以重要，是因为事件跨越了组织边界。仅凭发起侧的日志能显示 RIS 发送了什么，但不一定能显示中间实现发出了什么。仅凭厂商报告能解释缺陷，但无法量化全互联网范围的观测。可信的重建需要来自多个控制域的证据。

22:00 UTC：Cisco 的通告

Cisco 于 2010 年 8 月 27 日 UTC 时间 22:00 发布了 IOS XR 通告。[2] 该问题被记录为 CVE-2010-3035，Cisco 准备了软件维护升级。[3]

当天的通告确立了公开的产品层面响应。但通告本身不能证明每个受影响运营商安装了哪个版本、有多少设备遇到了该路由，或每个运营商都有立即可用的缓解措施。这些在有界记录中仍属未知。

8 月 31 日及之后：公开分析与治理响应

RIPE NCC 于 2010 年 8 月 31 日发布了事故与测量分析。[1] 说明描述了实验、实现交互、观察到的路由影响、DNSMON 发现以及未来合作实验的可能变化。

RIPE NCC 称未来实验将受到更严格处理，包括全面影响评估、向运营商充分提前通知以及负责任的漏洞处理。[1] 其执行委员会随后支持继续实验，同时强调适当沟通。[5]

这一响应并未否认研究的价值。它承认有用的研究目标不能消除限制运营暴露的必要性。因此治理修复不是“停止实验”，而是使发起公开实验的权限以更清晰的风险、通知、遏制和响应控制为条件。

3. 什么是可选传递属性——以及为什么“未知”不等于“无效”

BGP 路径属性携带与路由关联的信息。有些属性是公认的，预期 BGP 实现能够理解。另一些是可选的。另一个区分涉及传递性：即使中间实现不理解属性含义，该属性是否应继续跨 BGP 发言者传递。

RFC 4271 定义了相关行为。未被识别的可选非传递属性无需转发。未被识别的可选传递属性则不同。它被接受并传递给其他 BGP 对等体，同时使用 Partial 位指示中间系统未完全识别该属性。[12]

该机制支持扩展。没有它，路径上的每个自治系统都需要同时具备软件支持，新的传递特性才能跨越互联网。可选传递性允许增量部署：路由器可以传输信息而不解释信息。

这种设计产生了严格的实现责任。不理解可选传递属性的路由器仍必须安全处理其表示。实际而言，它不得将有效的透明信息变成格式错误信息。

四个概念必须保持分离：

识别。路由器理解属性的语义吗？

接受。属性是否具有路由器能够根据协议规则安全接收的形式？

传播。路由器必须或可以继续传递该属性吗？

变异。路由器会修改属性吗？如果会，该修改是否被允许且正确编码？

2010 年事件不要求受影响的 IOS XR 系统理解研究认证方案。缺陷在于传播。Cisco 的说明是受影响系统在向前发送时损坏了有效但未被识别的传递属性。[2]

这就解释了为什么第二个 Quagga 实例不足以预测事故。两个实现可以在属性形式上达成一致，而第三个实现在不同代码路径中存在缺陷。接收、存储和序列化未知属性可能涉及不同操作。入口通过一致性检查不能证明出口行为正确。

事件还展示了语法有效性与端到端运营安全之间的区别。初始 UPDATE 在源头可能有效。中间系统随后可能生成无效表示。下游系统可以依据可用规则正确响应，却仍然通过关闭整个会话造成破坏性运营后果。

没有任何单层能单独解释影响：

实验提供了陌生输入。
受影响产品提供了损坏。
下游错误响应导致了会话丢失。
BGP 重新收敛提供了更新放大。
公开传播提供了故障域。

称原始属性为格式错误会抹去产品缺陷，除非数据包证据证明相反。称整个事件只是产品缺陷会抹去在实时互联网上暴露不确定交互的决策。称其只是严苛的协议响应会抹去生成格式错误下游 UPDATE 的实现。

准确的描述是拥有不同控制所有者的链式故障。

4. 从一个损坏 UPDATE 到更广泛的路由不稳定

BGP 在自治系统之间分发可达性。当对等会话关闭时，仅通过或优先通过该会话学到的路由可能从本地路由表中撤回。路由器可能选择替代路径并向其他对等体宣告这些变化。这些对等体接着重复自己的选择过程。

这意味着附着在一条路由上的错误，如果响应移除整个邻接关系，就可能造成涉及多条路由的变化。实验前缀无需成为受影响用户寻求的目的地。一次重置就可能扰乱同一会话上承载的其他可达性。

事件的更新量与此放大机制一致。RIPE 观测到更新速率最高达到周围基线的 20 倍。[1] 这是控制平面测量：路由器正在交换明显更多的路由变化。它不直接说明损失了多少应用流量，但确实表明扰动超出了对单个前缀的一次平静拒绝。

会话恢复也可能造成复发。如果上游受影响路由器保留该路由，并在会话恢复后重复其有缺陷的传播，邻居可能再次遇到格式错误的 UPDATE。由此产生的循环将组合：

会话建立；
路由宣告；
传播过程中的损坏；
格式错误 UPDATE 接收；
会话关闭；
路由撤回和重新收敛；以及
再次建立。

并非每个对等体或路径都必然经历每一步。证据支持一个可能重复的机制以及观测到的不稳定升高；它不提供每个自治系统的完整逐包记录。

在评估影响时这一区分很重要。路由采集器在其观测点看到宣告和撤回，但看不到每一个转发决定、每一个用户会话或每一个被丢弃的数据包。不同采集器看到路由系统的不同切片。Vienna 采集器上特别剧烈的活动说明影响并不均匀。[1]

不均匀并不是测量的缺陷，而是互联网拓扑和策略的属性。自治系统在本地选择路由。它们有不同的对等方、软件、过滤器和替代路径。一个有缺陷的宣告可以通过一条路径、在另一条路径被阻断、在第三条路径上从未被选中。

因此，正确的分析动作不是将一个采集器的峰值外推到整个互联网，而是合并采集器、描述分布并保留推断限度。

5. 有界影响：证据支持什么

RIPE 的测量提供了三个主要指标。

第一，路由更新速率最高达到周围基线的 20 倍。[1] 这表明事件窗口内存在异常的控制平面活动。“最高达到”很重要：它描述的是峰值，而不是每个采集器或整个时段都保持的均匀速率。

第二，RIPE 估计额外有 0.5% 的前缀在比正常更长时间内完全不可达。[1] 这是前缀级可见性度量。不应将其换算为 0.5% 的用户、流量、路由器或经济活动。前缀在大小、用途和流量上差异很大，而且路由采集器无法观测每条转发路径。

第三，不稳定前缀占比峰值为 1.4%。RIPE 将该峰值与近 4500 个前缀关联，约为通常水平的 9 倍。[1] “不稳定”并不等于“普遍不可达”。前缀可能经历反复的路径变化，而在某些地方仍然可达。

这些发现支持结论：事件造成了重要、可测量且分布式的路由不稳定。它们不支持“1.4% 的互联网完全离线”的断言。

当时的简略说法是事件影响了约 1% 的互联网，这可能捕捉到了某些测量的数量级，但不如 RIPE 的三个独立指标精确。它不应替代这些指标。证据区分了额外完全不可达、观测到的不稳定和更新量。

地理与采集器差异

影响因地点和采集器而异。Vienna 采集器显示特别高的更新活动。[1] 差异可以反映拓扑、对等选择、对受影响实现的暴露程度以及备用路径的可用性。

采集器所在地并不是该城市或国家用户影响的直接映射。BGP 观测点从参与对等方接收路由。它们的视图可能包含服务于远程网络的路径，而本地用户可能沿采采器不可见的路径传输。采集器证据对路由行为很有力，对分配受影响人群的地理计数则较弱。

DNS 观测

RIPE 使用 DNSMON 检查路由扰动是否产生可见的 DNS 影响。它未发现根服务器系统故障。[1] 这一否定性发现很重要，因为广泛的路由不稳定并不自动意味着每个关键服务都失败。

分析确实发现部分被监测域名的查询丢失有限，且.si 和.fr 权威基础设施的部分区域出现更明显的困难。冗余服务器继续应答。[1] 因此证据支持部分且不均匀的 DNS 影响，而非普遍 DNS 故障。

冗余服务器的持续可用也提醒我们，路由问责包括服务架构。路由扰动可以通过一条权威服务器路径到达一个组件，而另一个仍然可达。冗余不能消除路由缺陷，但能防止组件故障变成完整服务故障。

运营商报告

当时的运营论坛记录了访问中断、路由反应和流量变化的报告。[4][6] 这些报告有助于确立事故在发起机构之外可见。它们也可以识别进一步调查的问题。

它们不能替代归一化测量。某个交换点或运营商的流量下降可能反映重新路由、损失、预防性策略变化或其他本地响应。没有匹配的基线、拓扑和流量记录，无法将其转换为全互联网影响数字。

证据不支持的断言

有界记录不能确立：

受影响 IOS XR 版本在当时已部署的完整清单；
受影响路由器或设备的确切数量；
每个重置会话的自治系统；
受影响用户的确切数量；
丢失的应用流量总量；
实验前缀的普遍故障；
DNS 根故障；
RIPE NCC、Duke、Cisco 或运营商的恶意意图；
事件前每项批准的完整记录；
事件前每个运营商都有可用缓解措施；或
法律责任。

这些不是次要免责声明。它们定义了基于证据的基础设施报道与无支撑乘法构建的中断故事之间的区别。

6. 通过控制分配实现问责

当问责追问谁控制了每项重要决策、实现和恢复行动时，它最强。当其把接近第一个可见事件当作唯一责任的证据时，它变弱。

控制域	参与者控制了什么	参与者未控制什么	更强评估所需证据
RIPE NCC	RIS 基础设施的使用、互联网可见的宣告、时间、沟通、监测、撤回、证据保留以及未来实验政策	每一台外部路由器的软件行为以及每个运营商的恢复	批准记录、风险评估、通知计划、监测阈值、撤回标准和保留的观测
Duke 研究人员	研究设计、实验属性构造、研究侧 Quagga 修改和研究侧测试	已部署 IOS XR 代码、下游会话策略以及运营商软件部署	测试向量、生成的 UPDATE 字节、研究实现记录以及互操作测试范围
Cisco	IOS XR 解析、存储和传播行为；产品测试覆盖；披露；维护修复	发起实验的决定以及运营商安装时间表	缺陷分析、受影响版本矩阵、回归结果、修复代码证据和部署指南
网络运营商	已安装软件、维护、导入和导出策略、对等控制、过滤、监测及其网络内的恢复	实验设计、上游厂商代码以及完整全球传播路径	设备日志、数据包捕获、配置、软件版本、会话历史和恢复记录
下游 BGP 实现	依据其实现的规则对格式错误 UPDATE 的本地处理	原始有效属性的创建或上游损坏	UPDATE 错误日志、会话通知以及支持更窄处理时的证据
互联网交换中心	参与网络交换路由所用的连通性	默认情况下，每个参与者 BGP 宣告的内容和正确性	在分配更多控制之前任何具体路由服务器、过滤或运营角色的证据

RIPE NCC 的控制

RIPE NCC 控制了将实验路由引入公开传播的行为。RIS AS12654 是测试所用源，宣告经由 RIPE NCC 在 AMS-IX 和 GN-IX 的连接传播。[1] RIPE NCC 还控制了计划撤回、证据收集以及未来类似合作研究的规则。

该控制确立了实验治理问责。它并不确立 RIPE NCC 制造了产品缺陷。初始属性被描述为有效。对 RIPE NCC 而言，相关问题不是它是否应该确定地预测出那个未被记录的精确故障，而是实验的不确定性是否被评估、沟通、监测和遏制到与其可能的公共影响范围成比例。

随后承诺更全面的影响评估、向运营商提前通知以及负责任的漏洞处理，表明 RIPE NCC 自己识别出了治理改进。[1] 执行委员会支持在适当沟通下继续实验，则强化了研究合法性与运营控制充分性之间的区分。[5]

Duke 的控制

Duke 研究人员控制了安全路由研究设计，并在其范围内提供 Quagga 修改。他们的工作帮助创造了实验输入。现有记录并未显示他们控制 IOS XR 的内部处理或下游路由器的错误响应。

研究侧问责涉及设计假设和互操作测试的广度。第二个 Quagga 实例可以展示相似软件环境中的行为，但无法确立在所有相关已部署实现中的安全性。

公开证据未揭示 Duke 与 RIPE NCC 之间事件前决定的完整划分。凭空编造这种划分是不合适的。任何更细粒度的分配都需要实验计划、测试记录和通信，以识别谁批准了公开传播条件。

Cisco 的控制

Cisco 控制了受影响的 IOS XR 实现。其通告指出在传播期间有效但未被识别的传递属性遭到破坏。[2] 该行为属于产品控制域：解析、保留、序列化、属性标志处理和回归测试。

Cisco 还控制了披露和维护响应。通告在事故当天出现，并准备了软件维护升级。[2] CVE-2010-3035 提供公开漏洞标识符。[3]

产品问责仍应基于证据。记录未确立所有已部署版本、受影响设备数量，或缺陷是否早期已被发现。更强评估需要版本特定测试、缺陷历史和安装证据。

运营商的控制

每个网络运营商控制系统的本地部分：软件选择和安装、维护时间、对等策略、过滤器、监测、会话保护和恢复。这些控制可能影响暴露和恢复。

这并不使运营商有责任预测未知的厂商损坏缺陷，也不表明每个运营商在实验前都有可用补丁或配置缓解。运营商问责以相关时间可知且可控的内容为条件。

披露之后，持续保证所需的证据发生变化。可以要求运营商识别受影响版本、应用修复、测试行为并保留证明。披露之前，声称不合理的无所作为需要证据表明风险和可行缓解已经已知。

为何不应将编造的角色分配给交换中心

实验使用了 AMS-IX 和 GN-IX 的连接。[1] 该事实确立了一条传播路径。它并未在无额外证据的情况下确立任一交换中心设计了实验、批准了该属性、运营了受影响路由器或控制了参与者导出策略。

基础设施报道常将物理或逻辑传输与决策权混淆。命名交换中心可以是路由路径的一部分，却并非宣告、损坏或接受 UPDATE 的行为者。问责不应仅从拓扑推断。

7. 产品修复与实验治理修复不同

完整响应需要两条修复路径。

产品修复

产品缺陷是受影响的 IOS XR 系统在传播期间破坏有效但未被识别的传递属性。直接修复属于软件及其测试。

可信的产品修复应证明：

有效未知可选传递属性可以被接收；
它被存储而不发生破坏性变异；
它以协议要求的形式被传播；
相关属性标志和长度字段保持一致；
重复会话建立不会重新产生损坏；
格式错误变体依据支持的错误处理行为被遏制；
回归测试覆盖识别和透明传播两种路径；以及
修正版本可被运营商识别。

Cisco 的通告和维护升级是应对该层面的即时公开行动。[2] 通告传达缺陷；升级改变实现。两者相关但不可互换。

验证还需要部署证据。厂商可以证明修正版本通过回归测试，运营商可以证明某台路由器正在运行哪个版本。单独一份记录不能同时确立产品修正和现场采用。

实验治理修复

治理缺陷不是研究发生了，而是一种不确定交互通过公共路由基础设施测试时，控制不足以阻止或迅速限制观测到的影响半径。

RIPE NCC 的响应确定了更严格未来要求：全面影响评估、为运营商提供足够提前通知、负责任的漏洞处理。[1] 这些针对实验前和实验期间的决策。

可信的治理修复将包括：

明确有边界的技术目标；
识别即将宣告的每一个属性和路由；
记录传播边界或解释为何需要更广泛传播；
与风险匹配的异构实现测试；
在可行时向受影响运营商提前沟通；
定义的测试窗口；
实时路由采集器观测；
相关时数据平面或服务探测；
量化停止标准；
能够立即撤回的授权人员；
演练过的撤回流程；
联系厂商的标准；
保留实验前和实验后的数据；以及
发生意外外部影响时发布公开事故说明。

治理控制无法保证未知缺陷永不出现。其目的是降低发现产生失控外部后果的概率，并缩短检测到遏制之间的时间。

为何一种修复不能替代另一种

如果 Cisco 修正了 IOS XR，但实验控制不变，后续实验可能暴露另一个实现中不同的未知缺陷。具体产品风险会下降，而发现风险仍然存在。

如果 RIPE NCC 加强了实验控制，但受影响软件仍未修正，普通互联网流量携带另一个有效陌生传递属性仍可能遇到潜在缺陷。公共测试风险会下降，而产品风险仍然存在。

因此此事件需要两个独立的闭环问题：

实现缺陷是否在相关位置被修正并部署？
未来实时实验是否有边界、可观测且以匹配其不确定性的方式治理？

只回答一个的报告没有证明完整修复。

8. 后续标准作为分析背景——而非追溯判断

2010 年 8 月之后发布的标准有助于描述更好的遏制和策略实践。它们不能证明这些实践在事件期间已经部署，也不能追溯性地将后续建议转化为过失认定。

RFC 4271：历史基线

RFC 4271 描述 BGP-4，包括可选传递属性和错误处理。[12] 其传播规则解释了为什么未识别的传递属性应被继续携带。其 UPDATE 错误处理也有助于解释为什么格式错误的属性会导致会话终止。

这种组合产生了危险交互。可扩展性依赖安全的透明传播，而格式错误输入可能触发广泛响应。当中间实现损坏透明信息时，下游系统面临的错误条件后果比单条路由更大。

RFC 7606：缩小故障域

RFC 7606 后来修订了 BGP UPDATE 错误处理，因为会话重置可能丢弃大量有效路由并导致重大路由中断。[13] 它通常推行更窄的响应，包括在定义情况下将受影响路由视为撤回，而不是自动摧毁整个会话。

作为分析背景，这展示了故障域如何被缩小。如果格式错误宣告可以被遏制到受影响路由，而会话和无关路由继续存在，一个损坏属性破坏邻接关系的能力就更小。

说 RFC 7606 是 2010 年事件的规则是不准确的。它发布得更晚。假设每个当前实现都统一应用每项建议也是不准确的。RFC 说明的是架构修复方向；部署证据仍然是必需的。

RFC 7454 和 RFC 8212：明确外部策略

RFC 7454 汇集了 BGP 运营安全建议，RFC 8212 确立了对外部 BGP 宣告和接受的明确策略预期。[14][15] 两者共同强化一个基本控制原则：外部路由不应只因会话存在就被交换。

明确的导入和导出策略可以降低意外传播，并使预期关系可审计。在有界实验中，仔细划定范围的策略有助于限制哪些对等方收到测试路由。

这些措施不能直接纠正必须传播属性却将其损坏的路由器。它们作用于策略边界，而非有缺陷的序列化路径内部。它们可能降低暴露，但前提是路由或会话能够被区分和限制，且不违背实验的合法目标。

RFC 7908：路由泄漏分类法

RFC 7908 描述了路由泄漏类型。[16] 在此其主要用途是作为防止松散术语的边界。2010 年事件涉及故意宣告的实验路由，以及影响可选传递属性的实现缺陷。现有证据不应被拉伸以将事件放入后来的泄漏类别，除非其条件吻合。

当分类法防止无关机制被合并时，它支持问责。当熟悉标签替代因果分析时，它破坏问责。

RPKI 源验证

RFC 6480 描述资源公钥基础设施架构，RFC 6811 定义 BGP 前缀源验证。[17][18] 源验证询问源自治系统是否被相关路由源授权授权宣告某前缀。

该控制解决的问题与此处暴露的不同。一条路由可以具有可接受的源关系，同时携带后来被中间产品损坏的属性。源验证不能证明每个路径属性都正确编码或保留。

无需就实验当时的 RPKI 实际状态得出结论。分析点有限：源验证本身无法测试受影响的出口处理路径。

BGPsec

RFC 8205 规定 BGPsec 路径验证。[19] BGPsec 处理定义架构中路径信息的密码保护。它与 Duke 小组研究的安全路由更广泛目标相关，但不是 2010 年实验期间部署了什么内容的证据。

也不应将其表述为每个实现缺陷的自动修正。安全机制本身由软件实现。安全解析、序列化、故障遏制和互操作测试仍然是必要的。

NIST 路由安全指南

NIST SP 800-189 提供后来的域间流量交换安全指南，包括路由保护和运营实践。[20] 它有助于构建当下围绕过滤、监测、验证和响应的预期。

它不确立 2010 年的法律义务，也不证明任何参与者当时所知内容。其正确用途是前瞻性的：询问网络现在应保留哪些证据，哪些控制可以降低类似故障链。

9. 反事实：改变哪个事实会减少影响？

反事实分析只有当每个场景改变一个定义条件而保留其余证据时才有用。它不能证明什么必然发生，但可以识别高价值控制。

反事实 1：IOS XR 正确保留属性

改变一个事实：受影响的 IOS XR 系统收到有效但未被识别的传递属性，并在不损坏的情况下传播它。

来自该产品路径的下游格式错误 UPDATE 不会出现。归因于损坏 UPDATE 的会话重置机制因此不会被此缺陷激活。宣告仍然不寻常且实验性，但记录在案的故障链在其主要实现点被打断。

这是最强的产品反事实，因为它移除了已识别的损坏机制。它不能证明其他实现不会出现不良反应。

反事实 2：异构测试复现已部署行为

改变一个事实：公开前测试包括足够代表性的受影响实现，并触发出站损坏。

缺陷可以在路由进入广泛公开传播之前被调查。Cisco 可以收到测试用例，而 RIPE NCC 和 Duke 可以决定推迟、约束或重新设计实验。

局限是代表性。任何实验室都无法复现每条互联网路径。价值在于超越两个相似 Quagga 端点，并对不同实现专门测试透明接收与传播行为。

反事实 3：实验在有界路由环境内进行

改变一个事实：同一属性和受影响软件在封闭或严格控制测试环境中交互，而非跨普通公开传播。

缺陷仍可能重置会话，但暴露的无关路由和外部网络数量可以受限。每一跳的证据都可以捕获。

局限是真实性。有界环境可能无法复现公共互联网上的拓扑、策略或软件组合。这就是为什么分阶段升级更好：从有界多样性开始，只有当风险和证据支持时才扩大。

反事实 4：下游路由器使用更窄的 UPDATE 错误处理

改变一个事实：在后期风格窄响应适用的情况下，下游路由器在不关闭整个 BGP 会话的情况下遏制格式错误宣告。

实验路由可能被丢弃，但通过会话学到的无关有效路由仍然可用。更新放大和重新收敛压力应明显变小。

此反事实反映了后来在 RFC 7606 中正式化的方向。[13] 它必须保持分析性，因为该 RFC 晚于事件，且精确处理取决于错误类别和实现。

反事实 5：提前通知到达受影响运营商

改变一个事实：运营商收到关于前缀、属性、窗口、预期行为和停止条件的充分技术通知。

部分运营商可能更密切监测相关会话、准备人员、限制暴露或在异常出现后迅速协调。因为路由被识别为实验而非未解释事件，诊断可能加速。

通知不能修复 IOS XR。如果预期测试会暴露不安全行为，它可能还需要谨慎的漏洞处理。因此通信是缓解和协调控制，而非完整遏制机制。

反事实 6：量化停止标准触发更早撤回

改变一个事实：监测在 09:08 UTC 之前足够早地识别出异常更新速率或会话重置，从而越过预定义停止阈值。

RIPE NCC 更早撤回。持续宣告更早结束，可能减少重复和暴露时间。

局限是 BGP 的分布式状态。已经传播的更新仍需要撤回和重新收敛。更早行动可以缩短持续时间，但不会瞬间恢复所有受影响路径。

反事实 7：策略限制向选定对等方传播

改变一个事实：导入和导出策略将实验路由限制在明确参与的网络。

故障域变小，参与运营商可以捕获证据。这与后来对明确外部策略的强调一致。[14][15]

局限是研究问题。如果目标要求观测多样化的公开实现，严格遏制会改变能学到什么。该权衡应被明确做出，而非假设不存在。

反事实 8：路由采集器和服务探测即时提供关联告警

改变一个事实：控制平面观测、会话遥测和相关服务探测实时关联。

调查人员能更快区分无害的新宣告与更新放大、前缀不可见和服务影响。撤回决定变得证据驱动。

这不能防止第一次损坏，但能改善检测并缩短不确定性持续的时间。

反事实 9：实验从未发生

改变一个事实：不进行任何公开宣告。

8 月 27 日的触发器消失，因此此事件不会暴露该缺陷。但产品缺陷仍可能保持潜伏，并可能在以后被另一有效陌生属性激活。

此反事实澄清了为什么“不实验”不是充分的安全策略。避免测试避免了此次事故，但不能修正正在运行的软件。更好的目标是安全发现：有界实验与产品修复结合。

10. 可验证修复是什么样子

修复声明应与证据和观测绑定，而非安慰。

产品证据

对于受影响实现，可信证据应包括：

精确的修正软件版本；
厂商在合适细节层面对有缺陷处理路径的描述；
使用有效未知可选传递属性的回归测试；
展示保留字节或符合规范的传播测试；
使用格式错误或故意损坏变体的测试；
支持窄错误处理时保留无关路由的证据；
重复会话循环测试以检测复发；
运营商记录识别已安装版本；以及
安装后观测证明缺陷不再复现。

公开 CVE 和通告识别了问题和响应。[2][3] 它们是可验证性的开始，而非现场闭环的完整证明。

实验证据

对于未来实时路由实验，可信证据应包括：

测试前缀和源；
拟议的属性编码；
参与对等方和预期传播范围；
跨显著不同实现的互操作结果；
覆盖控制平面和服务后果的影响评估；
提前通知记录；
量化停止阈值；
立即撤回权限；
撤回演练；
实时采集器监测；
相关数据平面或服务检查；
异常和决策的时间戳；
保留的 UPDATE 数据；以及
比较预期与观测行为的事件后说明。

RIS 和 Route Views 展示了多个路由观测点的价值。[7][11] 它们不能替代设备日志或数据包捕获，但可以独立显示宣告是否传播、撤回是否成倍增加以及影响是否因观测点而异。

运营商证据

声称其网络受到保护的运营商应能展示：

受影响 IOS XR 软件是否存在或曾存在；
安装了哪个修正版本；
如何定义外部路由策略；
当前软件如何处理格式错误 UPDATE；
如何检测会话重置；
如何测量无关路由丢失；
启用了哪些对等保护；
如何记录恢复决策；以及
是否完成受控回归测试。

这就是具体形式的运营连续性。没有运行版本证据的配置声明不完整。没有策略和观测证据的软件版本也不完整。

闭环标准

当原始字节、中间变异和下游响应由证据连接时，事件可被视为技术上已理解。当修复软件通过相关回归测试且部署在所需位置得到证明时，产品问题可被视为已修复。当未来实验无法在没有记录范围、通知、监测、停止权限和保留的情况下推进时，治理问题可被视为已修复。

这些闭环标准有意分离。公开事故报告应说明哪些已满足，哪些仍未知。

11. 会改变结论的证据

当前结论依赖证据。若干发现将需要重大修订。

显示初始属性格式错误的数据包捕获

如果权威捕获证明 RIS AS12654 宣告的属性在到达受影响 IOS XR 系统之前已经格式错误，那么“有效输入在传播过程中首次被损坏”的结论就必须改变。

责任将转向生成和宣告前验证，尽管任何额外变异或放大仍需单独分析。关键要求是端到端字节比较：源发送了什么、每个中间系统接收了什么以及发出了什么。

识别不同损坏点的设备日志

如果日志或捕获显示另一实现、路由服务器或中间设备制造了损坏，产品归因就需要修订。Cisco 通告可以识别真实缺陷，却不能证明同一缺陷解释每条观测路径。

事件可能包含不止一种故障模式。只有路径特定证据才能确定所有重置是否共享一个损坏点。

重大修订影响估计的采集器数据

如果保留的采集器数据显示基线、受影响前缀数量或持续时间显著不同，有界影响评估应更新。更正可能提高或降低测量范围。

修订不会自动改变实现机制。原因和量级是相关但独立的证据问题。

显示额外控制的批准和风险记录

如果完整实验记录显示公开说明中不可见的实质遏制、通知或停止控制，治理评估应承认它们。然后需要解释为何这些控制未能阻止或缩短观测到的扰动。

相反，显示已识别的高影响风险在没有缓解的情况下被接受的记录将加强治理批评。仅公开说明不能确立任一情景。

显示先前识别和有效控制的产品记录

如果产品测试记录证明缺陷在实验前已被识别并有效控制，时间线和责任分配将改变。调查人员需要询问受影响已部署系统是否缺乏可用修正、运营商是否收到适用通知，以及观测行为是否来自另一机制。

当前记录不确立这种先前识别。

更广或更窄服务影响的证据

完整流量测量、运营商日志或服务遥测可以改善对用户可见后果的评估。它们可能显示控制平面不稳定导致的应用程序中断比当前记录更多，或冗余使大多数服务在路由抖动中保持可用。

此类证据将改变影响部分，但不会在没有包级证据的情况下为原始 UPDATE 的有效性改写辩护。

12. 克制的结论

2010 年 RIPE-Duke 实验不是一次常规的恶意路由劫持，现有证据不支持如此描述。它也不是一次碰巧遇到不合理路由器的无害标准测试。

这是一次实时路由实验，其中有效、陌生的可选传递属性遇到了受影响的 IOS XR 实现。该实现在传播时损坏了属性。下游路由器随后可能对格式错误 UPDATE 作出响应，重置 BGP 会话，撤回无关有效路由，并促成反复重新收敛。RIPE 的测量捕捉到有界但重要的扰动：异常更新速率、额外前缀不可见以及近 4500 个不稳定前缀的峰值。[1][2]

事件暴露了两个不同控制域中的两个缺陷。一个是处理有效透明路由信息的产品缺陷。另一个是实验治理弱点：有限的公开前测试和不足的公开暴露边界，使未知交互成为互联网路由事故。

Cisco 的通告和维护升级应对了产品缺陷。RIPE NCC 的调查、证据保留和更严格的未来实验承诺应对了治理缺陷。后续标准提供了更好的错误遏制和策略指南，但它们是背景，不是追溯证据。

最持久的教训关乎控制。源头的标准符合性不能保证端到端安全行为。注册记录或路由采集器可以识别谁宣告了前缀并展示可见性如何变化，但无法强制每个中间实现正确保留属性。厂商必须证明安全运行代码。实验发起者必须约束不确定的公开测试。运营商必须了解其软件、策略和恢复状态。观测系统必须保留足够证据以区分触发、损坏、放大和影响。

问责不是通过指出时间线中的第一个组织来实现的，而是通过将每项重要控制匹配到所有者，并要求证据证明相应修复有效。

摘要