摘要

  • Cloudflare 报告称，2024 年 6 月 27 日 18:51 UTC，AS267613 开始通告 1.1.1.1/32；一分钟后，AS262504 又通过 AS1031 泄漏了 1.1.1.0/24。这是两起不同事件，不能合并为一条路由。
  • /32 事件改变的是一个单独地址的去向。Cloudflare 称，一家未具名的一级网络将该通告作为远程触发黑洞路由接受，沿相应路径到达的流量因而被丢弃。公开资料不足以识别该网络或重建其内部配置。
  • /24 泄漏仍显示 Cloudflare 的 AS13335 为起源，因此可能通过只检查起源与前缀长度的验证；但“起源有效”并不等于传播路径、客户关系或每一次中间出口都获得授权。
  • Cloudflare 于 20:03 UTC 建立事件，并记录 1.1.1.0/24 泄漏在 6 月 28 日 02:28 UTC 完全解决。其报告的用户影响是无法访问 1.1.1.1 或出现高延迟，不能据此推导出全球 DNS 中断。
  • APNIC 的分析认为该事件并非全球可见，相对于互联网用户总量，影响可能较为有限。Internet Society Pulse 使用了范围更广的跨网络、跨国家观测表述；两者必须分别归因，不能拼接为无条件的全球影响结论。
  • 地址分配资料、RPKI 数据和 ROA 是验证与取证依据，却不会自动配置路由器，也不能证明一条完整 AS 路径中的每段关系均被授权。
  • RPKI 起源验证能够帮助拒绝无效起源或超出最大长度限制的通告，但不能验证全部中间 AS 关系。客户出口过滤、路由角色、传输网络导入策略和 RTBH 授权仍需独立控制。
  • RouteViews 与 RIPE RIS 保存可见路由及传播观测，为复盘提供证据；它们不授权路由、不控制转发，也不能证明每个网络中的实际数据包结果。
  • 责任应沿实际控制能力分配：谁能发起通告、谁能限制客户出口、谁能接受或继续传播、谁能授权黑洞、谁能发现异常、谁能遏制事件，以及谁能确认路由已经撤回并恢复稳定。

两起事件必须分开重建

这次事件最容易产生的分析错误，是把 1.1.1.1/32 通告与 1.1.1.0/24 泄漏压缩成一场单一的“劫持”。两者在前缀长度、起源、传播含义、过滤机会和失效方式上均不相同。即使它们在相邻时间发生、影响同一个公共解析器地址，也不能因此假定它们来自同一操作、同一意图或同一控制缺陷。

据 Cloudflare 的事后说明，AS267613 在 6 月 27 日 18:51 UTC 开始通告 1.1.1.1/32。这个前缀只覆盖一个 IPv4 地址。对常规全球单播传播而言，/32 是异常具体的路由；许多运营者会限制可接受的最具体 IPv4 前缀，但这种通行做法并不意味着每个网络、每个对等会话和每种特殊用途都采用相同策略。

Cloudflare 进一步报告称，一家未具名的一级网络接受了这条 /32，并将其作为远程触发黑洞路由处理。RTBH 的目的通常是在攻击或严重异常期间尽快丢弃指向特定目标的流量，从而保护更广范围的基础设施。问题并不在于黑洞机制本身，而在于接受方是否有充分理由相信发送者有权请求针对该地址的丢弃，以及请求的客户、前缀、长度、作用域和生命周期是否都符合已批准策略。

18:52 UTC，Cloudflare 称 AS262504 又通过 AS1031 泄漏了 1.1.1.0/24。该通告覆盖整个 /24，而不是只有 1.1.1.1。它仍携带 Cloudflare 的 AS13335 作为起源，但传播路径并未获得相应授权。这里暴露的是另一种控制边界：一条路由可以拥有看似正确的起源，却通过不应出现的客户、提供商或中间传播关系进入更广网络。

两起事件由此提出不同问题。对于 /32，应询问异常具体前缀为何能够被特定网络接受为黑洞请求，授权主体是谁，接收条件是否受到严格限制。对于 /24，应询问哪个出口策略允许路由离开预期关系，AS1031 及其他传播环节实施了哪些客户过滤、路由角色或导出约束，以及接收方为何继续接受并转发这条路径。

公开材料没有证明 AS267613 或 AS262504 存在恶意意图，也没有证明任何参与网络实施了隐瞒、违法行为或达到法律过失标准。技术复盘能够识别控制点，却不能在缺少合同、配置、内部日志和决策记录的情况下自动得出法律责任结论。

