摘要

  • BGPMon 将 AS12389 事件定位在 2017 年 4 月 26 日 UTC 时间 22:36 至约 22:43 之间。它统计到跨越 37 个自治系统的 50 个受影响前缀。ThousandEyes 则使用了不同的框架：它在该时间窗口内观察到 137 个源自 AS12389 的前缀，将其中大约 100 个视为常规前缀或与俄罗斯组织相关的前缀，并识别出 36 个公司外部前缀。这些分母描述了不同的选择，不应予以合并。[1][2]
  • 直接的基础设施机制是虚假的路由发起和传播。部分宣告为更具体的路由。BGPMon 重点指出了 203.112.90.0/24（通常宣告为 /23），这一区别有助于解释为什么常规路由选择可能会优先选择虚假路由，而受影响服务本身并未受到任何损害。[2]
  • ThousandEyes 观察到包括 Cogent、Hurricane Electric 和 Tata 在内的对等体接受并传播了 AS12389 宣告。其路径测量显示，至少有一个受影响的电商服务的流量进入了 Rostelecom 并随后到达了预期目的地。这支持了部分生产流量被偏转流向的说法，而非声称每一条路由、每一个用户或每一个数据包都被偏转流向。[1]
  • 受影响的前缀中包括金融、支付、电子商务、网络安全和证书相关的服务。报道中提到的具体例子包括 Mastercard、Visa、BNP Paribas、HSBC、Symantec 和 GeoTrust。路由证据并未显示这些组织的内部系统遭到入侵。[1][2]
  • 已证实的证据包括 AS12389 起源观察、短暂的事件窗口、部分更具体的宣告、多个对等体的传播以及测得的路径变化。路由或配置故障是一个合理的解释。蓄意针对和拦截仍存在争议。攻击者身份、内部触发机制、数据包检测、解密内容、交易影响、损失和持久修复情况仍属未知。
  • 金融和安全相关目的地的集中使这一模式在 BGPMon 和 ThousandEyes 看来显得可疑。BGPMon 还观察到了涉及其他与 Rostelecom 相关自治系统的宣告，这支持了意外内部故障作为竞争性假设。两家监测机构均不掌握该运营商的内部变更、身份验证或配置记录。[1][2]
  • 问责制遵循实际控制，而非关于动机的无支持结论。Rostelecom 控制着 AS12389 内部的路由创建和导出。接受宣告的对等体控制着过滤、验证、路由接受和传播。前缀持有者控制着授权数据、外部监测和升级。独立监测机构控制着外部观察的质量和保存。
  • RPKI 可以帮助网络评估某个起源是否获得了匹配的路由起源授权（Route Origin Authorization）的授权，但它无法证明意图或内部机制。该事件也发生在广泛强制执行路由起源验证（Route Origin Validation）之前。在声称 RPKI 会阻止特定路由之前，必须先确定每个受影响前缀的历史 ROA 状态以及每个对等体的验证策略。[11]-[14][18]
  • 有证据支持的损害是暂时失去预期的路由控制，并将部分流量暴露给未授权的传输路径。记录并未证实存在交易欺诈、凭据被盗、TLS 泄露、数据被篡改、完全停机、量化的受影响人群或金融损失。加密可能会减少内容泄露，但现有证据无法确定哪些会话使用了有效的加密。
  • 确凿的说明将需要公共路由观察无法提供的记录：AS12389 的变更和身份验证日志、根本原因报告、对等体过滤器和路由选择日志、可复现的归档分析、历史 ROA 状态、服务侧流量和 TLS 记录、数据包捕获、客户事件记录，以及关于测得路径是否承载了生产流量的证据。

七分钟制造了持久的证据难题

该事件虽然短暂，但其证据结构依然至关重要。BGPMon 将其起点定位在 2017 年 4 月 26 日 UTC 22:36，终点定位在约 22:43。在此区间内，路由收集器和监测系统看到 AS12389 宣告了与其他自治系统相关联的地址空间的可达性。多个外部网络接受了其中至少一部分宣告并进行了传播。ThousandEyes 还测量了改变后的端到端路径，而不仅仅依赖于控制平面的更新。[1][2]

这些观察结果确立的不仅仅是模糊的路由异常。它们确定了一个起源自治系统、一个时间窗口、宣告的前缀、传播以及路径后果。因此，分布式的路由数据可以支持一个关于互联网被告知了什么的有力结论：AS12389 将自己表现为某些路由的起源，而这些路由并不属于其常规授权集，其中包括 Rostelecom 以外的组织所使用的地址空间。

然而，这些观察结果所能证实的内容，少于许多描述所暗示的内容。BGP 更新中并不包含运营商的动机。改变后的路径无法揭示是谁输入了命令、哪个系统生成了该命令、某个账户是否被滥用，或者计划中的配置是否超出了其预期范围。即使是一组可疑的目的地，也无法披露产生该组合的内部决策。

这一区别至关重要，因为用于描述路由事件的词汇可能会默认引入结论。“泄露”（Leak）可以描述本不应导出的路由的传播。“劫持”（Hijack）可以描述虚假起源或偏转流量的路由，但它经常被解读为敌意意图的证据。可观察到的记录支持虚假起源宣告和流量偏转。它本身并不能证实蓄意夺取、间谍活动或针对金融机构的计划。

