摘要

  • Qrator 的监测账户将事件起点放在 2020 年 4 月 1 日约 19:28 UTC,并描述了持续约一小时的可观察窗口。该时间是有归因的外部观察窗口,不是完整的 Rostelecom 内部时间线,也不能证明每个受影响网络都具有精确相同的起始和结束时刻。[1]

  • Qrator 报告了 8,870 个受影响前缀,涉及近 200 个自治系统。CERT-EU 又分别汇总了来自 200 多个网络的超过 8,800 条路由。[1][2] 这些数字反映不同报告视角下可见的规模;没有任何来源能证明每条受影响路由都具有相同的起源验证状态或产生完全一致的数据面后果。[1][2]

  • Qrator 观察到 AS12389 的通告经过 Rascom AS20764、Cogent AS174 与 Level 3 AS3356 传播。该链路表明事件越过了彼此独立控制的路由域,但并未揭示任何命名网络中具体的入口过滤、合同约定、验证状态或路由器配置细节。[1]

  • 路由证据必须保持多个类别分离:一种是学习到的路由被导出到超出既定策略范围;一种是未授权起源通告;一种是重起源的更具体前缀;一种是起源仍保持授权但 AS 路径违背预期商业关系的路由。这些类别与过滤和 RPKI 起源验证的交互方式不同。[4][17]

  • 另一起 RIPE NCC 事件发生在 RPKI 控制平面。一次注册表软件更新后,2,669 条路由起源授权声明被删除,因为若干 provider-independent 分配被归类为不可认证。RIPE NCC 于 4 月 2 日恢复了缺失的 ROA。[3][5]

  • 同时发生并不代表因果。RIPE NCC 的复盘与独立路由工作组分析未发现 ROA 删除与 Rostelecom 路由事件之间存在直接关系。[4][5]

  • 两起事件的重叠范围很窄:3 名 provider-independent 资源持有人和 12 个前缀。该重叠不能外推到全部 8,870 个前缀,且公开记录不支持将全部受影响路由标记为 RPKI Invalid。[4][5]

  • 路由起源验证(ROV)可将路由起源 ASN 与覆盖 ROA 对比后分类为 Valid、Invalid 或 NotFound。它不会验证完整 AS 路径,不会确定每个出口是否符合商业关系,也不能重建配置变更或推断意图。[13]-[15]

  • 实际控制是分布式的。Rostelecom 控制其通告与出口策略;接收网络控制自身入口、出口与验证决策;前缀持有人控制其记录与 ROA;RIPE NCC 控制其认证和 ROA 管理服务;依赖方控制缓存新鲜度和执行策略;监测机构控制其观测与告警系统。

  • 若干关键事实仍未知:内部触发序列、学习路由泄露与重起源更具体前缀的确切比例、每个接收网络的 RPKI 视图、每跳应用的过滤器、完整响应时间线、完整数据面影响,以及事件是偶发还是故意。

  • 因此问责结论应是运营导向而非归责型。注册记录和 ROA 记录提供了关于资源与起源授权的证据,但运行配置、当前缓存、邻居策略、监测与协同恢复才决定该证据是否改变了实时路由行为。

问责问题

2020 年 4 月 1 日事件的重要性在于它揭示了登记权限与运行控制之间的分离。RIPE 数据库可识别与 AS12389 相关的行政对象,而 RPKI 可表达部分前缀持有人起源授权。[8][10] 但任何一个系统都不能单独决定每台路由器会接受、偏好或传播什么。BGP 对等体交换 UPDATE 报文,在本地策略下选择路由,并向邻居公布被允许的结果。[12] 一旦意外通告穿越网络边界,每个接收运营者都要做出另一项本地受控决策。

该结构排除了“一个登记记录、一个安全机制或一个组织决定全部结果”的简单解释。Qrator 报告 AS20764、AS174 与 AS3356 的传播表明观测链上出现了多个运营控制平面。[1] 因通告中出现 AS12389,Rostelecom 的行为处于核心。该通告的覆盖范围还取决于哪些邻居接受它、哪些邻居将其再次导出,以及下游网络的选路决策。

