摘要

  • 发布即服务让运营商保留对其委托 RPKI 证书颁发机构和私钥的控制，而另一组织则接受并分发其证书、撤销列表、清单和签名路由对象。它既不是完全托管的 RPKI，也不是完全的自行发布。
  • 该服务解决了实际存在的问题。全球存储库可用性、协议维护、容量规划和事件响应是专业职责，许多原本有能力的证书颁发机构运营商不应重复承担。
  • 分离也引入了新的交接点。一个正确签名的对象可能在私有发布接口被拒绝、被接受但未整合到公共存储库、通过一种传输方式提供服务但未通过另一种、或者依赖方检索结果不一致。一个可用性百分比无法描述所有这些状态。
  • 责任应根据控制来划分。运营商拥有签名意图、密钥安全、对象正确性和及时协调的责任。发布提供商拥有认证接受、原子状态变更、公开可用性、新鲜度、证据保存和恢复的责任。父级 RIR 拥有精确的资源认证以及在存储库引用或提供商需要变更时的实际协作责任。
  • 有用的服务协议需要分阶段的目标、签名交易证据、外部可用性测量、保留规则、安全职责、事件分类、过渡援助以及与运营后果相关而非象征性订阅积分的补救措施。
  • 可迁移性是安排的基本检验标准。运营商应能在不放弃 CA 密钥、不丢失历史记录或忍受可避免的空档期的情况下迁移到另一个存储库，但迁移仍需父级证书颁发者的协调以及对新旧发布状态的谨慎控制。
  • 号码资源协会可以帮助比较条款、定义最低证据包、组织可迁移性演练，并在区域服务讨论中代表运营商。它不应声称一个示范条款或独立监督者能保证路由结果。

对象已签名、已接受但仍未出现

考虑一个委托证书颁发机构在维护窗口前准备路由变更。其运营商创建新的路由源授权，刷新清单，并将发布请求发送给存储库服务。服务返回成功。几分钟后，工程师查询独立验证器仍看到之前的授权。旧源保持有效；预期的新源保持无效。哪个机构出问题了？

有几种可能的答案。运营商可能发送了内部不一致的对象集。发布服务器可能接受了交易但未将其纳入存储库视图。其 RPKI 存储库增量协议端点可能正在提供旧的通知文件。rsync 副本可能落后。验证器可能缓存了之前的状态或未能刷新。父级证书可能包含不再匹配预期服务的存储库引用。时间可能只是比任何承诺的发布间隔要短。

这并非语义上的吹毛求疵。每种解释都分配了不同的职责和补救措施。协议成功响应可以确定一个事实，同时让运营结果悬而未决。一个公共对象可以密码学上正确但不可用。存储库可以可达但过时。验证器可以检索到当前快照，但仍以资源持有者未预料到的方式应用本地策略。

发布即服务使这些区分不可避免。委托运营商保留了签名密钥，但它外包了从签名到公共依赖的桥梁。只有当该桥梁有指定的所有者、可衡量的阶段和足够强的证据以便在维护窗口过后解决分歧时，弹性才会改善。

一个新市场从合理的专业化中诞生

分离的理由很充分。运营一个委托 RPKI 证书颁发机构已经需要安全密钥、与父级的证书交换、及时的清单和撤销列表、正确的签名对象、监控以及了解错误后果的人员。运行公共存储库则增加了另一套职责：全球可达的分发、两种检索协议、容纳大量验证器的容量、抗拒绝服务、一致性的快照和增量、复制、可观测性和全天候恢复。

互联网治理中没有任何原则要求每个私钥持有者都成为全球内容分发运营商。集中存储库专业知识可以减少脆弱的单服务器安装。区域注册机构或专业提供商可能比小型网络的次要任务能够维持更好的网络多样性、监控和支持。分离还可以缩小攻击范围：存储库无需拥有 CA 的私钥，而 CA 主机无需暴露高容量的公共服务。

技术基础早于最近的服务市场。RFC 8181规定了证书颁发机构和发布服务器之间的认证发布协议。RFC 8182规定了依赖方使用的公共端 RRDP。因此，签名者和分发者可以是不同的。

区域服务将这种可能性变成了可访问的产品。ARIN 在社区请求后部署了 RFC 8181 存储库服务，APNIC 支持自托管客户的发布，RIPE NCC 从 2022 年测试版过渡到生产级的“在父级发布”服务。中间商的出现不是因为运营商忘记了主权。它之所以出现，是因为专业化可能比业余的重复更安全。

混合 RPKI 是一种独特的控制分配

熟悉的标签“托管”和“委托”掩盖了新的安排。在托管 RPKI 中，区域注册机构通常运营持有者的证书颁发机构，保护或生成其私钥，将门户选择转为签名对象并发布它们。在完全自运营的委托 RPKI 中，持有者既运行子 CA，也运行其存储库。发布即服务介于两者之间。