CERT-EU 和 ENISA 随后的评估将该事件置于更广泛的 BGP 劫持和路由安全风险讨论中。这些描述作为有归属的机构评估是有用的。但它们不能替代未披露的 AS12389 日志、对等体策略记录或服务侧流量证据。[4]-[6]

适当的问责测试始于这种不对称性。公共路由证据可以被独立观察和复现。内部原因和目的在很大程度上取决于发起运营商和其他参与网络控制的记录。关于路由变更的外部证据越强，未回答的内部问题就越具体。然而，不应将外部证据延伸为它无法提供的答案。

这就是为什么一个仅持续七分钟的事件在多年后仍悬而未决的原因。撤销宣告结束了眼前的路由状况，但并未弥合证据差距。业务恢复与公开解释是不同的职责：前者恢复了路由，而后者则展示了故障是如何发生的、哪些流量被暴露、为什么控制措施没有遏制住它，以及事后做出了哪些改变。

两种前缀计数回答了不同的问题

BGPMon 统计到跨越 37 个自治系统的 50 个受影响前缀。ThousandEyes 报道称 AS12389 在相关窗口内发起了 137 个前缀，然后将大约 100 个看似常规或与俄罗斯组织相关的前缀，与属于外部组织的 36 个前缀隔离开来。[1][2]

这些数据足够接近，容易让人试图归纳出一个单一的头条数字，但又存在足够差异，使得这种做法并不可靠。BGPMon 的 50 个前缀计数涉及其跨 37 个自治系统的受影响集合。ThousandEyes 则从所有观察到的 137 个源自 AS12389 的前缀开始，然后进行分类以隔离出 36 个公司外部前缀。每个组织都使用了自己的观察和选择方法。此处提供的公开记录并未定义能够将一个分母转换为另一个分母的转换方式。

这并非细枝末节的统计细节。计数是因果主张的一部分。从一个自治系统看到的所有宣告的数字，与怀疑是虚假起源的数字并不相同。前缀的数字不是受害者组织、服务、用户、会话或数据包的数字。自治系统的数字也不是法律实体的数字。将这些单位结合起来，可能会将一个有界的路由异常变成一个无支持的人口估算。

负责任的表述应当同时保留这两种测量值，并说明它们测量的是什么。BGPMon 观察到跨越 37 个自治系统的 50 个受影响前缀。ThousandEyes 观察到 137 个源自 AS12389 的前缀，将其中约 100 个视为可能常规或与俄罗斯相关的，并识别出 36 个外部公司前缀。这种差异可能反映了视角、时机、分类和计数选择的不同，但除非有可复现的对比进行论证，否则这些解释仍仅是可能性。

历史重构可以改善这一状况。Moriano 及其共同作者的同行评审工作使用了历史 BGPStream 数据，而 CAIDA 描述了 BGPStream 对归档的 Route Views 和 RIPE RIS 材料的访问。这些来源在原则上使可复现的重新分析成为可能。但它们并没有消除记录收集器覆盖范围、时间边界、前缀过滤器和分类规则的必要性。[7][8]

计数纪律是一项问责控制，因为它限制了夸大其词。运营商的响应、外部监测机构和机构评估都应当公开其分母。如果它们的数字不同，任务应当是调和方法或保留差异，而不是选择能让事件看起来最大或最小的任何数字。

更具体的路由解释了为什么常规选择可能会偏转流量

BGP 是域间系统，网络通过该系统交换关于 IP 地址块可达性的声明。该事件的关键机制不仅仅是 AS12389 出现在非预期的路径中。它被观察到作为与其他自治系统相关联地址空间的路由起源。其中一些路由比通常用于相同地址空间的覆盖路由更为具体。[1][2]

BGPMon 重点指出了 203.112.90.0/24，而常规宣告覆盖的是一个 /23。/24 描述了比 /23 更小的地址块。对于目的地落在该较小地址块内的流量，路由器通常会优先选择更具体的路由。这种偏好发生在许多其他最佳路径比较之前。因此，即使合法的 /23 仍然可见，虚假的 /24 也能吸引流量。

这一机制对于归因纪律至关重要。偏转的路径不需要证明远程银行、支付服务或证书相关提供商遭到了入侵。路由选择系统可以将流量发送到虚假起源，因为网络接收并优先选择了一个更具体的物理可达性声明。受影响的组织可以继续正常运行自己的系统，而部分用户则通过非预期的传输路径访问这些系统。

更具体的观察也使得该事件区别于宽泛的声称，即 AS12389 仅仅是重新分配了一条带有更长或异常路径的路由。RFC 7908 提供了路由泄露分类框架，RFC 7454 提供了运营安全和过滤指南。这些标准有助于运营商描述路由策略故障和控制措施。但仅凭公开证据，它们无法确定是哪种内部操作生成了 2017 年 4 月的宣告，也无法确定该操作是否是故意的。[9][10]

