摘要

  • Number Resource Society 的资料指出，ROA 把前缀与获准起源该前缀的 ASN 联系起来，还可通过 maxLength 约束更具体路由；ROA 变更应遵循受控流程。
  • 验证器显示的 Valid、Invalid 或 NotFound 是某一时点、某一视角下的观察。它本身不能证明谁提出或批准了变更，也不能证明旧授权已经安全撤回。
  • 版本化的授权与撤回台账，可以把人的决定、RIR 发布记录、验证器观察和路由操作回执连接起来，同时避免把技术状态误当成授权意图。

Valid 不是一份完整的决策记录

Number Resource Society 对 RPKI 的介绍从一个基础作用讲起：资源公钥基础设施以密码学方式，把互联网号码资源与其合法持有者联系起来。Route Origin Authorization 说明哪个自治系统可以起源特定前缀；可选的 maxLength 则决定授权可以覆盖到多长的更具体前缀。证书与对象可以由 RIR 托管发布，也可以由资源持有者在委托模式下自建认证机构。

这套机制能回答一个关键问题：观察到的路由起源，是否匹配已发布的授权？但它不会自动还原授权背后的治理过程。眼前的验证结果看不出是谁申请更换起源 ASN、是谁同意扩大 maxLength、变更窗口多长，也看不出紧急回滚依据了哪项证据。

NRS 的号码资源审计文章提出了一组具体检查：ROA 是否存在、起源 ASN 是否正确、前缀是否匹配、maxLength 是否合适，以及路由处于 Valid、Invalid 还是 NotFound。文章还要求关注谁有权创建、修改和删除 ROA。maxLength 过宽，会授权运营并不需要的更具体路由；设置过严，则可能让合法发布变成 Invalid。

这些是冻结来源直接支持的事实。本文提出的台账是据此形成的治理推论，不代表 NRS 已采用该台账，也不意味着任何现网 ROA 存在错误。

授权应绑定一个明确的版本

控制对象应是“这次变更”，而不只是最终状态。每次变更都应有稳定编号，并记录变更前后的前缀、起源 ASN 与 maxLength。台账还应写明资源持有者、申请人、批准人、批准时间、计划窗口和理由。如果紧急程序缩短正常审批，就要标明所依据的规则和承担责任的人。

授权与执行需要分开。提出请求的人未必有权批准；批准发布的人未必操作 RIR 门户；执行 BGP 切换的人也未必有权编辑 ROA。把这些角色折叠成一个“已完成”，会让看似正确的终态难以审计。

授权的边界同样必须明确。对一个前缀的许可不应默默扩展到另一个前缀；允许变更起源 ASN，不等于允许放宽 maxLength；迁移期的临时权限，也不应在旧路径退出后继续存在。

可以对获批的变更对象计算哈希，以便把人的决定与随后提交的数值对应起来。哈希不能证明决定正确，也不能证明其法律效力；它能证明的只是后来观察到的对象，是否与批准人看到的版本一致。

发布、验证和启用是不同的观察

批准之后，台账应保存发布动作，以及带观察时间的权威 RIR 记录。NRS 的审计建议把带日期的 RIR 权威记录留作证据。这比“我当时看到门户是绿色的”更可靠，但它仍然只说明观察到了什么，并不说明为什么获得授权。

独立验证器的观察也要分别记录，注明时间、观察点以及软件或服务。不同仓库、缓存与刷新周期，可能让验证器短暂分歧。分歧是需要排查的信号，却不能自动证明发布失败或运营人员做错了事。

台账可把状态拆成：已申请、已批准、已提交、已观察到发布、已观察到验证、已启用路由、已申请撤回、已观察到撤回、已回滚、已被新版本替代。每次转换都要有自己的时间，以及负责的行动者或观察者。

NotFound 尤其能说明这种区分的必要。它只表示验证器视图没有找到覆盖该路由的 ROA，不能解释这种缺失是有意、延迟、错误还是不在本次变更范围。Valid 也只是证明某个视图下存在匹配，不能证明发起人如今仍拥有业务授权。

迁移必须预先排好撤回顺序

NRS 指出，在迁移场景中，通常应先建立并验证新授权，再撤下旧路由或删除旧 ROA。台账可以把这条操作原则变成可复查的证据。

执行前，应写明前置条件：必须看到哪个新 ROA、由哪些验证观察点确认、还要通过哪项路由检查。随后分别指定谁可以启用新起源、谁可以撤回旧路由、谁可以缩小或删除旧 ROA，以及谁负责确认各步骤完成。

撤回不是删除历史。旧授权应继续留存，结束事件说明原因，并连接替代版本或回滚记录。即使后来撤销变更，读者仍能看到最初发布在当时得到了授权、什么触发了回滚、最后恢复了哪个状态。

回滚顺序必须在窗口开启前确定。可量化的触发器包括：意外出现 Invalid、超过约定时限仍未传播、可达性受损、提交值与批准值不一致，或无法确认责任运营人员。RPKI 对象发布与 BGP 撤回运行在不同节奏上，“恢复原状”本身不是足够的操作方案。

事实、推论与未知不能混写

两份 NRS 来源支持 ROA、maxLength、验证状态、受控变更、审计检查和迁移顺序等事实。它们没有指出某家运营商失职、某个账号被攻破、某条路由有争议，也没有证明任何 RIR 流程失败。

本文的台账字段属于治理建议。可以合理推论，连接批准、发布、验证和撤回会让变更更容易还原；但不能因为公开文章没有描述内部控制，就断言 NRS 或任何机构缺少控制。

面对具体变更，还会存在许多未知：谁实际持有权限、使用了哪个平台或委托 CA、验证器刷新用了多久、路由动作覆盖哪些网络，以及授权有什么法律或合同效果。合格的台账应保留未知，而不是用猜测填空。密码学授权加上可问责的变更轨迹，才能让 ROA 既可验证，也可安全退出。

来源