在这种混合模式下，持有者运行委托 CA 并控制相应的私钥。它决定在认证资源集内签名哪个授权源、前缀和最大长度。存储库提供商接收认证的发布和撤销请求，维护存储库命名空间，并向验证器公开结果材料。父级 RIR 继续颁发资源证书并认证子级可以行动的范畴。

这种分配很重要，因为控制不是二元的。运营商对其创建的对象拥有密码学控制权。存储库对对象是否以及如何在指定位置变为可用并保持可用拥有操作控制权。RIR 对资源证书拥有层级控制权，并且根据部署情况，对支持新存储库关系所需的变更也有控制权。依赖方保留对其软件和路由策略的控制权。

将这种模式称为“委托”可能导致高管认为运营商是独立的。称为“托管”可能暗示 RIR 持有密钥。两者都不准确。“委托 CA 加托管发布”虽不够优雅但更具信息量。治理始于命名每个方实际能做什么，因为合同责任在故障后很少比之前更清晰。

RFC 8181 解决交易，但不是每一种后果

发布协议提供了有用的精确性。请求和响应通过签名的加密消息语法对象传输，允许客户端和服务器验证交换。CA 可以发布新对象、替换现有对象（当预期哈希匹配时）、撤销对象或要求服务器列出其认为客户端已发布的内容。包含多项更改的查询将原子处理：全部成功或无一成功。

这些属性减少了歧义。哈希防止客户端在客户端和服务器对其当前内容存在分歧时随意覆盖存储库对象。原子性防止协调对象集的一部分在另一部分失败后被提交。列表操作支持在系统失去同步时恢复。错误响应标识失败的请求，而不是让客户端从公共存储库中推断拒绝。

但协议的边界必须被尊重。成功响应表示发布服务器已根据交换处理了请求。它并不证明每个公共副本立即包含新字节。它不证明 RRDP 快照和所有相关增量一致、rsync 提供相同视图、远程验证器可以连接、或者对象在其父链下验证。

技术认证也不一定回答运营商内部谁批准了更改。客户端身份可能属于一个自动化的 CA。其请求可以完全真实但实质上错误。因此，发布证据是必要的但有边界。服务合同应基于协议精确的主张，而不是将成功响应变成“RPKI 已更新”的模糊承诺。

私有交接点和公共存储库是不同的服务

存储库提供商面对两类客户。其客户面向服务接受来自证书颁发机构的指令。其公共面向服务向依赖方分发材料。一个接口的可靠性并不意味着另一个接口的可靠性。

在私有端，提供商必须认证客户端、授权其命名空间、检查预期哈希、原子地应用请求、返回确定结果并提供协调。此处的容量由证书颁发机构和对象更改驱动。延迟从接收到提交的存储库状态之间测量。安全问题包括凭证泄露、跨租户写入以及针对其他发布者 URI 的恶意请求。

在公共端，许多验证器获取快照、增量或文件。容量由全局检索模式、重试和其他地方的中断驱动。提供商必须公开一致的最新状态，保持清单和撤销材料可达，正确管理 RRDP 会话和序列号，维护 rsync（如果提供），并避免从副本中提供不同视图而不被检测。可用性从不同的网络测量，而不是从提供商的内部负载均衡器。

在两者之间是集成。一个交易可以持久提交到发布引擎，但尚未在 RRDP 通知和快照中表示。在健全的系统中，这个间隔可能很小，但正是这个间隔在紧急路由变更中至关重要。它应有自己的目标和证据。

因此，成熟的协议描述三种服务：指令接受、存储库状态构建和公共分发。营销可以称它们为一个产品。事件审查不能。

存储库是证据的一部分，而非中性存储

将提供商描述为存储公司是很有诱惑力的。这低估了其功能。RPKI 发布是签名断言变为依赖方可用的方式。选择、新鲜度和一致性可能与签名有效性同样重要。

RFC 9286要求清单在 CA 发布点列出文件和哈希。清单帮助依赖方检测某些缺失、添加或更改的材料，并评估新鲜度。证书撤销列表指示哪些证书不应再被信任。RRDP 快照和增量让验证器重建存储库状态。这些不是围绕 ROA 的装饰性文件；它们是验证上下文的一部分。

存储库无法在没有 CA 密钥的情况下伪造有效的 ROA。这是一个重要的保护。然而，它仍然可能未能提供最新的有效对象、重放更早的存储库状态、遗漏文件、呈现不一致的视图或不可用足够长的时间以改变依赖方的处理。RFC 8211为此分析了证书颁发机构和存储库的不利行为。

这并不意味着每次遗漏都是恶意的，或者验证器反应相同。缓存状态、对象有效性、清单处理、获取顺序和本地实现影响结果。这意味着存储库执行了一个证据功能：它呈现了其他人据此行动的有签名记录。执行该功能的服务应保留它所接受、所服务、每个状态何时变更以及哪些公共视图被暴露的记录。

父级 RIR 仍在场

将 CA 与发布分离并不能将资源持有者与其父级分离。RIR 颁发子资源证书并根据注册状态定义其认证的地址和 ASN 范围。证书配置文件还将验证链连接到存储库位置和相关材料。持有者不能仅凭拥有自己的密钥来认证父级已删除的资源。