问责分析应当将创建、导出、接受和选择区分开来。首先，在 AS12389 内部创建或引入了一条路由。其次，AS12389 将其导出给邻居。第三，部分邻居接受并传播了它。第四，下游路由器根据其本地信息和策略选择它。第五，至少部分测得的流量遵循了随之产生的路径。

每一步都有不同的证据所有者。路由生成和身份验证记录将最接近起源。导出策略和会话日志将显示 AS12389 向哪个邻居发送了什么。对等体记录将显示接受、过滤和本地选择。收集器归档将显示哪些内容到达了外部观察点。主动测量将显示端到端路径效应。服务运营商将持有流量和应用证据。

这种链条阻止了将所有责任简单归咎于单一地点的做法。AS12389 是被观察到的虚假起源并控制了首次导出。对等体没有创建该路由，但接受和传播扩大了其影响范围。前缀持有者没有引起宣告，但他们的授权和监测姿态可能会影响检测和拒绝。没有任何单一参与者控制着整个互联网，然而有几方控制着可以预防、限制或解释该事件的特定节点。

路径测量证明了偏转，而非拦截意图

控制平面观察显示了宣告了哪些路由。路径测量则增加了关于流量流向何处的证据。ThousandEyes 报道称，包括 Cogent、Hurricane Electric 和 Tata 在内的部分对等体接受并传播了 AS12389 宣告。它对至少一个受影响电商服务的测量表明，流量进入了 Rostelecom 的网络，随后继续流向预期目的地。[1]

这种路径形态至关重要。它支持的不仅仅是虚假路由可能吸引流量的理论风险。它表明，测得的生产流量遵循了未经授权的传输路径。在引用的示例中，路径并未简单地终止于 AS12389；流量随后到达了预期目的地。这与偏转后继续递送的情况相一致。

该测量不支持普适性的陈述。并非每个网络都接受或优先选择了该路由。ThousandEyes 指出接受情况存在差异。从一个或多个测量观察点看到的路径，不能被扩大为关于所有用户、所有源网络或所有数据包的主张。路由决策因位置、提供商、时机和策略而异。

继续递送也不能证明存在拦截。流量通过非预期网络传输创造了观察或干扰的机会，但机会并非检测行为已经发生的证据。现有的路径数据并未显示数据包捕获、内容访问、修改、凭据收集或交易操纵。它没有确定拦截系统，也没有确定使用该系统的运营商。

加密使损害评估变得更加复杂。有效的加密可以限制非预期传输网络所能读取或更改的内容，但公开的路由记录并未确立每个受影响会话的安全状态。金融和证书相关服务的存在并不能证明加密失效。它同样不能证明每个连接都得到了正确的保护。需要服务侧的 TLS 记录、会话遥测和数据包证据才能得出更具体的结论。

因此，最稳妥的、有支持的损害是失去预期的路径控制，以及部分流量暂时暴露于未授权的传输路径。即使没有内容泄露的证据，这也是一个真实的网络安全后果。用户和服务运营商依赖域间路由通过预期的可达性关系递送流量。虚假起源可以打破该控制边界，同时保持应用服务器和加密会话的完好无损。

这一区别既保护了问责制，又保证了准确性。因为没有数据盗窃被证实而贬低该事件，忽略了已证实的路由偏转。将该事件称为拦截（仅仅因为流量跨越了 Rostelecom）是将一种可能的能力视为了已完成的行为。证据支持中间立场：测得的流量发生了偏转；而检测、解密、篡改和利用仍属未知。

四类证据保持归因的真实性

通过四类证据来理解该事件最为合适：已证实、很可能、存在争议和未知。混淆这些类别是从技术观察走向无支持指控的主要途径。

已证实的证据包括 AS12389 起源观察、UTC 22:36 至约 22:43 的时间窗口、虚假宣告、部分更具体的路由、多个对等体的传播以及测得的路径变化。当与监测报告相结合时，命名的服务类别和示例也得到了支持。这些结论取决于分布式观察，而不是对 Rostelecom 私有系统的访问。[1][2]

很可能的解释应当保持其条件性。内部路由或配置故障是一个合理的根本原因候选方案。BGPMon 观察到涉及其他与 Rostelecom 相关自治系统的同步宣告，这种模式可以支持更广泛的内部错误假说，而不是精心策划、受限的外部目标集。证据并未确定失败的具体配置、命令或系统。

存在争议的解释涉及蓄意针对和拦截意图。金融、支付、电子商务和安全相关目的地的集中，结合新引入的更具体路由，使该模式在 BGPMon 和 ThousandEyes 看来显得 suspicious（可疑）。可疑是相关的，因为它影响了事件响应和证据保存。它并不是对意图的认定。

未知的情况包括谁发起了变更、该人是否获得了授权、具体的内部机制、选择这些前缀的原因、数据包是否被检测、是否有任何内容被解密、交易是否受到影响、用户是否丢失了数据或资金、在共同测量方法下的完整受影响人群，以及发生了何种持久的修复措施。