事件时间线与已知边界

Cloudflare 给出的起始顺序十分接近，但仍需逐项保留：

时间（UTC） 已报告事件 分析边界
2024-06-27 18:51 Cloudflare 称 AS267613 开始通告 1.1.1.1/32 单地址起源事件，不应与随后发生的 /24 泄漏合并
2024-06-27 18:52 Cloudflare 称 AS262504 通过 AS1031 泄漏 1.1.1.0/24 起源仍为 AS13335，但路径传播未经授权
2024-06-27 20:03 Cloudflare 建立事件 这是其内部事件响应时间点，不代表所有网络在此时才首次观察到异常
2024-06-28 02:28 Cloudflare 记录 /24 泄漏完全解决 该时间明确针对 /24 泄漏，不应被用来推断所有网络的 /32 状态变化

这条时间线没有给出完整的全球传播图。它不能回答每个自治系统何时接收、选择或撤销了相关路由，也不能证明每个地方的转发行为与公共收集器观察到的控制平面路径完全一致。时间线所能支持的是：两项异常在一分钟内先后出现，Cloudflare 随后进入事件响应，并最终确认 /24 泄漏得到全面解决。

从责任视角看，20:03 UTC 与 02:28 UTC 之间不仅是一个持续时长数字。它应被拆解为发现、分类、联系传播方、实施过滤、等待更新传播、确认撤回和验证服务恢复等阶段。没有这些阶段的内部时间戳，外部观察者无法准确判断延迟发生在 Cloudflare 的监测、对等联络、上游执行，还是互联网范围内的路由收敛。

同样，不能把“完全解决”简化为某个路由器发送了一次撤回。可靠恢复至少需要确认异常路径不再出现在关键对等和收集器视图中，服务端探测恢复正常，缓存或旧状态没有继续影响选路，而且负责网络已理解并处理造成异常的控制条件。

最长前缀匹配为何使 /32 特别敏感

IP 转发通常依据最长前缀匹配：当多个路由同时覆盖一个目标地址时，覆盖范围最具体的路由优先。1.1.1.0/24 覆盖从 1.1.1.0 到 1.1.1.255 的地址，而 1.1.1.1/32 只覆盖 1.1.1.1。如果一台设备同时拥有这两条路由，/32 对该单独地址更具体，因此能够压过 /24 的一般路径。

这不等于互联网上所有路由器都会接收 /32。前缀首先必须穿过导入策略、最大前缀长度限制、客户与对等关系检查、RPKI 起源验证或特殊用途社区处理，才可能进入本地路由选择。正因为策略分布在各网络边界，某条路由可以在一些网络被拒绝，在另一些网络被接受，在第三类网络仅作为受限黑洞信号处理。

Cloudflare 报告称该 /32 为 RPKI 无效。RPKI 起源验证把收到的前缀、前缀长度和起源 AS 与已发布授权相比较，因此能够帮助运营者识别未获授权的起源或超过允许最大长度的通告。如果接收网络对无效路由采取拒绝策略，/32 事件可以在进入常规选路之前被阻断。

然而，RTBH 会引入一个必须单独治理的控制通道。网络可能允许经过认证的客户或邻居以特定 BGP 社区请求丢弃流量。此时，接收方不能只看到“这是黑洞用途”便跳过授权判断。黑洞的防御价值恰恰来自其迅速且有破坏性的效果：错误地接受请求会让目标流量在接收网络内主动消失。

因此，安全的 RTBH 设计应把客户身份、可请求前缀、可接受长度、来源会话、社区值、传播范围、持续时间、撤销权限与审计记录作为一个完整授权对象。对 IPv4 /32 的接受可以是合理的防御能力，但只有在该单一地址确实属于请求者被允许保护的资源、请求来自正确会话、不会被继续传播到未经批准的范围，并且具备清晰撤回机制时才成立。

公开来源只说明 Cloudflare 报告的一家未具名一级网络接受了 /32。它们不支持猜测该网络名称，也不支持重建其私有社区、客户映射或路由器配置。分析应停留在可验证的控制问题：接受条件是否足够严格，以及为什么一项针对不相干前缀或不相干客户的黑洞请求可能越过边界。

/24 路径泄漏为何可能“起源有效、传播错误”

1.1.1.0/24 泄漏展示了 RPKI 起源验证的另一条边界。Cloudflare 说明，该路由仍以 AS13335 为起源。若 ROA 授权 AS13335 起源该 /24，那么只检查前缀、长度和起源的系统可能把它判定为有效。这个结果不代表整条 AS 路径得到验证，也不代表每个中间网络都有权向当前邻居导出它。