这种持续的角色是合法的。RPKI 需要一个跟踪已获认可的号码资源注册的层级结构。前持有者不应仅仅因为控制着子密钥而在有效转移后无限期保留路由权威。困难在于，当运营商需要更换发布提供商而同时仍完全有权拥有相同的资源证书时。

存储库迁移可能需要新的设置材料、更改的引用、新的证书或协调的发布状态。RFC 8183帮助交换设置信息，但并没有创建服务截止日期或迫使父级批准新关系。技术互操作性不是可执行的退出权。

因此，即使当 RIR 不是发布供应商时，它也有持续责任。它应认证迁移请求、及时进行所需的父级端更改、支持安全的过渡或切换设计，并保留其颁发的证据。如果 RIR 同时提供发布服务，则它占据两个角色，应分开报告。父级权威不应成为一种悄悄阻止名义上竞争的存储库市场变得不可离开的机制。

专业化可以多样化运营风险

服务提供商可能不仅仅改善便利性。它可以跨网络和位置分布公共端点、维护经验丰富的待命员工、测试多种验证器实现、赞助拒绝服务保护并与 CA 软件开发者协调修复。一个集中的存储库可以证明每个小发布者都会推迟的工程合理性。

该模式还允许风险分离。CA 私钥保留在运营商的安全机制下。存储库的妥协不会自动授予签名权限。相反，CA 主机的妥协也不必然赋予攻击者对公共服务平台或其他租户的控制权。提供商端命名空间授权可以阻止尝试写入其分配分支之外的错误客户端。

整合可能提高可观测性。服务多个发布点的提供商可以比孤立的运营商更早检测到系统性的 RRDP 故障、异常的对象变动或验证器重试风暴。它可以发布共同的事件报告并提供一致的证据格式。区域提供商已经与资源持有者有关系，并可能在认证和存储库问题之间连接支持。

这些是可能的收益，而非普遍事实。一个大型共享服务也会增加破坏半径。其遥测可能广泛但不透明。其规模可能使客户不愿离开。弹性取决于实现、独立提供商的数量、移动能力以及服务报告的诚实性。外包转移职责；它并不会让它们消失。一个合理的比较会问：提供商的控制是否比运营商的替代方案更强，以及故障是否仍然可逆。

集中化造成了一种签名无法修复的故障

如果许多委托 CA 使用一个存储库服务，该服务的妥协或操作错误可能影响一大群原本独立的签名者。他们的私钥保持安全，但他们的对象可能变得过时、缺失或不一致地提供。CA 层的密码学去中心化可以与发布层的操作集中化共存。

这不是计算存储库主机名并宣称垄断的论点。一个提供商可能运营真正独立的服务区域；许多域名可能依赖相同的基础设施。相反，一个区域存储库可能比数百个名义上独立的服务器更健壮。集中化分析需要考虑提供商所有权、软件、云、DNS、网络、密钥管理、控制平面和人员依赖。

中间商也获得信息优势。它可以观察到客户何时更改路由授权、哪些更改失败、用户重试的紧迫性以及哪些验证器获取特定材料。其中大部分是运营必需的。尽管如此，保留和二次使用应被声明。一份发布合同不应悄然将路由安全管理转变为不受限制的行为数据集。

最重要的是，客户可能缺乏可信的备用方案。如果提供商失败，CA 运营商不能简单地将相同文件放在任意新 URL 并期望验证器发现它们。父级颁发的引用和存储库结构很重要。一个集中化且难以退出的提供商可能变得比其“存储”标签所暗示的更具组织重要性。可迁移性，而非品牌，决定了专业化究竟是服务还是控制。

责任应遵循被控制的行为

事件后的争论常常使用“共同责任”的语言。这个短语是合理的，但可能成为一个逃生口：当每个方普遍负责而没有一个方对失败步骤负责时。更好的规则是为每个被控制的行为和每项必要的协作分配责任。

运营商控制签名意图、CA 密钥、本地授权、对象生成以及提交决定。它应该对准确反映其批准但编码错误源的 ROA 负责。它还应该监控其提交的状态是否变得公开，而不是将成功响应视为更改的结束。

发布提供商控制客户命名空间、交易处理、已提交的存储库状态、公共接口、副本以及关于它们的保留证据。它应该对以下情况负责：无理由拒绝符合要求的授权请求、确认未提交的交易、在约定范围之外提供过时或分叉的视图、或丢失恢复所需的记录。

父级 RIR 控制资源证书和父级端协作。它应该对错误的资源范围、不合理的延迟改变存储库安排或不必要破坏连续性的退出设计负责。如果它同时也是发布提供商，内部部门不应模糊这些职责。

依赖方控制获取和本地验证。他们不能要求发布商赔偿一个忽略当前材料的验证器。证据必须定位故障。共同责任应意味着相邻各方交换足够的证据以便做到这一点，而不是责任在每个边界溶解。