这也是起源验证边界的检验场景。如果通告使用未授权起源或被 ROA 覆盖但长度不当,具备新鲜且有效验证数据并执行策略的运营者有可能将其判为 Invalid 并拒绝。若路由保留授权起源却沿不当 AS 路径传播,同样的起源检查也可能返回 Valid。若缺少覆盖 ROA,通常会返回 NotFound,而非 Invalid。技术控制因此对事件不同部分具有不同约束力。

公开证据只有在这些区分成立时才支持问责分析。去掉 BGP 通告、AS12389 证据、传播观测、ROA 状态、上游接受决策、监测与事件协调,就会得到的是通用安全讨论,而不是本事件解释。反过来,将所有路由都当作同类失败,则会把 RPKI 赋予未被设计的能力。

问责在此意指识别谁实际控制了可度量决策,以及哪些证据可证明该决策。它不意味着从外部路由观察推断疏忽、违法、个体过错、漏洞、法律责任或拦截意图。CERT-EU 说明事故是否偶发仍未明确。[2] 现有记录也未消除这一不确定性,因此分析不能以断言替代不确定性。

法证时间线

法证重建应区分直接报告的观察与推断、未决内部事件。公共路由采集器和监测平台提供的是选定控制平面视图,不是完整传输记录。RIPEstat 文档同样说明路由数据是可得源的观测,且受观测点与数据覆盖限制。[9] 因此以下时间线识别了可报告内容、可分离内容与仍未知内容。

时间证据事件
2020 年 4 月 1 日 19:28 UTC 之前公开记录未识别触发 Rostelecom 内部配置变更、路由器、命令、员工或内部审批序列。也未建立每个后来接收该通告网络在事件前精确的过滤状态和 RPKI 状态。
约 19:28 UTCQrator 将其观察起点定在约 19:28 UTC。它报告 AS12389 通告了与大量其他网络相关的路由。[1] 该时间戳属于 Qrator 的监测账户;并不证明每个受影响路由器在此时看到首个更新。
后续传播期间Qrator 报告通告经过 Rascom AS20764、Cogent AS174 和 Level 3 AS3356 继续传播。[1] 该观测证实了这些自治系统中的可见继续传播,但并未给出每个会话级决策、路由映射评估或背后商业关系。
大约一小时窗口内Qrator 计数到 8,870 个受影响前缀,涉及近 200 个自治系统。[1] CERT-EU 后续总结了来自 200 多个网络的 8,800 多条路由。[2] 这些是有归属的测量,不是证明每条路由有相同起源验证状态或产生相同数据面后果。
事件响应期间Qrator 表示 Rostelecom 收到了实时告警,并与 Qrator 一起进行故障排查和恢复。[1] CERT-EU 也记录了与报告机构的合作。[2] 具体到 Rostelecom 的升级、缓解与回滚顺序未公开。
首次观察后一小时左右Qrator 描述该事件持续约一小时。[1] 公开账户支持在该观测区间内恢复的事实,但未界定哪个配置或撤销结束了每条受影响路由,也未说明收敛是否在各处同步完成。
同期 RPKI 事件另起一事,RIPE NCC 的注册表软件更新导致部分 provider-independent 分配被归类为不可认证,进而删除了 2,669 条 ROA。[3][5] 这是与 AS12389 路由行为不同的控制平面记录管理失败。
4 月 2 日RIPE NCC 恢复了缺失的 ROA。[3][5] 该恢复属于独立的 RPKI 服务恢复时间线,不应被表述为结束 Rostelecom 事件的机制。
后续分析路由工作组和 RIPE NCC 的后续复盘未发现两起事件之间有直接关系。它们识别到三个 PI 持有人和 12 个前缀的重叠。[4][5]

该时间线包含两个同步但分析上独立的失败序列。一组发生在 BGP 通告及其跨边界接受;另一组发生在起源授权记录的生产与可用性。前者取决于实时路由策略;后者影响能否向依赖方提供有效的 ROA 数据。有限交集使得“缺失记录是否改变了 12 个前缀处理”成为可讨论问题,但不意味着 ROA 删除导致 8,870 前缀事件。

时间线也将检测时间与触发时间分离。Qrator 在约 19:28 的外部观察是事件在其观测点可见的证据,但不表明何时内部变更被提交、生效或下发。同样,约一小时时长是外部观测描述,不能确立每条路由在每个路由信息库中的精确存在时段。

