摘要

  • 路由起源授权（Route Origin Authorization，ROA）是一份签名声明，表明指定的自治系统可以发起特定的前缀。它并非所有权转让书，也不是对路由器的指令，不担保路由无害，也无法证明所指定的 AS 在私人租约下仍享有权利。
  • 在大多数租约中，出租人仍是直接的资源持有者，因此最接近 RPKI 认证链。承租人运行网络，知晓哪些起源 AS 和更具体的路由在操作上是必要的。上游运营商承载或过滤路由。RIR 运营信任锚或父级认证服务。这些是不同的权力。
  • 托管和委派的 RPKI 改变的是保管和执行方式，而非底层的商业协议。托管服务将关键操作和发布交由 RIR 处理；委派服务允许持有者运营 CA 并通常持有其私钥。这两种安排本身都不会赋予承租人及时的权利，也无法保护其免受有争议的删除。
  • 每份租约都应附带授权计划，明确指定确切的前缀、允许的起源 AS、最大长度、起止时间窗口、常规变更截止日期、紧急截止日期、审批人、身份验证渠道及需保留的证据。仅笼统承诺提供授权书是不够的。
  • 合同时间与 RPKI 时间必须有意识地协调一致。托管服务可能会自动续签签名对象，缓存按照自身节奏刷新，路由在商业期限结束后仍可能保持可见。因此，在午夜到期既不是即时的技术撤销，也不应在流量迁移之前删除唯一有效的 ROA 的充分理由。
  • 紧急访问应范围窄且具冗余性。承租人需要能够快速添加预先批准的缓解或替换源的方式，而出租人需要防止无限委托的限制。双重批准、受限前缀、短期紧急授权、独立日志以及事后审查，可同时满足双方需求。
  • 商业纠纷不应通过突然改变全球路由系统来解决。除非发生活跃的安全紧急情况，ROA 的删除应先通知，设置短暂的连续性窗口，独立上报并协调路由撤销。最终的撤销必须确定；达到这一结果的路径不应将客户作为筹码。

租约将使用权与认证分离

IPv4 租约中棘手的问题并非谁拥有路由器，而是谁能做出其他路由器可能依赖的密码声明。

承租人可以配置起源 AS、宣告前缀、服务客户、处理滥用举报并支付转接费用。然而，如果前缀仍认证给出租人，承租人可能无法创建、修改或删除描述其自身实时宣告的 ROA。出租人可以在经济上被动，却在技术上起决定性作用。一个被遗忘的门户账户或一位无法联系的签署人，都可能将常规路由变更转变为中断风险。

这并不意味租约存在缺陷。它意味着租约横跨两套权威体系。合同法决定一方对另一方承诺了什么。RPKI 决定一份签名的授权能否通过根植于号码资源层级的链条得到验证。BGP 决定网络实际宣告和选择什么路径。转接合同决定上游将接受什么。这些体系都不会自动读懂其他体系。

RFC 9582将 ROA 定义为一个签名对象，地址块持有者通过它授权一个 AS 向一个或多个前缀发起路由。其安全一节对治理特别有用：RPKI 提供的是授权，而非身份认证或不可否认性。该对象证明，在依赖方处理它时，存在一条有效的认证路径支持该声明。它不公开租约、价格、客户、受益用户、路由原因或商业协议中的截止期限。

这一区别驳斥了两种常见的捷径思维。第一种认为，能够创建 ROA 的一方必定是经济所有者。这一推断并不成立。第二种认为，ROA 中指定为起源的一方必定控制着地址权利。这同样不成立。持有者可以授权客户的 AS、上游网络、云网络或缓解服务商，而无需转让资源。签名对象的设计本身就比其周边关系更狭窄。

因此，正确的问题不简单是“谁控制 ROA？”，而是一组问题：谁可以请求变更？谁来决定请求是否在租约范围内？谁运营签名系统？谁能阻止不安全的变更？当主要方无法联系时，谁能采取行动？若承诺的变更延迟，谁来承担损失？当路由权终止时，谁必须移除授权？

只回答第一个问题的租约，将其余问题留给了临时应对。

四位参与者持有四种不同的权力

出租人、承租人、上游网络和 RIR CA 经常被描述为仿佛它们是单一指挥链上的节点。更准确的理解是，它们是四位权力既有交叉又各不相同的参与者。

