摘要

  • 严格 uRPF 可能拒绝合法的非对称流量，宽松 uRPF 则丢失接口方向性；RFC 8704 定义了按接口划分的可行路径集合。
  • 该方法继承 BGP 路由、前缀过滤和关系数据的质量，不能认证客户合同，也不能证明现实部署情况。

分析

源地址验证要回答的是：携带这个源地址的数据包，是否可能合法地从这个接口进入？在单宿主边界，转发表往往能给出清晰答案；在多宿主边界，返程最佳路由可能不同于来程。方向仍是证据，但单一最佳路由并不是完整授权记录。

BCP 38 确立了入口过滤的目标：尽量靠近源头阻止伪造源地址的流量，并提高滥用行为的可追溯性。RFC 3704 描述了多种实现。严格 uRPF 在转发信息库中查找源地址，并要求入接口与选定返程接口一致。在路径对称时，它简单而有力；当策略或多宿主造成非对称时，它也可能丢弃合法流量。

宽松 uRPF 只检查是否存在到源地址的路由，因此避免了许多误判，却付出了方向性代价。路由表某处可达的前缀，在当前入接口上仍可能完全不合理。

RFC 8704 调整了这一取舍。它为每个接口定义 RPF 列表，即允许在该接口出现的源前缀。算法 A 把列表从单一最佳路径扩展到可行路径，但不会扩展到整个路由表。如果路由器在某接口收到由某源 AS 发起的路由，那么该 AS 其他经过适当核验的前缀，也可以成为该接口的可行源。

这种扩展有前提。RFC 8704 假定相关路由已经过前缀过滤，并在适用时经过路由源验证。从错误一方学到的路由，不会因为算法把它加入 RPF 列表就变得可信。边界的可信度取决于路由输入，以及运营者对该邻接关系的理解。

面对更复杂的 ISP—客户拓扑，算法 B 可以把接纳范围扩展到已识别的客户锥。它能覆盖未直接出现在每个客户接口上的合法源，却更依赖准确的商业关系数据。陈旧的客户锥或错误归类的对等方，会让接纳边界超出合同授权。

RFC 8704 还讨论了用 ROA 和 IRR 数据补充 RPF 列表。这些数据可以改善前缀与源 AS 的证据，却不能单独证明某个具体接口有权承载该流量。源授权和接口授权是两个不同命题。

运行成本不可忽略：更大的 RPF 状态、BGP 收敛期间的更新、拒绝事件调查和例外管理。本事实包没有证据证明所有设备都支持该机制，也没有证明任何具名网络已经部署或取得量化效果。

IETF 的 SAVNET 工作说明准确性问题仍未解决：现有机制可能放行伪造流量，也可能阻断合法流量。其章程证明标准工作仍在推进，而不是未来架构已经可用。

来源