缺乏逐路由器时间线是关键。没有它,无法可靠判断第一位接收邻居、策略评估顺序、哪些路由先撤销或先修正,以及是否有网络在某些部分继续传播。负责任的重建应保留这些缺口,而不将监测轨迹误作完整内部日志。

观测到的传播可确立什么

AS 路径观测表明,意外可达信息并未局限于单一网络。BGP 是分布式协议:一个自治系统接受的 UPDATE 可输入另一个系统的决策流程,若符合策略可成为进一步通告给邻居的结果。[12] 因此 AS12389–AS20764–AS174–AS3356 的传播链标识出跨独立行政域的一系列运营决策。[1]

这并不意味着每个命名网络都接受每一条 8,870 前缀,也不意味着同一路径到达全网。它也未说明为何特定入口策略接受某条路由。运营者可能使用客户前缀过滤、IRR 数据、RPKI 验证、人工维护例外、宽泛限制或合同假设等组合。冻结证据未揭露 2020 年 4 月任何命名上游或对等体的配置。

尽管如此,传播证据仍有价值,因为它识别了可用的抑制点。AS12389 控制是否起源和导出该通告。每个直接连接的接收网络控制是否接受。每个进一步发布者控制下一步出口决策。下游网络控制路由选择和本地验证策略。这是精确的技术意义下共享控制:多个运营者拥有可独立改变至少部分路由结果的机制。

共享控制不应自动转化为共享问责。可见 AS 路径不能揭示路由关系条款、运营者前缀清单准确性、缓存状态,或某路由属于学习泄露还是重起源更具体部分。它标识了决策点,而非该决策的法律或道德涵义。

不能合并的四类路由情形

“泄露”常被宽泛使用,但该事件不能准确解读,除非将四种路由条件分开。RFC 7908 将路由泄露定义为将公告传播到其预期范围之外,尤其是当结果路径打破客户、提供商和对等关系的预期顺序时。[17] 该概念与起源授权不同。

  1. 学习路由策略泄露。某网络从一个邻居学习到合法路由后,将其导出到另一个不在该路由预期策略范围内的邻居。前缀持有者的授权起源仍可在 AS 路径末端。错误在于出口范围:中间网络充当了其策略不允许的 transit 角色。由于原始起源 ASN 与前缀长度可能仍匹配 ROA,普通 ROV 在该起源未变情况下仍可能判为 Valid,即使路径在商业或运营上不当。

  2. 未授权起源通告。某 ASN 通告了资源持有人未授权其起源的前缀。若覆盖 ROA 授权了不同 ASN,且依赖方具有最新有效验证数据,则该通告可因起源不匹配被分类为 Invalid。[13]-[15] “起源劫持”术语有时用于该条件,但该标签本身并不能证明恶意意图、流量劫持、犯罪行为或合法权属。

  3. 重起源更具体前缀。某 ASN 在另一个网络聚合内宣布更长前缀并自称起源。覆盖 ROA 可以因为起源 ASN 不一致或公告长度超出 ROA 的maxLength将该更具体前缀判为 Invalid。更具体前缀更可能被路径选择采纳,因为最长前缀匹配优先于普通 BGP 路径比较。但公开记录未界定每个重起源的用途或每个前缀的数据面效果。

  4. 有效起源策略泄露。前缀、起源 ASN 和长度均被授权,但 AS 路径或出口关系违反预期策略。这是 ROV 边界最清楚的体现。起源验证回答起源是否在可用 ROA 下被授权,不回答中间 AS 是否有权提供转接、路径是否符合允许关系,或该路由是否该被通告给该邻居。

公开分析显示 2020 年 4 月观察中包含学习路由与更具体重起源的混合。[4] 实际比例未知。故将 8,870 个前缀全部定义为未授权起源、全部定义为有效起源策略泄露或全部定义为 RPKI Invalid 都不准确,每种说法都以未解决分布代替统一分类。

NotFound 也应保持独立。缺少覆盖有效 ROA 时,起源验证通常返回 NotFound。[14] 这是在未完全覆盖路由体系中的常见状态。它不表明起源被授权,也不代表 Invalid;它仅说明当前可验证 ROA 集合未提供可用于测试该通告的覆盖授权。

这些类别定义了潜在控制的可达范围。基于客户前缀清单的出口过滤可同时约束未授权起源和错误导出的学习路由。ROV 可识别在存在合适 ROA 时的部分未授权起源或长度违规。路径关系控制可覆盖有效起源的策略泄露。任何单一过滤类型都不能囊括完整混合。