CERT-EU 和 ENISA 后来在机构讨论中使用了更具威胁导向的措辞。这些评估值得准确归因，因为公共机构使用过去的事件来解释路由风险。它们的措辞并不能创造出访问 AS12389 变更日志或受影响服务数据包记录的权限。后来的分类标签不应被视为关于运营商 2017 年意图的新一手证据。[4]-[6]

互联网协会（Internet Society）的路由安全年度回顾将该事件置于更为宏大的路由事件和防范担忧模式中。这一背景有助于展示为什么该案例的重要意义超出了单一运营商。它不应将事件扁平化为通用的统计数据，也不应回答其未决的归因问题。[3]

证据阶梯阐明了什么能够证明使用更强硬的措辞是合理的。分布式路由更新可以确立虚假起源。多视角传播数据可以确立影响范围。主动路径测量可以确立特定视角的偏转。服务日志可以确立接收到的连接、TLS 状态和应用效应。数据包捕获可以在其有限的视角和保留期内确立流量内容和修改。运营商变更和身份验证日志可以确定内部操作。根本原因调查可以将这些记录与责任和意图联系起来。

2017 年 4 月的公开记录在事件的某些部分达到了前三个层级。它没有达到后面的层级。这一边界允许明确的业务问责，而无需指定无支持的动机。即使蓄意针对未被证实，Rostelecom 也可以对源自 AS12389 并由其导出的路由承担解释责任。即使对等体没有创建这些路由，也可以要求他们对接受和传播做出解释。可以向前缀持有者询问授权和监测情况，而不暗示他们导致了该事件。

归因证据也应当是对称的。支持敌意假设的证据应当予以保存，包括目标集中度和更具体的宣告。支持意外故障假设的证据也应当予以保存，包括涉及相关自治系统的宣告。一个可信的说明应当解释为什么一个假设最终更加吻合，或者说明现有记录无法在它们之间做出决断。

这种纪律并非优柔寡断。它将明确的责任归咎于可观察到的行为，同时拒绝捏造其背后的心理状态。在路由事件中，这通常是负责任的分析与地缘政治叙事之间的区别。

AS12389 控制着最具证明力的内部证据

Rostelecom 作为 AS12389 的运营商，控制着外部观察者看到的发起和导出这些路由的系统。这并不能证明高级管理层指使了该事件，也不能证明某个人是有意为之。它确实确定了最接近路由生成过程的组织，以及最能够解释该过程的证据。

相关控制始于导出之前。路由生成权限决定了哪些账户、系统和工作流可以将前缀引入路由过程。变更审查可以对敏感或异常宽泛的修改进行二次检查。前缀准许列表可以将客户和基础设施宣告限制在预期的地址空间内。流出策略可以阻止不应离开自治系统的路由。监测可以检测到非预期的起源或突然出现的一组更具体的宣告。撤销程序可以在检测后缩短暴露时间。

这些是控制类别，而非关于 2017 年 4 月 AS12389 具体配置的断言。公开记录并未披露存在哪些控制、哪些控制失败了，或者哪些控制被绕过了。它同样没有披露该路由集是来自手动命令、自动化、客户会话、内部重分配错误、遭泄露的凭据还是其他机制。

运营商的证据应当将这些类别连接起来。配置历史可以显示发生了什么变化。身份验证记录可以显示哪个账户或系统做出了更改。批准记录可以显示该更改是否获得了授权。BGP 会话和导出日志可以显示哪些路由被发送到了哪些邻居。告警记录可以显示工作人员首次获悉的时间。事件记录可以显示是谁下令撤销的，以及受影响的集合是如何确定的。

单凭速度是不够的。这些宣告在短暂的窗口后被撤销，但七分钟的持续时间并不能揭示是监测起到了作用、对等体发出了警报、运营商注意到了错误，还是发起条件自动结束。快速结束减少了暴露，但它并不能解释检测或控制的有效性。

披露是起源运营商的最后一个检查点。一份有用的公共事件说明应当将观察到的路由事实与运营商的根本原因调查结果区分开来。它应当阐明受影响的导出范围，解释前缀是通过配置、自动化、客户还是其他路由源引入的，识别失败的控制，描述遏制情况，并给出有界的修复证据。它不需要暴露凭据、客户机密拓扑或可利用的细节。

在没有这一说明的情况下，外部观察者仍然可以对起源和导出指定业务责任。他们无法可靠地指定个人责任、意图或内部过错分配。证据的不对称性本身就是一个问责事实：控制了路由过程的组织也控制了解析最重大不确定性所需的记录。

运营商不能通过指出 BGP 是分布式的来回答这一差距。分布式意味着 AS12389 无法控制哪些远程网络接受了该路由。它并没有消除对 AS12389 起源和导出的内容的控制。相反，将虚假起源定位在 AS12389 并没有消除传播该路由的邻居的作用。实际责任遵循每个检查点，而不是将整个链条坍缩为单一的行为者。

接受宣告的对等体控制着事件的传播边界

虚假起源只有在其他网络接受并传播它时才会产生广泛的后果。ThousandEyes 观察到 Cogent、Hurricane Electric 和 Tata 等对等体承载了 AS12389 宣告。这一观察并不能展示任何命名网络内部的完整策略或决策过程。它确实表明对等体的接受是从起源到测得的偏转的路径的一部分。[1]

