RIPE NCC 展示 ROA 错误如何成为共模路由依赖

摘要

• RPKI 和路由起源授权本质上是安全改进，而非风险。当不准确的 ROA 数据、过窄的 maxLength 选择、过时的记录或薄弱的变更控制导致合法路由被实施起源验证的网络判定为无效时，责任问题便出现。
• RIPE NCC 应被视为注册机构和 RPKI 服务/文档表面，而非互联网上每个路由决策的控制者。路由发起者创建和管理 ROA；验证器和网络决定验证状态如何影响路由。
• ROA 错误不会自动导致全球中断。影响取决于哪些前缀受影响、路由如何被通告、验证网络是否拒绝无效路由、运营商发现问题的速度以及回滚路径是否有效。
• 共模风险真实存在，因为许多网络可能使用相同的验证信号。一旦部署了自动拒绝无效路由，数据错误可能从一个管理行为扩散到多个路由决策。
• 值得信赖的 RPKI 运营问责记录应包括变更控制、发布前验证、maxLength 审查、路由监控告警、客户通知、回滚证据以及注册机构、资源持有者和网络之间清晰的职责划分。

安全控制也需要变更控制

RPKI 的存在是因为 BGP 的信任模型需要更强的起源证据。RIPE NCC 的RPKI 认证页面解释了号码资源认证的注册机构背景。关于RPKI和ROA的 RIPE 数据库文档介绍了实用的路由起源授权管理。这些材料支持一个简单观点：路由安全数据是运营数据。它必须以与路由器配置相同的严肃性进行创建、审查、监控和纠正。

ROA 声明某个自治系统被授权发起一个前缀，并带有最大前缀长度。RFC 6482《路由起源授权配置文件》定义了 ROA 对象。RFC 6480《支持安全互联网路由的基础设施》描述了更广泛的 RPKI 架构。RFC 6811《BGP 前缀起源验证》解释了验证如何将路由起源分类为有效、无效或未找到。这种机制很优雅，但运营上很尖锐。

尖锐来自强制执行。如果一条路由被分类为无效，且网络拒绝无效路由，可达性可能发生变化。当路由未授权或属于劫持尝试时，这是预期的安全收益。当 ROA 错误、过时或过于狭窄而无法匹配资源持有者实际通告路由的方式时，这也是运营风险。安全控制可以阻止攻击；同样的控制如果数据错误，也可能阻止合法流量。

这并不意味着 RPKI 是一个坏主意。这意味着 RPKI 是一个生产控制。防火墙规则、DNSSEC 密钥、身份策略或证书可以保护用户，如果管理不当也会中断服务。ROA 属于同一类别。需要问责的问题不是是否使用 RPKI，而是使用它的组织是否具备生产控制所需的运营纪律。

“共模依赖”一词描述了这种风险。许多验证网络可能基于相同的 ROA 派生验证状态做出行动。如果源数据错误，且足够多的网络执行无效拒绝，那么错误的影响可能比单个本地路由器配置错误更广泛。控制成为共享基础设施。这就是变更控制重要的原因。

MaxLength 是文本虽小但后果重大

ROA 最重要的决策之一是 maxLength。资源持有者可以为一个起源 AS 授权一个前缀，并指定应被视为有效的最具体路由长度。如果该组织后来通告了一个更具体的前缀，但超出授权长度，验证网络可能将该路由分类为无效。从组织的角度来看，该路由可能是合法的，但仍然无法通过验证。

这正是文档与数据包流交汇之处。创建 ROA 的人可能以为自己只是在做文档选择。实际上，他们正在创建其他网络可能用来决定流量是否到达目标的数据。该选择应针对实际通告、计划中的流量工程、DDoS 缓解实践、客户去聚合、云迁移和紧急故障转移进行验证。一个在策略上简洁的 maxLength 值可能在运营上是错误的。

ARIN 的ROA 请求文档和 APNIC 的路由起源授权文档提供了跨 RIR 的有用比较背景。它们表明 ROA 管理不仅仅是 RIPE 的问题。各地区的资源持有者都需要理解前缀授权和最大长度如何影响路由有效性。不同的注册机构提供不同的界面和指导，但基本责任是共同的。

当组织所有权不明确时，问责问题就会出现。网络工程师可能了解当前路由通告。注册管理员可能有权限创建 ROA。安全团队可能推动无效路由拒绝。客户团队可能了解 DDoS 提供商或流量工程需求。如果这些角色不协调，一个 ROA 可能在一个团队的思维模型中“正确”，但在生产中出错。

