摘要

  • 9 月提交的一份个人草案提出独立的“受保护委托”资源登记机制，但不强制任何依赖方过滤既有 RPKI 路由源授权。
  • 草案明确承认：若过滤先行、持有人的新授权尚未最终确认，本地验证结果可由已有有效 ROA 所支持的状态变为 NotFound；这不是已发生的事故。

把私钥交到资源持有人手里，不等于上级发证机构失去撤销下级证书的能力。这一层关系已有报道。Joseph Gersch 在 9 月 18 日提交的新草案另开了一条路：为 IPv4/IPv6 资源建立独立的层级登记，试图让受保护范围不再被上级收回、重发或压制。不过，这种登记不会自动改写路由器的 ROV 行为。选择发生在提供 VRP 集合的依赖方或汇聚层：它究竟叠加新来源，还是先减去原有来源？

草案对“受保护”设下比一笔链上交易更严格的门槛。状态必须达到最终性，由持有人确认，且临时窗口已经结束；不可逆之前还须记录持有人选择的恢复政策。外部导入的 RIR、RDAP 或 RPKI 记录起初只是被声称的资料，不是已确认的保护状态。对外导出的路由源授权也必须出自最终且已确认的状态。换言之，登记日志里刚出现一条记录，不能成为立即排斥原有 ROA 的理由。

现行 RFC 8416 的 SLURM 本就允许依赖方在本地增加或过滤 RPKI 数据。新草案第 10.6 节区分了两件事：增加一条受保护登记生成的 VRP，与装载一条会压掉既有 RPKI VRP 的过滤器。后者若配错，就可能剥夺原来合法的授权；装不装由使用者的本地政策决定，不是草案强制的转换。第 10.5 节还指出，按受保护前缀直接过滤可能漏掉范围更大的 ROA：其 maxLength 仍可覆盖目标范围。要局部压制，必须有足够精确的替代数据或更丰富的表达办法。

草案描述的另一种后果更容易被误读。如果依赖方先删除既有 VRP，而持有人的新源授权未达最终且已确认状态，相关路由在该依赖方眼里可能成为 NotFound，即使原 ROA 仍有效。这不等于 Invalid，也不能据此断言流量必然中断；转发结果还受运营者的路由政策影响。只接收导出 VRP 的依赖方，还需信任导出者，因为该导出物在此设计中没有持有人签名。

作者报告了许可链上的概念验证，同时把独立实现、生产级最终性配置、互联网规模测量及持有人接入和恢复经验列为尚未完成的工作。SIDROPS 邮件列表上，一名参与者质疑方案是否属于工作组范围，作者表示交由主席判断；这并非工作组已经裁决。Datatracker 将其列为个人草案，而非 IETF 采纳的标准。现阶段值得治理者追问的不是它能否宣称更强“主权”，而是谁批准了过滤原授权这一步。

资料来源