摘要

  • ROV 可以在不询问前缀所有者的情况下，拒绝与当前 ROA 不一致的路由。验证网络做出决定，说明却未必传回去。
  • iROV 提议通过签名授权和反馈弥补缺口。论文中的可达性提升来自特定条件下的仿真，并非全球互联网的实测部署。

紧急改路由时，运营商可能把流量导向缓解攻击的服务，但验证网络缓存的 ROA 还没有更新。ROV 按设计办事：把新路由标为无效并丢弃。前缀所有者却可能看不到拒绝发生在哪里，也不知道有多少网络因此不可达。

Younsoo Kim、Seungjin Baek、Weitong Li、Tijay Chung 和 Min Suk Kang 在 USENIX Security 2026 论文中提出 iROV；Min Suk Kang 随后在 NANOG 98 介绍了这项工作。验证网络可向所有者询问一次性授权，所有者返回签名结果。后续的 iROV 验证网络可以校验随路由传递的授权凭证，而不必重复询问。概率式查询则用来控制初始请求量。

最醒目的结果是：紧急路由变更的可达性从 23% 升至接近 90%。这是论文的大规模仿真结果。主场景把一级网络的 iROV 采用率固定为 100%，按网络层级设定 ROV 采用率和查询概率，并用简化的无谷传播与本地优先级模型。作者明确承认，该模型不能覆盖真实控制面的全部差异。BIRD/FORT 原型是在封闭测试环境中运行的。仿真和原型都不能证明全球互联网已经获得这种效果。

设计的交换条件也很清楚：无效路由仍须获得所有者可验证的加密授权；查询超时或签名不通过，就回到常规 ROV 拒绝。新增机制也新增责任：有人要运行所有者端点、维护密钥、设置查询策略、分拣告警，还得应对请求洪峰本身成为攻击的问题。作者没有给这些成本定价，因为它们取决于各自的运营环境。

iROV 是一项值得运营商认真讨论的设计提案，不是已经铺开的开关。NANOG 的问题是：ROV 应该反馈哪些信息，怎样加入反馈而不带来不可接受的安全与运维风险？更小也更难的问题是：谁定默认参数，谁承担响应工作，什么情况足以触发紧急例外？

来源：USENIX Security 2026 论文 · NANOG 98 官方议程 · RFC 6811：ROV · RFC 6482：ROA。 · PDF original