成熟的 ROA 变更流程应在发布前将拟定的 ROA 与观察到的 BGP 通告进行比较。应标记会变为无效的更具体通告。应考虑紧急去聚合计划。应要求对高影响前缀进行同行评审。应在发布后立即对新无效项发出警报。应具备可快速执行的回滚路径。这是将普通变更管理纪律应用于路由安全数据。

验证状态是信号，而非道德判决

“有效”和“无效”听起来像道德判断。在 RPKI 起源验证中，它们是技术验证状态。被分类为无效的路由并不一定意味着起源 AS 是恶意的。它可能意味着路由的起源和前缀长度与发布的 ROA 数据不匹配。这可能表明存在攻击、泄露、过时的文档、错误、迁移差距或未在 RPKI 中反映的计划通告。

RFC 9319《BGP 决策中 BGP 起源验证状态的使用》很有用，因为它解决了网络如何处理验证状态的问题。关键点是路由验证是路由策略的一部分。网络必须决定如何在其环境中处理有效、无效和未找到的路由。过于简单的策略可能无法适应每个过渡或例外，而忽略无效路由的策略则会丧失安全收益。

问责因此扩散。资源持有者控制 ROA 的准确性。注册机构提供 RPKI 服务和文档表面。验证器获取并处理 RPKI 数据。网络运营商决定是否拒绝无效路由以及如何监控后果。客户体验可达性影响。不良结果可能涉及多个层面：错误的 ROA 数据、验证器行为、严格拒绝、监控不足和回滚缓慢。

Cloudflare 的RPKI 解释和RPKI 技术细节有助于向更广泛的受众解释该机制。它们也展示了为什么提供商的视角很重要。部署验证的网络不仅需要考虑标准，还需要考虑遥测、推出、例外和客户影响。路由安全不是一个复选框，而是一种运营行为。

因此，公开问责的语言应谨慎。不要说 RPKI “导致”了中断而未说明哪些数据和策略发生了变化。不要说 RIPE NCC “破坏”了可达性，仅仅因为 RIPE 管理的资源出现了 ROA 问题。不要说无效路由拒绝是不负责任的，因为它可能暴露配置错误。精确的问题在于哪个层面出现了错误的数据或策略，以及受影响方是否有足够的监控和回滚证据来快速恢复。

排版说明

采用率提高收益和爆炸半径

MANRS 的文章《RPKI 正在起飞》描述了采用势头和路由起源安全的激励因素。MANRS 的网络运营商行动将 RPKI 置于更广泛的路由安全框架中。这种采用是好的。当更多网络能够拒绝未授权的起源通告时，互联网将受益。但采用也增加了数据质量的重要性，因为更多网络可能基于同一个信号做出行动。

这是成功安全控制的悖论。当控制是可选的且被忽略时，配置错误的影响可能有限，因为只有少数系统使用它。当控制被广泛使用时，其数据质量变得更加重要。DNSSEC、证书颁发机构、身份联合和云 IAM 都展示了这种动态的版本。RPKI 也不例外。网络越重视起源验证，资源持有者就必须越重视 ROA 管理。

CISA 的《保障互联网路由安全》资源将路由安全定位为更广泛的基础设施问题。公共部门的关注很重要，因为路由事件可能影响基本服务、云可达性、政府门户和普通企业。当无效路由拒绝改变谁能到达谁时，RPKI 采用不仅是一个网络运营商的偏好，而成为一个公共韧性问题。

问责的教训不是减缓采用，而是将采用与安全相结合。验证器应可靠。运营商应在大规模拒绝无效路由之前监控无效项。资源持有者应测试 ROA 变更。注册机构应提供可用的指导和工具。客户应在路由起源变更可能影响他们时收到通知。社区项目应同时衡量部署和运营质量。

仅靠采用指标可能误导。显示更多 ROA 或更多验证器的图表令人鼓舞，但它不显示组织是否理解 maxLength、在迁移期间维护记录或监控无效通告。下一个成熟度问题是质量：有多少 ROA 与实际路由实践相匹配，无效项纠正的速度，变更中断可达性的频率，以及工具在发布前向运营商发出警告的效果如何。

RIPE NCC 是服务表面，而非整个控制链

RIPE NCC 的角色很重要，因为它为其区域提供注册和 RPKI 服务、文档和社区参与。RIPE Labs 的RPKI 更新提供了运营和采用背景。但 RIPE NCC 不是每个引用 RIPE 区域资源的路由的自治系统运营商，也不决定每个验证网络的路由策略。公开文章应保持这一界限。