BGP 的基本任务是交换网络可达性及其路径属性。路由器依据本地政策判断哪些路由可以接收、优选和继续通告。RPKI 起源验证为其中一个判断提供加密可验证的授权依据，但它不编码所有客户—提供商、对等、路由服务器或传输关系，也不自动判断一条路径是否违反商业和拓扑预期。

因此，“RPKI 有效”与“路由合法、正确或安全”不能画等号。更精确的说法是：起源与 ROA 所表达的授权相符，但路径仍可能因错误出口、客户泄漏、角色配置不当或接收策略过宽而异常。这里没有必要假定主观恶意；配置错误、自动化缺陷和关系模型不完整都可能产生类似控制平面结果。

RFC 7908 为路线泄漏提供分类背景，RFC 7454、RFC 8212 和 RFC 9234 则分别提供过滤、显式策略、BGP 角色与 Only-to-Customer 属性等控制语境。这些标准说明运营者可以采取哪些防护，却不能证明事件中的任何具名网络已经部署、正确配置或持续验证了这些机制。

Only-to-Customer 一类信号可以帮助网络表达路径不应越过的关系边界，但其效果取决于双方部署、会话角色正确性和一致执行。显式导入、导出策略也能减少默认接受造成的泄漏，但只有实际加载到运行设备并覆盖正确会话时才有效。标准文本存在，并不等于控制在每个边界上真实运行。

/24 泄漏的责任调查因而需要超越 ROA 状态。调查者应要求查看：AS262504 向 AS1031 发送了什么更新；该会话被配置为何种关系；哪些导出规则允许这条路由离开；AS1031 如何分类与接受它；后续路由服务器、传输或对等环节又依据什么政策继续传播。没有这些证据，公共路径只能显示“发生了传播”，不能完整解释“为什么被允许传播”。

影响证据：可达性问题不等于全球 DNS 中断

Cloudflare 报告的用户体验包括无法访问 1.1.1.1 或出现较高延迟。这是实质性服务影响，因为 1.1.1.1 是广为人知的公共解析器地址；当到达该地址的路径被丢弃或绕行时，依赖它的请求可能失败或变慢。

但这并不支持“全球 DNS 瘫痪”之类的结论。全球域名系统由大量权威服务器、递归解析器、本地缓存和不同运营网络组成。即便一个重要公共解析器地址在部分路径上不可达，也不能推导出所有 DNS 服务、所有 1.1.1.1 用户或所有国家同时中断。

APNIC 的独立技术分析指出，事件没有在全球范围可见，并认为相对于互联网用户总量，其影响可能较为有限。这一判断约束了影响叙述：观测到异常传播，不等于每条潜在路径都实际承载了用户流量；路由策略、缓存、替代解析器和网络位置都会改变用户体验。

Internet Society Pulse 则使用了更广的观测语言，描述相关异常在多个网络和国家被看到。该材料有助于说明传播并非局限于单一设备或单一会话，但其范围表述必须保留来源归属。它不能与 APNIC 的边际影响判断混合成“既全球普遍、又几乎无人受影响”的无归因结论。

控制平面可见性与数据平面影响之间还存在关键差异。收集器可以观察到一条路由，却不代表该路由被每个网络选为最佳路径；即使被选中，也不证明一定有用户流量经过；即使流量经过，也需要端到端探测才能确定是丢弃、延迟、绕行还是快速回退。

现有资料没有确定受影响客户数量、准确流量损失、完整地理分布或每条传播路径。它们也没有证明所有失败都由同一项路由事件造成。负责任的影响评估应区分四种证据：路由被通告、路由被观察、路由被选用、用户请求实际失败。四者相关，却不是同一件事。

地址记录、ROA 与运行配置的边界

APNIC 的地址分配资料为 1.1.1.0/24 提供了登记背景。注册系统和 RPKI 使运营者能够核对资源归属、起源授权和相关安全元数据。在事件发生后，这些资料也有助于判断某项通告是否符合公开授权，并建立调查基线。

这些记录的价值不应被低估。没有准确的地址资源记录和 ROA，接收网络更难自动区分正常起源与明显异常起源，事件响应人员也会缺少一致的验证依据。记录准确性、授权更新及时性和持续可用性都是路由安全的重要基础。