CA 运营商保留了严格的职责

托管发布不是托管 RPKI。运营商仍然运行证书颁发机构。它必须保护其私钥、保持父级交换的及时性、在认证范围内颁发对象、刷新清单和撤销列表、维护备份、控制管理员访问以及了解更改如何影响路由。

它应维护一个独立于提供商的权威预期状态记录。对于每个发布交易，该记录应包括更改后预期的对象及其哈希、发起服务身份、批准的人员或规则、业务原因、相关路由更改以及提供商的响应。运营商应能重建其期望的存储库，而无需询问提供商其原先意图是什么。

协调也是运营商的职责。RFC 8181 的列表操作之所以存在，是因为客户端和服务器可能不一致。CA 应将提供商的已提交清单与本地状态进行比较，并将公共存储库观察结果与两者进行比较。从提供商同一主机或网络进行监控是不够的。至少有一个视图应近似于远程依赖方能够检索到的内容。

运营商需要针对每种故障类别的响应计划。被拒绝的请求需要纠正或升级。成功响应后公共状态缺失需要提供商的证据。父级证书问题需要联系 RIR。过时的本地清单需要 CA 干预。计划应指定谁可以冻结更改、发布紧急对象、联系父级以及启动迁移。

当客户仍然能够检测失败并行使退出权时，外包才是负责任的。否则，便利性变成了缺乏监督的依赖。

提供商的职责始于可用性之前

存储库提供商通常强调正常运行时间，因为它容易放在状态页面上。他们的首要职责更窄也更早：只接受经过认证和授权的指令，并精确一次地应用到正确的命名空间。

租户隔离是基础。客户端不得在另一个 CA 的 URI 上发布。替换和撤销必须检查预期的旧哈希。多对象更改必须保持原子性。重复请求、重试和模糊网络故障需要确定性的处理。运营商应能询问交易是否已提交，而无需冒第二次不一致应用的风险。

接下来的职责是忠实的整合。所接受的字节应是提供商权威存储库状态中表示的字节。提供商不应静默地转换签名对象。它应一致地生成公共存储库元数据，在承诺的间隔内公开新状态，并在支持的检索方法上提供相同的当前视图，受协议语义约束。

然后是可用性：多样化的验证器应能够检索完整、新鲜的材料。提供商需要容量、复制、DNS 弹性、网络多样性、监控和经过测试的恢复。恢复必须保护一致性；恢复一个旧快照而不检测之后接受的交易可能比可见的中断更糟糕。

最后是证据。提供商应保留签名的请求和响应、提交标识符、状态哈希、集成时间、RRDP 会话和序列号、副本健康、管理操作和事件决策。一个恢复服务但不能解释其服务过的状态的提供商修复了可用性，却破坏了问责制。

RIR 的职责是认证的连续性

父级 RIR 可能辩称委托运营商选择了其存储库，因此承担后果。选择确实重要。它并没有消除 RIR 颁发证书以认可子资源及其发布安排的独特能力。

在注册时，RIR 应使可用模型易于理解。资源持有者需要知道其控制哪些密钥、哪个方发布、使用哪些父级引用、如何更换提供商、提供哪些支持以及哪些终止事件可能影响证书。一个标记为“委托”的复选框不是知情选择，如果发布依赖仍然隐藏。

在运营期间，RIR 应及时公开父级端事件。证书颁发、资源集更改、撤销或设置修改应有稳定的标识符和时间。子级必须能够区分提供商问题与父级行为。支持团队应有时间敏感路由变更的升级路径，而不是将存储库迁移视为普通账户管理。

在退出时，RIR 应根据已发布的时间表处理有效的存储库变更。它应支持技术上合理的连续性方法，验证新发布点是否可达，并保留旧证书和新证书历史。紧急安全行动可能需要立即撤销，但普通的商业或服务争议不应迫使最具破坏性的过渡。

RIR 并非每个第三方的保险人。它是存储库选择与层级权威交汇点上不可或缺的协调者。其义务是实际的中立性和及时的合作。

一个正常运行时间百分比掩盖了五个时钟

一个严肃的服务承诺应至少测量五个间隔。第一个是请求可用性：授权客户端能否到达发布端点并收到有效响应？第二个是决策延迟：服务需要多长时间接受或拒绝符合要求的请求？第三个是集成延迟：成功后，提交的对象集何时进入权威公共存储库状态？

第四个是分发新鲜度：RRDP 和 rsync（如果支持）何时从不同位置公开一致的材料？第五个是恢复时间：故障后，提供商多快能恢复包含所有有效已接受交易或标识需要重放的状态？

这些时钟有不同的分母。一个月的端点正常运行时间数据可能排除失败的身份验证、维护、慢速集成和过时的副本。平均发布时间可能隐藏长尾，正好在紧急更改发生时。存储库可以每对探测都以 HTTP 成功响应，但其通知文件可能过时。缺乏语义新鲜度的可用性就像是空路上的绿灯。

