摘要

  • RFC 2267 将源前缀检查放在服务商连接下游客户的接口上，因为服务商可以在本地维护该客户允许使用的前缀。
  • BCP 38 于 2000 年把这项建议确立为最佳当前实践；通过检查只能把流量约束到一个网络边界，不能确认发包主机或操作者。

受害者看见地址，却看不见发送者

服务器收到一批连接请求，源地址可能根本无法到达。它照常回复，数据包却沿着无路可走的路径消失；发送者不断更换报文里的源地址。另一种报文会填入某个真实地址，而地址所属网络与攻击毫无关系。受害服务器若封锁这个表面来源，也可能顺带切断无辜网络的正常流量。

RFC 2267 描述的正是这种盲区。接收端只能读出报文中填写的源地址，不能直接核实是谁选了它。增强服务器处理能力，可以让主机承受更多连接请求；但它无法告诉远端受害者，这个来源字段是否被伪造。RFC 2267 把主机加固视为解决方案的一部分，同时提出在更靠近发包网络的位置检查来源。

服务商知道客户从哪条链路进入

设想一家互联网服务商为多个下游网络汇总路由。面对其中一条客户接入链路，服务商可以回答一个具体问题：哪些源前缀允许从这条链路进入？RFC 的示例允许报文使用该客户的前缀；若报文声称来自其他范围，则丢弃。文档还建议记录被丢弃报文，为排查可疑活动留下线索。

这不是查询全球地址注册簿，也不是判断谁“拥有”一个 IP 地址。过滤规则依赖边缘设备手中已有的本地关系：这条客户链路对应这一组允许的源前缀。数据包进入服务商更广的网络之前，接口便能把报文中的来源与这组范围比较。来源不匹配时，服务商可以在靠近客户的一侧拦下它，而不是把所有判断都留给受害者。

控制点前移，也改变了防御的负担。没有上游过滤时，受害者必须依据自己并不信任的地址字段作判断，封锁一个伪造来源可能误伤无辜地址持有人。若服务商在客户侧入口检查前缀，承载客户流量的网络就可以拒绝不属于该客户链路的来源。即使攻击者仍使用一个获准前缀，调查也至少有一个较小的起点：与该客户链路相关的网络，而不是整个互联网。

源前缀检查不同于回程路由检查

RFC 2267 特意区分了两种容易混淆的做法。作者考虑过一项规则：检查到源地址的回程路由是否会从报文进入的同一个接口离开。他们没有建议普遍使用这条规则，因为当时互联网中的路由不对称会让它产生问题。RFC 2267 的核心检查则是：这个源前缀是否属于接在该接口上的下游网络。

两者都在入口处理数据包，但回答的问题不同。回程路径检查依赖路由表选择的方向；客户前缀过滤依赖该网络在这条链路上获准使用的地址范围。RFC 3704 后来讨论多宿主网络的入口过滤机制，并更新 RFC 2827。该文中的严格、可行和宽松反向路径模式及其权衡属于另一篇文章的主题，这里不展开。

移动 IP 暴露了规则的边缘

一个地址对移动节点而言可以完全有效，但它在节点临时接入的网络中仍显得陌生。RFC 2267 提到移动 IP 的情况：节点从外地网络发出的报文，可能继续使用其归属网络的源地址。若服务商只允许本地客户前缀，这类流量可能被过滤。备忘录因此指出反向隧道方案；后续的 RFC 2344 规定了把移动节点发出的数据先送到归属代理、再发往互联网的方式。

这不是过滤器在判断用户是否可信，而是在执行一项接口策略：哪些源前缀可以经过这条客户链路。若合法服务需要另一个来源，就必须有与该边界相容的路径或明确规则。RFC 并未说所有移动流量都会失败，也没有要求取消所有例外；它说明例外需要与入口过滤规则协调。

信息备忘录后来成为 BCP 38

RFC 2267 于 1998 年 1 月作为信息类文档发布，并非互联网标准。2000 年 5 月，RFC 2827 取代它，保留了 “Network Ingress Filtering” 这一标题，并以 BCP 38 的编号发布为最佳当前实践。核心建议仍然清晰：服务商应在客户流量进入网络的位置过滤源地址，避免客户发出其网络并未合法使用的前缀。

文档类别的变化值得注意，却不是部署凭证。RFC 2827 给出了一项实践建议，但没有统计哪些服务商在哪些路由器、客户或链路上安装了过滤。RFC 2267 提到当时已经有服务商开始实施，却没有给出覆盖率调查或测量。文档发布、服务商策略、接口上实际安装的规则、被丢弃的数据包，以及由此完成的调查，是彼此不同的事实。

这项过滤的承诺也有明确边界。它可以阻止客户发出不在允许集合中的伪造源前缀，却无法阻止攻击者伪造同一允许前缀内另一台主机的地址，也无法挡住使用有效源地址发起的洪泛。它既不识别具体设备或个人，也不证明其意图。丢弃日志能提示哪条网络边界作出了决定，却不能当成发送者的身份记录。

RFC 2267 的历史贡献因此很具体：防御伪造地址不再只能依靠受害者解释一个可能不真实的来源。服务商可以在客户接入边界维护并应用一条可核验的源前缀规则。BCP 38 让这种操作建议有了更稳定的名称。至于某条链路上的过滤是否有效，最终仍取决于规则是否准确、安装并处于运行状态。

来源

  1. RFC 2267 — Network Ingress Filtering
  2. RFC 2827 — Network Ingress Filtering（BCP 38）
  3. RFC 1812 — IPv4 路由器要求
  4. RFC 2002 — IP 移动性支持
  5. RFC 2344 — Mobile IP 反向隧道
  6. RFC 3704 — 多宿主网络的入口过滤（BCP 84）