出租人通常保留着资源认证所源自的注册关系。在托管 RPKI 服务中，出租人组织的授权用户可以通过 RIR 的界面创建 ROA 配置。在委派安排下，出租人可以运营自己的 CA 并持有对应的私钥。出租人的关键能力在于认证：它可以使关于前缀和起源 AS 的声明进入或离开经过验证的 RPKI 集合。

承租人拥有运维知识。它知道预期的起源、上游设计、客户迁移状态、流量工程所需的更具体路由、缓解安排以及新路由必须生效的日期。其关键能力在于使用：它或其服务商能够配置并发起 BGP 宣告。即使路由变为 RPKI 无效，该能力依然存在，因为 RPKI 不会关闭 BGP。实际后果取决于哪些网络应用路由起源验证及如何应用。

上游网络拥有接受与传播的权力。它可以要求提供授权书、IRR 对象、匹配的 ROA、合同证明或某种组合。它可以根据自己的记录、IRR、经过验证的 RPKI 载荷或人工审查来构建客户前缀过滤器。它可以因为客户关系未经核实而拒绝一条原本有效的路由，或按照其策略承载一条未找到（Not Found）状态的路由。有效的 ROA 是相关证据，而非对上游的命令。

RIR CA 处于认证层级之中。RFC 6480描述了一种与号码资源分配相一致的架构。RIR 服务颁发或维护父级资源证书，为众多持有者托管签名、发布资料，并将已认证资源的变化与层级关联起来。RIR 并非大多数租约的当事方，通常也不知晓其完整的商业条款。其系统能够认证持有者账户并验证资源覆盖范围，而无需知道承租人的账单是否存在争议。

这些权力不应被混为一谈。出租人能够删除 ROA，并不意味它应当控制承租人的路由器。承租人能够发送宣告，并不意味它应当对出租人的聚合地址拥有不受限的签名权。上游的过滤器并不能解决租约争议。RIR 的证书也并不能裁决受益使用问题。

良好的治理始于承认，没有任何单一参与者能看到整个关系全貌。

ROA 授权的是一个起源，而非路由的所有维度

ROA 的狭窄性是一种优势，但当合同对其进行过于宽泛的描述时，就变得危险了。

一份 ROA 指定一个起源 AS 和一个或多个前缀。它可以包含一个最大长度，允许某些更具体的宣告。如果多个 AS 被授权发起同一前缀，则需要单独的 ROA。该对象并不指明哪条上游可承载路由、什么 AS 路径可接受、起源方是否有当前服务协议、哪些客户流量属于该地址，或者宣告在地理上是否可预期。

这就是为什么“符合 RPKI 的租约”可能隐藏的问题比揭示的更多。出租人可以为一个错误的商业方的 ASN 创建一个技术上有效的 ROA。承租人可以在服务合同结束后继续通过授权起源宣告。一个被授权的 AS 可能意外泄露或故意宣告一个因最大长度过宽而被允许的更具体路由。一条路由可以处于 RPKI 有效状态，但在操作上却是错误的或滥用的。

RFC 6483警告说，一份 ROA 可能影响被同一地址空间覆盖的其他宣告：来自未列出起源的路由，或超出允许长度的更具体路由，可能变为无效。它建议应考虑到所有合法授权的起源以及相关的更具体路由。RFC 7115同样将起源验证视为一种运维输入，而非通用的路由选择判决。

对于租约而言，这意味着授权计划不能仅仅写“出租人将创建一份 ROA。”它必须声明确切的前缀-起源对，并解释更具体路由的策略。如果一个 /20 将仅作为 /20 从承租人的 ASN 宣告，则不应出于方便而授予不必要的宽松最大长度。如果承租人在迁移期间需要从两个起源宣告 /24，则两个起源和临时期限都应明确说明。

上游的角色仍是独立的。MANRS 网络运营商行动呼吁运营商确保自身及客户宣告的正确性，保持可用的联系方式，并发布他人能够验证的信息。仅检查是否存在 ROA 的转接提供商，并未完成该任务。它仍需知道其客户是被授权请求其承载路由的一方。

因此，租约应承诺多项相互协调的事实，而非某种魔法般的状态：出租人的商业许可、承租人的运维指令、RPKI 中的起源授权、准确的路由信息，以及预期上游的接受。

托管 RPKI 将执行集中在持有者账户上

托管 RPKI 之所以具有吸引力，是因为它省去了资源持有者的大部分密码管理。这种便利性也澄清了租约依赖的所在。

