摘要

  • Andrei Robachevsky 在 RIPE 93 介绍的工作组方案，拟把 ROV 定为 MUST，并要求 MANRS 参与者公告的每个前缀都有有效 ROA。
  • 有些网络运营者无法独自补齐这份证明：未与 ARIN 签协议的遗留资源持有人无法使用 ARIN 的 RPKI；客户租用的前缀也可能没有 ROA。

分析

运营者把路由送进 BGP，授权却可能掌握在另一家公司手里。MANRS 讨论的“RPKI 覆盖率 100%”，真正考验的是这条责任链能不能闭合。

10 月 27 日，Andrei Robachevsky 在 RIPE 93 介绍了 MANRS 网络运营者计划审查工作组的进度。该计划的行动要求自 2014 年启动后没有大幅修订。工作组把要求和实施、审计指南拆开，并借用 IETF 的 MUST、MUST NOT 等规范用语，试图让每项要求更容易解释和核验。按他当时介绍的草案，ROV 将是 MUST，IRR 注册将是 SHOULD；对路由信息这项行动，组内讨论的是 100% RPKI 覆盖，也就是参与者公告的每个前缀都应有有效 ROA。

这还不是正式生效的 MANRS 规则。Robachevsky 说，工作组计划先进行内部最后征询，再向更广泛的社区征求意见。他强调，文本要反映工作组和现有 MANRS 参与者之外的共识。RIPE 的官方逐字稿记录了提案和当时尚未解决的问题。

MANRS 今年 3 月公布的调查收到 38 份回复，主要来自网络运营者。受访者把要求清晰度和审计能力列为优先事项；一半受访者把网络运营者计划排在首位。调查页面没有披露邀请人数，因此无法计算回复率，也不能把这组意见写成全行业投票。

RPKI 的权限边界很具体。ARIN 说明，没有签署 ARIN 协议的遗留资源持有人不能使用其 RPKI 和 IRR 服务；签署协议后即可获得这些服务。ARIN 还规定，ROA 只能覆盖资源持有人资源证书中的资源。运营者公告别人的前缀，不能直接用自己的证书替资源持有人签发授权。

Robachevsky 点出了两类难题：一类是无法使用 RPKI 的 ARIN 遗留资源持有人；另一类是客户租用的前缀由运营者公告，但客户没有创建 ROA。BGP 中的路由经过运营者，登记资源的控制权却可能属于客户或其他持有人。最终被标记为不合规的，仍可能是无法完成登记动作的一方。

IRR 并没有从方案里消失，只是地位不同。草案把它列为 SHOULD，把 ROV 列为 MUST。部分网络仍依赖 IRR，工作组当时也还没确定哪些 IRR、哪些对象可以计入。把 IRR 一概当成 RPKI 的替代品，会改写工作组明确提出的分级；彻底忽略 IRR，则会漏掉运营者目前用来说明路由、生成过滤列表的工具。

Robachevsky 说，MANRS 从 2014 年的 9 家运营者发展到演讲时约 1,400 个参与者。这个基线的价值在于让更多网络采用，而不是把最高要求做成少数网络才拿得到的徽章。若一条规则只让容易满足条件的网络留在名单里，合规比例可以变漂亮，难以登记的前缀却仍在系统边缘。

所以，“100%”要先回答四件事：哪些公告必须有 ROA，谁负责创建，资源持有人掌握登记权时有哪些办法，现有参与者有多长的整改期。答案缺席时，规则只是在责任人之间传递压力，无法自动生成缺失的授权。

来源

RIPE 93 场次与官方逐字稿；MANRS 社区调查；MANRS 网络运营者计划审查工作组；MANRS 八月工作进展；ARIN 遗留资源服务说明；ARIN 的 ROA 规则。