摘要

  • ROA 授权一个 AS 作为指定前缀的源；可选的 maxLength 可以扩展到更具体前缀，却不说明哪些路由会实际宣告。
  • RPKI 起源验证把观测路由与前缀、最大长度和源 AS 数据比较。Valid 不等于运营意图、可达性或本地优先级。
  • 尽量采用最小 ROA，并在策略变化时对照授权集合、BGP 观测和版本化策略，可以减少歧义。

RFC 9582 把 ROA 定义为地址块持有者授权某一 AS 宣告一个或多个前缀的签名对象。每张 ROA 只指定一个 AS。没有 maxLength 时，只授权准确前缀；存在 maxLength 时，则授权到该长度为止的所有受覆盖更具体前缀。/20 加 /24 因而描述一组许可范围，而不是站点、时间、路径属性或撤回条件。

RFC 6811 说明了验证边界：VRP 包含前缀、前缀长度、最大长度和源 AS。覆盖路由在 AS 与长度匹配时为 Valid；有覆盖却不匹配为 Invalid；无覆盖为 NotFound。这些状态分类已收到的路由，不能重建内部变更批准。

因此，意外的更具体路由仍可能是 Valid。旧配置、错误出口或未撤回的临时宣告都可能位于宽泛授权之内。本文不指控任何真实运营者或事件；它指出验证结果本身无法排除这些情况。

RFC 9319 建议尽可能使用只覆盖实际起源前缀的最小 ROA，并通常避免 maxLength，因为它往往扩大可被伪造起源利用的许可集合。例外情况需要运营判断，而且在起源或路由策略变化时必须重新审查。

证据台账应分开保存三层：ROA、AS、前缀、maxLength 与有效期构成授权层；路由、观测点与时间构成观测层；批准集合、用途、负责人、期限与撤回条件构成策略层。三者按时间连接，才能发现“已授权但未批准”“已授权但不再需要”以及“已批准但未观测”的差异。RFC 9582 还提醒，资源 PKI 证明授权，而非身份认证或不可否认性。maxLength 始终只是授权边界。

来源