有缺陷的 ROA 可将路由安全转变为共模中断

摘要

• 2025 年 3 月 18 日，公开网络分析来源报告，在一个有缺陷的路由起源授权（ROA）发布后，与朝鲜关联的 BGP 路由变为 RPKI 无效，该 ROA 显然授权了一个/22 前缀，而该网络通告了四个/24 前缀。
• 此事件是一个有用的问责案例，因为从验证器的角度来看，路由安全机制按设计运作：拒绝无效路由的网络降低了那些在运营上合法但与新 ROA 不一致的路由的可达性。
• 因此，这次故障并非反对 RPKI 的论据，而是证明了 RPKI 数据已成为共享基础设施，必须通过变更审核、分阶段部署、maxLength 规范、监控、回滚和告警来进行治理。
• 共模依赖是关键风险。随着更多网络采用路由起源验证并拒绝无效路由，单个资源持有者或 RIR 层面的发布错误可能产生更广泛的运营后果，因为许多网络都消费了同一份加密声明。
• 修复标准应是可验证的：识别无效前缀，纠正 ROA，测量路由传播恢复情况，保存时间线，并发布足够证据以便其他运营商能够审计其自身的 maxLength 和告警控制。

证据记录及其使用方式

本文将公开记录视为分层证据。事件报告、标准、浏览器或路由测量、监管或政策材料以及当前的运营商指导用于支持不同的论证。公司撰写的来源被归为公司立场。标准和后续指导用于解释控制措施并提出问责预期，而非在公开记录不支持相应主张的情况下创造不公开的事实或追溯性地强加后续义务。

RPKI 让错误变得可见且后果严重

RPKI 之所以存在，是因为普通 BGP 给网络太多相信虚假可达性声明空间。路由起源授权（ROA）让资源持有者能够声明哪个自治系统可以发起哪个前缀，并通过 maxLength 指定通告的具体程度。执行路由起源验证（ROV）的网络随后可将路由标记为有效、无效或未找到，并实施策略。这是一项重大的安全改进。朝鲜有缺陷 ROA 事件表明，这一改进创造了一种新的运营依赖，即对已发布授权数据准确性的依赖。

Kentik 报告称，2025 年 3 月 18 日，由于发布了一个有缺陷的 ROA，朝鲜的 BGP 路由变为 RPKI 无效。其他公开报告描述了一个 /22 授权，其 maxLength 也为 /22，而该网络正在通告四个 /24 前缀。根据 ROV 逻辑，即使起源 AS 匹配，当通告的前缀比 ROA 允许的更具体时，路由也可能无效。如果运营商拒绝无效路由，可达性就会下降。换句话说，系统并没有因为忽略 ROA 而失败，而是因为 ROA 错误地描述了生产路由而失败。

这就是共模的意义所在。在有 RPKI 之前，每个网络的路由过滤和判断可能以不同方式失败。有了 RPKI，许多网络可以消费同一份签名对象。当对象正确时，这是有益的：错误起源的劫持可以被广泛拒绝。当对象错误时，则是危险的：合法路由可能被广泛拒绝。共享的真实来源变成了共享的故障模式。

答案不是避开 RPKI。因为授权可能出错而拒绝验证，会让旧的 BGP 信任问题原封不动。答案是将 ROA 数据视为生产变更控制。为资源持有者创建第一个 ROA、更改 maxLength、移动起源或拆分前缀，都应像处理高影响路由变更一样对待，需要审核、模拟、监控、回滚和告警。

这对于小型或集中的网络尤其重要。朝鲜的公共互联网足迹与超大规模提供商相比有限，这使得事件更容易分析。但相同的模式可能影响大学、政府、银行、CDN、区域运营商或应急服务网络。少量前缀依然可以承载关键服务。一个错误的 ROA 可将安全控制转变为可用性事件。

maxLength 是策略决策，而非表单字段

可选的 maxLength 字段是许多 ROA 错误演变为中断的地方。针对覆盖前缀的 ROA 可以仅授权该前缀长度，或者允许直到指定最大值的更具体通告。如果网络通常在 /22 下通告 /24，但 ROA 仅授权 /22，验证器会认为 /24 无效。这似乎是朝鲜事件公开解释中的情况。该字段并非装饰性细节；它编码了生产路由是否被允许存在。

