摘要
- RPKI 到路由器链路将授权与行动分离开来。资源持有者和认证机构发布签名对象；依赖方软件验证它们并导出已验证的有效载荷；路由器对路由进行分类；运营商决定 Valid、Invalid 和 NotFound 在本地导入、最佳路径和导出策略中的含义。
- RFC 8481 在 2018 年明确了这一边界：实现应设置验证状态，但除非运营商明确配置，否则不应应用任何策略。做出最终处理决定的是运营商，而非注册机构或验证器。
- 本地控制并不意味着上游参与方无关紧要。错误的证书、撤销、ROA 或存储库状态可以改变所有正确遵循它的下游分类。因此，责任必须根据所控制的行为来划分，而不是完全分配给注册机构或承载路由的网络。
- “Invalid”（无效）是根据某一时刻可用已验证数据得出的密码学和语法结果。它是路由策略的有力证据，但并不指明根本原因是劫持、持有者错误、转移延迟、不正确的 maxLength、不利的证书操作还是陈旧的验证数据。
- 路由器策略不是单一的二元开关。网络可以拒绝 Invalid 路由，保留它们但使其无资格参与最佳路径选择、降低优先级、按对等体类别限制处理方式、先发出告警，或维持狭窄的本地例外。每种选择对安全性、可达性和可恢复性都有不同的影响。
- 运维链具有时序和状态特征。RPKI 路由器协议会话携带来自缓存的宣告和撤销，使用序列号和会话标识符，并指定刷新、重试和过期行为。注册机构处的更正必须等到发布、验证、缓存传输和路由器重新评估全部汇聚完成后，才能成为修复后的转发决策。
- 治理应当要求每个边界处都有决策凭据：签名对象及其变更原因、验证器版本和信任输入、缓存序列和年龄、路由器策略版本、受影响的对等体类别、观察到的路由后果、例外授权和恢复时间。缺乏这些证据的标签，对于申诉或责任归属都过于单薄。
- 一个号码资源协会可以比较这些边界、测试纠正路径并代表较小的运营商，而无需成为全球路由控制者。其效用在于使授权与补救措施清晰可辨，同时保留运营商决定本地路由策略的权利与职责。
最终决策按设计是本地化的
现代源验证中意义最深远的一句话，并非出自注册机构合同或路由器命令指南。它出现在 2018 年 9 月发布的 RFC 8481 中：一旦路由经过评估并设置了验证状态，运营商应当完全控制基于该状态应用的策略。如果没有特定的运营商配置，策略不得被应用。该标准的指示是“设置状态，但不采取行动”。
这一区分回答了那个具体问题：谁最终决定一条 Invalid 路由的处理方式。答案是网络运营商。RIR 可以操作信任锚点、颁发证书、托管认证服务并发布对象。资源持有者可以在 ROA 中授权一个源 AS。验证器可以检索存储库、验证证书路径并生成已验证的 ROA 有效载荷。路由器可以将 BGP 宣告与这些有效载荷比对并附上状态。上述任何步骤本身，都不能单独决定某个特定网络是从客户那里接受该路由、优选对等体传来的路由、将其导出至转接提供者，还是将其安装到转发表中。
这个答案只有当我们把“决定”理解为最后配置的动作时才显得简单。当“决定”与“导致”相混淆时，问题就变得复杂了。注册机构的错误可能导致正确的验证器移除一项授权。正确的缓存可能导致路由器重新分类一条长期存在的路由。厂商的默认设置可能使策略比运营商所理解的更具侵略性。转接提供者的拒绝可能导致持有者无法访问，即使持有者自己的网络仍继续接受该路由。多个机构可能具有重要的因果作用，但每个本地路由决策仅由一家网络管理部门控制。
这种分布是域间路由的一项结构性特征。自治系统之所以自治，部分原因在于它们选择与谁连接以及使用哪些路由。将注册机构的签名对象变成通用的远程控制指令，将把路由权力集中于认证等级体系，并抹杀风险、客户义务和本地知识方面的差异。反之，假装注册机构只是发布无害信息，则低估了其经过认证的对象对自动化策略所能产生的强大影响。
良好的治理必须同时秉持这两种观点。认证机构对其所控制的声明和状态变更负责。运营商对其选择的路由策略及其应用策略时的韧性负责。缺失的层面并非两者之间的一个新的中央决策者，而是跨越边界对职责、证据和补救措施的清晰分配。
四个动词使一个机构无法承袭所有职责
公开讨论常常将源验证压缩为一个动词：“RPKI 阻止劫持”。这个说法对于宣传很有用，但对于制度分析则很糟糕。实际上涉及四个不同的动词：授权（authorize）、验证（validate）、分类（classify）和行动（act）。每个动词都有不同的主体、证据基础和补救措施。
持有者通过颁发或请求基于证书路径的 ROA 来授权一个源。在托管服务中，RIR 可能控制更多的密钥和发布操作；在委托安排中，持有者可以更直接地控制。认证等级体系确定签署者是否拥有相关的号码资源授权。所产生的对象表明某个 AS 被授权在指定的长度边界内发起一个前缀。它并不在 BGP 中宣告该前缀，也不承诺该路由在商业上可被接受。
依赖方进行验证。它检索签名对象，检查证书、撤销列表、清单和对象配置文件，并根据标准和本地信任配置构建当前可用的有效载荷集。这是对经过认证的数据的计算性判断。不同的验证器实现或存储库视图可能暂时存在分歧。本地过滤器和断言也可能产生与全局数据故意不同的视图。
路由器通过将其源和前缀与已验证的有效载荷比对来对路由进行分类。我们熟悉的状态是 Valid、Invalid 和 NotFound。Valid 意味着至少有一项相关授权匹配。Invalid 意味着存在覆盖性的授权数据，但没有一项授权同时匹配所观察到的源和前缀长度组合。NotFound 意味着没有相关的已验证载荷覆盖该路由。该状态描述的是这种比对；它并不是对该路由历史或合法性的完整说明。
最后，运营商采取行动。其策略可以拒绝、优选、降低优先级、隔离、标记、记录或临时例外处理一条路由。这些策略可以按客户、对等体、转接、路由服务器、地址族、地区或关键服务而有所不同。它们与前缀过滤器、IRR 数据、最大前缀限制、团体属性、商业偏好和最长前缀转发相互作用。一条以低优先级保留的路由，当其比一条竞争性聚合路由更具体时，仍能吸引流量，RFC 7115 警告运营商不要忽视这一点。
这些词汇之所以重要，是因为责任应当跟随控制权。签署者应对错误授权负责。验证器维护者应对在其提供的保证范围内可复现的验证缺陷负责。缓存运营者应对其承诺运营的不安全或陈旧的分发服务负责。网络应对自身的策略和测试负责。任何一层都不应被允许一边宣称其输出的权力，一边将各种后果描述为他人的问题。
Invalid 是一种状态，而非对动机的裁定
Invalid 分类比传闻更精确，但比司法裁定更狭窄。在源验证中，它意味着至少有一条已验证的有效载荷覆盖了该路由的前缀，但没有任何一条有效载荷既覆盖所宣告的长度，又指明所观察到的源 AS。这个数学结果并不说明不匹配的原因。
这种不匹配可能是一次源劫持企图。也可能是资源持有者在更改其 ROA 之前更换了转接提供商，或者是运营团队宣告了一个超出 maxLength 的更具体前缀，或者是转移过程中证书状态在路由协调完成之前发生了变化，或者是注册机构的操作意外地移除了授权。验证器可能拥有比运营商的变更工单所预期更新的存储库视图。路由器可能正在使用一个缓存，而工程师的诊断工具则查询另一个缓存。本地断言可能修复或产生差异。所有这些情况都能在命令行上产生相同的三个字母的状态。
这并不使 Invalid 成为弱证据。源验证的目的是将经过认证的授权转换为可用的路由信号，而拒绝 Invalid 路由会实质性地提高意外和恶意误源宣告的成本。该分类旨在支持行动。但一项安全控制只有在能够区分即时遏制和最终归因时，才是可治理的。
运营商可以合理地首先拒绝 Invalid 路由，事后再进行调查，尤其是在没有经过认证的客户例外的对等体或转接边缘。这种即时行动是一项本地安全判断。如果受影响的持有者声称存在错误，问题就变了。此时各方需要确切的前缀、源 AS、覆盖的有效载荷、maxLength、验证器时间、缓存序列号、路由器策略以及首次观察到的状态转换。他们需要知道是否存在其他匹配的授权、是否发布了撤销以及不同视图的汇聚速度。
将每个 Invalid 视为恶意行为的证据，剥夺了有意义的纠正权利。将每个 Invalid 视为无害的配置噪音，则破坏了保护作用。可行的中间道路是程序性的：根据声明的策略进行遏制，保留证据，提供经过认证的升级途径，对原因进行分类，在引入该问题的层面进行纠正，并度量恢复情况。这样的程序既尊重自动拒绝的价值，也承认经过认证的数据可能出错。
因此，治理问题不在于该标签是否应被信任，而在于该标签支持什么主张、在多长时间内、基于哪些输入，以及当一个具有合法利益的个人对其提出质疑时会发生什么。
注册机构的权力是巨大的，但止于转发表
RIR 占据着强大的位置，因为 RPKI 证书等级体系遵循号码资源管理。它们运营着区域信任锚点和相关服务，维护注册关系，并发布依赖方所依赖的证书材料。在托管安排中，它们可能根据持有者经过认证的指令生成并发布 ROA。撤销、资源集变更或发布故障都可能改变验证器所产生的有效载荷。
这是真正的权力。将 RPKI 仅仅称为一个可选的数据库，掩盖了密码学优先性和自动化消费的效果。一旦许多网络拒绝 Invalid 路由，一个错误的上游变更就可能转化为跨独立网络的可达性损失。每个运营商自由地配置了拒绝这一事实，并不使错误的证书状态无关紧要。一座桥梁的权威不能仅仅因为每个司机选择遵守信号灯，就否认自身错误信号的责任。
然而，一个 RIR 并不操作全世界的 BGP 发言者。它不可能知道每一项双边对等条款、紧急服务依赖、私有路由、客户维护窗口或本地例外。它不能强迫一个网络拒绝一条 Invalid 宣告，也不应能通过未记录的默认设置做到这一点。RFC 8481 的运营商控制规则防止验证软件悄悄地将注册机构状态转换为路由策略。
这一边界应当通过服务承诺来表达。注册机构应当保证经过认证的控制、对持有者指令的准确处理、受保护的关键操作、一致的发布、通知、纠正以及在限定范围内的记录保存。它们应当公布证书和 ROA 变更是如何授权的，存在何种紧急渠道，记录了哪些时间戳，以及如何对不利或错误的操作提出质疑。它们无需保证每个网络都承载每条已纠正的路由，也无需补偿所有间接商业损失。
反过来，运营商不应将注册机构未做出的选择归咎于注册机构。一个网络在未监控缓存年龄、未测试重新评估或未提供客户升级途径的情况下就实施拒绝，须对这些设计决策负责。一个提供商因为其路由器丢弃了路径且从未恢复而忽略一条已纠正的有效载荷，则承担另一种不同的失误。一个网络出于商业便利而继续接受一条已知的误源宣告，不能将这种接受描述为受 RIR 所迫。
可见的边界使责任更强而非更弱。它们识别出能够进行修复的机构。注册机构可以修复授权状态。验证器运营者可以纠正检索或验证过程。路由器厂商可以修复实现漏洞。网络可以更改策略并恢复路由。对共同责任的模糊宣称往往意味着没有人承担修复时效。
验证器是独立的解释者，而非上诉法院
依赖方软件位于签名发布和路由器消费之间。它从分布式存储库收集对象，根据配置的信任锚点验证它们，应用验证规则并产生一组有效载荷。RFC 8897 整合了针对这一角色的许多要求，而独立的实现在解析、检索、缓存处理和发布实践方面提供了有益的多样性。
验证器的自由裁量权是有限的。它可以拒绝一个格式错误的对象，将一个过时或被撤销的链视为不可用，在标准范围内选择存储库传输行为，并暴露诊断信息。它不能宣布一条经过正确认证的 ROA 是不公正的，并仅仅因为运营商对注册机构有异议就替换为不同的全局授权。如果它这样做，软件维护者就会成为未经任命的、对号码资源权力进行裁决的上诉机构。
尽管如此，本地自治仍然存在。RFC 8416 定义了 SLURM，允许运营商过滤已验证的有效载荷或添加本地断言。这可以在不利操作期间保护路由，或允许使用全局 RPKI 无法代表的私有用途。重要的修饰词是“本地”。一个例外会改变该运营商及其有意向其提供修改后视图的任何客户所使用的视图。它并不为其他网络重写签名状态。
因此，验证器运营包含着应当予以声明的治理选择。接受了哪些信任锚点定位符？是否加载了任何本地过滤器或断言？启用了哪些存储库传输？如何处理陈旧数据？正在运行哪个验证器版本和密码学库？路由器是接收一个缓存视图还是在多个视图之间选择？谁可以批准一个例外，该例外可以多狭窄，何时到期，以及什么证据将关闭它？
运行多个验证器是有价值的，但其本身并不能回答这些问题。两个实例可能共享一个存储库路径、信任配置或软件包渠道。当它们的输出不同时，多数表决可能保存一个陈旧状态，就像它可能识别出一个缺陷一样容易。有用的比较应解释对象和输入层面的差异：获取了哪些字节，接受了哪条证书路径，输出了什么序列号，以及添加或撤回了哪条有效载荷。
这也是验证器不应吸收路由策略的原因。它们应当提供高质量的状态、出处、存续时间和错误信息。路由器和网络策略层应决定运营处理方式。将验证和拒绝结合在一个不透明的托管服务之后可能很方便，但它掩盖了最重要的交接点：即经过认证的声明变成连接性决策的那一刻。
RPKI 路由器协议传递的是状态，而非机构同意
RFC 8210 描述了从已验证缓存到路由器的实际桥梁。路由器与一个或多个缓存建立关系，根据配置的偏好进行选择，并请求完整或增量的数据集。会话标识符区分不同的缓存实例；序列号标识一个会话内的逻辑版本。前缀宣告和撤销添加或删除确切的已验证记录。数据结束（End of Data）消息完成一个连贯的更新，并携带时间参数。
这些细节对运营很重要，因为策略是应用于随时间变化的状态的。缓存可以通知路由器有新数据可用，但该通知只是一个提示；路由器仍需查询。如果增量历史不可用，路由器可以重置并请求一个完整数据集，或转移到另一个缓存。如果会话身份意外更改，可能需要清除过时记录。在缓存到路由器协议中，一次撤销会移除一条先前宣告的具有相同前缀、最大长度和 ASN 的权利。
时间模型创建了一个有限的连续性窗口。刷新间隔指示路由器何时应再次轮询。重试间隔控制失败后的尝试。过期间隔限制当前缓存数据在没有成功续订的情况下可以继续使用的时间。RFC 8210 推荐的默认值是工程参数，而非普遍的服务承诺，部署可以根据指定范围配置值。从机构角度看，重要的是过时的授权不会仅仅因为缓存连接失败而拥有无限的生命期。
同时，过期可能改变可达性风险。当已验证数据消失时，路由可能转向 NotFound 处理或其他实现特定状态，具体取决于架构和策略。一种仅拒绝 Invalid 路由的设计可能在过期后开放故障；一种将验证丢失作为广泛拒绝理由的设计可能封闭故障，并断开合法网络的连接。标准传输行为无法选择运营商应该偏好哪种连续性风险。
协议的存在可能诱使机构过度解读消息。一个前缀 PDU 并非从 RIR 到路由器的指令。它是路由器运营商所信任的缓存发出的数据，源于该缓存的已验证视图。其序列号证明了该缓存会话内的顺序，而非注册机构间的一致性或某项对等合同下的许可。路由器对它的使用仍然是配置的本地行为。
一个可治理的部署会记录这一交接。它可以显示哪一缓存会话和序列号提供了用于有争议决策的有效载荷，路由器何时接受了它，后续的撤销何时到达，以及受影响路径何时被重新评估。没有这份记录，运营上最关键的一步留下的证据，就会少于上游的证书仪式。
路由器提供若干种处理方式，每种对应的补救措施不同
厂商和开源路由器的文档证实，源验证并不强加一种普遍的操作。思科（Cisco）的示例展示了对 Valid、NotFound 和 Invalid 路由分配不同本地优先级的策略，也提供了保留 Invalid 路径但阻止其成为最佳路径的替代方案。瞻博（Juniper）指南将对验证状态进行标记的策略，与稍后拒绝 Invalid 路由的术语分离开来。FRRouting 暴露了针对相同状态的 route-map 匹配，并可以降低优先级而非丢弃路径。
第一种处理是导入时的硬拒绝。它阻止该路由在该边界处进入可用的 BGP 决策集。这提供了清晰的保护，但如果实现没有保留被拒绝的路径，可能会使恢复变得复杂。当纠正后的 ROA 到达时，路由器可能需要存储的策略前路由、软重配置或向邻居发起路由刷新。RFC 9324 论述了当新的 RPKI 数据触发繁重的刷新时所造成的危害，并建议保留受 RPKI 策略影响的路径，以便在本地进行重新评估。
第二种处理是保留路径，但使其无资格参与最佳路径选择。当验证状态改变时，它可以快速恢复，因为路由仍可用于重新评估。它会消耗内存，并要求确保路径不会意外泄漏到转发或导出中。证据应当区分“为恢复而保留”和“作为可用项接受”。
第三种处理是降低优先级。这可以支持分阶段部署或特定于客户的过渡，但它并不等同于安全。如果 Invalid 路由是唯一的路径，它仍可能获胜。如果它比一条 Valid 聚合路由更具体，最长前缀转发可能会吸引流量，而无论 BGP 优先级是否较低。例外必须围绕实际的转发后果来设计，而不仅仅是路由表的外观。
第四种处理是先监控和标记，然后再强制执行。它给予运营商时间来识别客户错误、建立升级服务并测试设备。其弱点显而易见：单纯的观察并不能阻止劫持。因此，一个分阶段的计划需要设定日期、阈值和可问责的批准，而非无限期的试点。
最后，运营商可以应用狭窄的本地例外。在纠正期间，为经过验证的持有者设置例外可能是合理的，但它应当指定前缀、源、受影响的会话、批准人、证据、到期时间和复审。一个宽泛的永久性绕过手段会悄悄地创建第二个授权体制。针对错误拒绝的补救措施和针对不安全例外的控制措施是同一回事：带有保留决策记录的、精确的、有时间限制的状态。
对等和转接将一种状态转变为不同的义务
网络并非在法律真空中接收路由。客户会话、免结算对等会话、转接馈送和路由服务器会话承载着不同的期望。源验证作为一项输入进入这些关系，与前缀授权、导出范围、流量工程、最大前缀保护和商业偏好并列。
转接提供商通常承诺可接受使用和路由安全条款下的可达性。如果它拒绝一条客户的 Invalid 路由，该客户需要清晰的通知以及一种经过认证的方式来证明授权已被纠正。提供商可能有充分理由进行拒绝，但它仍应指明前缀、观察到的源和验证证据。“互联网说它是 Invalid”并非一个充分的服务回应，因为并没有一台单一的互联网路由器在做出这个决定。
在对等边缘，一个网络可能没有义务承载每条路由。它可以将严格策略作为交换的条件。然而，透明度仍然重要，因为错误的分类可能同时影响双方对等体及其客户。对等协调员需要知道拒绝是来自本地网络、路由服务器、验证服务，还是传播的状态团体属性。跨 iBGP 或路由服务器安排使用源验证扩展团体属性可以分发状态，但 RFC 8481 警告，除非运营商配置了自动操作，否则不应自动采取行动。
路由服务器使边界尤为明显。它们可能代表许多成员进行验证和过滤，或仅附加信息并让每个成员自行决定。一项共享服务可以提高一致性并降低部署成本。但它也可能将一个配置错误成倍放大到整个交换中心。因此，其策略、例外权利、缓存输入和变更通知应当明确出现在服务条款和技术文档中。
下游客户使归因变得复杂。一个小型网络可能不运营验证器，而只能接收到上游的有效策略。其路由可能在远离发布数据的 RIR 的地方被拒绝，且没有通向那个遥远运营商的合同路径。这正是集体机构可以发挥作用的地方：标准化的通知和可互操作的证据，减少小型持有者与每个过滤网络单独协商的必要。
商业自治不应变成信息上的免责特权。一个网络可以保留拒绝任何路由的权利，但如果它以 RPKI 执行为名呈现该拒绝，它就应当能够显示是哪种状态和策略产生了该拒绝。这种最低限度的披露在不必强制承载的情况下，维护了准确的责任归属。
改正并非在 ROA 改变时即告完成
运维链是异步的。持有者可以在门户中纠正一条 ROA，但仍然无法被访问。新对象必须生成并发布。存储库客户端必须获取它。验证器必须认证一个连贯的当前视图并更改其有效载荷集。缓存必须通知路由器或等待其轮询。路由器必须接收添加或撤销，重新计算验证状态，并重新应用策略。如果路径被丢弃，邻居可能需要重新评估。然后流量必须重新汇聚。
每个阶段都可能成功，而最终结果仍然是坏的。RIR 可以展示其存储库中已被纠正的对象，而某个验证器却无法获取该发布点。验证器可以显示正确的有效载荷，而路由器却固定在一个失败的优选缓存上。路由器可以更新状态，但保留在变更前计算出的策略结果。一个边界集群可以恢复，而另一个集群的数据已经过期。提供商可以恢复导入，但继续阻止向对等体导出。
因此，有意义的服务度量不是“门户确认时间”，而是从经过认证的纠正请求到在所声明的检查点处观测到恢复的时间。这些检查点无需包含地球上的每一个网络。它们应当包括发布者的发布行为、至少两个独立的验证视图（如可用）、受影响提供商的缓存和路由器状态，以及具有代表性的外部 BGP 收集器或客户探针。
RFC 9324 增加了一个重要的恢复教训。如果路由器丢弃了 Invalid 路径，并且没有保留足够的策略前状态，新的 RPKI 数据可能提示向邻居发起路由刷新请求。在大规模情况下，这曾导致严重的负载甚至解除对等关系。因此，为本地重新评估而保留受影响的路径，不仅仅是性能改进；它是纠正权利的一部分。如果网络已经忘记了该路由并且没有安全的方式恢复它，持有者的授权就无法被及时修复。
这一链条也解释了为什么固定的全局截止时间可能产生误导。发布频率、存储库健康、验证器轮询、缓存定时器、路由器架构和 BGP 汇聚各不相同。治理应当指定在受控阶段的可度量目标，并报告观测到的端到端恢复情况，而不是承诺一个不可能的普遍瞬间。
一份纠正凭据应当包括旧的和新的对象标识符、发布时间、验证器首次发现时间、有效载荷变更、路由器首次应用时间、路由重新评估方法和外部观测。这为事后改进以及任何关于哪个机构延迟了恢复的争议创建了一份记录。
五种故障案例揭示五种不同的责任方
首先，考虑因持有者经过认证的指令而产生的错误 ROA。如果持有者输入了错误的源或最大长度，而注册机构准确地处理了它，则主要的纠正义务在于持有者，而注册机构仍负有提供可用的变更控制措施和警告工具的义务。如果门户错误地转换了一条正确指令，责任则转移到服务运营者。拒绝由此产生的 Invalid 路由的路由器应用了其声明的策略；它并未制造出错误的授权。
其次，考虑注册机构的证书或发布错误，它移除了一条有效的有效载荷。验证器可能达成一致，因为它们正在忠实地处理相同的上游状态。它们的一致并不免除发布者的责任；它定位了原因。运营商仍要决定紧急例外是否合适，但注册机构负有快速恢复、说明原因和保留证据的义务。
第三，假设两个验证器因其中一个拥有陈旧的存储库数据或存在软件缺陷而出现分歧。缓存运营者应当隔离输入差异，软件维护者应当纠正可复现的缺陷。网络必须决定在分歧期间使用哪个视图。简单的多数票是不够的；两个陈旧的实例可以胜过当前实例。决策应当考虑新鲜度、信任输入、对象证据和故障独立性。
第四，假设缓存到路由器连接失败直到数据过期。RFC 8210 阻止无限期保留，但它并不选择网络后续的路由策略。缓存服务对其承诺范围内的可用性负责。运营商对冗余、过期处理以及验证丢失是开放故障还是封闭故障负责。如果实现违背了配置或标准化的行为，厂商负有责任。
第五，假设正确的有效载荷到达了路由器，但策略项的顺序不正确、仅应用于部分会话或继承自厂商默认设置。这是运营商配置失败，可能因不够充分的厂商诊断而进一步加剧。注册机构无法修复它。证据必须包括策略版本、会话范围和路由表结果，而不仅仅是一张 Valid 有效载荷的截图。
这些例子表明，为什么一个笼统的“RPKI 事件”类别是不充分的。相同的可见症状——一个不可达的前缀——可能源于授权、验证、分布、分类或策略环节。事件复盘应当识别出第一个不正确的状态转换，以及每一个失败的遏制或恢复职责。多个参与方可能为不同部分承担责任，而不会使责任变得毫无意义。
权利与补救措施必须在损害发生的边界处可强制执行
治理章程只有在受影响方能够援引它时才有用。持有者需要一条通向认证服务的、经过认证的紧急渠道，一种查看待处理和已发布变更的方式，以及一份持久的收据。当授权被移除时，它需要知道原因，以及一条质疑错误或不利操作的途径。对于日常持有者错误，自助纠正可能就足够了。对于有争议的撤销或法律强制，独立审查和连续性安排则变得更加重要。
运营商的客户需要一种不同的补救措施。它应当能够询问一条路由为何被拒绝，并收到与提供商自身观察相关的答复。提供商应当披露验证状态、缓存时间、覆盖的有效载荷和相关的策略类别，而不暴露无关的网络安全细节。在商业和安全风险允许的情况下，它应当提供一种受到狭窄控制的临时例外程序，但任何客户都不应假定其拥有强制传播的无条件权利。
运营商也需要针对其缓存或托管验证供应商的权利。服务条款应当指明信任锚点、软件、更新目标、陈旧数据行为、通知、日志保留以及在分歧期间的支持。如果供应商合并了验证和路由建议，它应将事实性的有效载荷变更与其策略建议分离开来。客户必须始终能够理解并覆盖最终的路由选择。
路由器厂商负有提供可实施控制的义务。运营商需要能将验证与行动区分开、显示缓存会话和数据年龄、安全地保留或恢复受影响的路径，以及暴露策略项匹配原因的指令和遥测。默认值应当有文档记录，升级操作不应静默更改对 Invalid 或 NotFound 路由的处理方式。可复现的缺陷应有安全响应和发布记录。
补救措施应当相称。立即的技术纠正通常比投机性损害赔偿更有价值。通知、保留的状态、快速撤销或替换、重新评估和外部验证应优先考虑。当受控的故障和已记录的损失仍然存在时，可以跟进财务或合同上的补救措施，但无限责任将阻碍共享基础设施的建设，并且无法反映证书和数据包之间众多的独立决策。
因此，可强制执行的最低限度并非对普遍可达性的保证。它是由控制争议步骤的机构提供证据和及时行动的权利。这项权利将一种分散的技术依赖关系转化为一系列可问责的服务。
决策凭据使分布式权力可审计
RPKI 已经包含了签名对象和详细规定的验证规则。它在运营商边界处常常缺乏的，是将这些对象与路由后果联系起来的紧凑记录。一份决策凭据并非一项新的全局授权。它是由每个参与者为其自身行动产生的一种证据格式。
在认证层，凭据应当指明资源、旧的和新的授权、请求身份、批准方法、生效发布时间、原因类别以及任何申诉或紧急事件引用。敏感的个人细节可以受到保护，而对象级变更和授权依据则是可见的。
在验证器层，它应当记录软件和版本、活跃的信任锚点、本地修改、存储库快照或观察时间、验证结果、有效载荷的添加或撤销以及相关的警告。在缓存到路由器层，它应当添加缓存身份、协议版本、会话标识符、序列号、传输完成状况和数据年龄。这些细节将“我的验证器显示别的东西”转变为可复现的比较。
在路由器层，凭据应当指明路由、对等体类别、验证状态、匹配的策略项、结果动作、策略版本和时间。如果一条路由被保留但无资格，记录应说明这点。如果应用了例外，它应包括范围、批准人和到期时间。对于大型提供商，记录可以自动生成，并根据合法的查询有选择地披露。
外部观察完善了这条链条。RIPE RIS、RouteViews 和运营商的 looking glass 可以显示宣告是否从选定的观测点出现。它们不能证明每个网络接受了什么，并且在一个收集器处的不存在也不能作为全局压制的证明。它们的价值在于独立的时间证据：该路由在变更前此处可见，变更后此处消失，并在记录的时间此处恢复。
凭据应使用稳定的标识符，而不应假装来自不同缓存的序列号可直接比较。它们应保留原始时间戳并清楚地标记推断。一个中心化仪表板可以聚合它们，但底层证据应保持可归属于产生它的参与者。
这种做法改变了激励机制。注册机构改进变更记录，因为下游影响可以被追溯。验证器改进诊断，因为差异变得可审查。运营商测试策略，因为他们可能需要解释一次拒绝。持有者维护 ROA，因为他们自己的指令保持可见。问责从相互关联的证据中涌现，而非通过在所有参与者之上设置一个新的权威。
测量必须尊重能观测到和不能观测到的
关于部署的主张常常因模糊的分母而被削弱。统计有效的 ROA 数量衡量的是授权发布，而非拒绝 Invalid 路由的网络数量。统计似乎过滤了一条实验性宣告的网络数量，并不能确定其对每个客户、对等体和地区的策略。统计拥有 RPKI 功能的路由器厂商数量，并不表明运营商正确启用了它。
一个有用的测量方案至少区分四个量。第一是发布覆盖率：被已验证有效载荷覆盖的地址空间或路由前缀，并明确处理重叠授权和最大长度。第二是验证器可用性和一致性：选定的独立依赖方是否从指定的信任输入得出相同的有效载荷集。第三是路由器策略部署：被观测的网络是否显现拒绝、降低优先级或传播受控的 Valid、Invalid 和 NotFound 宣告。第四是后果：在一次真实的授权事件中，哪些前缀和路径发生了变化。
RIPE RIS 和 RouteViews 通过志愿者对等体和收集器提供广泛但抽样的 BGP 可见性。它们的档案可以支持前后分析，但看不见每条双边路径或内部策略。主动实验可以揭示沿被测路径的处理方式，但路由传播、商业关系和路径变化可能混淆归因。运营商的声明增加了背景，但描述的可能是意图而非实际策略。
正确的回应不是放弃测量。是公布观测点、时间窗口、被测路由状态、置信度和局限性。来自不同收集器的重复观测可以识别趋势和事件，而无需发明一个精确的全球百分比。证据应当区分“未观测到”和“被拒绝”，以及“AS 级推断”和“路由器级配置”。
对于纠正审计，测量可以更窄更强。相关的提供商可以暴露其缓存和策略记录；独立的验证器可以展示有效载荷的汇聚；路由收集器可以展示外部重新出现；端点探针可以测试可达性。这并不证明普遍修复，但它可以证明相关各方的运维链条。
一个号码资源协会可以维护通用的测量定义，并发布可复现的事件研究。它应当抵制基于不可比分母的排名。其目的是展示权力与实施在何处偏离，而不是给注册机构或运营商颁发单一的道德评分。
一个边界清晰的号码资源协会角色能填补制度空白
RIR 发布与路由器行动之间的空白，引诱着人们要么放弃，要么走向集权。放弃者说每个网络都是自治的，因此不可能有共同的问责。集权者说一家机构应当规定每种验证状态的处理方式。这两种答案都过于简单。
一个号码资源协会可以占据一个更狭窄的位置。它可以定义决策凭据格式，比较各注册机构的纠正承诺，根据确定的快照测试验证器，发布缓存到路由器的恢复演练，并帮助小型运营商解读厂商行为。它可以围绕跨越组织边界的证据，将持有者、RIR、转接提供商、交换中心运营者、厂商和研究人员聚集在一起。
它还可以运营一份升级路径目录。面临拒绝的持有者应当能够找到正确的注册机构紧急联系人、验证器维护者、提供商路由桌面和交换中心服务所有者。标准化的案例字段将避免前缀、源、有效载荷和时间证据的重复转化。聚合的案例可以揭示反复出现的 maxLength 错误、陈旧缓存模式或策略顺序缺陷，而无需暴露私有客户数据。
该协会不应为其不管理的资源签署替换 ROA，不应强制承载，也不应依据机构偏好宣布有争议的所有权。它不应将一项自愿的最佳实践转变为一项隐蔽的全球规则。其合法性将来自透明的方法、平衡的代表性、公开的局限性以及更快纠正的实际价值。
它也不应通过一次性的问卷调查，认证某个网络是“符合 RPKI 要求的”。保证应当基于事件。该网络能否显示缓存年龄？变更的有效载荷是否触发了安全的重新评估？客户能否获得一份有理由的拒绝通知？例外是否会到期？两个验证器的分歧能否得到解释？注册机构的纠正是否在所报告的时间间隔内变得外部可见？
这些测试在保持自治的同时，使其变得可答复。RIR 保留认证责任。运营商保留路由责任。厂商保留实现责任。协会提供共同的证据和审查，在双边关系过于碎片化而无法高效运作的地方发挥作用。
对于议价能力最弱的网络，建立这样一个机构的正面理由最为充分。大型运营商可以构建自己的遥测系统，并直接致电注册机构工程师。小型持有者和区域提供商往往不能。共享的程序可以赋予他们可信的补救措施，而无需假装他们有权支配每个远程网络的策略。
治理层是一张边界地图，而非另一个开关
对 RPKI 部署的成熟视角始于宣传图表通常结束的地方。一个签名对象到达一个验证器；一个有效载荷到达一个路由器；一个状态到达一个策略；一个策略影响一项商业关系和一条数据包路径。每一个箭头都是一个技术接口，也是一次制度交接。
核心规则依然清晰。RIR 和资源持有者发布经过认证的授权声明。验证器确定从它们能够验证的受信数据中可以得出什么。路由器对路由进行分类，并执行配置的控制措施。网络运营商决定最终处理方式。标准有意阻止将自动策略偷渡进分类当中。
这种划分不应成为一连串的免责声明。发布者必须为颁发和发布负责。验证器和缓存运营者必须为忠实、及时的计算和分发负责。厂商必须为实现负责。网络必须为策略、例外和恢复负责。转接和对等服务必须解释共享控制措施影响他人的条款。
三项改革将使这一安排变得可治理。首先，发布决策凭据，将对象变更与验证器、缓存和路由器状态连接起来。其次，在每个受控边界处提供可强制执行的纠正和质疑程序。第三，使用声明的观测点测量端到端事件，而不是用采用数量替代运营证明。
其结果不会消除路由事件或关于权力的分歧。但它将使它们变得可处理。受影响的持有者可以识别第一个不正确的状态、能够修复它的机构以及验证恢复所需的证据。运营商可以为其安全决策辩护，而无需假装一个 Invalid 标签就证明了动机。注册机构可以接受对其自身行为的责任，而不成为每个路由选择的保险商。
因此，缺失的治理层并非缺失的代码。它是缺失的可读性。RPKI 到路由器架构已将最终选择权留给了自治的运营商。从 2018 年开始的制度任务，是确保这种自治保持可见、有据可依且可审查，而非隐藏在一个绿色、灰色或红色的验证状态之后。
资料来源
- RFC 8481：基于 RPKI 的 BGP 源验证澄清— 确立了 2018 年的规则，即验证设置状态而运营商配置控制策略。它并未规定对每种对等体类别或每个事件的首选处理方式。
- RFC 8210：RPKI 到路由器协议，版本 1— 定义了缓存到路由器会话、序列更新、有效载荷宣告和撤销、传输选项，以及刷新、重试和过期参数。它规定的是数据传输，而非商业路由义务。
- RFC 6811：BGP 前缀源验证— 定义了 Valid、Invalid 和 NotFound 的比对，并将结果的使用视为本地策略。它并未识别不匹配背后的动机。
- RFC 7115：源验证操作— 提供部署和路由策略指南，包括关于流量转移、低优先级和更具体路由的警告。某些运营假设反映的是早期的采用阶段，不应解读为当前的部署数量。
- RFC 9324：无需路由刷新的基于 RPKI 的策略— 记录了部署中观察到的有害刷新行为，并建议保留受影响的路径以便重新评估。它并未度量每个厂商或网络的实现。
- RFC 8897：RPKI 依赖方需求— 整合了获取、验证和分发 RPKI 数据的需求。它是一份需求图谱，而非对当前私有验证器服务的审计。
- RFC 8416：使用 RPKI 的简化本地互联网号码资源管理— 定义了可支持有限例外的本地过滤器和断言。此类本地状态并不为其他运营商改变全局签名视图。
- RFC 8211：认证机构的不利操作— 分析了证书和存储库操作如何损害持有者，以及本地控制如何减轻影响。它并不裁决某个特定注册机构的操作是否在法律上合理。
- 思科：Cisco 8000 上使用 IOS XR 7 的 BGP RPKI— 展示了一个产品系列中的策略匹配、降低优先级、最佳路径处理和重新评估选项。示例并未确立全球运营商实践。
- 思科 IOS XE：BGP 源 AS 验证— 记录了缓存连接以及针对验证状态的多种策略结果。产品命令不应未经验证就推广到其他版本。
- 瞻博网络：配置 RPKI— 将状态标记与稍后的接受或拒绝策略分开，并解释了在客户、对等体和转接导入中的放置。它是运营指南，而非独立的测量研究。
- FRRouting BGP 文档— 演示了对 Valid、Invalid 和 NotFound 状态以及缓存遥测的开源 route-map 处理方式。行为取决于发布版本和本地配置。
- RIPE RIS 文档— 描述了一个分布式 BGP 收集平台及其原始数据。收集器的可见性是抽样的，无法证明每个网络的处理方式。
- RouteViews API 文档— 描述了来自参与收集器的当前和历史视图。在某个收集器处的不存在，本身并不证明某条路由被全局拒绝。
- NRS 章程— 为分布式参与和限制集中的号码资源权力提供了规范性支持。此处提议的保证、凭据和升级功能是建议，而非当前普遍部署的证据。