RPKI 起源验证能说明什么

RPKI 提供地址资源持有人可创建 ROA 的加密支撑结构。ROA 表达某前缀授权给特定 ASN 起源,并可设置最大前缀长度。[13] 依赖方检索并验证 RPKI 材料,产出已验证的 ROA 载荷,并将其提供给路由系统或策略引擎。RIPE NCC 为其服务区资源运行认证与 ROA 管理服务,但并不集中下发每个参与网络的路由器配置。[10]

在某一可验证数据集下,起源验证可得到三类结果。当覆盖授权允许 observed 起源 ASN 与前缀长度时,路由为Valid;当有覆盖授权但没有任何一项允许该起源与长度组合时为Invalid;当无覆盖授权可用时为NotFound。[14] 这些结果是某一时间某一依赖方数据持有状态的结论,不是路由本身恒定的全球性质。

这在记录管理事件中尤为重要。两个依赖方可能暂时持有不同的验证视图,因为仓库同步时间、缓存状态、过期行为或运营响应不同。RFC 7115 强调了依赖方处理和验证信息的重要性。[15] 冻结证据未揭示一小时 Rostelecom 观察期间每个网络实际看到的验证缓存内容。因此,称某命名运营者“看到 Invalid”需要该运营者在当时刻的验证数据与策略证据支撑。

ROV 在某些场景可提供有用起源证据。如果 AS12389 的受覆盖前缀通告与授权 ASN 冲突,或更具体前缀超过适用maxLength,并且有生效 ROA、正确同步到当前依赖方缓存、接入路由策略且无例外覆盖,执行中的运营者可将其潜在拒绝为 Invalid。若这些条件有一缺,则实时结果会变化。

Valid 结果说明远不及“安全路由”。它不验证中间 AS 序列,不证明客户-提供商或对等关系,不证明中间网络有权导出学习路由,不说明数据路径到达预期目的地或未被分流,也不说明运营联络会响应。授权起源可能在非预期路径下出现。

Invalid 的含义亦有限。它只显示该依赖方当前验证视图下与覆盖授权存在冲突,可来自未授权起源、过长前缀、过时运营意图或错误 ROA。它不能单独证明动机、截获或犯罪。运营者仍需通过变更管理、例外处理和调查区分攻击与配置或记录错误。

NotFound 提供最少起源特异性证据。在依赖方视图内无覆盖授权时,ROV 无法通过 ROA 确认或否认起源。将所有 NotFound 一概视为恶意,是本地策略选择,而非验证结论本身;也可能将无 ROA 覆盖的正常路由拒绝。

RIPE NCC 的删除说明了上述边界。删除 2,669 条 ROA 可能使部分路由在同步后从 Valid 或 Invalid 变为 NotFound,取决于剩余覆盖记录与缓存时点。[3][5] 但这并未创建 AS12389 BGP 通告,不会导致中间网络开始导出这些通告,也不会重写完整 AS 路径。对于 Rostelecom 事件,公开重叠仅三名 PI 持有人与 12 个前缀,后续分析未发现直接关系。[4][5]

因此不能声称通用 ROV 可阻止该事件全部发生。它可在“可用且当前 ROA 数据下可判 Invalid”的部分路由上约束;却不会天然拒绝起源授权不变的学习路由泄露,也无法验证完整 AS 路径。该边界不是对证据的缺陷,而是对机制设计目标的准确表达。

根本原因

Rostelecom 的内部起始序列未知。公开来源未识别具体配置变更、命令、路由器、员工、评审决策或自动化故障。它们仅显示 AS12389 的外部观察行为和后续传播,而非内部生成机制。因此,路由事件的根本原因不能被简化为公开可识别的单一动作或个人。

在可观察层,事件始于 AS12389 的起源或出口行为,向 BGP 引入意外路由,其中包含被解读为学习泄露与重起源更具体前缀的证据。[1][4] 其他网络的接收与继续导出扩大了可见范围。该序列获得了路由观测支持,但还不能等同完整根因归断。

RIPE NCC 事件是另一条技术序列。注册表软件更新将部分 provider-independent 分配标记为不可认证并删除了 2,669 条 ROA。[3][5] 该记录管理故障改变了 RPKI 数据,而 Rostelecom 事件改变了实时 BGP 通告。后续分析未发现两者直接因果关系。[4][5] 将两者合并为单一根因会与公开记录冲突。