运营商有时偏好较窄的 maxLength 值，因为过于宽泛的授权会削弱保护。如果 /22 的 ROA 允许 /24，那么使用相同起源的未经授权更具体路由可能更容易被视为有效。如果不允许 /24，合法的流量工程或前缀拆分可能失败。正确的值取决于实际路由意图、应急计划和监控。不存在普遍安全的自动设置。

这使得 maxLength 成为一个治理问题。谁知道生产路由集？谁批准前缀拆分？当前缀移动、通告变化或增加提供商时，谁维护 ROA？当路由变为无效时，谁接收告警？谁能在非工作时间纠正对象？谁能在依赖方网络开始拒绝无效路由之前，验证新发布的 ROA 与 BGP 一致？这些问题听起来是程序性的，但它们决定了安全部署是保护还是破坏可达性。

APNIC 关于清理无效路由的指导以及 RIR 关于错误 ROA 的材料指出了实际的修复路径：找到无效路由，检查 ROA，纠正 maxLength 或起源，等待依赖方缓存和 BGP 传播收敛。这一过程应进行演练。为一个国家、机构或企业首次创建 ROA 不应像发布低风险文书更新那样对待。

这个问题也应纳入合同语言。管理网络提供商、RIR 账户持有人和外包路由团队可能共同承担 ROA 创建的责任。客户可能不知道提供商更改了 ROA，直到用户报告验证网络出现故障。合同应明确谁拥有 ROA 数据、谁批准 maxLength、存在哪些监控，以及在有效性状态更改后提供哪些证据。

故障开放与故障关闭的激励困境

RPKI 创造了一种激励张力。如果网络拒绝无效路由，它们有助于阻止劫持和误起源。如果它们接受无效路由，则可以在合法网络发布有缺陷 ROA 时避免破坏可达性。朝鲜事件正处于这种张力之中。路由变为无效。执行拒绝的网络降低了可达性。宽松的网络可能保持了路径可用，但也保留了路由安全弱点。

这种张力有时被用作反对严格验证的论点。那过于简单化了。一个永不阻止任何事物的安全控制无法防御它本应阻止的攻击。但一个因陈旧或错误数据而阻止生产流量的安全控制，将产生禁用它压力。可持续的答案是改善数据卫生和告警，使合法的无效路由变得罕见、快速检测并快速纠正。

关于良性 RPKI 冲突和运营商激励的研究在大规模层面阐述了这一点。错误配置持续存在，拒绝无效路由的网络在无效状态为良性时可能损失流量。这造成了不利于采用的经济压力。解决方法不是让错误数据正常化，而是让错误数据可见，提供发布前检查，在路由状态变更前警告资源持有者，并创建紧急纠正路径。

路由起源验证还改变了错误代价由谁承担。资源持有者或账户管理员可能发布一个有缺陷的 ROA。直接的连接损失可能由用户和下游服务承受。执行 ROV 的传输提供商可能被指责丢弃流量，尽管其策略正是安全模型要求它做的。创建错误对象的一方可能不会收到所有支持电话。这种成本分担会破坏信任，除非证据能够识别无效性的真实来源。

因此，成熟的问责记录应避免使用“RPKI 导致了中断”这一懒惰说法。更准确地说，不准确的授权使合法的生产路由变为无效，而拒绝无效路由的验证网络强制执行了该声明。根本问题是共享安全系统中的数据治理失败。

监控必须同时关注控制平面和授权平面

传统的路由监控关注 BGP 通告：起源、路径、前缀长度、撤回和传播。RPKI 需要第二层监控：授权平面。路由可以在 BGP 发言者不改变其通告的情况下改变有效性。一个新发布的 ROA、过期的证书、存储库故障或 maxLength 变更，都可能将昨日的有效路由变为今日的无效路由。仅监控 BGP 已不再足够。

这就是为什么 bgp.tools 无效路由告警等服务很重要。一个变为 RPKI 无效的前缀是一个紧急的生产信号。它可能表示劫持、错误起源、maxLength 不匹配、过时的 ROA、存储库问题或计划变更出错。运营商需要快速知道属于哪种情况。对于关键网络，该告警应通知有权限更改 ROA 或路由通告的人员。

