摘要

  • draft-sriram-savnet-intrasav-solution-00 让客户与本地 AS 明确登记每个接口上可路由或可作为源的前缀，包括从不宣告的 BYOIP 源前缀。
  • 草案所说的零误拦、零误放以配置完整为前提；01 前的首版尚未定义如何证明同一代规则已经到达并控制正确的物理或逻辑接口。

一张白名单在控制器里完全正确。第二个客户可以宣告 r，也可以用 s 作为源地址，只是不宣告 s。因此，客户边缘接口应当允许 {r, s}。集合没有多一个，也没有少一个。

问题发生在集合离开控制器之后。新增 s 时，一台路由器已经提交了新版本，另一台仍在重启前的旧版本；或者客户迁移到了新的逻辑接口，旧许可却还留在原端口。中央计算依然是零误差，真正接收数据包的接口却不一定拥有同一事实。

这正是 IntraSAV - A Solution for Intra-Domain Source Address Validation 带来的管理问题。00 版于 2026 年 10 月 1 日上传，是 I-D Exists 状态、拟定 Best Current Practice 的个人 Internet-Draft。它不是 SAVNET 工作组采纳、RFC、IANA 行动、实现报告或部署测量；只有获批后才会更新 BCP 38 与 BCP 84。

路由可达并不等于源地址获准

传统方法经常从转发表寻找答案。严格 uRPF 要求源地址的返回路径指向数据包的进入接口；在非对称路由或多宿场景中，这会把合法流量判成伪造。宽松 uRPF 只检查是否存在任何路由，减少了一些误拦，却失去接口方向性，因而可能放过伪造流量。人工 ACL 可以很精确，直到前缀变化而更新没有跟上。

更根本的问题是，FIB 表达如何抵达一个地址，不一定表达谁获准使用它作为源。Direct Server Return 就是典型例子：边缘节点可用 anycast 服务地址直接回包，却不在本地宣告该前缀。没有路由记录，不代表这个源地址不合法。

IntraSAV 要求把授权事实明确写出来。BYOIP 客户告诉本地 AS：哪些前缀用于路由、哪些只用于发包、对应哪个接口。本地 AS 对自有前缀也做相同配置。Configuration Manager 可借助 SAV Agent 汇总信息，为各 Customer Edge 接口生成独立允许列表。

草案示意图中，客户 1 登记 {p, q} 并宣告两者；客户 2 登记 {r, s}，只宣告 r，但用 s 发包。因此接口 1 得到 {p, q}，接口 2 得到 {r, s}。它把 FIB 看不见的源授权变成了可配置对象。

ROA 与本地配置面对不同的依赖方

草案建议前缀持有人创建 ROA，授权本地 AS 作为源起 AS。与此同时，它规定：对于本地路由与源地址验证，本地配置优先于 ROA。运营者仍应比较两者并在不一致时提醒客户，因为远端 AS 可能依赖 ROA 构造跨域 SAV 表。

这不是两套真相互相否定，而是两种作用域。本地配置回答某客户此刻能否在某接口使用某前缀；ROA 向外部表达源起授权。两者一致有助于降低偏差，却不能证明提交者有权更改本地绑定、接口仍归该客户、规则已下发或硬件已经执行。

00 版说 Configuration Manager 要认证客户，却没有定义登记协议、凭证范围、变更批准、撤销、抗重放或事务 ID。最小初始规范可以把具体实现留给运营者，但事故追溯不能只剩一条“控制器成功”的记录。至少需要把客户、前缀、接口、用途与配置代次绑定在一个可核验回执中。

“完整”是零误差承诺的全部重量

草案最醒目的判断是：只要 Configuration Manager 拿到完整配置，IntraSAV 就能保证零 improper block 与零 improper admit。在抽象模型里，这个逻辑成立——该接口所有合法源都在集合中，集合外的源都不合法。

但是，草案没有给出独立的完整性证明。它未定义配置代次、生效时间、预期设备清单、原子替换、路由器确认或回滚流程，也没有描述并发修改、控制器分区、路由器重启和客户换端口时的状态。

于是，控制器正确与网络一致可以分离。一台 CE 执行第 31 代，另一台仍执行第 30 代；软件控制面接收了规则，转发 ASIC 没有；源前缀已被客户移走，旧接口仍允许；新前缀已获准，传播窗口却让合法流量被丢弃。

这些情况不证明方案失败，只说明运行代码要补上哪类回执。所谓“零”只有在存在分母时才是观测事实：已授权的前缀—接口总体、每个执行点承诺的代次、被标注为合法或伪造的测试包，以及正确允许、正确阻断、误放、误拦四类计数。

汇总白名单会丢掉客户与接口的绑定

草案还有一段明确标为 “To be Discussed” 的提议：如果本地拓扑足以证明 ASBR 接口收到的源都应来自本 AS，运营者可以在该接口部署 {p, q, r, s} 的并集。若升级 ASBR 比升级所有 CE 容易，这种做法很有吸引力。

正文自己也提醒，这可能超出问题陈述的范围，除非 ASBR 直接服务主机或无 AS 客户。并集只能证明 s 在本域某处获准，不能再证明它应从客户 2 的接口 2 到达。汇总防御与逐客户执行不是同一种保证。

渐进部署也有类似边界。问题陈述要求只覆盖部分外部接口时仍能产生可测收益。控制器统计“已生成 60% 接口规则”只是一项部署清单。真正的收益要看关闭了哪些攻击路径、是否破坏了合法流量，以及未覆盖或过宽的边缘是否成为绕行入口。

让决定数据包的代次可见

稳健的证据链要分别记录：客户认证；前缀、接口与用途授权；带版本配置的接受；ROA 一致性；允许列表计算；向指定路由器和接口的交付；原子提交或拒绝；匹配与丢弃计数；带标签的误差测试；最终安全与服务结果。

Heng Lu 的最小初始规范理念允许各网络保留自己的控制器与决策方式。运行代码优先则要求在执行边界留下证据。配置摘要、每接口代次和提交确认不需要建立全球权威，却能让独立运维人员判断意图是否真的抵达正确设备。

IntraSAV 的关键进步，是不再把路由信息当成源授权的替代品。下一步是让这份显式授权一路保持显式，直到接口和数据包计数器。控制器中的完整白名单只是证明的起点。

来源