贡献条件

首个贡献条件是 BGP 在每个网络边界都依赖本地策略。BGP 负责可达性分发,但运营者决定接收、偏好与通告的对象。[12] 本应局限于单一关系的路由,在连续配置允许时可逐步传播。2020 年的观察链经过 AS20764、AS174 和 AS3356 说明存在多个接收与出口点,但未暴露任一网络具体策略。[1]

第二个条件是起源授权相关性的不均衡。含有冲突覆盖 ROA 的路由可能成为 ROV 拒绝目标;有效起源策略泄露不会被 ROV 拒绝;无覆盖 ROA 的路由会落在 NotFound。类别混合使得不能把统一修复措施套用于全部集合。

第三个条件是对当前运营数据的依赖。正确创建的 ROA 若未被依赖方检索与验证、缓存不新鲜、路由器未接收结果且本地策略未执行,就不会改变路由。RIPE NCC 删除短期影响了记录层;缓存同步和本地执行决定该改变何时影响具体网络决策。[3][10][15]

第四个条件是分布式过滤。客户前缀过滤、最大前缀控制、路由注册表、RPKI 验证与出口策略检查可互补。[11][16] 公开记录未确定 Rostelecom 或传播网络在 2020 年 4 月是否启用、禁用、绕过或错误配置了这些控制。它们是相关控制类别,不是未公开配置的发现。

第五个条件是可见性的碎片。监测机构可从选定观测点识别异常并告警,但无法掌握每台路由器 Adj-RIB-In、地方路由信息库、转发表或配置历史。Qrator 的告警提供了可执行的外部证据。[1] 但无法独立重建触发内部故障,也不能保证所有受影响网络同时收敛。

触发事件

Rostelecom 内部的触发点仍未识别。不能在公开证据基础上负责任地归因到某个人、命令、路由器、合同或动机。可报告的第一外部事件是 AS12389 通告在 Qrator 观测点约 19:28 UTC 出现。[1]

“触发”不应与“条件”混淆。宽松的邻居策略、ROA 覆盖不足、数据过时或监测有限可能让事件扩散或延迟控制,但这些条件都不能证明谁最先发起通告。同样,ROA 删除这一并行事件是同期发生,而非 AS12389 路由行为的已证实触发机制。[4][5]

检测

Qrator 报告实时检测到事件并告警给 Rostelecom。[1] 它的测量给出了约起始时刻、持续时长、规模及可见传播链,为公开重建提供锚点。CERT-EU 随后总结该事件,并记录了是否属于偶发和 Rostelecom 与报告机构合作情况。[2]

外部检测是重要的连续性控制,因为运营者内部视图可能无法完整看到邻居或远端网络对其路由的接收情况。其局限同样关键:监测告警只证明在监测系统观测点可见,并不显示内部触发的精确时间、每个下游选择决策或完整数据面影响。强监测要结合本地会话与策略遥测,以及独立路由观察。

响应

Qrator 表示,在收到实时警报后,Rostelecom 与其合作进行故障排查和恢复。[1] 这说明已进行事故协调,但未公开内部升级链条、响应人员身份、检查的配置或每一步的准确时间。

传播网络的响应在公开记录中没有可比细节。它们可行选项包括过滤通告、调整路由偏好、联系相邻网络或等待更新纠正,但推断某个命名运营者采用了具体方法都属不当。问责要求将可见控制与已示范动作分离。

RIPE NCC 的响应遵循其自身时间线。其调查了缺失 ROA,4 月 2 日恢复并后续说明监测改进。[3][5] 该响应针对记录和服务的完整性,不是 AS12389 通告在网络内修正的路由响应机制。

恢复

Qrator 约一小时的观测和故障排查恢复叙述支持结论:可见路由事件在该窗口内受控,但不能识别恢复来源于撤销、修正通告、变更出口策略、邻居过滤或其组合,也不能证明所有网络同步收敛。

运营恢复至少分三层。通告层要求停止或修正异常路由。传播层要求邻居与下游网络处理变更。证据层要求监测确认异常路径在有效观测点消失。仅依赖本地路由器可能遗漏残留传播,仅依赖外部采集可能遗漏内部状态。