对等体的问责问题与 Rostelecom 的不同。一个接受宣告的网络在路由到达时并不一定知道它是虚假的，而且它也没有创建最初的声明。然而，它控制了本地导入策略、客户和对等体过滤器、路由授权信息的使用、异常告警、向前导出以及紧急协调。

过滤责任必须用证据来描述，而不是从商业标签中假设。网络可以在其自身策略下将邻居视为客户、对等体或传输提供商。公开观察并未披露这些合同或每个会话的导入规则。它们同样没有显示路由通过是因为不存在过滤器、准许列表过于宽泛、注册局数据不完整、验证信号不可用，还是本地策略接受了警告。

RFC 7454、NIST SP 800-189 和 MANRS 运营商材料为过滤、协调和弹性路由交换提供了控制参考。它们支持这样的期望，即网络应当了解邻居可能宣告哪些路由，在可靠信息允许的情况下拒绝不可信的广告，监测异常情况并保持联系路径以进行快速纠正。它们并没有确立特定对等体在 2017 年 4 月违反了特定职责。该结论将需要对等体的历史策略、路由选择和告警记录。[10][15]-[17]

传播创造了对等的证据职责。承载了非预期的更具体路由的对等体应当能够显示其接收到了什么、运行了哪些验证或过滤器、哪种本地首选（Local Preference）选择了它、它将路由导出到了何处以及何时撤销了它。保留的证据有助于日后区分可用授权数据中不可避免的局限性与可控的策略失败。

同样的证据可以防止不公平的指责。对等体可能会证明不存在适用的 ROA、注册局数据没有定义足够窄的客户群、它是在书面策略下接受路由的，或者它在收到告警后迅速改变了方向。或者，记录可能会显示缺失或忽略了已知限制。公共路由观察确定了要质疑的网络；它们并没有提供完整的答案。

因此，分布式路由产生了分布式的问责。AS12389 对虚假起源和导出承担责任。接受宣告的网络对其自身边界的控制承担责任。这些责任在效果上重叠，但在原因上并不等同。

前缀持有者和独立监测机构控制着不同形式的准备就绪状态

地址空间出现在受影响集合中的组织并未创建 AS12389 的宣告。他们的责任涉及准备、检测、升级和服务侧证据，而不是对起源的指责。

前缀持有者可以维护准确的路由和授权记录，安排外部起源监测，定义提供商升级联系人并在发生告警时保存服务证据。在业务适合的情况下，他们可以考虑通过合法提供商宣告缓解性的更具体路由。任何缓解措施都必须仔细评估，因为在事件期间做出的路由变更可能会创造新的可达性问题。

历史背景至关重要。该事件发生在广泛强制执行路由起源验证之前。现有记录并未确定哪些受影响的前缀在 2017 年 4 月具有有效的 ROA、这些 ROA 授权的最大长度是多少，或者哪些接收网络使用了验证。因此，将未普遍拒绝视为每个前缀持有者忽视了 RPKI 或每个对等体忽略了可用的无效信号，是错误的。

监测组织控制着一个不同的检查点：外部证据的质量。BGPMon 提供了一个有界的事件窗口、受影响前缀计数、37 个自治系统的分母、更具体的示例以及关于意图的竞争性假设。ThousandEyes 提供了其 137 个前缀的观察框架、导致 36 个外部公司前缀的分类、对等体传播观察、受影响服务示例和测得路径。[1][2]

当这些记录的视角、时间边界和分类方法保持可复现时，它们是最有说服力的。CAIDA 的 BGPStream 数据访问以及 Moriano 及其共同作者的历史重构，说明了归档的 Route Views 和 RIPE RIS 材料如何支持后来的分析。后来的重构仍需要阐明使用了哪些收集器和更新间隔，以及前缀是如何分组的。[7][8]

独立监测机构还负有语言职责。他们可以描述可疑的选择，并解释为什么更具体的路由会引起担忧。他们应当分别说明自己是否拥有关于目的、内部访问或内容拦截的证据。这种分离允许监测机构快速警告运营商，而无需将异常得分转换为归因判定。

受影响的服务运营商持有评估下游损害所需的证据。流量日志可能显示连接变化。TLS 记录可能显示会话是否安全完成。应用和交易记录可能显示错误、欺诈或没有实质性影响。客户报告可能确定地理位置和持续时间。单凭路由更新无法可靠地重构这些记录中的任何一项。

实际分工是明确的。前缀持有者控制准备就绪和升级。独立监测机构控制外部观察和分析。服务运营商控制应用和客户效应的证据。每个人都可以完善事件记录的不同部分，且任何人都不应声称另一方的证据是不必要的。

RPKI 可以约束虚假起源但无法决定动机

RPKI 在控制讨论中居于中心地位，因为该事件涉及虚假起源。其作用必须狭义地阐明。RPKI 架构支持关于互联网数字资源的、可进行密码学验证的声明。路由起源授权（Route Origin Authorization）确定了在一个对象范围内，获得授权发起指定前缀的自治系统。路由起源验证（Route Origin Validation）允许接收网络将 BGP 起源宣告与可用的授权数据进行对比。[11]-[14][18]