协议应定义每个测量的起止事件、观测点、排除项和报告周期。它应发布百分位数和最大违规，而不仅仅是平均值。计划内维护仍应披露发布后果。安全暂停可能有效，但应被计数和分类，而不是从历史中移除。

运营商也需要自己的测量。提供商的结果是一个视图。独立探测应测试从多个网络和验证器实现的检索。当两者不一致时，证据程序必须决定什么是服务审查的权威，而不假设供应商的仪表板胜出。

收据必须说明它证明了什么承诺

签名交易证据是公平分配的基础。对于每个请求，运营商应保留签名的 CMS 消息、对象哈希、服务器响应、交易标识符以及本地发送和接收时间。提供商应保留相同的交换，外加其认证的客户端身份、授权决定和提交记录。

第二份收据应确定存储库集成。它可以标识提交的状态根或清单摘要、首次包含更改的 RRDP 会话和序列号、快照哈希、集成时间以及任何相关的 rsync 状态。这不是 RFC 8181 的要求，但它将内部事件转化为可审查的证据。

第三层应展示外部可用性。独立监测器可以从不同网络记录通知、快照、增量和文件检索，并附带加密哈希和签名观察时间。它们应既保留失败也保留成功。仅由提供商选择的监测器不能独立于治理；监测器的选择、密钥和保留的治理很重要。

每份收据证明一个有边界的命题。请求收据证明发送了什么。成功响应证明服务器端的协议处理。集成收据证明提供商提交了什么。外部观察证明某观察者在某个时间检索到了什么。单独一份都不能证明全局路由处理。

这种谦逊加强了证据。事件报告变成一系列可检验的陈述，而非截图之间的竞赛。控制每个阶段的方产生该阶段的记录。间隙可见，没有收据被提升为它不能确定的后果的证明。

事件类别不应为方便而混合

发布服务需要公开的事件词汇表。至少应区分认证失败、授权错误、格式错误请求、哈希冲突、交易处理失败、集成延迟、不完整的存储库状态、过时元数据、RRDP 故障、rsync 故障、副本不一致、父级证书不匹配、拒绝服务、管理暂停和证据丢失。

这种区分既保护客户也保护提供商。如果运营商发送了无效对象，提供商不应记录存储库中断。如果服务接受有效交易但延迟公共集成，不应指责客户端认证。如果一个传输方式失败而另一个保持最新，报告应说明部分降级，而不是要么完全失败要么完全可用。

严重性应反映时间和后果，但避免假装提供商知道每个路由结果。一份有用的报告可以说明多少客户命名空间经历了过时的公共状态、持续多长时间、哪些存储库视图受影响以及涉及哪些对象类别。它应单独说明已知的路由观测或客户报告。未知的影响保持未知。

根因语言应分离触发因素、控制弱点和后果。软件缺陷可能触发坏快照；不充分的发布验证可能允许它；监控盲点可能延长它。“人为错误”很少是完整原因。如果架构集中化使得该网络不可或缺，那么“外部网络问题”同样薄弱。

一致的分类随时间产生可比较的证据。没有它，每个提供商可以重命名相同的故障，直到可靠性无法评估。

可迁移性不仅仅是下载对象

RPKI 对象是签名文件，因此客户可能看起来可以通过复制它们离开。存储库关系并非如此简单。公共位置通过认证结构被引用。存储库命名空间、设置凭证、RRDP 状态和提供商特定证据必须重建。父级可能需要颁发更改的材料。验证器必须通过有效链发现并检索新位置。

因此，可迁移性有五个部分。配置可迁移性让运营商以文档化格式导出对象意图、发布清单、URI 和相关设置数据。证据可迁移性提供请求、响应、哈希、集成历史和事件。身份可迁移性允许 CA 建立新的认证发布关系，而不必从零开始重建组织。

操作可迁移性协调新旧服务状态，以便验证器不面临可避免的空档期或冲突的权威视图。合同可迁移性强制旧提供商和父级在特定期限内合作，即使客户在争议后离开。

私钥不应需要离开运营商的掌控。保留密钥是混合模式的一个优势。但仅有密钥并不能完成迁移。提供商和父级持有其他必要的控制权。

费用可以覆盖合理的过渡工作，但惩罚性的退出收费破坏了市场的合法性。提供商不应在终止时擦除日志，或使证据检索以放弃索赔为条件。离开期是记录最重要的时刻。只有当退出既保持运营连续性又保留证明在此之前发生之事的能力时，服务才是可迁移的。

先建后拆必须设计，而非假设

理想的迁移允许新存储库在旧存储库被撤销之前变为有效并可观测。在实践中，认证引用和验证器行为使重叠成为一个技术问题，而非口号。两个发布点不能简单地在没有明确权威的情况下声称竞争的最新状态。

父级 RIR、旧提供商、新提供商和 CA 运营商应发布经过测试的迁移程序。它应定义普通更改的冻结点、需转移的清单和哈希、新设置认证、证书颁发、新存储库的验证标准、旧存储库的保留期以及最终撤销事件。过渡期间的紧急更改需要明确的路径。