RIPE NCC 的托管 CA 指南指出，托管服务根据授权账户管理的配置，对 ROA 对象进行签名、发布和续期。用户管理预期的起源和前缀信息；服务端处理密钥、对象续期和发布。ARIN 的托管 RPKI 文档同样将 CA 和签名置于 ARIN 处，并表示下游组织在无法直接参与的情况下，必须由其上游提供商代为提交 ROA。

对出租人而言，托管服务可以减少运维故障。没有需要承租人监控的私有 CA 仓库，也不需将签名密钥存放在员工笔记本电脑中。然而，对承租人而言，关键问题变成了账户治理。出租人组织中哪些人可以批准请求？是否提供全天候覆盖？承租人能否拥有受限角色，还是每次变更都必须由持有者转录？如果出租人的账户在身份核验、公司变更或争议期间被锁定，会发生什么？

不应随意共享门户访问权限。将出租人的通用凭据交给承租人，可能暴露不相关的前缀、其他客户以及破坏性操作。这还会模糊责任归属：出租人后续无法分辨变更是由其员工、承包商还是客户所做的。即使界面支持多用户，授权也应限定在组织及每个人被允许执行的任务范围内。

更安全的托管模式将承租人视为经过验证的请求方，将出租人视为受限的审批方。请求使用指定通道，标识租约和前缀，包含拟定的起源和最大长度，并获取事务记录。常规变更设有服务截止期限。紧急变更使用带有独立身份验证的更快速通道。出租人方面应有两名人员能够操作，承租人方面也应至少有两名获批的请求者。

自动化可以减少延迟，但应严格执行授权计划，而非绕过它。涉及已列出前缀、已列出 ASN 和允许的最大长度的请求，可能有资格快速批准。涉及授权未知 ASN 或更宽泛更具体范围的请求，则应停下进行人工审查。区别在于，是将已知承诺自动化，还是悄然扩大承诺。

托管服务解决了密钥运营问题。但它不会解决商业委托问题，除非合同和账户角色也做到了这一点。

委派 RPKI 移动的是密钥，而非父级关系

委派 RPKI 可以给予资源持有者更多的技术自主权。但它也可能造成一种误解，以为持有者已摆脱所有上游依赖。

RIPE NCC 对托管与委派服务的比较指出，委派模式下的运营方控制其资源证书及对应私钥，并可选择发布位置。ARIN 的部署选项说明，直接持有者可以运营自己的 CA、签署 ROA，并在委派模型下为客户颁发资源证书。APNIC 在其资源认证资料中也将自托管模式认定为委派 RPKI。

该架构可以支持更直接的分工。一个成熟的出租人可以运行父 CA，并颁发仅限于承租人前缀的子级资源证书。承租人随后可在该受限集合内签名对象，而无需获得对出租人其他资源的权力。租约结束时，出租人可以按照约定顺序撤销子证书或任其过期。

表面上的优雅背后是运维责任。必须有人保护私钥、维护 CA、发布当前对象、管理清单和撤销信息、监控可用性、轮换密钥并保留恢复访问权。RIPE NCC 关于持续无法正常运作的委派 CA 的政策说明了长期故障的后果：若在较长时间内无法发现和验证当前物料，父级可能撤销委派的资源证书。委派是控制与维护的结合，而非一次性的交付。

父级关系同样依然存在。委派的证书存在于层级之中。若已认证的资源发生变化或父证书被撤销，子级的授权将受到影响。RFC 8211正是出于本地持有密钥并不能消除层级和发布依赖这一原因，分析了 CA 及仓库管理者的有害或错误行为。

对于许多承租人而言，运营 CA 可能过于负担沉重。对于有频繁起源变更、多条上游或严格连续性需求的大型运营商，受限的委派或许值得付出成本。选择应取决于变更频率、中断容忍度、人员能力以及出租人的资产组合设计，而非持有密钥的声望。

最重要的是，委派 RPKI 绝不应变成一种非正式的永久赠予。子资源、证书有效期、续期规则、撤销触发事件、仓库责任、紧急联系信息以及退出时的销毁或转移证据，都应纳入租约之中。将私钥移向承租人更近处，减少了一处延迟，却也增加了有序终止的重要性。

授权计划是缺失的商业工具

主协议可以阐明经济上的约定。一份单独的授权计划应以工程师和律师均能检验的方式，阐明路由安全上的约定。