服务表面仍然产生职责。注册界面应使风险选择可见。文档应解释 maxLength 后果。工具应在可行时警告拟定的 ROA 与观察到的路由冲突。运营商应能够无必要摩擦地查找、更新和撤销 ROA。当注册方面服务出现问题时，状态和事件沟通应清晰。这些职责并不使注册机构对每个下游路由决策负责；而是使其对其部分系统的可用性和可靠性负责。

资源持有者也有职责。他们必须知道谁可以创建 ROA，谁批准变更，如何检查路由通告，以及如何处理紧急变更。他们不应将 RPKI 管理视为一次性项目。前缀迁移，ASN 变更，添加 DDoS 提供商，收购发生，流量工程实践演变。ROA 必须随网络一起演变。

执行验证的网络也有职责。他们应理解自己的策略，监控无效丢弃，当路由被拒绝时向客户提供可操作的证据，并避免静默故障。如果客户路由变为无效，提供商应能够告知客户涉及的前缀、起源和 ROA 状态。当验证数据可以识别问题时，模糊的“路由问题”是不够的。

这种职责划分是问责的核心。注册机构提供可信数据基础设施。资源持有者发布授权。验证器处理它们。网络应用策略。客户体验可达性。故障可能需要在该链的任何点进行修复。仅指责一个参与者可能隐藏实际修复方案。

监控应在拒绝之前开始

一种更安全的采用模式是在依赖严格拒绝之前监控验证状态。网络可以观察哪些路由可能变为无效，通知客户，修复记录，然后再转向执行。这并不意味着无限期延迟。这意味着带有反馈的推出。当运营商确信无效路由确实不受欢迎且客户知道如何修复例外时，RPKI 的安全价值会增加。

资源持有者也应从外部监控自己的前缀。他们应知道何时路由从验证器视角变为无效。他们应在 ROA 变更生效、观察到的通告不再匹配授权或新提供商通告前缀但无匹配 ROA 数据时收到警报。内部变更单不够，因为效果是外部的。

回滚很重要，因为 RPKI 数据具有分发和缓存行为。纠正错误的 ROA 可能不会立即恢复所有路由。运营商需要理解传播延迟、验证器刷新行为和服务提供商策略。变更流程应包括预期生效时间和验证步骤。“我们修复了 ROA”与“验证网络现在接受该路由”不同。

客户需要可用的语言。如果他们的路由因 ROA 状态被拒绝，提供商应解释确切的不匹配：前缀、起源 AS、最大长度、当前通告和预期纠正。该证据帮助客户修复记录，而无需将路由事件变成数小时的猜测。它还有助于避免常见支持问题，其中安全、网络、注册和提供商团队各自只看到问题的一部分。

最强的监控文化将无效状态视为共享警报。资源持有者看到它。提供商看到它。注册工具帮助预防它。客户支持路径可以解释它。这种文化将 RPKI 从一个脆弱的安全开关转变为受管理的控制。

剩余未知和问责问题

公开记录不包含每个 ROA 错误、每个客户可达性影响或每个验证网络执行决策的完整清单。一些中断可能由 ROA 数据引起；其他可能由本地路由策略、验证器故障、提供商过滤、运营延迟或无关网络条件引起。没有路由证据，很容易过度将损害归因于 RPKI，仅仅因为验证可见。

这些未知应产生谨慎的语言，而非瘫痪。问责问题是谁控制了使路由有效、无效、被接受、被拒绝、被检测和恢复的数据和决策。资源持有者控制 ROA 内容。注册机构控制服务和界面。验证器控制数据处理。网络控制路由策略。提供商控制客户沟通。客户控制变更请求和紧急协调。每个层面都应留下证据。

修复证据应具体。什么发生了变化？涉及哪个前缀和 ASN？设置了什么 maxLength？哪个观察到的通告变得无效？哪些网络拒绝了它？问题何时被发现？谁纠正了 ROA 或通告？验证状态用了多长时间恢复？客户是否被通知？变更流程是否已更新，使同样的错误更难重复？

该证据保护 RPKI 的合法性。当用户认为安全控制可能神秘地中断服务时，信任会丧失。当故障是可解释、可修复且罕见时，信任会增长。目标不是使路由起源安全更不严格，而是使其更安全地严格运营。

共模教训

当共享信号改善安全时，互联网受益。RPKI 为网络提供了一种减少路由劫持和错误起源的方法。同一共享信号在错误时可能造成共模依赖。这不是反对信号的论点，而是支持纪律管理的论点。