RIPE Labs 后来关于实时路由分析和事件可视化的讨论指向了一个有用的未来：将 BGP 视图、RPKI 有效性、路由传播和可达性证据结合到一个工作流中。在朝鲜事件期间，外部观察者能够看到有效性变更和传播下降。资源持有者至少应在公众注意到之前，对自己的前缀拥有这种程度的可见性。

监控还应前置到变更之前。在发布 ROA 之前，工具应将预期 ROA 与当前 BGP 通告进行比较，并标记每条会变为无效的路由。如果结果是有意的，运营商应一并安排路由变更和 ROA 变更。如果非有意，工具应阻止发布。这是应用于加密路由数据的普通变更管理逻辑。

公共部门网络需要特别关注。机构通常依赖承包商、共享服务或上游进行路由。如果 ROA 管理由一个团队负责，而服务连续性由另一个团队负责，maxLength 错误可能会落在所有权边界之间。连续性计划应列名 RPKI 账户持有人、路由集所有者、紧急联系人和证明恢复所需的证据。

可验证的修复优于口头保证

一个有缺陷的 ROA 事件不应以“已修复”结束，而应以证据结束。哪个 ROA 是错误的？哪些前缀变为无效？授权了哪个起源？设置了什么 maxLength？对象是何时发布的？哪些路由收集器看到传播下降？ROA 是何时纠正的？依赖方缓存花费多长时间收敛？纠正后，哪些网络仍然拒绝该路由？这些细节让其他运营商学习，并让受影响的用户信任修复。

朝鲜事件在外部有所记录，但缺乏大型企业或公共机构在同等中断后应提供的完整运营商事后分析。外部分析可以重构事件的大部分，但内部证据能够回答：为什么以那种方式创建 ROA，是否存在检查，谁批准了它，以及之后发生了什么变化。这些事实很重要，因为同样的错误类别可能在任何地方重现。

对于 RIR 和工具提供商，教训是让危险的 ROA 变更难以沉默地完成。界面应显示当前的 BGP 通告，模拟有效性结果，警告 maxLength 冲突，提供回滚指导并鼓励告警。目标不是取消运营商的自主权，而是在签名对象影响全球可达性之前，使其后果可见。

对于验证 RPKI 的网络，教训是继续强制执行，同时改善异常处理。运营商需要了解他们拒绝的无效路由、资源持有者的联系方式以及紧急评估的策略。拒绝无效路由不应意味着忽视客户痛苦，而应意味着使用证据识别路由是恶意、错误还是陈旧，然后将纠正工作推给适当的所有者。

最重要的是，RPKI 将路由信任转化为数据。这是进步。但当足够多的网络依赖数据时，数据就成为基础设施。因此，一个有缺陷的 ROA 可能成为基础设施事件，而非文书错误。治理必须跟上签名对象的威力。

安全控制变成了可用性依赖

路由起源验证旨在通过拒绝与签名授权冲突的路由来使网络更安全。正是这种设计，使得一个有缺陷的 ROA 可能导致中断。该控制并非装饰性；验证网络实际使用它。当合法路由因错误的 maxLength 或起源声明变为无效时，拒绝无效路由的网络正在执行资源持有者发布的数据。因此，中断是 RPKI 变得具有运营意义的信号，而非无用的标志。

这对组织如何描述风险很重要。如果领导说“RPKI 搞坏了我们”，他们可能禁用验证器，并返回到更旧、更弱的信任模式。如果他们说“我们的路由授权数据与我们的路由不匹配”，他们可以解决真正的问题。朝鲜事件最好理解为授权平面与路由平面之间的不匹配。BGP 通告继续存在，签名授权改变了它们的全局有效性状态。

由安全控制产生的可用性依赖，应以与任何其他生产依赖相同的严肃性进行治理。DNSSEC 信任锚点、证书透明度日志、OCSP 响应器、RPKI 存储库和验证器源都属于这一类别。它们是安全系统，但影响生产流量是否流动。将它们视为合规产物而非实时基础设施，会招致运营意外。

共模风险随着采用而增长。当只有少数网络拒绝 RPKI 无效路由时，一个有缺陷的 ROA 影响有限。当许多主要网络拒绝无效路由时，同一个有缺陷的 ROA 可能产生广泛影响。这不是反对采用的论据，而是要求严格发布控制的论据。共享的安全机制必须随着其成功而变得更加规范。