该机制可以为网络提供有用的证据，表明观察到的起源与覆盖授权不匹配。如果受影响的前缀在 2017 年 4 月具有适当的 ROA，并且接收网络执行了验证，那么 AS12389 起源可能会产生一个策略可能拒绝或降低优先级的信号。实际结果将取决于历史授权、前缀长度、验证数据和本地路由策略。

随之而来的是几个边界：

第一，RPKI 不能证明意图。路由发起可能因为敌意宣告、运营商错误、陈旧授权、范围不正确的 ROA 或其他不匹配而无法通过起源验证。该信号关注的是起源的授权，而不是变更背后的人的心理状态或身份。

第二，起源验证无法解释内部触发机制。它可以识别接收边界处的冲突，但无法回答路由是来自手动配置、自动化、客户、泄露的访问还是非预期的重新分配路径。

第三，RPKI 本身并不能验证完整的 AS 路径。获得授权的起源声明并不能在密码学上证明每个传输关系或路径段都是合法的。RFC 7908 路由泄露分类和 RFC 7454 过滤指南解决了无法简化为单一起源检查的更广泛策略和运营关注。[9][10]

第四，追溯性主张需要追溯性数据。不能在没有证据的情况下，将当今的 RPKI 覆盖范围、验证实践或注册局指南向后投影。相关问题是，在 2017 年 4 月 26 日，哪些受影响前缀具有合适的 ROA，它们授权的前缀长度是多少，每个对等体接收到了什么验证数据，以及每个对等体如何处理随之产生的状态。

第五，控制只有与其运营整合一样有用。授权记录必须准确且得到维护。必须监测验证器和数据分发。路由策略必须定义在信号存在或缺失时会发生什么。运营商需要异常、回滚和紧急联系程序。MANRS 和 NIST 指南将过滤、验证、协调和全球路由卫生置于更广泛的运营实践中，而不是将 RPKI 呈现为完整的答案。[15]-[17]

这些局限性并没有削弱路由起源安全的理据。它们澄清了该控制措施能够证明什么。RPKI 可以减少对未经身份验证的起源声明的依赖，并可以帮助接收网络做出更明智的决策。它无法确定 AS12389 为何宣告这些路由、流量是否被检测，或者谁应当承担所有责任。

因此，2017 年 4 月的案例是分层控制的一个论据。起源授权可以约束接受行为。前缀过滤器可以约束邻居导出的内容。更具体和起源变更监测可以缩短检测时间。对等体协调可以加速撤销。主动测量可以显示路径影响。服务日志可以评估损害。运营商记录可以解释原因。

没有任何一层提供了完整的说明。最强大的机制设计是使这些层产生能够在事件发生后进行调和的证据。

路由安全标准创造了能力职责，而非追溯性裁决

标准和最佳实践文档在这里作为控制图最为有用。RFC 7908 为路由泄露提供了词汇表。RFC 7454 解决了运营 BGP 安全和过滤问题。RFC 6811 和 RFC 7115 描述了起源验证及其运营使用。RFC 6480 和 RFC 6482 定义了 RPKI 和 ROA 基础。NIST SP 800-189 和 MANRS 将过滤、验证、协调和监测连接到弹性的域间业务中。RIPE NCC 解释了 BGP 起源验证及其边界。[9]-[18]

它们共同支持了在不声称 2017 年存在法律违约的情况下，可进行衡量的机构职责。起源网络应当约束其可以创建和导出的前缀。接收网络应当维持相称的导入控制，并在可用时使用可靠的授权数据。前缀持有者应当维护准确的记录并监测非预期的起源。运营商应当保存允许快速撤销和日后解释的日志和联系方式。

这些职责是能力，而不是口号。“我们使用 RPKI”在没有历史 ROA、验证状态和本地响应的情况下是不完整的。“我们过滤客户”在没有许可的前缀集和过滤器运行证据的情况下是不完整的。“我们监测 BGP”在没有告警阈值、时间戳和升级的情况下是不完整的。“路由已被撤销”在没有检测和决策记录的情况下是不完整的。

这些文档并未确定 Rostelecom 或任何命名的对等体在事件期间未能实施特定控制。那将需要将历史要求、运营商的实际架构与事件证据进行对比。现行标准仍然可以定义一个负责任的机构目前应当能够回答的问题。

这种方法避免了两种错误。一种是技术决定论中的消极宿命论，其中 BGP 的分布式设计成了没有人能承担责任的理由。另一种是技术确定论，其中一项现代控制措施被宣布为有保障的历史预防。证据对两者都不支持。

相反，机构问责制询问每个参与者是否能在其拥有的节点上论证其控制力。即使在全球系统没有中央运营商、原始动机未解决的情况下，该标准依然有效。

应当在不虚构入侵的情况下衡量损害

受影响的集合包括金融、支付、电子商务、网络安全和证书相关的服务。报道中提到了与受影响前缀相关联的 Mastercard、Visa、BNP Paribas、HSBC、Symantec 和 GeoTrust 等例子。这些名称解释了为什么观察者会严肃对待该模式。它们并不能证明这些组织或其客户受到了侵害。[1][2]