共模教训应塑造运营商编写程序的方式。RPKI 变更应经过同行评审。高影响前缀应有额外检查。DDoS 缓解和流量工程计划应在需要前反映在 ROA 中。收购和 ASN 迁移应触发 ROA 审查。验证状态监控应成为正常网络运营的一部分。客户支持应知道如何诊断无效路由。公开指导应同时强调采用和运营卫生。

对于 RIPE NCC 和其他注册机构，可用性很重要。良好的安全基础设施应帮助用户避免危险错误。界面可以显示观察到的路由冲突，解释 maxLength，警告可能的无效项，并使回滚清晰。文档可以展示紧急去聚合、多起源场景和提供商变更的示例。社区参与可以将事件教训转化为更好的工具。

对于网络，拒绝策略应与告警和客户解释相结合。静默丢弃无效路由的提供商可能改善全球安全统计，同时造成不透明的客户损害。拒绝无效路由并提供精确诊断证据的提供商则能加强安全和信任。

对于客户，教训是将路由安全记录视为生产资产。ROA 不是远离运营的存档文件。它是一个可能决定流量是否到达的控制。正确的所有者不仅是有注册登录权限的人，而是理解路由、安全、客户影响和紧急回滚的跨职能所有者。

这就是为什么 ROA 错误属于风险与问责系列。它们展示了安全改进如何变成运营依赖。互联网越擅长使用 RPKI，以证据、关怀和谦逊运营 RPKI 就变得越重要。

对象模型应在注册团队之外也被理解

RPKI 拥有一个技术对象模型，可能看起来远离日常服务交付。社区文档中的RPKI 介绍解释了证书、ROA、仓库、验证器和依赖方的角色。该结构很重要，因为当只有一名专家群体理解它时，错误可能出现。如果注册管理员在没有网络运营背景的情况下创建 ROA，或者网络团队在没有注册背景的情况下更改通告，控制可能会漂移。

负责任的组织应将对象模型转化为平实的运营职责。谁拥有证书颁发机构账户或注册门户？谁可以创建、编辑或删除 ROA？谁批准针对高价值前缀的变更？谁将拟定的 ROA 与当前 BGP 通告进行核对？谁了解在正常运营期间哪些提供商通告前缀？谁了解在 DDoS 缓解期间可能出现哪些更具体的通告？当路由变为无效时，谁收到告警？

这些问题很常见，但它们防止了典型的控制失败：权限与知识分离。有权发布 ROA 的人可能不了解所有流量工程实践。了解路由的人可能没有注册访问权限。安全团队可能在不理解传统去聚合计划的情况下推动严格验证。客户支持团队可能从无法访问服务的用户处收到工单，但可能不知道如何解释 RPKI 有效性。

修复方法是跨职能所有权。ROA 变更不应是隐藏的注册操作。它应是一个带有安全影响的网络变更。这意味着同行评审、变更单、影响评估、验证检查、回滚计划和变更后监控。对于低风险变更，程序不必很慢，但它需要认识到前缀何时支持基本服务、云客户、政府门户、金融流量或大量用户群体。

对象模型也有助于外部沟通。如果提供商告诉客户路由无效，因为 ROA 只授权了更短的前缀，客户可以采取行动。如果提供商只说“RPKI 错了”，客户可能不知道是编辑 ROA、撤回路由、更改起源 AS、联系注册机构还是等待验证器刷新。好的术语缩短了中断时间。

迁移是 ROA 漂移的高风险时刻

ROA 错误在变更期间更可能出现：网络迁移、ASN 过渡、提供商变更、收购、DDoS 提供商接入、云端迁移、流量工程重新设计或紧急故障转移。路由计划发生变化，但授权数据可能滞后。昨天有效的前缀，当由新的 AS 或作为更具体路由通告时，可能变得无效。该路由可能在运营上有意，但在密码学上未授权。

收购尤其危险。一家公司可能继承前缀、ASN、注册账户、旧路由对象、未知客户和分散的文档。收购方网络可能在每个授权记录更新之前通告路由。遗留团队可能知道为什么选择了某个 maxLength，但这些团队可能离开。如果上游网络普遍执行严格验证，整合可能变成可达性事件。

DDoS 缓解创造了另一个风险。在攻击期间，组织可能需要通过清洗提供商通告更具体的前缀。如果 ROA 没有授权该起源和前缀长度，验证网络可能正好在组织最需要时拒绝缓解路由。安全控制和防御性紧急控制可能冲突。规划可以防止这种冲突。