RPKI 服务恢复是独立事件:RIPE NCC 于 4 月 2 日恢复删除的 ROA。[3][5] 依赖方随后仍需通过自身同步与验证流程接收修复状态。记录仓库恢复和每个依赖方收敛并不等同。

实际控制的分配

问责在于按决策而非泛化标签分配控制。

主体实际控制证据界限
Rostelecom / AS12389路由起源与出口策略、邻居级过滤、前缀清单、配置复核、变更发布、告警升级与回滚触发配置与内部响应序列未公开
Rascom AS20764、Cogent AS174、Level 3 AS3356 与其他传播网络各自的入口和出口过滤、关系策略、前缀限制、ROV 使用、例外、异常响应及进一步通告2020 年 4 月时各网络的配置、缓存状态与合同未知
前缀持有人资源记录准确性、ROA 创建、起源 ASN 与maxLength选择、运营联系人和独立路由监测不能在近 200 个受影响自治系统内统一推断其个体决策
RIPE NCC认证与 ROA 管理系统、软件测试、服务监测、回滚、恢复及按角色公开披露未集中选择或执行独立路由器所用 AS 路径
依赖方运营者仓库同步、缓存新鲜度、验证结果下发、Invalid/NotFound 策略、例外处理与最终路由决策任何全局观察者都无法推断每一依赖方在每一时刻的验证视图
路由监测机构观测点采集、异常分析、告警交付、协调证据与事后报告仅观察选定路由视图,不控制通告,也不重建全部内部动作

该分配避免两种反向错误。第一是把全部问责集中到起源网络并忽视独立接受决策;第二是过度分散控制使任何决策都无明确归属。Rostelecom 控制 AS12389 的通告或出口;每个邻居控制是否接收;每个继续传播网络控制下一次传播决策;登记机构控制起源记录可用性;依赖方控制该记录是否影响路由。

控制不同层不等于控制全部层。前缀持有人可发布正确 ROA,但不能强制每台网络检索或执行;RIPE NCC 可恢复缺失记录,但不能直接撤销独立运营者的 BGP 路由;监测机构可告警,但不能执行回滚;上游可在边界拒绝一条路由,但不能修复起源配置。运营连续性由这些控制共同形成。

这种分配同时约束推断边界。命名自治系统出现在报路径中,只能说明其网络标识在观察中出现,不自动说明员工状态、合同违约或法律责任。要得出这类结论,需要超出本文路由证据的记录。

根因证据与贡献证据的差异

根因证据应识别最先产生 AS12389 异常行为的内部机制,例如配置差分、自动化日志、提交历史、会话追踪与时间戳匹配。公开记录未提供。外部路由观测建立了事件及其扩散,但未填补这一内部证据缺口。

贡献证据作用不同。路由被连续网络接收并继续传播说明,在该路径上观察到的边界上策略未在先前阶段挡住。可见 Invalid 通告若超出验证网络可 raise 数据新鲜度、执行政策或例外处理问题,但前提是该网络在相关时刻的 RPKI 状态已知。若在 Valid-origin 泄露中仍通过 ROV,则表明该部分路径问题并非源自起源授权。

触发证据将内部动作连接到第一条异常更新。检测证据显示监测系统何时识别异常。响应证据记录联系人、决策与改动。恢复证据展示各层面撤销或纠正。保持这些类目独立,才能使事故复盘可验证,避免把检测时间戳当作触发时间戳。

可衡量的整改

该事件支持分层整改,但改进应以可观测控制而非归责判断表述。

第一,起源或中转网络可维护邻居级路由清单,并在上线前测试入口和出口策略。可用指标包括每邻居允许前缀数、与批准基线偏差、异常起源 ASN、更多具体前缀公告,以及会话期间关系分类变化。应区分本地起源路由与学习路由。

第二,运营者可在外部边界测量遏制能力。客户与对等会话应检验默认拒绝、显式允许列表、最大前缀阈值和防止 provider- 或 peer- learned 路由进入不当关系的出口规则。运营实践中的通用过滤与验证可提供分层模型,而非单一万能检查。[11][16]

第三,RPKI 运维可端到端测量。相关指标包括仓库同步时长、缓存序号推进、验证馈送可用性、每会话 Valid/Invalid/NotFound 计数、策略例外和 ROA 覆盖突变告警。仅有发行系统记录的授权不够,若缓存过期或策略引擎断联,仍无法影响实时决策。[10][15]