该事件还表明，RPKI 计划需要更精细的衡量标准。覆盖率百分比不够。一个网络可能具有高 ROA 覆盖率，但如果 maxLength 值错误、过时或过于宽泛，仍会产生风险。更好的衡量标准结合了覆盖率、有效性对齐、过时对象审核、maxLength 策略、告警、存储库健康和纠正时间。目标不仅是“我们有 ROA”，而是“我们的 ROA 准确描述了我们希望互联网接受的路由”。

RIR 和账户工作流是控制面的一部分

ROA 通常通过 RIR 门户或授权工具创建。这意味着用户界面、账户权限、审批工作流和告警系统都是安全控制的一部分。设计良好的验证器无法弥补一个发布工作流的缺陷，该工作流允许高影响的 maxLength 错误在无警告的情况下通过。朝鲜事件表明了为什么 ROA 创建应在发布前包含针对当前 BGP 通告的模拟。

门户可以告知运营商：如果你发布此 ROA，这些当前可见的路由将变为无效。该警告并非推测，它直接源于路由起源验证逻辑。如果运营商有意撤销这些路由，警告有助于协调时间。如果运营商本意并非导致无效，警告则防止了中断。RIR 和工具供应商应将这种模拟视为安全防护，而非可选的便利功能。

账户所有权也很重要。在许多组织中，可以发布 ROA 的人员与管理路由器或服务连续性的人员并非同一个人。注册管理机构管理员可能从地址管理角度行事，而 NOC 观察 BGP 通告，应用团队观察中断。如果这些团队不相关联，授权平面可能在不改变路由平面的情况下发生变化。解决方法是所有权映射：每个 ROA 应有路由所有者、服务所有者、紧急联系人和审核周期。

权限应进行范围界定。并非每个注册管理机构账户用户都能在未经审核的情况下进行高影响的 ROA 变更。会导致当前观察到的路由无效的变更应需要确认，对关键资源可能需要第二个审批者。应存在紧急纠正路径，但紧急创建危险对象应当是可见且有日志记录的。再次强调，重点不是官僚主义，而是尊重签名路由授权的运营威力。

RIR 关于错误 ROA 和清理的指导很有价值，因为它正常化了无效状态往往源于普通错误的观念。这是建设性的。羞耻不会改善路由安全数据。清晰的警告、更好的工具、共享的示例和快速的纠正路径才能。该事件应激励 RIR、管理服务提供商和资源持有者改善围绕 ROA 数据的工作流，而不是放弃发布它。

验证器需要异常处理的证据

拒绝无效路由的网络还需要异常处理规范。如果客户或公共服务投诉某条路由因 RPKI 无效而不可达，执行验证的运营商需要知道哪些证据能证明临时覆盖的合理性。盲目接受无效路由会破坏安全。拒绝协助诊断良性的无效路由会破坏部署信任。中间路径是基于证据的分类处理。

第一个问题是，无效性是由起源不匹配、前缀长度不匹配、发布过期或缺失、存储库故障还是验证器状态引起的。每个原因指向不同的所有者。起源不匹配可能是劫持或过时的迁移。前缀长度不匹配可能是 maxLength 错误。存储库故障可能影响许多前缀。验证器缓存问题可能是本地的。良好的工具应能快速分类无效性。

第二个问题是，可达性损失是否广泛。路由收集器、路由透视镜、RIS/RouteViews、商业监控和客户报告可以显示是许多网络丢弃了该路由，还是只有少数。这一证据有助于确定紧急程度和沟通方式。影响有限的单一无效路由可以通过普通工单处理。在多个验证网络中广泛无效的关键公共服务前缀，需要立即升级。

第三个问题是，谁能够修复事实来源。如果资源持有者发布了错误的 ROA，干净的修复是更新 ROA，而不是要求每个验证网络覆盖策略。如果 BGP 通告有误，干净的修复可能是更改路由。如果两者都因迁移而改变，修复则是协调的顺序安排。异常处理应将修复推送给正确的所有者，而不是常态化本地绕过。