但记录不是执行机构。数据库中的分配关系不会自行登录路由器、创建前缀列表、配置最大长度限制或撤回异常通告。ROA 也不会强迫任何网络拒绝 RPKI 无效路由。每个依赖网络都需要获取并验证数据，把验证结果接入路由政策，并决定对有效、无效和未找到状态采取什么动作。

同样，ROA 只回答有限问题：某个 AS 是否被授权起源某个前缀，以及更具体通告是否在允许长度内。它不证明客户关系真实存在，不验证所有中间 AS 是否按授权顺序传播，也不判断某项商业出口是否符合约定。

这正是两起事件形成对照的原因。/32 可因起源或长度不符合授权而被起源验证识别；/24 却可能因为起源仍为 AS13335 而通过该项检查。前者说明起源验证有明确防护价值，后者说明它不能替代路径和关系策略。

责任不能只落在资源持有人或注册系统上，也不能因 ROA 正确存在便宣告控制充分。完整链条还包括依赖方是否维护验证缓存、是否监测验证状态、是否在运行会话中执行策略、是否为例外配置设置审批与过期时间，以及是否在变更后验证实际路由结果。

RTBH：合法防御控制与高风险授权

远程触发黑洞过滤是一种正当而常见的网络防御。面对容量型攻击或对特定目标的严重流量异常，运营者可能选择在更靠近网络边缘的位置丢弃流量，以保护其他地址和基础设施。RFC 3882 提供相关技术背景，RFC 7999 则描述了公认的 BLACKHOLE 社区。

黑洞控制的危险并非源于“丢包是错误行为”，而在于它有意造成丢包，而且通常追求快速执行。正常路由策略配置错误可能通过错误路径转发流量；黑洞授权错误则可能直接使流量消失。因此，其身份验证和作用域约束应高于普通路由偏好信号。

稳健的授权模型至少要回答以下问题：

  1. 哪个客户或相邻网络可以提出黑洞请求？
  2. 请求者可以操作哪些精确前缀？
  3. 是否允许 /32，允许的最大和最小长度分别是什么？
  4. 请求必须从哪条已认证会话进入？
  5. 黑洞只在本地网络生效，还是允许向特定上游或区域传播？
  6. 哪些社区组合才构成有效请求，是否需要额外属性？
  7. 请求何时自动过期，由谁撤回，撤回失败如何升级？
  8. 每次接受、拒绝、传播、修改和撤销是否留有可核对日志？

如果这些问题只依赖人工记忆、宽泛客户映射或长期不复核的例外列表，RTBH 的速度优势就会转化为误操作风险。相反，如果授权与资源登记、会话身份、客户对象和审批记录绑定，黑洞可以在保留防御效率的同时减少越权。

Cloudflare 报告的 /32 情形说明，一家接收网络可能在正常全球路由过滤之外，为黑洞信号保留特殊处理通道。该通道是否合理，只能结合私有配置和客户关系判断；公开来源没有提供这些材料。外部责任分析可以要求控制证明，却不应虚构证明内容。

观察系统保存证据，但不拥有路由决定权

RouteViews 和 RIPE RIS 从多个观察点收集 BGP 信息。它们使研究人员和运营者能够查看某条前缀在特定时间、特定观察点可见的路径，比较通告与撤回，并在事件结束后保留部分历史证据。

这类系统对于本次事件尤其重要，因为路由状态可能短暂出现又迅速消失。没有外部收集器，调查会更依赖参与网络自己的日志，而那些日志可能保留期限不同、格式不一，或只覆盖本地视角。多个观察点能够帮助核对通告时间、传播范围和撤回进程。

然而，收集器不是路由授权机构。它们不会判断某个客户是否有合同权利导出路由，不会批准 RTBH 请求，也不会替运营者配置过滤。收集到一条路径，只证明该观察点接收到了相应控制平面信息；它不证明全球每个网络都接收了它，更不证明每个数据包都沿该路径转发。

观察范围也受对等覆盖限制。未向收集器提供视图的网络可能出现不同路径，网络内部的 iBGP、策略重写、流量工程和转发变化也未必完整呈现。因此，RouteViews 和 RIPE RIS 应与网络内部更新日志、路由器策略快照、RPKI 验证结果、流量遥测和主动探测结合使用。

在责任分配上，收集器承担的是证据基础设施角色，而不是传播控制角色。它们可以缩短发现与复盘时间，但不能代替起源方撤回通告、接收方拒绝路由、传输方停止传播或服务运营者启动缓解措施。

控制平面的责任链

路由事件往往没有一个能够独自控制全部结果的单一主体。责任需要按照各方拥有的实际控制权分层，而不是简单地把所有后果归给最先出现在 AS 路径中的网络。