第四,前缀持有人可核验 ROA 是否反映当前起源,并评估maxLength是否必要且不过宽。较窄授权可使部分未授权更具体前缀更快变为 Invalid,但过窄设置也可能将合法流量工程公告误判。正确取值应基于实际路由方案,后续关于maxLength与伪装子前缀暴露的分析强调此点的重要性。[20]

第五,事故响应可通过时间指标评估:从第一条异常更新到本地告警、从外部确认到内部告警、联系相关邻居、识别受影响策略、停止新传播、以及多观测点确认恢复的时间。Qrator 的记录展示了实时告警与协调价值,但未给出全部时间区间。[1]

有价值的事故记录应保留首次观察更新、配置状态、路由策略评估结果、RPKI 缓存状态、运营联系人、纠正变更与最终外部验证。只有这样,后续复盘才可区分起源失败、出口失败、接收失败、ROA 数据陈旧与协调滞后。缺失这些时,就会用局部全网观测推断内部成因。

这些措施对意图与责任保持中立。它们问的是是否有对应控制、是否生效、是否可观察、恢复速度如何。相比默认认为路由异常必是恶意,或要求单一技术防止所有类别,该方法更能支撑问责。

注册记录与运行现实

注册对象与 ROA 属于核心证据。数据库记录将管理信息与网络资源关联,ROA 则表达资源持有人起源授权。[8][13] 准确性、唯一性和当前安全元数据使其对运营者和分析者有价值。它们帮助回答谁在记录中持有资源、哪个 ASN 被授权起源。

记录并不直接“指令”互联网运行。BGP 对等体将接收更新按本地策略处理。依赖方必须先获取当前 RPKI 数据。路由器必须接收验证结果。运营者随后决定拒绝、偏好或调查。出口过滤需编码预期关系,监测需发现传播偏离意图。协调恢复再将证据转为更正。

这起独立 RIPE NCC 删除事件突出了双重逻辑。登记与 RPKI 服务重要,因为删除授权会改变依赖方可用的起源证据;但该删除并未直接改写 AS 路径或强制 AS12389 通告传播。运营连续性仍取决于记录修复、实时缓存、局部路由策略和响应协调作为链式组合。

这种“记录-运行”视角避免将登记机构误当作主权路径执行者,也避免因为执行在本地就将记录定义为无关。ROA 可提供机器可验的证据,使部分起源冲突可被处理;当记录准确性、分发、缓存健康与运营策略都可观测时,其价值才最大。

后续设计背景,而非溯及既往的要求

RFC 8212 描述了外部 BGP 会话未明确配置时默认拒绝的姿态。[18] 作为设计背景,该做法减少未完全指定关系时默认交换路由的风险。它对后续配置规范有参考意义,但不代表 2020 年 4 月所有命名运营者都使用该行为,也不构成对该事件成因的追溯性责任标准。

RFC 9234 后续定义了 BGP Roles 和 Only-to-Customer 机制,提供了用于识别并防止部分基于关系结构泄露的协议信号,这正是 ROV 不提供的信息。[19] 该工作用于未来设计,不应被描述为 2020 年 4 月可用的要求、该事件因果或已知机制。

RFC 9319 后续讨论了 RPKImaxLength与伪造子前缀暴露。[20] 它有助于说明覆盖授权何时能或不能约束更具体前缀,但无法证实 2020 年每条受影响路由的 ROA 配置,也不能把 8,870 前缀直接解释为 Invalid。

这些后续文档共同说明分层设计的必要性。默认拒绝可应对关系配置缺失;BGP Roles 与路径信号可处理 ROV 不覆盖的关系范围泄露;RPKI 可覆盖部分起源冲突与长度问题。监控和协调仍然必需,因为没有单一机制能验证路由的全部属性。

本文不混淆的边界

2020 年事件与 Rostelecom 在 2017 年的财务路由异常并非同一事件。后者发生在不同时间、不同受影响路由集合、持续时长和归责问题。它不应在本文中重述,也不能用于推断本事件的意图、重复因果或责任。本文限定于 AS12389 的观测传播链、约一小时观察窗口,以及该事件对应的控制与修复。