测试应包括在迁移之前、期间和之后启动的验证器；使用 RRDP 和 rsync（如适用）的客户端；丢失一个提供商；重放旧请求；在新服务验证失败后回滚；以及父级端操作延迟时的恢复。测试应记录经过时间和观测到的状态，而不仅仅是声明成功。

可能存在某些设计无法安全避免短暂中断的情况。如果是这样，服务应在注册前披露该限制，并估计相关对象有效性的余量。有紧急路由变更的运营商可以相应安排或选择其他模式。隐藏的先建后拆是治理缺陷，因为它将技术约束转化为不知情的依赖。

可迁移性演练应在提供商陷入危机之前进行。只有在中断期间才首次阅读的退出计划是文档，而非准备。

合同条款应遵循控制和后果

发布协议通常包含广泛的排除条款，因为路由决策发生在提供商的网络之外。该边界是真实的。存储库不控制每个验证器、路由器或运营商策略。它不应保证全球可达性。但这并不证明否认它所控制的步骤是合理的。

合同应保证认证处理、命名空间隔离、忠实发布、定义的新鲜度、证据保留、安全实践、事件通知和过渡协助。它应以相同精度说明客户职责：正确的 CA 操作、当前联系方式、安全凭证、及时更新、监控以及恢复中的协作。

责任应区分直接服务故障与远程路由后果。提供商可以在协商限制内承担重新执行、法证支持、紧急迁移成本或独立验证的损失的责任，而不必承诺补偿每个下游数据包丢失。重大过失、故意压制、保密性破坏和销毁必要证据应与普通的短期降级区别对待。

客户也需要程序性权利。暂停应有理由、在安全情况下提前通知、快速审查路径和导出证据的途径。有争议的发票不应悄无声息地变成路由安全干预。提供商可能需要紧急权力以控制入侵，但该权力应过期或接受独立审查。

标准条款因地区和法域而异。重要的制度规则是对称性：控制应带来相应的义务，义务应有比状态页面道歉更有意义的补救措施。

服务积分不够

根据小额月费计算的积分可能在商业上常见，但在运营上无关紧要。发布失败后运营商的主要损失可能是员工时间、延迟的网络迁移、紧急传输变更、客户解释或迁移存储库的成本。下个月的折扣不能恢复错过的授权或确定验证器看到了什么。

补救措施应是多层次的。第一个是性能：立即纠正、确认的存储库集成和外部验证。第二个是证据：按固定时间表提供完整的事件包，包括交易和状态记录。第三个是连续性：临时专家支持、父级协调以及如果信心丧失则加速迁移。

财务补救措施可以跟随严重性和重复违规，并设有适合服务的上限。它们不需要将提供商变成路由保险公司。终止权应在特定失败、证据销毁或慢性客观违规后激活。因故离开的客户应获得合作及其记录，而无需支付退出罚金。

集体补救措施在许多小 CA 无法单独谈判时很重要。成员协会可以汇总事件模式、请求服务变更并比较提供商。独立审查员可以检查受保护日志并发布有限结论，如果公开披露会暴露安全细节。

最有力的补救措施是通过可信的退出进行预防。知道客户可以在经过测试的规则下迁移的提供商有动力维护信任。知道可以退出的客户不太可能要求不可能的保证。可迁移性将责任从修辞变成了讨价还价的结构。

紧急暂停需要狭窄的章程

存储库提供商必须能够阻止有害活动。受感染的发布凭证可能试图大规模撤销或替换。租户错误可能淹没服务。法院命令或制裁义务可能限制服务。拒绝每一种紧急权力将使存储库以另一种方式变得脆弱。

权力应通过威胁和范围来定义。提供商可以阻止凭证、冻结命名空间或拒绝包含可信风险所需的交易。它应避免移除已发布的现有有效材料，除非风险需要并且相关权威允许。冻结新更改和撤回现有证据不是等效的行动。

如果预先通知会恶化威胁，通知可以紧随其后。客户应收到原因类别、受影响的命名空间、开始时间、决策权威、证据保存状态和审查路径。敏感的检测细节可以保持受保护。除非由授权审查员续期，否则行动应过期。

如果提供商同时也是 RIR，认证和发布权力不应随意结合。存储库暂停并不必然意味着资源证书撤销。如果两者都发生，每个决策需要自己的权威和记录。否则，一个商业或安全争议可能级联通过 RPKI 控制的每一层。

紧急章程是严肃性的标志，而非不信任。它告诉运营商哪些风险可以中断服务，并告诉提供商员工哪些行动需要更高级别的批准。发现边界的最糟糕时机是在管理员已经跨越它之后。

独立性需要的不只是不同的公司名称

由几个发布提供商组成的市场可能仍然共享相同的云区域、DNS 运营商、软件版本、监控供应商或信任安排。采购应检查共同依赖。当故障真正不太相关时，提供商多样性才有用。

