摘要

  • SAVNET 工作组的 AS 内部源地址验证架构第05版日期为10月1日。新版明确区分运营商配置与路由系统取数，并指出客户使用 BYOIP 或其他渠道获得的前缀时，接入 AS 应要求客户申报并提供其作为源地址使用的授权证据；即使没有配置或发布对应路由，也要表示这种授权。
  • 这仍是拟作信息性文档的活跃 Internet-Draft，不是已通过的 RFC、实际部署记录或统一的证明格式。新版的重要变化是把客户、前缀、接入接口和 SAV 规则之间的证据链讲得更具体，而不是发明“路由不等于授权”这一早已存在的问题。

想象客户同时接入同一 AS 的两台路由器。它的某些前缀能从路由信息看到，另一个前缀只用于发出数据包、并不出现在相关路由视图里。若两台设备各自按本地反向路径过滤，合法流量可能在其中一侧被挡住；若为了避免误挡而一概放开，又会扩大伪造源地址的空间。问题不是过滤开关是否打开，而是两台设备是否得到同一份可信的客户—前缀—接口关联。

第04版已指出非对称路由、隐藏前缀使路由资料无法完整表达源地址使用权，也已经提出 SAV Agent 的概念。因此第05版不能被写成发现了全新风险。它的新细节是把数据获取方式拆开：运营商可从客户登记、地址分配及路由配置复用资料；SAV Agent 也可从路由系统取相关信息。两条路径可以并用，但路由系统没有的授权，不能靠“再查一次路由”补出来，只能由运营商配置提供。

BYOIP 正好暴露这个分界。客户带来的前缀或从其他供应商获得的前缀，未必在接入 AS 的相应路由状态中。草案要求运营商让客户指出这些前缀，并交代自己有权把它们用作源地址的证据。文档没有指定必须是 ROA、某一注册记录或任何单一凭证；它也没有把审批权移交给目录机构。要判断证据能否支持本地接口规则，仍是接入运营商的工作。

新版用 C、i1、i2、P1、P2 和 H 做了可检验的示例：客户 C 连到两个接口；P1、P2 可从适当的路由资料或运营记录获得，H 是路由系统看不到的隐藏、仅作源地址前缀。若三者均获授权，两个接口上的允许列表都应包括三者。H 必须由显式配置补入；撤销 H 的授权或改变接入关系后，也要更新受影响的规则。该示例只是架构说明，不能据此声称已有网络照此部署。

草案建议生成允许列表，但同时提醒信息不全会误拦合法数据包。对被判为无效的流量采取监测、记录、限速还是严格丢弃，取决于本地策略和部署阶段。文档既未规定新的 AS 间信令，也未给 SAV Agent 固定位置或统一算法。Datatracker 仍将其列为工作组文档、I-D Exists。可以确认的是规则生成的责任边界更清晰：目的可达性是线索，源地址使用权需要另有依据。

来源