本文也不同于对 ROA 配置错误与常见依赖脆弱性的抽象分析。RIPE NCC 删除在本事件中只作一项独立同期事件,重叠仅三名 PI 持有人与 12 个前缀。[4][5] 将其扩展为更宽泛的 ROA 失配理论,会模糊核心问题:本事件中哪些混合路由可被起源验证识别,哪些需要路径关系与边界过滤。

保留该区分能维持证据核心。2020 年问责检验依赖于 AS12389 通告、经过 AS20764、AS174、AS3356 的传播、差异化路由类别、随时间变化的 ROA 状态与独立运行决策。缺少这些要素时,分析会滑向另一次 Rostelecom 事件的复述,或变成抽象的 RPKI 论点。

关键不确定性

触发内部故障序列仍未知。学习泄露与重起源更具体前缀的精确分摊仍未知。完整受影响转发路径和最终用户影响仍未知。每个依赖方每个时刻的 RPKI 状态仍未知。每个传播网络的入口和出口过滤也仍未知。

完整响应时间线也未公开。Qrator 记录了实时告警、合作、排障和恢复,但未披露全部内部决策。[1] 现有证据不支持对任何责任人、故意截获、犯罪、漏洞或法律责任的结论,也未测量每一受影响服务的完整中断范围。

这些不确定性是边界,不是可忽略注脚。严谨的账户可以识别控制归属与遏制机会,同时让动机和法律结论保持未决。

结论

Rostelecom 2020 年 4 月 1 日事件显示起源证据和路由策略证据回答不同问题。Qrator 观察到 2020 年 4 月 1 日约 19:28 UTC 起始、约一小时持续、经 Rascom、Cogent、Level 3 传播的 AS12389 大规模事件,并统计了近 200 个自治系统的 8,870 个前缀及对 Rostelecom 的实时协调。[1] 这些观察确立了规模、传播与响应,但未确定完整内部成因。

同一时间发生的 2,669 条 ROA 删除事件是独立的运营失败。后续分析未发现与 Rostelecom 泄露直接关系,仅确认三名 PI 持有人和 12 个前缀重叠。[3]-[5] 该证据既排除了因果合并,也排除了“全部受影响路由均为 Invalid”的表述。

ROV 可在存在当前覆盖 ROA 和执行策略的情况下,为部分未授权起源或超长更具体前缀提供可执行证据,但不能验证完整 AS 路径,也不能阻断每条有效起源策略泄露。其余控制仍在运行中的入口与出口策略、关系感知过滤、当前缓存、路由监测和协同恢复中。

因此问责结论是分布式而明确的。Rostelecom 管控其通告和出口决策;传播网络管控边界决策;前缀持有人管控授权准确性与联系人;RIPE NCC 管控认证与 ROA 管理服务可靠性;依赖方管控缓存新鲜度和执行;监测机构管控观测与告警速度。没有任何一方控制整个系统,但每一方都控制可识别的连续性片段。

来源

  1. https://qrator.net/blog/details/how-you-deal-route-leaks/
  2. https://cert.europa.eu/publications/threat-intelligence/threat-memo-bgp-hijacking-russia/pdf
  3. https://www.ripe.net/ripe/mail/archives/routing-wg/2020-April/004072.html
  4. https://www.ripe.net/ripe/mail/archives/routing-wg/2020-April/004083.html
  5. https://labs.ripe.net/author/nathalie_nathalie/lessons-learned-on-improving-rpki/
  6. https://manrs.org/2021/03/a-regional-look-into-bgp-incidents-in-2020/
  7. https://qrator.net/blog/details/2020-report/
  8. https://apps.db.ripe.net/db-web-ui/lookup?key=AS12389&source=ripe&type=aut-num
  9. https://stat.ripe.net/docs/
  10. https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/resource-certification-roa-management/
  11. https://manrs.org/netops/
  12. https://www.rfc-editor.org/rfc/rfc4271
  13. https://www.rfc-editor.org/rfc/rfc6480
  14. https://www.rfc-editor.org/rfc/rfc6811
  15. https://www.rfc-editor.org/rfc/rfc7115
  16. https://www.rfc-editor.org/rfc/rfc7454
  17. https://www.rfc-editor.org/rfc/rfc7908
  18. https://www.rfc-editor.org/rfc/rfc8212
  19. https://www.rfc-editor.org/rfc/rfc9234
  20. https://www.rfc-editor.org/rfc/rfc9319