通告发起方能够控制哪些前缀被注入 BGP、使用哪个起源 AS、附带哪些社区以及何时撤回。其最低责任包括资源授权校验、变更审批、前缀与长度限制、模板测试、异常通告告警和可验证撤回。

客户或边缘网络能够控制向上游导出哪些路由。它应避免把从提供商、对等方或内部错误来源学到的路径重新作为客户路由导出，并确保导出内容与登记资源、路由对象和合同关系相符。

直接提供商或 AS1031 等传播环节能够实施客户前缀过滤、最大长度约束、路由角色检查、显式导入和导出策略。Cloudflare 将 AS1031 识别为 /24 泄漏经过的路径，但这一公开路径事实本身不足以说明其内部配置或主观原因。

路由服务器和互联网交换环境能够对参与者通告实施基本过滤、前缀和 ASN 校验、角色约束及异常告警。路由服务器可能不位于数据平面，却能显著扩大控制平面可见性，因此其过滤和传播政策仍是责任链的一部分。

传输与一级网络控制自己接受、优选和继续传播哪些路径。若提供特殊 RTBH 服务，还必须证明黑洞请求来自获授权客户并仅影响获授权资源。其责任不因“客户发送了路由”便完全消失，也不能在没有内部证据时被无限扩大。

地址持有人与 RPKI 管理者能够维护准确的资源记录与 ROA，使依赖网络拥有可靠的起源验证基线。它们不能直接配置所有外部网络，但应监控自身前缀的异常起源、长度和路径变化，并建立高优先级联络渠道。

Cloudflare 作为服务运营者能够监测解析器可达性、BGP 路由变化、区域延迟和错误率，联系对等与上游网络，实施自身可控的路由调整，并在缓解后验证恢复。它无法单方面改变第三方路由器，但能影响发现速度、证据质量和协调效率。

观察平台能够保留外部视图，帮助各方核对发生了什么。它们不决定路由是否被接受，也不应因保存异常路径而被误认为授权或传播主体。

预防：把不同控制放在正确边界

第一道预防控制是起源和出口约束。网络不应允许任意系统或客户会话通告任意前缀。前缀列表、IRR 或登记资料、RPKI、客户授权对象和设备配置应相互核对，但任何单一数据源都不应在未经审查时无限扩展权限。

第二道控制是默认拒绝式的导入与导出策略。RFC 8212 所体现的显式政策原则，有助于减少新会话或角色不明会话在缺少配置时自动交换路由。其效果仍取决于设备支持、迁移方式和实际启用情况。

第三道控制是客户到提供商边界过滤。接收方应知道客户通常可以通告哪些前缀、哪些起源和哪些长度。对动态客户而言，自动化更新必须具有审批、差异审查、回滚和过期机制，避免“临时例外”永久扩大接受范围。

第四道控制是 RPKI 起源验证。拒绝无效起源或超长前缀可以拦截一类明确异常，包括本次 /32 所呈现的风险。但运营者应理解其边界，不能因一条 /24 为起源有效便停止路径异常检测。

第五道控制是 BGP 角色与传播约束。网络应明确会话是客户、提供商、对等还是路由服务器关系，并据此限制哪些路由可以跨越该边界。Only-to-Customer 等机制可以补充关系表达，但不能替代正确的本地策略和持续核验。

第六道控制是 RTBH 权限最小化。黑洞请求必须绑定客户、资源、前缀长度和入口会话，默认限制传播范围，设置自动过期，并要求撤回确认。面向关键公共服务地址的黑洞请求还应触发更高等级复核。

第七道控制是变更前仿真与变更后验证。路由策略调整不能只通过配置语法检查；还应验证生成的前缀列表、社区动作、导出结果和 RPKI 状态是否符合预期，并从多个外部视角确认没有意外传播。

检测：不要等待用户投诉证明路由异常

服务运营者应同时监测起源、前缀长度、AS 路径、RPKI 状态、覆盖范围和真实可达性。仅监测自己的起源是否改变，会漏掉“正确起源、错误路径”的 /24 泄漏；仅监测路径，又可能错过极具体 /32 通过特殊黑洞通道生效的情况。