这正是公开事件记录发挥作用的地方。当像朝鲜有缺陷 ROA 这样的已知事件被记录时，运营商可以将其用作培训材料。他们可以问自己，NOC 是否会识别出无效性，告警是否会触发，注册管理机构联系人是否是最新的，以及在非工作时间是否能够进行回滚。一个好的事件会成为下一次事件的演练。

共模依赖需要独立检查

共模故障意味着许多方以相同方式失败，因为它们依赖相同的组件或假设。在 RPKI 中，签名授权对象可能成为那个共享组件。如果它是正确的，许多网络一起改善。如果它是错误的，许多网络可能一起拒绝。因此，在发布前和变更后进行独立检查至关重要。

一项独立检查是 BGP 比较。将预期的 ROA 与当前的全局通告进行比较。另一项是分阶段监控。以允许快速观察有效性变化和回滚的方式进行发布。再一项是来自非资源持有者运营的服务的外部告警。本地仪表板可能显示对象存在；外部监控可能显示某条路由在公共互联网上现在无效。两者都有用，且都不应成为唯一信号。

第二项独立检查是对策略意图的人工审核。该网络是否曾在此 /22 下通告 /24？它是否具有导致前缀拆分的 DDoS 缓解措施？在故障转移期间是否使用多个起源 ASN？是否有提供商代表它进行通告？迁移是否需要临时的双起源？如果忽略这些现实，ROA 可能在语法上正确但在运营上是错误的。审核者需要理解路由意图，而不仅仅是注册管理机构语法。

第三项检查是到期和存储库健康状态。ROA 可能通过证书或存储库问题变为无效或不可用，而不仅是通过 maxLength 错误。验证器具有缓存行为和故障模式。资源持有者应监控其 RPKI 存储库是否可达，以及依赖方视图是否与预期对象匹配。无人能够检索的签名对象不是可靠的控制。

共模思维也影响沟通。如果一个有缺陷的 ROA 使关键路由无效，许多验证网络可能独立拒绝它。资源持有者需要一个公开的状态渠道或联系人来解释纠正措施。否则，每个提供商可能开启单独的工单，并花费时间诊断相同的原因。一份简明的公开说明可以减少重复工作并加速收敛。

若证据改善，激励问题可解

RPKI 的采用面临激励问题，因为拒绝无效路由的收益是分散的，而良性无效路由带来的痛苦可能是即时且局部的。拒绝无效路由的提供商可能在他人发布错误 ROA 时被客户指责。接受无效路由的提供商可能避免了支持电话，但助长了不安全的全球路由系统。更好的证据可以缓解这种张力。

如果无效告警能清晰识别负责的 ROA、受影响的前缀、起源、maxLength 和可能的所有者，执行验证的提供商就可以解释问题并指出修复方法。如果 RIR 工具在发布前发出警告，良性无效的发生就会减少。如果资源持有者立即收到告警，他们可以在许多用户注意到之前进行纠正。如果公开事件报告使清理工作常态化，组织就不太倾向于隐藏错误。每项证据改善都降低了严格验证的成本。

采购可以提供帮助。大型采购方应询问传输和云提供商是否拒绝无效路由，以及如何处理良性无效事件。他们还应询问，如果采购方拥有地址空间，谁管理其自身的 ROA。在每个错误中施压提供商接受无效路由的采购方，会破坏路由安全。维护清洁 ROA 并期望严格验证的采购方，会改善生态系统。

监管机构和政府网络应采取同样立场。公共部门的地址资源应具有 ROA 所有权、maxLength 策略、路由监控和紧急纠正。政府采购可以要求提供商进行 RPKI 验证，同时要求提供无效路由诊断的支持工作流。安全性和可用性应一并管理，而非在压力下进行权衡。

朝鲜有缺陷 ROA 事件是一个紧凑的提醒：路由安全不再仅仅是阻止攻击者进入，它还关乎保持授权数据的准确性。签名声明具有威力，这种威力值得变更控制、监控和问责。

读者对 ROA 治理的决策

读者不应将有缺陷的 ROA 案例视为不信任 RPKI 的理由。更好的决策是将 ROA 治理视为生产治理。如果一个组织拥有地址空间，它需要 ROA 数据的所有者、正常和紧急通告的映射、maxLength 策略、发布前模拟、无效性告警、回滚路径以及能够快速纠正对象的联系人。没有这些控制，该组织拥有签名的路由策略，但非受管的路由策略。