选择服务的运营商应询问发布引擎和公共副本在哪里运行、控制平面访问如何分离、使用哪些网络和 DNS 依赖、软件变更如何分阶段、RRDP 和 rsync 是否独立失败、以及证据保留在哪里。它应询问另一个提供商能否消费导出数据，以及父级 RIR 是否与该提供商完成了迁移演练。

多提供商发布听起来有吸引力，但需要协议和权威的清晰性。通过冗余基础设施服务相同的权威状态可以提高可用性，如果一致性得到保证。允许两个独立提供商同时接受更改可能产生裂脑风险。冗余不应在没有冲突规则的情况下倍增写入者。

开源软件有助于检查和互操作性，但不揭示运营质量。提供商可以运行健全的代码，但访问控制薄弱或恢复能力差。专有层可能控制良好但难以离开。保证应涵盖部署的系统、人员和依赖关系，而不是将软件许可证视为代理。

独立性是承受或离开故障的能力，而不仅仅是共享标志的缺失。一个弹性声明应识别它设计来承受的相关事件。

安全审查应测试控制平面

公共存储库扫描有用但不完整。最严重的服务缺陷可能发生在对象公开之前：弱的客户端认证、跨租户授权、不安全的管理员访问、模糊的重试、未审查的紧急操作或错误提交交易的发布版本。

独立评估应追踪从认证请求、授权、原子提交、存储库构建、RRDP 和 rsync 服务、监控、备份和恢复到整个链条的典型更改。它应测试员工是否能在普通接口之外更改客户状态，以及此类行动是否被单独批准和记录。它应像检查存储库密钥一样检查证据密钥和日志保护。

恢复值得在受控环境中进行破坏性测试。提供商应从备份中恢复，重放在备份点之后接受的交易，重建 RRDP 状态或开始有效的新会话，并显示没有租户收到另一个租户的对象。一个恢复可用性但丢失已确认更改的备份失败了核心承诺。

评估结果可以公开，而不暴露漏洞细节。它应标识范围、时期、评估者独立性、重大例外和修复措施。通用的安全徽章不如一份声明有用，该声明说明发布交易完整性、存储库一致性和证据保存已通过测试。

客户还需要报告缺陷并接收跟踪标识符的权利。负责任的披露不应被视为合同违约。一个受托处理公共路由证据的中间商通过使其自身控制面接受有纪律的挑战来赢得合法性。

隐私属于服务设计

公共 RPKI 存储库有意公开，但服务会产生非公开元数据。客户端 IP 地址、管理员身份、认证失败、草稿更改、重试模式、支持消息和事件证据可以揭示网络计划或内部角色。永远保留一切会增加泄露和监控风险。

提供商应将公共验证所需的内容与运营和安全记录分开。公共签名对象遵循 RPKI 发布规则。客户交易证据应对客户可用，并在定义期限内保留。安全遥测应有更窄的访问和目的。员工笔记不应成为不受治理的并行记录。

证据设计可以最小化暴露。哈希和签名状态承诺可以支持后续完整性检查，而无需公开底层客户事件。独立监控器需要存储库观测，而非客户端身份。审计员可以检查受保护的交易记录，并报告公共承诺是否匹配，而不泄露每个行动。

删除规则应考虑到争议和法律保留。定期遥测可以过期；与已知事件相关的证据应保留。终止不应立即触发解决终止本身所需的记录的删除。客户应知道时间表以及如何请求保留。

隐私和问责并非对立的两极。答案是保留正确的证据，以密码方式绑定它，限制访问，记录披露并发布聚合性能。不加区分的透明可能和无法验证的秘密一样不负责任。

区域服务展示了一种模式，而非一个全球协议

ARIN 的部署选项区分了托管、委托和存储库发布服务安排。存储库服务让委托参与者保留其 CA，而 ARIN 维护公共存储库。该服务在社区记录在案的请求和部署工作后出现。这表明 RIR 可以在使用现有基础设施的同时，将签名与发布解耦。

RIPE NCC 的 2022 年测试版通知描述了用户运行自己的 CA 并保留私钥的唯一控制权，而注册机构运行存储库。其当前的在父级发布条款基于 RFC 8181 正式化了区域服务。APNIC 的认证实践声明同样描述了针对自托管客户的发布。

相似之处足以确立混合模式。它们不足以声明相同的资格、服务水平、补救措施、迁移支持或责任。一个说高可用性的页面不是可比较的服务报告。认证实践声明不是完整的事件记录。条款可以改变。

因此，运营商应同时抵制区域例外主义和粗心的全球评分。比较需要一组共同的问题和当前文档。每个提供商应在其自身的法律和技术背景下回答。目标不是宣布一个 RIR 普遍优越；而是使协议足够可见，以便客户和董事会能够改进它。

采购应购买证据和退出

一个只询问正常运行时间、价格和合规性的采购表格将错过发布的基本特征。买方首先应映射服务阶段并确认哪个方控制每个阶段。买方应在签署前请求样本交易、集成和事件证据。