计划以确切的 CIDR 开头。接着列出每个被许可的起源 AS、控制该 AS 的法律实体、预期的转接或托管关系，以及每次宣告所允许的前缀长度。若有多个起源是临时的，计划应给出它们的启用和移除日期。若承租人可能使用缓解服务商，该服务商的 ASN 可以预先批准，但仅在事件发生时才会激活。

接下来是角色。指明出租人的服务负责人及备用审批人、承租人的网络负责人及备用请求人，以及每个预期上游的联系人。使用角色地址和经过验证的渠道，而非仅靠具名员工。员工会离职；授权应能存续，而不会留下失效的个人账户。

接着，计划设定时限。常规请求可能需要在一个工作日内完成。计划内的迁移可能需要提前五或十个工作日的通知。严重中断可能要求在十五分钟内确认，并在六十分钟内完成受限的变更。精确数字因服务而异，但沉默不语并不构成服务水平。

变更记录应包括请求时间、经验证的请求者、受影响的前缀、新旧起源、最大长度、业务理由、批准、发布观察和验证观察。这并非为官僚主义而设。当一条路由变为无效时，各方需要知道 ROA 是未曾变更、已变更但尚不可见、变更错误，还是被另一条覆盖性的 ROA 使之失效。

最后，阐明出租人可以拒绝哪些请求。超出所租前缀范围的请求、非获准运营方控制的 ASN、超出约定路由设计的最大长度，或会导致另一位客户路由无效的变更，均可要求先修改计划而非立即执行。拒绝应有理由并标明时间戳，而非含糊地以安全为由。

计划应有版本控制，并附有签名或等效的认证接受方式。在线 ROA 集合应在激活时、每次获批变更后、定期审查时以及终止前，与之进行比对。届时，协议对控制权就有了可衡量的答案：出租人在预先商定的授权范围内控制认证；承租人在同一授权范围内控制运维请求；任何一方都不得悄然扩大另一方的风险。

合同时间与 RPKI 时间是不同的时钟

租约使用日期，因为日期对法院和财务团队而言易于理解。路由安全则通过发布与取回运行，二者的边界很少重合。

租约可能于周一 UTC 时间 00:00 开始。ROA 可能提前创建，以便依赖方缓存能在首次宣告前获取它。托管服务可能会在配置保持活跃期间自动续签签名对象。若租约结束，即使最后发布的授权仍然有效且可见，商业权利也可能已到期。反之，在 00:00 删除配置并不能证明每个依赖方在 00:01 都已移除相应的已验证载荷。

因此，合同需要的不是一个时间点，而是三个。授权就绪时间，即预期路由已具备可见的有效授权，且上游已确认其过滤器。服务使用时间，即承租人获许宣告前缀并承载客户流量。授权结束时间，即在流量已撤销后，旧起源不得再在 RPKI 中表现为被许可。

这些时间点可以重叠而不矛盾。ROA 可以在商业使用前准备就绪，前提是禁止承租人提前宣告。它可以在有序撤销期间短暂保留，前提是禁止承租人新增客户，并且必须减少流量。剩余的授权是受控的过渡能力，而非租约经济利益的延长。

这也解释了为何 ROA 过期并非终止的良好替代。较长的证书或对象寿命可能超越租约期限。较短的寿命则可能在租期内造成本可避免的续期风险。托管系统可能在到期前早早续期，而委派系统则依赖本地操作。治理事件应当是明确的终止指令，并辅以观察确认，而非寄望于定时器与协议恰好吻合。

反向错配同样重要。若出租人在承租人的替换地址或备用起源尚未就绪时就删除了 ROA，拒绝无效路由的网络可能会停止承载流量。即使出租人在最终日期上合同正确，客户仍要承受中断。若出租人从未删除它，前承租人则保留了一种较弱但真实的机会，仍能发起某些验证器视为授权的路由。

因此，时间对齐并非宽纵。它是一种纪律：让授权在依赖之前出现，并在依赖之后消失，且尽可能减少服务能够容忍的不安全重叠。

紧急变更权应在紧急情况发生前设计好

对 ROA 治理最具揭示性的考验，并非计划内的迁移。而是周六发生中断时，获准的起源无法承载流量，且通常负责签署变更的唯一工程师正在睡觉或无法联系。