已证实的损害是路由损害。部分流量失去了预期的路径，跨越了未经授权的传输网络。这改变了受影响连接的信任边界，并减少了前缀持有者对用户如何访问其服务的控制。

可能存在的次级损害需要单独的证据。交易欺诈将需要交易记录。凭证盗窃将需要身份验证、用户或取证证据。TLS 泄露将需要会话和证书证据。数据篡改将需要数据包、应用或完整性记录。停机将需要与受影响用户相关联的可用性测量。金融损失将需要损失记录和因果分析。

仅仅因为路由跨越了 AS12389，并不能得出此类结论。继续递送可能使服务保持可用，而加密可能会限制可读内容。这两个事实都无法消除风险。两者也都无法证明每个连接都是安全的。

因此，损害报告应当使用分层的尺度。路由控制权的丢失已得到确立。对于测得的流量，暴露于非预期传输路径的情况已得到确立。内容可视性是可能的，但未得到证实。主动拦截存在争议且未得到证实。数据泄露、交易影响和损失属于未知。

这一尺度为受影响的组织提供了诚实报告的空间。他们可以在调查继续进行的同时，承认发生了一起严重的网络控制事件。他们随后可以增加服务侧的发现，而无需重写路由观察。如果没有发现应用损害，该结果应当作为所审查范围内的证据予以报告，而不是作为虚假起源无害的证明。

同样的纪律适用于公共机构和研究人员。强烈的威胁定位可以激发更好的控制，但不应将可能损害的类别转变为事件事实。路由安全倡导的公信力取决于维护这一界线。

即使归因仍未解决，披露也应回答控制问题

一份事件报告不需要确定一个有敌意的行为者才有用。它可以阐明运营商对于路由创建、导出、传播、检测和撤销的了解，同时将动机标记为未决。

对于 AS12389，最低限度有用的说明将确定宣告的源类别、路由集和导出范围、检测渠道、撤销决策、受影响期间以及事后做出的控制变更。它可以解释事件是否涉及配置、自动化、客户输入或其他内部机制，而无需暴露敏感命令或凭据。

接受宣告的网络可以披露这些路由是被视为客户、对等体还是传输宣告；是否应用了前缀、起源或路径检查；历史 RPKI 数据是否产生了可用的信号；以及这些路由是如何被移除的。前缀持有者可以披露他们何时收到告警、联系了哪些提供商，以及服务证据是否显示了可衡量的客户效应。

监测机构提供的公开记录已经将一些事实与解释分离开来。BGPMon 和 ThousandEyes 记录了时机、路由集、更具体路由、传播和路径效应，然后讨论了为什么目标模式看起来令人怀疑。BGPMon 还保存了支持意外故障假说的证据。[1][2]

这就是对不确定性负责的典范。报告不应为了避免声誉风险而隐藏可疑证据。它不应将怀疑呈现为意图。它应当说出能够判定该问题的记录，并说明是否审查了这些记录。

披露还需要持久的修复测试。关于撤销路由的陈述描述了遏制情况。它并不能论证权限发生了改变、过滤器变窄了、告警改善了、日志得到了保存，或者对等体协调得到了测试。修复证据应当确定失败的控制、变更、测试和监测结果。

各机构有不同的披露限制。运营商可以保护对安全敏感和客户机密的信息。金融和安全服务提供商可以避免暴露流量模式。对等体可以将策略视为商业机密。这些限制证明了聚合和编辑的合理性，而不是无证据结论的合理性。

公众利益在已证实的业务与宣称的目的之间的边界处最为强烈。一份清晰的说明可以说 AS12389 发起了虚假路由，对等体传播了其中一些，测得的流量改变了路径。它还可以说，蓄意针对、拦截和间谍活动并未得到确立。这种结合比通过模糊进行否认或通过推论进行指控更负责任。

可能改变评估的证据

若干记录可以实质性地加强、缩小或逆转当前评估的部分内容。

AS12389 配置历史可以确定确切的路由源和变更。身份验证和授权日志可以确定所涉及的账户或系统，以及该操作是否遵循了经批准的工作流。导出和 BGP 会话记录可以确立哪些邻居接收到了哪些宣告。告警和事件响应日志可以显示事件是如何被检测到的，以及为什么会发生撤销。

Rostelecom 的根本原因报告可以将这些记录联系起来，将错误与未经授权的行为区分开来，并记录修复措施。其可信度将取决于方法、证据保存以及是否审查了竞争性假设。仅仅断言是意外或攻击并不能解决归因问题。

接受宣告的对等体的过滤器、验证和选择日志可以显示为什么特定路由得以通过。历史策略快照可以将缺失控制与缺失授权数据区分开来。导出记录可以显示传播边界，而联系人和工单记录可以显示对等体何时协调撤销。

对归档的 RIPE RIS 和 Route Views 更新进行可复现的重新分析，可以调和 BGPMon 和 ThousandEyes 的计数框架，或解释它们为何不同。它还可以绘制跨时间和视角的传播图。该分析将需要声明的收集器、时间戳、去重和前缀分类方法。[7][8]

