摘要

  • ROA 中的 maxLength 规定被授权的起源最多可以发布多具体的前缀，却不说明运营商实际打算发布其中哪些路由。
  • 授权过窄会使未预置的合法应急拆分变成 Invalid；授权过宽则会让未经内部批准的更具体前缀显示为 Valid。
  • 有效控制应把每个起源前缀与 ASN、用途、启用窗口、ROA 变更、传播观察、撤回责任人和回滚期限绑定起来。

一个网络平时由 AS 64496 发布 203.0.0.0/16，ROA 只精确授权这条 /16。攻击发生后，值班团队决定发布 203.0.113.0/24，把一项服务导向清洗平台。BGP 变更经过了内部批准，但 RPKI 授权没有提前准备。对于执行路由起源验证的网络，这条 /24 可能成为 Invalid，原因不是起源 ASN 错误，而是它比 ROA 允许的长度更具体。

最省事的补救似乎是把授权改成 203.0.0.0/16、maxLength 24。应急 /24 随即可以通过验证。问题在于，这个对象也允许指定 ASN 发布该 /16 下任何一个 /24——总计 256 个可能的 /24。它不区分事件中真正需要的那一个与其余 255 个，也不记录哪些前缀配置了服务、监控和撤回责任。

RFC 9582 对字段的含义界定得很窄。ROA 表达地址空间持有者允许某个 AS 起源所列前缀；可选的 maxLength 表示授权的最长前缀长度。若不填写该元素，则只授权所列前缀自身的长度。对象里没有流量工程指令、变更单、事件期限或业务目的。

RFC 6811 描述的验证结果同样有限：收到的路由会与覆盖它的已验证 ROA 载荷、起源 AS 和允许长度比较。结果回答的是起源授权问题。即使为 Valid，也不能证明完整 AS_PATH 真实、数据包可达、拆分策略有效，或这条路由仍在批准窗口内。

最小授权让真实意图可见

RFC 9319 建议在可能时使用“最小 ROA”：只授权实际在 BGP 中起源的前缀，而不是一个理论上可能发布的集合。该文档通常建议避免使用 maxLength，同时也承认某些明确的运营场景可能构成例外。重点不是把这个字段定性为错误，而是防止简写授权掩盖真正的路由计划。

假设运营商发布一条 /16 聚合路由，以及四条用于区域入口的指定 /24。四项精确授权能够直接呈现这套设计。一个 /16–24 授权虽然覆盖这四条，却也在 /24 层级多覆盖 252 条并未计划发布的路由。RPKI 起源验证不验证完整路径，因此攻击者可能伪造一条以获授权 AS 结尾的路径，瞄准其中一条未使用但被宽泛授权的更具体前缀。

精确对象带来协调成本。资源托管人、路由团队、安全团队和清洗供应商必须在新起源出现前确认前缀、ASN 与时间窗口。但这种协调不是多余手续。它生成了 maxLength 无法提供的证据：谁授权了哪条起源、为了什么，以及何时必须撤回。

应急灵活性依靠顺序，而不是永久放宽

DDoS 缓解是最需要例外设计的场景。供应商可能要求更具体路由、不同的起源 ASN，或基于目的地址的丢弃路由。RFC 9319 专门讨论了相关情况。客户应在事件前取得供应商的准确要求，并演练 ROA 变更和 BGP 发布之间的顺序。

先确认前缀、起源、范围和期限；再创建或替换 ROA，等待独立验证器出现预期载荷；随后在受控范围发布路由，观察验证状态和传播，再决定是否扩大。事件结束时，应先撤回 BGP 路由并确认其消失，然后按计划移除临时授权。

这些动作不会共享同一时钟。RPKI 仓库发布、验证器抓取、验证器到路由器的传递以及 BGP 传播可能在不同时间收敛。公开 RFC 也不能证明每个下游网络如何处理 Invalid。RFC 7115 因此把起源验证视为运营策略变更：先观察影响、理解本地例外，再逐步施加路由后果。

来源