负责任的程序是将 ROA 审查附加到每个可能改变起源或前缀长度的网络变更类别。提供商接入清单应包括 RPKI。DDoS 合同应指定将使用哪些前缀和起源，以及 ROA 是否已授权它们。收购清单应盘点 RPKI 记录。云端迁移应将计划路由与 ROA 进行比较。紧急预案应包括预先批准的 ROA 更新或经过测试的替代方案。

这可能感觉繁琐，但负担比可达性故障小。变更控制的目的是在平静时刻完成工作。如果组织只在中断期间发现 ROA 漂移，每一分钟都变得昂贵。如果在规划期间发现漂移，修复是常规操作。

客户支持是路由安全运营的一部分

路由安全故障通常以客户投诉的形式出现，然后才被诊断。客户报告某些网络无法访问某项服务。监控系统显示某些提供商的流量下降。服务台看到看起来区域性或间歇性的报告。如果支持团队不了解路由起源验证故障的表现，他们可能将问题误分类为托管、DNS、应用程序或最后一英里连接问题。

支持团队不需要成为 BGP 专家，但他们需要升级线索。如果服务部分网络可达而部分不可达，如果路由收集器显示无效状态，如果刚刚添加了新提供商或 DDoS 服务，或者如果受影响的前缀最近更改了 ROA，则应升级到网络运营。支持记录应包括源网络、有用的 traceroute、时间戳、受影响的前缀和客户影响。良好的接单拯救工程师重建基本事实。

拒绝无效路由的提供商也应准备好向客户解释拒绝原因。路由因 ROA 不匹配而被丢弃的客户需要精确证据。提供商应识别无效路由、期望的授权、观察到的起源和验证源。这类似于电子邮件认证支持：告诉客户“您的邮件认证失败”不如显示 SPF、DKIM 或 DMARC 原因有用。路由安全需要同样面向客户的清晰度。

这个支持维度是问责的一部分，因为用户经历了伤害。路由起源验证问题在图表上可能很优雅，但客户看到的是可达性丢失、交易失败、服务不可用或声誉损害。支持越快将症状转化为路由证据，组织就能越快修复控制。

支持证据也改进了事后审查。哪些客户最先报告？哪些网络受影响？诊断用了多长时间？涉及哪些团队？支持是否有正确的升级路径？客户是否收到清晰解释？这些问题表明 RPKI 运营是集成了服务运营还是孤立在专家角落。

注册界面可以减少错误，但不能替代所有权

注册机构和 RIR 可以使 ROA 管理更安全。界面可以警告观察到的无效项，解释 maxLength 选择，显示当前通告，标记常见错误，要求对高影响变更进行确认，并使删除或回滚易于理解。文档可以包括迁移示例、DDoS 提供商示例、多起源场景和客户支持诊断。更好的工具减少错误。

但工具不能替代所有权。注册界面可能不知道每个未来的紧急通告。它可能不知道客户的私人流量工程计划。它可能不知道哪个前缀是关键任务。它可能不知道更具体的路由是临时的、恶意的还是计划内的。人力和组织背景仍然重要。资源持有者仍然负责使授权数据与实际路由策略对齐。

这种平衡对于分配问责很重要。如果注册界面令人困惑或未能警告明显冲突，注册机构应改进。如果资源持有者忽略警告或在没有网络审查的情况下发布 ROA，资源持有者承担该选择。如果验证网络在没有客户诊断的情况下丢弃无效项，网络承担运营不透明性。关键不是找一个反派，而是识别可修复的层面。

同样的原则适用于所有 RIR。APNIC 和 ARIN 的文档表明，ROA 创建是一个全球性运营任务，而非单区域特点。每个区域都有自己的门户、文档和社区实践，但拥有跨国网络的资源持有者可能需要跨注册机构管理 ROA。这增加了对内部标准的需求。公司不应依赖每个本地团队发明自己的 RPKI 习惯。

强大的内部标准应定义命名、所有权、审查、测试、监控、紧急变更、审计频率和客户沟通。应确定谁可以批准宽泛的 maxLength 值，谁可以批准可能降低灵活性的窄值。应记录每个高影响 ROA 存在的原因。该记录使后续故障排除成为可能。

路由起源安全应与业务连续性挂钩

组织通常将 RPKI 归类为网络安全。它也是业务连续性。如果前缀因无效路由拒绝而变得不可达，影响可能是交易失败、SaaS 产品不可用、政府门户无法访问、客户门户损坏或收入损失。业务所有者可能不知道 ROA 这个词，但业务依赖于结果。