有效检测至少包括：

  • 为关键前缀监测新起源、异常更具体前缀和意外路径；
  • 比较多个 RouteViews、RIPE RIS 观察点，识别异常传播是否扩大；
  • 对关键地址进行跨运营商、跨区域的主动可达性和延迟探测；
  • 把 RPKI 无效状态与用户错误率、丢包和解析延迟关联；
  • 监测黑洞社区的接收、执行、传播与过期状态；
  • 对客户路由数量、前缀长度或出口模式突变设置告警；
  • 记录每次路由策略变更前后的路由差异；
  • 在异常撤回后持续观察，防止旧路径或重复通告再次出现。

检测阈值应反映资源关键性。1.1.1.1 是广为使用的公共解析器地址，针对它的新增 /32 通告即使只在有限网络可见，也值得立即升级。低可见范围不应自动被视为低风险，因为特殊传播关系可能使有限控制平面事件集中影响特定用户群。

遏制与恢复：撤回只是开始

事件发生后，最短遏制路径通常是让错误发起方撤回通告，同时由直接上游和传播网络安装精确过滤。若发起方无法及时响应，接收网络可以在自身控制范围内拒绝相关前缀、起源或路径，并联系继续传播的邻居。

对 /32 事件，遏制重点是停止未获授权的黑洞接受，确认相关社区或特殊政策不再生效，并检查是否存在同类客户—前缀映射缺陷。对 /24 泄漏，遏制重点则是阻止错误出口与后续传播，修正会话角色或导出策略，并验证正确的 AS13335 路径重新成为可用选择。

撤回验证应覆盖多个层面：

  1. 发起设备确认已撤销相关通告；
  2. 直接邻居确认不再接收或传播；
  3. 外部收集器显示异常路径逐步消失；
  4. 服务端主动探测恢复，错误率和延迟回到正常范围；
  5. RTBH 状态、临时前缀列表和紧急例外已清理；
  6. 观察窗口内没有重复通告；
  7. 负责人员记录修复内容、时间和残余不确定性。

Cloudflare 记录 /24 泄漏于 6 月 28 日 02:28 UTC 完全解决。这一时间点提供了重要恢复标记，但外部资料并未展示每个网络的完整收敛轨迹。分析不能据此断言所有地区在完全相同的瞬间恢复，也不能把它用于推定 /32 在所有位置的状态。

责任矩阵：预防、检测、遏制、回退与证据保留

控制主体 预防 检测 遏制与回退 应保留证据
通告发起网络 限制可起源前缀、起源 AS、长度和社区；变更审批 新前缀和异常长度告警 立即撤回，锁定错误模板或自动化任务 配置差异、提交者、设备更新日志、撤回时间
客户边缘网络 出口前缀列表、关系和资源授权校验 导出数量与路径突变监测 停止错误出口，恢复最后已知正确策略 客户授权、会话配置、导出前后路径
直接上游与 AS1031 等传播环节 客户过滤、显式策略、角色约束 客户通告异常、RPKI 与路径告警 拒绝并停止继续传播，通知邻居 收到和发送的 BGP 更新、策略命中记录
路由服务器或交换环境 参与者前缀和 ASN 校验、策略边界 异常传播范围与参与者偏差 停止向成员分发异常路径 路由服务器视图、过滤结果、成员通知记录
传输或一级网络 导入限制、RPKI、RTBH 严格授权 无效起源、特殊社区和 /32 告警 撤销黑洞动作，阻断异常传播 客户映射、社区处理、黑洞启停和过期日志
资源持有人与 RPKI 管理者 准确登记、适当 ROA 与最大长度 前缀起源、长度和路径监测 协调传播方并在必要时调整自身路由 ROA 历史、告警、联络和变更记录
Cloudflare 服务运营 多路径设计、路由与服务联合监测 可达性、延迟、错误率及 BGP 异常 联系相关网络，调整可控路径，验证恢复 事件时间线、探测数据、流量指标、沟通记录
RouteViews 与 RIPE RIS 不承担路由授权 保存外部观察点的路径变化 不直接遏制或撤回 带时间戳的通告、路径与撤回观测

这张矩阵的核心不是把每个主体都宣布为同等有责，而是把责任限定在其能够实际操作和验证的控制上。发起方不能把全部责任推给接收者，接收者也不能因上游或客户发送了路由便免除自身策略责任；与此同时，缺少内部证据时，外部分析也不能把技术控制缺口自动升级为法律过失。

真正可审计的路由责任链应能回答五个问题：谁允许状态进入系统，谁让它跨越下一边界，谁首先看到异常，谁有权停止传播，以及谁确认撤回已经在运行网络中生效。登记记录与标准提供判断依据，最终结果仍取决于这些控制是否在实际设备、实际会话和实际值班流程中运行。