紧急情况可能需要新的转接提供商、DDoS 缓解 ASN、备份数据中心、路由器故障后的替换起源，或临时更具体的宣告。也可能涉及已泄露的 RPKI 凭据，或一份意外授权导致合法路由变为无效。观察到事件的可能是承租人、上游、出租人或外部网络。

租约应预先授权类别，而非无限的行动。备用 ASN 清单可在签署时验证。可设定紧急情况下的最大前缀长度。可以允许承租人仅激活其所租前缀，且只允许短期。任何更宽泛的变更需另加一位审批人。这给予了运营方速度，同时未交给它一张永久的空白支票。

身份验证必须能在同一事件中存活。若常规请求依赖于托管在受影响前缀后的某个电子邮件域，该通道可能在需要时发生故障。应使用至少一种带外方法，并在双方组织中保留联系信息。出租人应要求请求代码、指定角色、回呼或适合各方风险的加密审批。关键在于防范冒充，同时避免将身份核验变成耗时数小时的障碍。

变更本身应是可逆的。添加所严格需要的起源；不要拓宽不相干的 ROA。为紧急授权设定过期或审查截止时间。在撤销旧路径前，确认新路由已被观察到并被接受。事件过后，移除临时授权，并将在线集合与计划进行核对。

责任应跟随可控制的延迟。若承租人未能维护获准的联系方式，或在无证据的情况下要求一个未列出的 ASN，则应承担相应后果。若出租人虽收到有效请求，却错过了约定的紧急截止时间，仅凭费用减免可能无法反映客户损失；协议可能需要设置赔偿上限、终止权或转为受限委派的权利。若上游在收到所有要求证据后仍拒绝某条路由，其服务条款则另行处理。

紧急权利应极少行使。其价值在于，各方在压力下知晓路径，而非让出租人成为常规变更的 24 小时路由服务台。

最大长度是一项商业风险决策

ROA 中看似最具技术性的字段，可能承载着重大的商业后果。maxLength决定了被授权的 AS 在保持与 ROA 一致的同时，可以发起多么具体的宣告。

过于狭窄的授权可能使合法的流量工程或缓解路由变为无效。过于宽泛的授权则可能允许租约中从未需要的更具体宣告。这一决策影响着故障遏制、上游实践以及验证器可能视为授权的路由范围。

起草时容易犯的错误是，为每个所租的 IPv4 聚合地址都将最大值设为 /24，因为 /24 在全球路由表中普遍被接受。这或许在运维上便利，但它授予的权限超出了仅宣告聚合地址的承租人之所需。如果一个 /19 始终作为 /19 宣告，设为 /24 的最大长度便为 32 个独立的更具体前缀创造了空间，却未解释其理由。RFC 9582指出，当该字段等于前缀长度时应予省略，并定义了它如何限制更具体授权的范围。

相反的错误是，当承租人的成文设计依赖于更具体路由时，却仅授权聚合地址。一个应急清洗服务商可能会宣告 /24。两个起源之间的迁移可能会暂时分割聚合地址。如果合同忽略了这一设计，承租人便会在最糟糕的时刻请求仓促变更。

授权计划应匹配预期路由的最小集合，而非技术上尽可能宽泛的集合。当预期有来自不同起源的多个 /24 时，明确的 ROA 可使划分可见。当临时的较宽最大值有充分理由时，它应附有终止日期和理由。

这对出租人而言也是一个资产组合问题。一条宽泛的覆盖性 ROA 可能与其下的更具体租约产生互动。在批准变更前，出租人必须测试，是否会因一条具有不同起源或限制性最大长度的覆盖授权，导致其他客户的有效路由变为无效。因此，出租人的资源清单需要理解重叠情况，而不单是租约台账。

商业原则是“最少必要权限”。承租人获得足够的密码许可，以运行约定的网络，包括现实的弹性。出租人不保留对成文操作的人为否决权，但也不发布超出约定范围的许可。

上游是独立的控制方，而非信使

转接提供商常被当作授权书的最终送达点。在成熟的租约中，它们应更早参与。

在启用前，预期上游应确认它将接受的确切前缀与起源 ASN、其要求的证据、最小路由尺寸、对更具体路由的处理方式、它是依据 IRR 还是 RPKI 数据构建过滤器，以及这些过滤器刷新的速度。这一确认应附于 ROA 计划之旁，因为若上游的客户过滤器仍拒绝该路由，一份技术上正确的授权几乎没有运维价值。

