摘要

  • IESG 于 9 月 17 日就 SAVNET 跨域问题陈述第 21 版发起最后征询，实质意见须在 10 月 1 日前提交。
  • 草案按客户、对等和上游接口分别讨论合法流量被误拦、伪造流量被误放及人工维护成本。
  • 工作组已有共识，不等于 IESG 已批准 RFC，更不等于机制部署或流量效果得到证实。

一个客户可以选择性地向上游发布前缀，也可以通过另一条链路发送源自该前缀的合法流量。若过滤器仅凭某接口所见的 BGP 公告建立允许表，这个包便可能被误拦。直接服务器返回场景也会出现相似裂缝：边缘服务器用 anycast 地址作应答源，但该地址的公告发生在别处。SAVNET 第 21 版草案用这些拓扑检验既有办法的边界；图中的 AS 不是已确认受害者，也不是生产故障统计。

放宽规则并不自动解决问题。在客户锥尚未普遍执行验证时，一个下游网络可能冒用同一锥内另一网络的源地址，上游的宽松允许表无法区分。横向对等链路还常有非对称路由，过严的反向路径判断会损害合法回程；上游接口若只用 Loose uRPF，则路由表里有该前缀并不能证明上游传来的包没有伪造源地址。人工 ACL 可以更具体，但配置随前缀和关系变化而更新的负担随之增加。

IESG 的 9 月 17 日公告请求把这份问题、缺口和要求分析作为信息性 RFC 考虑，并向公众征求实质意见至 10 月 1 日。Datatracker当前仍标为 Publication Requested 的活跃 Internet-Draft。其建议是未来机制应争取精确验证、降低运营负担、在部分部署时有益、保护专用于 SAV 的信息，并在状态改变时正确收敛；它没有交付已运行的通用方案。

文档 shepherd 的记录指出工作组经历两轮内部最后征询并达成广泛认同，同时明确这不是协议文件，也不定义 BGP 扩展或新的 RPKI 对象。一份针对旧版 -20 的路由领域早期评审询问“寻求零误拦”究竟是硬要求还是设计愿望，以及既有路由/RPKI 信息与专用 SAV 信息的信任边界。该评审不能被冒充为 -21 的未决裁决；它说明最后征询需要怎样的精确用语。

读者应把七件事分开：工作组认可问题陈述、IESG 审查文档、可能出版信息性 RFC、未来制定机制、厂商实现、运营商启用策略、真实流量变化。前一项不会自动证明后一项。此次新闻价值正是把下一步决策所需证据公开摆上桌，而不是宣布网络边界已有新开关。

来源