技术尽职调查应涵盖 RFC 8181 一致性、命名空间隔离、协调、RRDP 行为、rsync 行为（如提供）、存储库一致性、容量、依赖关系多样性、监控、恢复和安全测试。运营尽职调查应涵盖支持时间、紧急升级、员工访问、变更管理、事件报告和适当的保密性过去重大故障。

合同审查应测试暂停、终止、证据保留、分包商、数据使用、外部评估、父级协调和补救措施。买方应获取迁移程序并至少进行一次桌面演练。员工将“帮助”的承诺不是过渡目标。

运营商也应自我评估。它是否有人员来运营 CA、维护新鲜对象、协调状态和解释证据？托管存储库并不能使一个被忽视的委托 CA 变得安全。对于某些组织，托管 RPKI 仍然是更负责任的选择，因为它将签名和发布都放在一个有能力提供商手中。当持有者能够履行其保留的控制权时，混合模式才是有价值的。

采购决策应在事件和重大服务变更后重新审视。发布是一种运营关系，而非一次性的软件采购。正确的产品是责任地图与运营商能力相匹配且退出仍然可靠的那个。

号码资源协会可以使市场清晰

号码资源协会可以在不运营存储库或声称监督权的情况下做出贡献。其第一个有用的产品将是围绕控制事实建立的发布服务比较：资格、CA 密钥托管、提供商所有权、公共传输方式、服务目标、证据字段、保留、暂停、父级协调、迁移步骤、收费和补救措施。提供商应能纠正事实错误，而缺失的答案仍然可见。

第二，NRS 可以发布最低证据规范。它可以定义运营商应收到的请求收据、集成收据、外部观测和事件时间线。规范应说明每个证明的限制，以便成员不将存储库证据误认为是路由接受的保证。

第三，它可以召集有意愿的 RIR、软件运营商和成员进行可迁移性演练。结果可以报告步骤、经过时间、验证器观测和未解决的依赖关系，而不暴露私钥或客户数据。重复进行将显示可迁移性是否改善。

第四，NRS 可以聚合成员经验。一个小运营商可能无法说服提供商在故障后更改条款。对模糊成功响应、缺失证据或缓慢父级协调的文档化模式值得董事会层面的关注。聚合报告应使用已知的本地分母，并避免将轶事转化为全局故障率。

这些活动适合成员问责角色。NRS 应披露其章程和常见问题解答是第一方声明，识别利益冲突，并避免认证它无法独立验证的可靠性。可读性之所以是有意义的贡献，正是因为它比控制更狭窄。

董事会应治理交接，而不仅仅是存储库

审查发布服务的 RIR 董事会可能专注于基础设施正常运行时间和采用率。它还应询问该机构是否已经治理了客户、存储库员工和认证员工之间的交接点。最具破坏性的模糊性往往位于成功系统之间。

董事会应接收单独指标，包括已接受交易、集成延迟、公开新鲜度、事件、证据请求、争议行动和迁移。它应知道在当前程序下有多少客户可以离开，一个经过测试的迁移需要多长时间，以及需要哪些父级端批准。报告应区分区域服务性能与客户运营 CA 故障。

风险监督应包括集中度和分包商。一个高可用性的服务可能仍然依赖于一个云控制平面、DNS 提供商、软件维护者或小型员工团队。董事会应看到提供商的故障演练以及来自独立评估的重大例外状态。

政策监督应检查紧急暂停和终止。员工需要权限以遏制威胁，但高影响行动应有记录在案的批准和快速审查。如果发布和父级认证位于同一个 RIR 内，治理应防止一个角色中的问题自动触发另一个角色。

成员咨询应在条款固化之前进行。发布即服务改变了路由安全控制的实际分配。它不仅仅是一个技术特性发布。治理运营链的董事会可以保持专业化有用，而不让便利性隐藏制度权力。

弹性协议是可逆的专业化

发布即服务不应根据是否插入中间商来判断。互联网运营依赖中间人。相关问题是中间商是否使专业知识可用，而不成为不可审查的控制点。

当运营商保留有意义的签名托管并监控其预期状态；提供商忠实地进行认证更改并在可衡量目标下分发它们；父级 RIR 支持准确的认证和及时的过渡；依赖方能够检索到一致证据时，该模式通过了测试。当成功响应无法连接到公共状态、中断无法重建、或拥有有效资源的客户无法在不避免的连续性损失情况下离开时，它失败了。

没有合同能保证每个路由器接受每条路由。没有存储库设计能消除运营商错误、父级争议或验证器故障。可达到的标准是更严格的：每方证明其控制的步骤，事件保留共享时间线，补救措施对应于有边界的义务，以及在信任崩溃之前测试可迁移性。

这个标准并不削弱托管发布的理由。它使理由持久。专业存储库可以成为重要的弹性层，尤其是对于不应复制全局分发的委托 CA 而言。但专业化只有在可逆时才合法。新的中间商赢得其位置不是通过承诺什么都不会失败，而是通过使失败可见、可恢复和可离开。

来源