上游应独立验证其客户。一份有效的 ROA 可以表明，一条认证链授权了某起源 ASN 用于某前缀。但它不能证明开具转接工单的人控制着该 ASN，也不能证明出租人批准了该商业账户。授权书可以连接各方，但信函易于转发，却难以全局撤销。账户记录、已验证的联系方式以及出租人的直接确认，能使证据更为有力。

在租约期间，上游不应仅因出现了新的 ROA 就接受起源变更。该变更可能是意外的、恶意的，或旨在用于另一家提供商。它也不应忽视新的无效状态。它应通过已知渠道联系承租人和出租人，将路由与约定的前缀清单进行比对，判断是路由还是授权有误。

在终止阶段，上游在使撤销成真方面具有决定性作用。出租人可以移除 ROA，但前承租人仍可能发送 BGP 宣告。上游可以移除客户前缀许可，并在直接边界拒绝该路由。这种本地行动通常比等待每个网络应用更新后的验证数据更快、更确定。

这种分工是健康的。RPKI 提供全球可验证的起源授权。上游在距离源头最近处执行客户关系。租约将二者连接起来。不应要求任何一方独自承担全部责任。

支持租赁前缀的上游可以公布其证据要求和紧急联系方式。可预测性使安全租用更加容易。隐秘且不一致的审查，会将运营方推向最后关头的工单和非正式的例外情况，从而削弱安全性与问责性。

纠纷需要与客户流量隔离开来

最棘手的条款是，当前缀仍承载着在线服务时，若出租人与承租人在金钱、违约、滥用或续期等问题上存在分歧，应如何处理。

出租人可能担心，连续性窗口会奖励不付款行为或允许造成损害。承租人可能担心出租人会以删除 ROA 作为远程开关。这两种担忧都是合理的。解决方案不能是永久授权，但也不应是未经通知的密码学突袭。

首先，区分不同事件。计划内的到期和普通的非续约，应遵循完整的退出计划。有争议的账单应触发通知和短暂的补救期，除非协议明确规定付款是立即且关键的。有可信证据表明存在活跃滥用行为，或许可成为加强控制的理由，但移除 ROA 未必能阻止滥用路由；直接上游和承租人的设备仍是更直接的干预点。签名密钥泄露则要求采取安全行动，即便商业关系良好。

在善意的争议期间，应冻结自由裁量的扩展。承租人不应新增客户、请求新起源或放宽最大长度。出租人应在受限的连续性期限内，保留最后已知的安全授权。双方都应通知上游，除有记录的为保护流量所需的紧急情况外，任何变更均需双方确认方为有效。

独立的升级联系人可以判定请求是否符合现有计划，而无需裁定整个官司。问题是狭窄的：所请求的行动是维持一项已获授权的服务，还是扩大了权利？这一有限的判定能在商业诉求在其他渠道进行的同时，保持路由稳定。

协议还应界定一个硬性终止点。连续性不能变成无限期的占用。补救或迁移期结束时，承租人必须撤销路由，上游必须移除过滤器，出租人必须删除 ROA。任何一方未履行，则产生特定的证据和补救措施。若客户安全需要法院命令或紧急救济，各方知晓哪些行为必须被约束。

日志在此最为重要。声称不当删除的一方，应能出示约定的授权、请求、确认、变更时间及验证影响。声称仍在继续使用的出租人，应能出示撤销截止时间之后的路由观察。唯有当事实能够重建，而无须信任某一方的收件箱时，争议隔离才能奏效。

治理准则很简单：不要使无关的互联网用户成为私人债务的执行机制，也不要利用他们的依赖使租约永续。

撤销是必要的，但删除并非完整的补救

租约必须以原承租人无法再依赖出租人的授权为终结。这要求在适当层面进行撤销或移除。它需要的也不仅仅是撤销。

当授权结束时间到来时，出租人应移除或修改相关的 ROA 配置。在委派安排下，可在确认无需继续授权后，撤销受限的子证书。各方应从不止一个独立的观察点观察所生成的已验证载荷。门户的成功消息是已提交操作的证据，而非公共状态已收敛的证明。

与此同时，承租人必须撤销 BGP 路由，其各条上游必须移除客户许可。仍以旧起源命名的 IRR 路由对象应删除或更新。反向 DNS 和公共联系方式不应再指向原运营商，以免误导运维或滥用举报。这些系统具有不同的刷新时间和维护者，因此单一的时间戳无法证明完全退出。