这意味着业务连续性计划应包括路由安全依赖。哪些产品依赖哪些前缀？哪些前缀有 ROA？哪些提供商执行无效拒绝？哪些 DDoS 或故障转移路由已授权？哪些面向客户的服务会受到 ROA 错误的影响？如果网络变更后可达性下降，必须联系哪些团队？

对于关键服务，ROA 变更应进行风险排序。小型实验室前缀和生产支付前缀不应接受相同的审查。公共机构或医疗系统使用的前缀可能需要额外监控。拥有许多下游客户的前缀可能需要规划客户通知，然后进行重大起源变更。业务影响应塑造技术控制程序。

连续性视角也改变了测试。网络团队可能确认一条路由在一个验证器中有效。业务连续性测试询问关键市场的用户是否可以通过执行验证的提供商访问服务。它询问监控是否从用户侧捕捉问题。它询问支持是否收到有意义的警报。它询问回滚是否在可接受时间内工作。这些测试连接路由和服务。

安全团队应欢迎这种连接。它防止 RPKI 被视为偶尔破坏东西的专业任务。当业务所有者理解准确的 ROA 保护可达性免受劫持和错误时，他们更可能支持流程。当它们理解管理不善的 ROA 可能破坏可达性时，他们更可能资助监控和所有权。

采用故事应包括负面测试

随着 RPKI 采用的增长，组织不仅应测试成功路径，还应测试失败路径。如果计划中的更具体通告未授权，会发生什么？如果 ROA 被意外删除，会发生什么？如果验证器提供过时数据，会发生什么？如果提供商开始更严格地拒绝无效项，会发生什么？如果 DDoS 提供商在紧急情况下通告前缀但验证失败，会发生什么？

负面测试将理论变为证据。测试可能揭示告警缺失、支持无法诊断无效状态、注册访问依赖单一员工或回滚时间超出预期。这些发现之所以有价值，正是因为它们在客户受损之前出现。RPKI 运营应像事件响应一样进行桌面演练和技术演练。

测试应精心设计以避免影响生产。实验室前缀、维护窗口、模拟和路由监控演练可以在不引入不必要风险的情况下提供学习。目标不是为练习制造中断，而是了解组织在验证问题发生时能否检测和修复。

社区项目可以鼓励这种成熟度。MANRS 风格的采用信息当它结合“部署 RPKI”与“良好运营 RPKI”时最强。公开指导可以包括变更审查、监控、客户沟通和回滚的检查表。案例研究可以描述错误而不将其变成指责剧场。路由社区从诚实的运营细节中学习。

负面测试也保护信心。如果组织知道它可以从 ROA 错误中快速恢复，它可以更自信地部署验证。如果它从未测试失败路径，严格强制执行可能感觉冒险。良好的运营使强安全更容易采用。

最终的问责问题是对齐的证据

ROA 相关的可达性事件后，真正的问题是授权数据、路由实践和验证策略是否对齐。如果没有对齐，为什么？ROA 是否过期？maxLength 是否太窄？网络是否从错误的起源通告？提供商是否在没有通知的情况下执行无效拒绝？验证器行为是否异常？监控是否错过了问题？回滚是否滞后？每个答案都指向不同的纠正措施。

对齐的证据应是常规性的。资源持有者应能展示当前前缀、起源、maxLength 值、观察到的路由、提供商和验证状态。网络应能展示它如何处理无效项以及如何通知客户。注册机构应能展示服务状态和清晰指导。面向客户的服务应将业务影响映射到路由起源控制。这些不是奇特的产物，而是现在影响可达性的安全控制的运营记录。

公开辩论有时将安全与可用性视为竞争价值。RPKI 表明它们相互交织。更好的起源验证通过防止劫持和泄露来保护可用性。运营不良的授权数据可能通过错误的无效项危害可用性。答案不是选择一个价值，而是运营控制使两个价值都提高。

这就是 RIPE NCC、其他注册机构、资源持有者、验证器、网络和客户的问责标准。每一方应知道自己的层面，为其层面提供证据，并在验证信号产生可达性风险时合作。共享的安全基础设施值得共享的纪律。

RPKI 变得越好，弱运营的容错度就越低。如果组织以审查、监控和透明修复回应，这是一种健康的压力。路由起源安全应使互联网更难被劫持，并在错误发生时更容易解释，尤其是在公共服务压力和审查之下。