摘要
- 托管 RPKI 免去了资源持有者处理困难的证书、续期、清单、撤销列表和存储库的职责。它使没有专业公钥团队的组织能够创建和维护路由源授权。
- 该服务还捆绑了多个控制项。根据区域互联网注册机构的不同,注册机构可能持有托管 CA 的私钥、将门户设置转换为签名对象、发布这些对象、根据资源记录更新证书范围,并在服务终止时将其移除。
- 门户中断不会自动使现有 ROA 失效。更大的风险是失去变更和恢复权限,或者注册机构做出撤销托管 CA 或移除其对象的决定。此时,用户可能没有独立的密钥或发布路径来维护预期的授权。
- 委托 RPKI 赋予持有者自己的 CA 和私钥。它可以改善自动化、多 RIR 管理以及对托管签名接口的独立性。但它并未脱离父级:RIR 仍然颁发资源证书,并且可以缩小或撤销该证书。
- 混合方案将密钥保管与存储库操作分开。它们通常提供最实用的平衡,但由父级发布仍然是一种服务依赖,而过时的委托 CA 本身也可能成为依赖方的风险。
- 运营商应根据后果而不是潮流来选择模型。关键公共服务、复杂多源网络和大型下游委托应拥有更强的控制和经过测试的过渡;简单的小型网络可以合理地保持托管状态,只要程序保障和恢复能力可信。
- 资源号协会可以通过发布模型比较登记册、连续性测试以及向 RIR 董事会提出的会员问题来提供帮助。它应加强知情选择,而不是将自行托管简单地描述为主权。
当有效的变更无法进行时,故障就开始了
一个网络正在将服务从一个源 AS 迁移到另一个源 AS。其工程师已配置新的 BGP 公告,并打算在撤回旧路由之前创建新的 ROA。在托管 RPKI 下,他们必须使用 RIR 的门户或接口。如果账户无法访问、接口不可用或 RIR 已暂停认证,运营商无法自行签署替换。它不持有托管 CA 密钥。
这并不意味着现有路由立即失败。在门户不可用时,现有的 ROA 可以保持发布和有效。在这种情况下,直接危险是变更瘫痪。如果旧的覆盖 ROA 仅授权旧 AS,则新源可能变为无效。工程师可能推迟必要的迁移、运行某些网络拒绝的路由,或在时间压力下请求注册机构恢复访问。
更严重的事件是托管 CA 被撤销或其签名对象被移除。运营商无法从备份中重新发布相同的对象和密钥,因为密钥从未由其控制。除非父级合作,否则在父级结束服务后,它无法创建委托子级。提供便利的机构成为了恢复的必要途径。
这就是便利陷阱。这并不是说托管 RPKI 总是不可靠,或者每次服务中断都会移除 ROA。而是在用户最需要独立选项的时候,权力集中了。一项服务在正常情况下可能很方便,但在争议、转移、妥协或紧急路由变更时却可能变得脆弱。
因此,正确的比较应从控制路径开始,而不是口号。谁可以声明路由意图?谁拥有签名密钥?谁确定已认证的资源?谁发布对象?谁可以撤销它们?谁能在迁移期间保持有效的授权可见?托管和委托 RPKI 对这些问题的回答不同。
便利解决了真正的采用问题
运营 RPKI CA 与创建普通登录证书不同。CA 必须保护密钥、请求和续期资源证书、颁发签名对象、维护清单和证书撤销列表、发布新鲜材料、在故障中存活,并与父系统正确交互。其存储库必须可供依赖方直接或通过发布提供商访问。错误可能改变路由源验证。
大多数中小型运营商并没有为此组建团队。他们想要授权自己的前缀,而不是成为公钥基础设施专家。托管 RPKI 让他们在熟悉的会员门户中选择一个源 AS 和前綴,而 RIR 则处理证书颁发、签名、续期和发布。
区域服务公开描述了这一好处。ARIN 称托管 RPKI 为最简单的选项,并表示它经营着 CA 和高可用性存储库。RIPE NCC 表示托管用户主要需要保持 ROA 与预期的 BGP 路由一致,而其系统处理加密操作和发布。APNIC 为托管用户管理证书和发布基础设施,并代表他们生成私钥。LACNIC 自 2011 年以来一直提供托管服务。
这种模式产生了正外部效应。一个从不部署委托 CA 的资源持有者仍然可以发布准确的授权。RIR 接口可以在拟议的 ROA 会导致已知公告无效时发出警告。中央系统可以自动化续期、密钥轮换、清单和存储库可用性。支持人员可以帮助成员纠正错误。
将成熟度定义为强迫每个社区网络、大学或本地提供商运营 CA 是反常的。只有大型运营商才能确保的安全将仍然不完整。反对过度依赖的论点必须保留进入 RPKI 的低摩擦路径。
政策目标是具有安全默认值的可选性。托管服务应保持为可访问的默认选项。委托和混合服务应保持为风险需要更多控制的用户的实用退出路径。在它们之间切换不应造成可避免的空白。便捷是有价值的,当它是一种选择时;当它悄然变成束缚时,价值就降低了。
一个门户背后隐藏着五项控制
托管接口呈现为一项服务,但其下至少存在五项控制。
第一是注册范围。RIR 决定其记录将哪些 IP 地址块和 AS 号码与持有者关联,并将它们放入资源证书中。门户无法授权该范围之外的前綴。
第二是路由意图。持有者选择源 AS、前綴和任何最大长度。在设计良好的托管服务中,工作人员不会发明这种意图。用户通过经过身份验证的控制提交,系统会警告明显冲突。
第三是密钥保管和签名。托管提供商生成或存储私钥,并使用它创建签名对象。RIPE NCC 条款将托管 CA 定义为其负责加密操作并托管持有者的公钥和私钥对的 CA。APNIC 同样表示它代表托管用户生成私钥。
第四是发布。RIR 存储库使证书、清单、撤销列表和签名对象可供依赖方获取。发布必须保持新鲜并可全球检索。正确的签名如果验证者无法获取,则几乎没有操作价值。
第五是生命周期权限。服务在资源或服务状态变化时续期、替换和撤销证书,并移除对象。这是注册、合同和路由证据交汇的地方。
门户出于充分的理由隐藏了这种复杂性。问题在于治理也隐藏了它。用户可能认为它控制 RPKI,因为它可以点击“创建 ROA”,而提供商控制着密钥、发布和终止。提供商可能强调路由器做出本地决策,而低估其生命周期操作如何改变这些路由器接收的数据。
一份有用的服务协议应指明每项控制并分配责任。没有这种映射,责任只会在事件发生后显现,此时各方指向不同的层面。
托管密钥保管并非普通外包
组织通常外包电子邮件、工资和云计算。托管 RPKI 在一个方面有所不同:服务提供商同时也是决定证书范围的父级权威。因此,它可能结合了定义可签名内容的权力与执行签名的能力。
这种集中化是高效的。提供商可以在持有量变化时自动更新证书、在过期前续期对象、以及移除用户不再注册的资源的授权。它可以将密钥保存在硬件安全模块中,并比小型运营商更有效地分离操作角色。
它同时也改变了威胁模型。如果认证和批准薄弱,受损的用户账户可能创建有害的路由意图。受损的托管签名环境可能影响许多 CA。错误的注册更新可能移除资源并触发对象更改。内部管理员可能拥有任何员工都不应拥有的权力。法律或合同决策可以在持有者不采取单独签名行动的情况下实施。
这些不是指责 RIR 滥用密钥。它们是控制集中的后果。答案是强大的服务设计:多因素认证、基于角色的批准、高风险变更延迟、独立审计、硬件保护、不可变历史以及注册变更与证书影响执行之间的分离。
持有者应该能够导出一份完整的、签名的路由意图和当前对象集记录。如果服务正确地保持密钥不可检索,它不能导出私钥,但它可以保留足够的信息,以便在委托 CA 或继任托管 CA 下重新创建授权。数据可移植性不是密钥可移植性。
提供商还应披露:账户管理员、RIR 工作人员或自动化事件是否可以撤销整个托管 CA;需要哪些批准;以及错误撤销可以多快恢复。当围绕密钥使用的控制与门户中的绿色“有效”标签一样可见时,安全服务才值得信赖。
单点是撤销和恢复,而非每一次中断
将托管 RPKI 称为单点故障可能过于粗略。存储库可能被复制。现有对象有有效期。依赖方软件会缓存验证数据,并对不可用的存储库有规则。短暂的门户中断可以保持路由验证不变。RIR 可能运营着比成员所能负担的更具弹性的基础设施。
更尖锐的单点是撤销和恢复的权柄。如果 RIR 撤销托管 CA 或终止对认证的访问,用户无法继续在该 CA 下签名。如果 RIR 在服务终止时移除托管对象,运营商无法强制旧存储库无限期地提供它们。父级必须颁发新的委托证书或恢复托管服务,用户才能重新获得有效路径。
当前条款说明了问题。RIPE NCC 条款称所有签名对象在认证服务终止时被移除,并允许在证书与注册记录冲突、出于技术或安全原因、违反条款或持有者结束服务时撤销。ARIN 的协议列出了多项立即终止的理由,将 RPKI 资格与其他协议联系起来,并保留了基于通知的终止权。
法律语言因地区而异,不应扁平化为一个全球规则。合同权利也不能证明其被不公平地使用。问题是结构性的:托管用户依赖同一个交易对手进行持续签名以及退出这种签名安排。
一个可信的托管服务需要退出保证。对于非紧急终止,它应提供一个明确的期限来建立委托或替换 CA、导出配置、验证发布以及协调路由变更。紧急撤销应包括在持有者仍然有权获得认证时,使用干净密钥快速重新注册。对于支付或身份的争议,应有一条快速审查途径,以免不必要地销毁路由证据。
没有这些设施,普通周的高可用性并不能应对最严重的故障模式。
委托 RPKI 改变了谁可以签名
在委托 RPKI 中,持有者运行子 CA 并控制其私钥。父级 RIR 向该子级颁发资源证书。然后,持有者可以创建 ROA 和其他允许的对象,从其网络系统自动化更改,并在支持的情况下颁发进一步的子证书。
这给了运营商三种形式的独立性。它不需要为每次路由变更使用托管签名门户。它可以按照自己的安全策略保护密钥。它可以统一管理从多个 RIR 父级接收的资源,减少跨区域接口的不一致手动操作。
这种独立在密码学意义上是有意义的。RIR 父级不能仅仅因为颁发了子证书就使用子级的密钥签署虚假对象。本地保留的审计历史可以准确显示持有者何时签署了什么。运营商可以决定 BGP 意图变化与 RPKI 对象的耦合程度。
委托并未使持有者成为资源的自有信任锚。父级仍然决定证书中的资源。它可以在转移或归还后用更窄的证书替换。它可以撤销子证书。如果持有者签署超出有效范围,依赖方会拒绝越权声明。
这个界限在争议中很重要。委托防止了对父级托管密钥和用户界面的依赖;它不允许前持有者在合法转移后保留认证。它不会使注册记录变得无关。它让运营商在父级当前认证的范围内控制声明。
因此,委托应被宣传为职责分离,而非分离。它的价值在于没有任何一个机构既拥有所有签名密钥,又控制所有父级决策。它的限制在于资源层次仍然需要一个权威父级。
发布创造了第三种模式
通常的托管与委托 RPKI 比较忽略了一个有用的中间地带。持有者可以运营自己的 CA 和私钥,同时使用 RIR 的存储库发布服务。ARIN 称此为“存储库发布服务”。RIPE NCC 提供“在父级中发布”。APNIC 为自行托管的客户提供发布服务。
这种混合模式将签名保管与分发分开。运营商可以在没有 RIR 托管 CA 的情况下创建对象,而 RIR 提供依赖方已经获取的高可用性存储库。它避免了要求每个持有者暴露和防御全局发布服务。
对于有能力运营者来说,混合服务通常提供最佳平衡。本地密钥控制减少了对托管签名接口的依赖。父级发布减少了操作负担和脆弱存储库的激增。RFC 8181 等标准定义了认证的发布和撤回请求,允许 CA 和存储库由不同方运行。
这种分离并非完全独立。发布提供商可能无法接受变更、变得不可用,或根据其条款移除材料。父级仍然颁发子资源证书。需要最强自主权的运营商可以同时运行 CA 和存储库,同时接受由此产生的可用性和安全职责。
APNIC 2025 年关于 RPKI 可用性的讨论直接说明了权衡。委托 CA 让持有者对其 RPKI 状态有更大的控制权,并负责颁发和续期对象。然而,它仍然依赖 APNIC 信任锚,并且如果使用 APNIC 发布,则依赖该存储库。该文件还警告说,许多委托存储库是单个实例,位于一个地点。
因此,有用的模式是一个频谱。托管将签名和发布置于 RIR。混合将签名保留在本地,发布由提供商负责。完全委托将两者都保留在本地。父级认证仍然存在于三者之上。组织应审慎选择它们有能力吸收的依赖关系。
自行托管有其自身的撤销陷阱
忽略操作故障的委托 RPKI 论据是不完整的。CA 必须在其下一次更新时间之前颁发新鲜的清单和撤销列表。其存储库必须提供一致的材料。密钥必须能在硬件故障中存活而不易被窃取。工作人员必须理解越权声明、密钥轮换和父级交换。
被忽视的委托 CA 可能给依赖方带来负担,并使其自身的对象不可用。RIPE-847 处理了一种极端情况:当 RIPE NCC 在超过三个月内无法发现和验证委托 CA 的当前清单和撤销列表时,在经过合理的发现和通知努力后,应撤销资源证书。该政策明确针对持续非功能性 CA,而非普通的短暂中断。
这一政策揭示了相互责任。委托赋予了持有者签名控制权,但父级和依赖方社区需要确保子级不会无限期地保持故障状态。父级必须能够修剪枯枝。持有者必须收到验证失败、通知和恢复路径的证据。
运营商还面临人员连续性风险。构建 CA 的那位工程师可能离职。备份密钥可能存在问题但不可读。公司收购可能使网络团队与安全设备分离。危机可能暴露本地主权仅依赖于一台笔记本电脑和一段记忆。
在计算方面,委托服务不一定是昂贵的;现代 CA 软件可以在低配硬件上运行。真正的成本是制度性的:所有权、待命责任、变更审查、备份测试、存储库监控和继任。大型运营商可能在这些任务上失败,而自律的小型运营商可能做得很好。
因此,与托管服务的比较必须同时考虑两个撤销单点。托管用户面临依赖提供商决策和恢复的风险。委托用户则面临成为自身分支内失效权威的风险。混合设计和强大的父级流程可以减少但无法消除任何一种风险。
迁移是检验可选性的试金石
只有在用户可以改变选择时,市场才提供选择。托管和委托 RPKI 之间的迁移在技术上很微妙,因为新旧 CA 可能覆盖相同的资源,而依赖方在不同时间检索数据。
RIPE NCC 托管文档表示,用户转向委托服务必须首先撤销托管 CA,并且目前在那里无法进行“先建后断”的迁移。APNIC 表示托管和自托管模式在过渡期间可以并行运行。ARIN 告诉用户在更改部署时联系注册服务。这些是实质上不同的操作体验。
理想的过渡是在密钥和发布点变化时保留有效的路由意图。用户应导出其当前授权,准备新 CA,测试父级和存储库交换,发布等效对象,并在旧 CA 消失之前从独立验证者观察它们。如果区域政策禁止重叠,服务应支持计划内的切换并快速回滚。
并行认证并非自动无害。重复或不一致的对象可能混淆运营商,旧密钥不应比需要的时间更长地保持权威。安全重叠需要固定的持续时间、等效的资源范围、明确的责任和自动关闭。然而,替代方案不应该是用户既没有托管控制也没有委托控制的未说明时期。
迁移在转移、合并和公司重组期间也很重要。买方可能希望委托控制,而卖方使用托管服务。通过多个 RIR 运营的集团可能合并 CA。RIR 应将 RPKI 过渡视为资源迁移的标准部分,而不是留到交接日的后事。
可移植性指标将改善问责制。每个 RIR 可以发布正常步骤、最短通知、没有变更访问的预期期间、是否提供重叠以及故障切换的升级联系人。如果可选性不能安全地行使,那么托管默认值比其简单界面所暗示的具有更多的锁定效应。
关键网络需要基于后果的选择
没有适用于所有持有者的单一正确部署模型。选择应取决于无法更改授权的后果、路由的复杂性以及组织运营 CA 的能力。
拥有少数稳定前缀和一个源的小型提供商可以合理地使用托管服务。RIR 可以比提供商更可靠地保护密钥、续期对象和运营发布。委托可能增加故障模式而没有实质收益。提供商仍应导出其 ROA 清单,维护紧急联系人并理解终止条款。
具有频繁路由变更、多个源、客户和自动化缓解的多 RIR 运营商更有理由采用委托签名。它可以将授权与已批准的网络变更集成,跨父级保持一个控制面,并减少对多个门户的依赖。混合发布可以避免运行许多公共存储库。
公共部门网络需要特别注意。医院、紧急通信、税务系统、公共云和研究网络因碎片化可达性而可能遭受不成比例的损害。这并不意味着每个机构都应自行托管。这意味着所选模式应有明确的连续性目标、经过测试的访问恢复、多个经过培训的管理员以及与父级预先商定的升级路径。
下游责任也很重要。直接持有者可能为无法直接参与 RIR 服务的客户创建 ROA。如果一个托管账户控制许多下游源,账户暂停或接管将产生更大的爆炸半径。委托子 CA 可以分散控制,但前提是父级和持有者能够安全地支持它们。
董事会应问一个简单的问题:如果当前提供商或本地 CA 在路由变更期间不可用,有效的授权将如何恢复?答案应指明人员、密钥、父级联系人、发布路径和最大可容忍延迟。仅仅因为设置界面简单而选择的模型未能通过这一测试。
成员治理应塑造默认设置
RIR 不是普通的软件供应商。它们在区域、社区治理的机构内协调唯一资源。它们的托管 RPKI 条款可能影响那些无法将相同地址带到竞争父级的成员。这使成员问责制成为服务设计的核心。
成员应批准或审查允许撤销的事件类别、每种类别的通知、争议账户的处理以及退出委托服务的路径。技术社区应审查证书和存储库实践;法律和治理社区应审查终止和责任语言。单独的学科都不足够。
默认应为托管是因为采用很重要,而不是因为制度集中不可见。在注册时,用户应收到一份简单的控制比较。托管意味着提供商管理密钥和存储库。委托意味着持有者管理密钥,或许还有发布。混合分配这些职责。所有模式仍处于父证书之下。
用户不应需要证明特殊身份才能选择委托,如果他们满足已发布的技术要求。董事会也不应强迫无法安全运营的成员进行委托。服务费应反映实际成本,而不将密码独立性定价为仅限大型老牌企业的奢侈品。
条款变更应提前通知社区,除非紧急安全或法律使这不可能。例如,RIPE NCC 2026 年条款定义了托管和委托保管,并指定了撤销条件。每个地区都应提供类似的清晰度,即使具体规则不同。
机构应发布事件类别和恢复性能。如果成员只知道服务正常运行时间,就无法判断便利交易是否仍然合理。门户可能可用,而持有者错误地无法更改对象;存储库可能可达,而注册错误已移除了正确的对象。
合同应区分滥用和分歧
广泛的终止条款保护提供商免受欺诈、妥协和非法使用。它们也可能将无关的争议与认证连续性结合起来。未付发票、公司文件问题、滥用指控和被盗私钥并不构成相同的路由风险。
服务条款应对它们进行区分。确认的密钥泄露可能需要立即撤销。完成转移后的权利丧失需要快速的证书变更。疑似账户接管需要冻结新的签名、强重新认证和在安全的情况下保留现有有效对象。有争议的费用可能证明服务补救是合理的,但如果资源仍注册在持有者名下,自动销毁路由授权应作为最后手段。
这种区分并不创造无条件的认证权。它使补救措施与威胁对齐。RPKI 不应仅仅因为有效而成为通用的收集机制。RIR 也不应为不再持有资源的当事方继续签名。
书面理由对托管用户最为重要,因为他们无法绕过提供商。通知应指明限制是否影响门户访问、新对象创建、发布、证书范围或整个 CA。临时访问冻结与撤销不同,用户需要知道哪种情况适用。
审查应足够快以支持路由操作。技术审查员可以首先验证身份、资源范围和对象差异。单独的合同审查员可以决定基础争议。对于大范围验证影响,应在正常办公时间之外提供紧急联系人。
责任条款也应反映分配的控制。托管用户负责不正确的指令和凭证安全。提供商负责忠实地实施已接受的指令、保护其保管的密钥以及遵循已发布的撤销流程。远程网络仍对自己的路由策略负责。明确的划分比暗示每个后果都属于最弱方的条款更可信。
连续性需要演练,而非政策页面
运营商应在危机之前测试其 RPKI 恢复。演习可以从不更改公共对象开始。团队应列出当前前缀、源 AS、最大长度、父 CA、托管配置、委托子级和发布提供商。他们应将此清单与实际 BGP 公告和已验证的有效负载进行比较。
托管用户应验证至少两名授权人员可以通过独立凭证访问服务。运营和法律联系人应为当前状态。团队应知道在正常访问失败时如何联系 RIR,以及身份将如何重新建立。应保留一份机器可读的预期授权副本。
委托用户应在隔离环境中测试密钥备份和恢复,监控证书续期,验证清单和撤销列表,并从自己网络外部观察发布。应有多人了解父级和存储库交换。文档应在收购或员工离职后存活。
混合用户应测试两个部分。本地签名成功是不够的,如果发布服务拒绝该对象。他们应知道如何区分 CA 故障和存储库故障,以及是否可以在父级下及时建立备用存储库。
所有用户应演练源 AS 的更改。测试应包括在路由变更之前创建新授权,通过独立验证者观察,应用 BGP 更改,检查验证状态,并在收敛后撤回过时授权。如果现场测试不安全,区域测试环境可以暴露流程失败。
结果应以小时而非形容词表示的连续性目标。不同组织将选择不同的容忍度。当演练精确揭示了控制恢复的依赖关系并指定了所有者来修复它时,演练就是成功的。
依赖方完善了风险图景
资源持有者和 RIR 并不单独决定可达性。依赖方获取和验证 RPKI 材料。路由器接收已验证的有效负载并应用本地策略。这种分布式设计限制了中央命令,但也使后果不均匀。
如果托管 CA 消失且没有覆盖授权,之前有效的路由可能变为 NotFound。许多网络继续接受 NotFound。如果存活的覆盖授权与路由冲突,它可能变为 Invalid,而拒绝 Invalid 的网络可能会丢弃它。缓存和刷新时序意味着变化出现在不同时刻。
运营商不应假设存储库可用性或证书撤销会产生一个立即的全局结果。APNIC 的可用性论文警告不要比架构预期更强烈地依赖 RPKI,例如要求客户提供 ROA 并拒绝任何未被覆盖的路由,而不考虑可用性特性。
这种谨慎并不削弱源验证的理由。它呼吁分层安全。网络可以将 RPKI 与客户合同、路由过滤器、互联网路由注册数据、直接验证以及受严格控制的紧急例外相结合。例外不应悄然变成对不良路由数据的永久接受。
依赖方多样性也可以帮助恢复。持有者和 RIR 在宣布切换完成之前应观察多个验证器实现和视角。存储库可能在本地看起来健康,而远程验证者无法获取。签名对象可能存在,但因越权声明或陈旧支持材料而被拒绝。
因此,便利陷阱从两端都可见。生产者可能依赖一个签名提供商。消费者可能依赖一类验证数据,而没有暂时丢失的计划。成熟的路由安全让 RPKI 在其能证明的方面具有权威性,同时拒绝将其视为每个紧急情况下唯一可用的证据。
更好的托管交易有具体条款
托管模型可以改进而不变得繁琐。第一项改革是对象托管记录:一份持续可导出的、已签名的当前路由意图、已认证资源和发布标识符列表。它不会暴露托管私钥。它将让持有者能够在替换 CA 下重建等效授权。
第二是撤销阶梯。低风险的账户问题应限制更改,同时在安全的情况下保留现有对象。较高风险的注册事件应产生通知和过渡。确认的妥协可以触发立即撤销和干净密钥恢复。每个阶梯应有指定的批准和审查。
第三是可移植注册。选择委托的用户应能够准备身份交换、发布和等效对象,然后才移除托管 CA,并采取保障措施防止不受控制的重叠。无法支持此功能的区域服务应发布确切的差距和缩小差距的计划。
第四是破坏性操作的独立确认。撤销整个托管 CA、删除所有配置或缩小已认证资源需要双重控制,除非自动续期或预先授权的转移遵循已验证的事件。系统应在执行前显示对已知公告的预期效果。
第五是衡量不仅仅是正常运行时间的服务报告。RIR 应报告影响证书的注册错误、失败的迁移、紧急撤销、恢复时间和通知性能。应谨慎披露小数字,而不假装支持全球比率。
第六是狭窄的补救措施。如果提供商的错误移除了有效授权,它应立即提供恢复、专家支持、保留的事件记录和独立审查。严重的重复故障应提交给董事会和成员,而不是停留在私人支持票据中。
这些保障使托管 RPKI 更方便,而不是更不方便。它们减少了当正常假设失败时所需的定制协商量。
资源号协会可以增加什么
资源号协会将自己定位为准确注册、持有者权利、参与和降低官僚壁垒的倡导者。托管 RPKI 是将这些原则转化为可衡量的会员服务的合适领域。
NRS 可以发布一份比较五个 RIR 的部署选择登记册。它应列出谁持有私钥、委托服务是否可用、是否提供父级发布、迁移如何进行、发布了哪些撤销理由、适用哪些通知以及持有者可以在哪里寻求审查。每个条目应链接到相关的 RIR 材料并说明未解决的问题。
它可以维护三项连续性演习:一项针对托管用户,一项针对委托 CA,一项针对混合发布。托管演习将测试访问恢复和配置导出。委托演习将测试密钥、清单、父级交换和继任。混合演习将测试本地签名与远程发布。结果可以对参与者保密,而常见的故障主题在未公布比率的情况下发布。
NRS 还可以将较小的运营商带入区域政策讨论。大型网络可以评估 CA 软件并通过已建立的关系协商紧急支持。农村提供商或非营利网络可能不知道门户访问、证书范围和对象发布是独立的控制。成员会议上的简单问题可以改善每个人的服务。
贡献应保持边界。NRS 的倡导并不确立它是 RPKI 信任锚、证书颁发机构、存储库运营商或中立仲裁者。它不应暗示每个持有者可以安全地自行托管,或 RIR 服务本质上是可疑的。其有用角色是使选择更明智、退出更实用、问责制更具可比性。
积极的制度批评比猜疑更持久。一个赞扬强大过渡设计并识别薄弱通知的登记册可以为 RIR 董事会提供实用的改进清单。它还可以向运营商展示托管服务何时是负责任的选择,而不是将本地密钥保管视为地位的徽章。
常见反对意见忽略了分配问题
托管 RPKI 的辩护者常说 RIR 已经控制注册,因此委托密钥增加甚少。前提部分正确:父级可以缩小或撤销委托证书。结论错误。子密钥控制仍然防止父级签署子级的路由意图,并让运营商无需托管接口即可进行更改。分离并不消除等级制度;它减少了其中的集中。
批评者说托管服务不安全,因为 RIR 持有密钥。这也过于宽泛。运营良好的 RIR 可以比许多成员更可靠地保护密钥、续期对象和发布存储库。相关问题是其安全、授权和恢复控制是否与权力集中相匹配。
另一个反对意见是并行迁移削弱了唯一性。如果设计不当,确实如此。为等效授权进行短期、可控的重叠与无限期的竞争认证不同。即使短重叠不可接受,计划内的切换和快速回滚仍然是可能的。
有些人认为依赖方本地政策使生产者连续性的紧迫性降低。本地政策确实缓和或改变了后果。它无法重新创建缺失的有效授权,也不能防止选择性可达性损失。生产者仍然需要准确、连续的证据。
最后,一些成员会说复杂的选项会提高所有人的费用。区域社区可以保持托管服务简单,同时对委托支持或发布收取透明的增量成本。基本保障——理由、通知、导出和恢复——不是奢侈功能。它们是绑定到唯一资源的服务的基本职责。
每个反对意见在作为分配问题时都会变得更清晰。哪一方控制风险,哪一方可以预防,哪一方可以恢复?托管和委托模型应根据这些答案而不是对中央或地方运营的意识形态偏好来判断。
在信心变得绝对之前,证据应该改进
公开材料解释了架构、条款和个别事件,但它没有提供完整的跨 RIR 被撤销托管 CA、失败迁移、被阻止变更、恢复时间或路由影响的记录。服务页面披露了能力,而非每个操作结果。私人支持案例和安全事件适当不全是公开的。
这限制了经验性主张。无法估算托管 RPKI 导致路由丢失的全球概率。公开证据也不能证明委托操作对所有持有者更可靠。区域服务模型和控制路径是可观察的;比较故障率则不然。
RIR 报告可以部分弥合差距。它应区分门户不可用、签名失败、存储库不可用、父证书错误、用户配置错误和非自愿终止。它应记录当前对象是否保持有效、路由状态是否改变以及恢复花费了多长时间。
运营商可以贡献匿名化账户和可验证的时间线。研究人员可以观察公共证书和对象更改,但应避免仅从消失推断意图。转移、密钥轮换或故意撤回 ROA 从外部看起来可能像失败。
因此,信心在架构上应最强,在普遍性上较弱。托管服务集中了命名的控制。委托服务重新分配了其中一些。两者仍处于 RIR 父级之下。这些是有记录的事实。每种安排造成实质性损害的频率仍然没有充分测量。
承认这一限制的治理计划比选择几次中断或正常运行时间数据来证明普遍情况更可信。更好的证据将使未来的社区能够调整默认值,而无需猜测。
便利应该是可逆的
托管 RPKI 做了良好基础设施经常做的事情:它将一项困难的安全实践变成了普通操作。运营商可以在不构建 CA、管理清单或防守公共存储库的情况下创建路由授权。这一成就应予以保留。
危险出现在简单进入与没有安全退出配对时。如果注册机构持有密钥、发布对象、更改证书范围并控制重新注册,争议或错误可能使运营商无法维护自己的路由意图。高正常运行时间不会消除这种结构性依赖。
委托 RPKI 提供了一个有意义的平衡力量。持有者用自己的密钥签署,可以自动化本地更改,并可以连贯地管理多个父级。混合发布减轻了负担。任何一种选项都不能消除父级 CA 或可靠操作的职责。
成熟的解决方案是多元的。托管服务仍然是普通用户的默认选择。委托签名是有能力的持有者的标准权利。父级发布作为中间路径可用。迁移是经过测试的,并且在安全的情况下支持先建后断。撤销理由是精确的,普通争议不会导致不成比例的路由后果,紧急行动附带快速审查和恢复。
便利不是控制的反面。它是一种在日常操作中借用另一机构控制的方式。只有当借方能够看清条款、检索其意图、选择不同安排并在便利出借者犯错时恢复时,这种交易才是合理的。
RPKI 要求网络依赖密码学声明。其治理应对制度承诺应用同样的纪律。谁持有密钥,谁可以撤销,谁发布,谁恢复,应该像 ROA 中的前缀和源 AS 一样明确。当这些答案是明确和可逆的时,托管服务是一个入口。当它们隐藏且无法逃脱时,它是一个陷阱。
来源
- IETF, RFC 6480,支持安全互联网路由的基础设施:https://www.rfc-editor.org/rfc/rfc6480
- IETF, RFC 6483,使用资源证书公钥基础设施和路由源授权验证路由起源:https://www.rfc-editor.org/rfc/rfc6483
- IETF, RFC 6492,资源证书供应协议:https://www.rfc-editor.org/rfc/rfc6492
- IETF, RFC 6811,BGP 前缀源验证:https://www.rfc-editor.org/rfc/rfc6811
- IETF, RFC 7115,基于资源公钥基础设施的源验证操作:https://www.rfc-editor.org/rfc/rfc7115
- IETF, RFC 8181,资源公钥基础设施的发布协议:https://www.rfc-editor.org/rfc/rfc8181
- IETF, RFC 8211,资源公钥基础设施中证书颁发机构或存储库管理员的不利行为:https://www.rfc-editor.org/rfc/rfc8211
- ARIN,RPKI 部署选项:https://www.arin.net/resources/manage/rpki/options/
- ARIN,RPKI 常见问题:https://www.arin.net/resources/manage/rpki/help/faq/
- ARIN,RPKI 服务条款:https://www.arin.net/resources/manage/rpki/tos/
- RIPE NCC,使用 RPKI 系统:https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/using-the-rpki-system/
- RIPE NCC,使用托管证书颁发机构:https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/resource-certification-roa-management/
- RIPE NCC,使用委托证书颁发机构:https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/using-a-delegated-certification-authority/
- RIPE NCC,认证服务条款和条件:https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/legal/ripe-ncc-certification-service-terms-and-conditions/
- RIPE NCC,在父级中发布服务和存储库条款和条件:https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/legal/ripe-ncc-publish-in-parent-service-and-repository-terms-and-conditions/
- RIPE NCC, RIPE-847,撤销持续非功能性委托 RPKI CA:https://www.ripe.net/publications/docs/ripe-847/
- APNIC,资源公钥基础设施:https://www.apnic.net/community/security/resource-certification/
- APNIC,认证实践声明:https://www.apnic.net/community/security/resource-certification/certification-practice-statement/
- APNIC,RPKI 可用性担忧:https://www.apnic.net/wp-content/uploads/2025/10/RPKI-availability-concerns_241025.pdf
- APNIC,APNIC 现已支持符合 RFC 的在父级中发布自托管 RPKI:https://blog.apnic.net/2020/11/20/apnic-now-supports-rfc-aligned-publish-in-parent-self-hosted-rpki/
- LACNIC,资源认证:https://www.lacnic.net/640/1/lacnic/resource-certification-rpki
- 资源号协会,我们的章程:https://nrs.help/our-charter/
- 资源号协会,常见问题:https://nrs.help/faq/