删除还可能产生附带影响。一份 ROA 可能涵盖多个前缀，而若出租人设计不当，委派证书可能包含超越单一租约的资源。运营方必须识别需要更改的确切对象或授权。“撤销客户的 RPKI”并非一个安全的指令，除非认证边界与客户边界相符。

残余风险存在于两个方面。若 ROA 依然存在，前承租人若继续宣告，便保留着验证优势。若 ROA 消失而过时路由犹存，该路由可能变为无效并被不均匀地拒绝，造成部分可达而非普遍沉默。若无覆盖性 ROA 留存，路由可能变为未找到（Not Found），并在许多策略下继续传播。因此，RPKI 状态并非从源头撤销的可靠替代。

一份完成记录应载明：路由已被旧起源撤销；上游过滤器已移除；旧 ROA 已不存在或已被替换；无意外覆盖性授权留存；适用时委派证书已关闭；IRR 记录已核对；并在指定的观察期内继续监控。例外情况应具名列出，而非敷衍概括为“完成”。

撤销保护出租人和下一位用户。协调有序的撤销则保护当前客户。负责任的退出应二者兼顾。

RIR 应认证证书授权，而非裁决租约

RIR 处于一个敏感位置，因为托管服务可能使它们成为执行有争议变更的场所。但这并不意味着它们应成为每一份 IPv4 租约的裁判庭。

RIR 在认证有权使用其认证服务的组织、保护账户、维护层级以及应对经证实的凭据泄露方面，拥有合法利益。它可能需要在转让、归还或注册变更后修改已认证的资源。RIPE NCC 的托管文档指出，资源证书会随着资源移动而更新，而已发布的 ROA 会在资源被移除时进行调整。这些都是认证层级所带来的后果。

私人租约纠纷则不同。RIR 通常缺乏合同、付款记录、客户迁移事实以及准据法证据，来判定哪一方违约。若它接受承租人未经证实的指示，可能会取代持有者的权限。若它将每一条持有者指示均视为定论，而无视法院命令或经证实的账户泄露，则可能放大损害。答案是扮演一个狭窄角色，配以清晰的流程。

RIR 可以保存日志、认证账户操作者、发布服务状态、为安全事件提供有记录的紧急通道，并遵守有效的法律命令。它可以使账户角色细化到持有者无需分享宽泛凭据的程度。它可以解释托管与委派选项的技术效果。它应当审慎，避免将模糊的租用政策转化为对在线路由的自由裁量控制。

这种克制与 ROA 的有限含义是一致的。认证服务验证的是号码资源层级内的权限。它并不认证行使该权限的每一项私人理由。商业义务在双方之间仍可执行，并在必要时通过法院或商定的争议解决机制执行。

注册机构层仍可改善租用，而无需承认一个新的产权类别。它可以支持限定范围的用户、机器可读的变更历史、向多个联系人发送通知、在安全时延迟破坏性操作，以及可导出的当前与先前配置证据。这些工具减少了对单一账户持有者的依赖，同时将法律约定留在 CA 之外。

政策目标应是可预测的执行，而非对每一份租约的道德认可。一个安全的系统可以区分技术上有权签名的人与合同上有权请求的人，而无需佯装二者总是同一人。

控制有其经济成本

ROA 控制常常被塞进租约价格中，仿佛它是一项免费的文书任务。它实际上是一项独立的连续性服务。

承诺快速变更的出租人，必须维持训练有素的人员、受保护的凭据、监控、备用审批人以及事件覆盖。委派模式要求 CA 运维和发布可靠性。与仅使用一个稳定 ASN 的承租人相比，需要频繁变更起源的承租人会产生更多成本，并制造更多出错机会。定价应使这些差异可见。

另一种选择则是虚假的经济。一份低成本租约，若对紧急 ROA 变更有五天的响应时间，对于有严格可用性承诺的网络而言可能不适用。承租人可能会非正式地共享凭据，向上游请求例外处理，或维护一份过于宽泛的授权以避免未来的延迟。每条捷径都将一项未定价的服务需求转化为了安全风险。

更广泛的网络身份经济学更凸显了这点。卢恒关于网络身份与客户连续性的论述指出，一个地址可能嵌入到客户白名单、合作伙伴规则、API 和合规系统之中。一旦发生这种情况，一次失败的 ROA 变更就不仅仅是路由上的不便。它可能中断外部各方已然信任的商业身份。