每个受影响前缀的历史 ROA 记录可以显示起源验证在当时是否会产生有用的结果。该分析将需要相关的授权起源、前缀和最大长度范围，以及每个接收网络拥有哪些验证数据以及其本地策略如何响应的证据。

受影响服务的流量、TLS、身份验证、应用和交易日志可以确立偏转的连接是已完成、失败还是显示了可疑效应。数据包捕获可以在其有限的视角和保留期内提供更直接的证据。客户事件和损失记录可以将技术影响与人或组织联系起来。

表明测得路径并未承载生产流量的证据将缩小损害结论。数据包检测、修改或凭证使用的证据将扩大损害结论。与负责任行为者相关联的、经过身份验证的蓄意路由变更证据将实质性地改变归因评估。内部错误和经过测试的纠正控制证据将加强意外故障的解释。

在获得此类记录之前，结论应当保持有界。AS12389 宣告和路径偏转已得到证实。路由或配置故障是合理的。蓄意针对、拦截和行为者身份仍悬而未决。数据泄露和损失未得到证实。

问责始于控制证据之处

2017 年 4 月的事件主要不是一个关于一个令人恐慌的标签是否击败另一个标签的故事。它是在设计上分布式的基础设施中如何分配责任的测试。

Rostelecom 控制着路由创建、导出策略以及最接近原因的内部记录。接受宣告的对等体控制着过滤器、验证、传播以及他们自己的证据。前缀持有者控制着授权数据、监测和升级。独立监测机构控制着外部观察和分析的透明度。受影响的服务控制着客户和应用影响的证据。

没有哪个行为者控制了整个路径。每个人都控制了一个可以进行预防、限制、检测或解释的检查点。即使在动机未知的情况下，这对于业务问责也已经足够了。

该事件还展示了为什么必须将 RPKI 视为一种有界的控制。当历史数据和策略支持该结果时，起源授权可以帮助接收网络拒绝或降低对虚假起源的信任。它无法确定变更背后的人，无法证明拦截，也无法替代导出过滤、对等体协调、路径测量和服务侧调查。

因此，最强有力的结论既是坚定的，又是有限的。公共观察证明 AS12389 发起了虚假路由，多个对等体传播了其中一些宣告，并且测得的流量改变了路径。它们并不能证明俄罗斯或 Rostelecom 蓄意进行间谍活动、流量受到检测，或者金融数据或资金发生了丢失。

问责并不需要虚构这些事实。它要求控制着关键证据的运营商保存、测试并解释它所显示的内容。

来源

访问核查日期：2026-07-25

  1. ThousandEyes，事件机制、路径证据与受影响服务面：https://www.thousandeyes.com/blog/rostelecom-route-leak-targets-ecommerce-services
  2. BGPMon，事件时间、计数、更具体示例与竞争性假设：https://www.bgpmon.net/bgpstream-and-the-curious-case-of-as12389/
  3. Internet Society，独立路由安全年度背景：https://www.internetsociety.org/blog/2018/01/14000-incidents-2017-routing-security-year-review/
  4. CERT-EU，后来的机构事件与损害摘要：https://cert.europa.eu/publications/threat-intelligence/threat-memo-190611-1/pdf
  5. ENISA，BGP 安全分析与控制建议：https://www.enisa.europa.eu/sites/default/files/publications/WP%202019%20-%20O.1.2.3.P%20-%20Short%20position%20paper%20%E2%80%94%20analysis%20of%20a%20technical%20topic%20%28BGP%20security%29.pdf
  6. CERT-EU，后来的归因威胁评估：https://cert.europa.eu/publications/threat-intelligence/threat-memo-bgp-hijacking-russia/pdf
  7. Moriano 及其共同作者，同行评审的历史重构：https://pmoriano.com/docs/COMNET21.pdf
  8. CAIDA BGPStream，历史 Route Views 和 RIPE RIS 数据访问：https://bgpstream.caida.org/data
  9. IETF RFC 7908，路由泄露定义与分类：https://datatracker.ietf.org/doc/html/rfc7908
  10. IETF RFC 7454，BGP 运营安全与过滤指南：https://datatracker.ietf.org/doc/html/rfc7454
  11. IETF RFC 6811，BGP 起源验证状态：https://datatracker.ietf.org/doc/html/rfc6811
  12. IETF RFC 7115，RPKI 起源验证的运营使用：https://datatracker.ietf.org/doc/html/rfc7115
  13. IETF RFC 6480，RPKI 架构：https://datatracker.ietf.org/doc/html/rfc6480
  14. IETF RFC 6482，路由起源授权配置文件：https://datatracker.ietf.org/doc/html/rfc6482
  15. NIST SP 800-189，BGP 安全与弹性交换指南：https://csrc.nist.gov/pubs/sp/800/189/final
  16. MANRS，网络运营商行动：https://manrs.org/netops/
  17. MANRS，网络运营商实施指南：https://manrs.org/netops/bcop/
  18. RIPE NCC，BGP 起源验证解释与边界：https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/bgp-origin-validation/