对于资源持有者，眼下的问题是，每条可见路由是否都被一个有意且准确的 ROA 覆盖。这包括起源 AS、前缀长度和 maxLength。还包括例外情况：DDoS 提供商、备份传输、任播、流量工程、迁移窗口和紧急前缀拆分。如果路由计划和 ROA 计划存在于不同工具中且由不同所有者管理，风险已然存在。

对于验证网络，决策是拒绝无效路由，同时建立人性化的诊断。严格验证改善互联网，但当无效路由为良性时，客户需要清晰的证据。运营商应能解释无效性，指出负责对象，并帮助资源持有者修复事实来源。这保护了安全，而不会将每个错误转化为禁用验证的压力。

对于 RIR 和工具提供商，决策是让危险的 ROA 变更难以静默发布。显示当前通告。模拟有效性。在使实际路由无效前发出警告。保留审计追踪。鼓励告警。提供紧急纠正指导。良好的界面可以在加密对象离开门户之前防止路由中断。

朝鲜事件之所以紧凑，是因为其公共足迹小到足以分析。教训之所以重大，是因为依赖是全球性的。随着 RPKI 采用的增长，签名数据的质量变得与验证决策本身同等重要。互联网应继续朝着拒绝无效路由的方向发展，但这一未来需要更好地维护使路由有效的授权数据。

故障类别不限于一个国家

朝鲜示例之所以有用，是因为它可见，但故障类别并非特定于某一国家。任何在覆盖分配下通告更具体路由的资源持有者，都可能通过狭窄的 maxLength 造成同样问题。任何在起源 ASN 之间移动前缀的组织都可能造成起源不匹配。任何在未与 NOC 协调的情况下更改 ROA 的管理网络提供商，都可能使生产流量无效。共同模式是签名声明不再与运营现实匹配。

这意味着每个 RPKI 计划都应包含周期性的核对任务。提取全局 BGP 中可见的路由，提取当前发布的 ROA，比较起源和 maxLength。标记每条无效路由和每条应被覆盖但未找到的路由。审查每个允许网络无意通告的更具体路由的过于宽泛的授权。这种核对不是一次性的入职任务。路由在变化，提供商在变化，DDoS 缓解在变化。合并、拆分和云迁移改变起源计划。授权平面必须跟随路由平面。

最好的长期结果是文化上的。运营商应对过时的 ROA 感到不安，就像他们对关键服务的过时 DNS 记录或公共端点上过期的证书感到不安一样。签名对象很小，但依赖可能很大。将其视为活的基础设施，是赢得信任的路由安全与在首次痛苦错误后被禁用的路由安全之间的区别。

这种文化还需要变更审核习惯。当 ROA 编辑可能在严格验证下改变可达性时，不应将其视为文书性的注册管理机构更新。审核者应询问：当前哪些路由是活跃的，提供商变更后哪些路由将是活跃的，是否故意授权了更具体路由，任何 DDoS 或备份起源是否需要临时授权，以及组织如何知道已发布的对象是否使流量无效。回滚计划应与变更计划同样明确。如果答案是“等人来抱怨”，那么签名数据不在生产控制之下。云提供商、注册管理机构、路由服务器运营商和大型企业都有利益使这一习惯成为常态，因为当授权数据平淡而准确时，严格验证效果最佳。

同样的习惯也应涵盖所有权转移。地址资源通过收购、注册管理机构更新、提供商变更、云迁移和灾难恢复设计而移动。在一个运营模型下正确的 ROA，在下一个模型下可能变得有害。因此，治理需要交接清单：谁拥有对象，谁接收告警，谁批准 maxLength，谁可以撤销过时的授权，以及谁在变更后验证全局路由可见性。朝鲜记录有用，因为它使故障小到足以理解。下一次故障可能涉及银行、公共机构、CDN 客户或应急服务，其路由计划在压力下发生变更。签名路由授权应在验证强制执行之前为此类压力做好准备。

排版

底线

问责标准是实用控制与公开证据的结合。最有力的记录并不假装每个行动者都控制了每个结果。它确定谁本可以防止故障，谁本可以检测到它，谁本可以限制影响范围，谁本可以通知受影响的方，谁本可以修复信任关系，以及哪些证据证明修复达到了依赖它的系统和人员。