他对托管 IPv4 租用与注册机构风险的探讨，提出一个相关的市场观点：获取地址不过是可见的交易；持续的可操作性取决于注册机构、路由和生命周期风险如何被承担。中立的分析无需接受该论点中的每一制度性结论，即可承认这一运维事实。出售连续性的当事方，应描述并标定连续性所需行动的价格。

这可以产生服务层级。基础租约可能允许一个稳定起源和工作时间内的变更。具有弹性的租约可能包含两个起源、预先批准的缓解服务、全天候响应和定期核对。拥有自身能力 CA 的承租人，可以选择受限委派并承担更多职责。透明的层级体系，胜过佯装每份租约都包含即时、不受限的 RPKI 管理。

控制权还应影响救济措施。若出租人就紧急覆盖收取费用，却未能提供，后果应是实质性的。若承租人选择了较慢的服务层级，随后又要求即时行动，出租人不应被视作承诺了其未曾出售的东西。

当密码学依赖被名为产品的一部分，而非隐藏在“支持服务”之中时，市场会变得更加安全。

一种实用的权利分配

不存在通用的安排，但可以清晰阐明一种可辩护的默认设定。

出租人保留对资源认证关系的最终控制权，并可拒绝租约范围之外的变更。它必须维持至少两名授权操作者，保护凭据，在启用前创建初始 ROA，遵守既定的常规和紧急变更时限，除真正的安全紧急情况外，在进行破坏性操作前发出通知，并在验证退出后移除授权。

承租人在计划范围内控制其网络设计。它必须标识并证明对每个起源 ASN 的控制，提供准确的路由方案，维持两名经过验证的请求者，在计划变更前通知出租人，避免授权之外的宣告，监控 RPKI 状态，在终止时及时撤销，并保留上游关闭的证据。

上游独立验证客户-前缀关系，在启用前准备过滤器，监控差异现象，支持直接的紧急联系，在获得确认前拒绝计划外的起源变更，并在退出时移除许可。它不依赖 ROA 作为客户权限的唯一证明。

RIR 或父 CA 认证资源持有者，运营或支持所选认证模型，保护父级层级，提供可靠的发布和变更记录，并在透明的职责范围内处理经证实的凭据或法律事件。它不会从 BGP 推断私人租约，也不会裁决普通的账单。

对于高变更频率或高依赖度的租约，受限的子 CA 可以将执行移到更靠近承租人的地方。对于低变更频率的租约，带有严格响应承诺的托管服务可能更安全。对于很短的期限，RPKI 和上游过渡的成本或许可成为更长的通知期或不同的地址设计方案的理由。选择应依据运维依赖，而非意识形态。

每种模式都需要同样的护栏：确切的范围、最少权限、冗余联系、有度的响应、可见的状态、安全的重叠、硬性的终止以及独立的证据。若移除其中一项，控制权便会流向在出错时恰好持有凭据的任何人。

检验在于权限是否跟随责任

当负责服务的一方能够获得必要的授权，同时负责资源的一方能够防止未经授权的扩展并保证最终的撤销时，IPv4 租约便是可持续的。

这种平衡无法通过一句话将 ROA 指派给某一方来实现。它要通过将商业许可与运维事件连接起来实现。出租人的证书权威，决不能成为对常规网络变更的未定价否决权。承租人对于速度的需求，决不能变为对聚合地址的永久签名权。上游绝不能将对客户的验证外包给一个密码学对象。RIR 绝不能被迫去裁决一份它看不到的合同。

技术已经揭示了相关的区别。一份 ROA 指明了前缀、起源以及可选的最大长度。托管服务将签名操作集中化。委派服务将密钥控制和维护转移出去。依赖方取回并验证已发布的物料。路由器应用本地策略。治理的任务是让租约变得同样精确。

最安全的租约在流量依赖之前创建授权，使授权与有记录的路由保持一致，允许狭窄的紧急调整，将纠纷与客户隔离开来，并在结束时一同撤销路由及其密码学许可。它记录了每个行动的执行者和时间。

因此，“谁控制 ROA？” 的最终答案是有意多元的。出租人控制经认证的权威。承租人控制运维需求。上游控制直接的接受。RIR 在其职权范围内控制父级或托管服务。合同控制这些权力如何交汇。

若合同保持沉默，凭据持有者便控制着危机。若合同精准，则没有任何参与者控制着超出其已同意承担的责任。

来源