Summary

  • RFC 2979 将有意执行的安全拒绝与意外破坏合规通信区分开来；后者应由防火墙及其配套软件负责修正。
  • 路径 MTU 发现和 SMTP 扩展两个例子说明，中间设备即使只执行一条看似简单的规则，也可能打断通信。

安全策略的拒绝，不等于协议故障

到 2000 年前后，互联网的端到端理想正撞上现实边界：越来越多机构把重要内部系统接入自己无法完全信任的网络。防火墙因此成为流量检查点。但它们的行为常缺乏明确说明，不同实现也会带来超出安全策略本身的故障。

RFC 2775 已将“透明性”拆成多个架构问题，包括端到端功能、性能和地址透明性。RFC 2979 则聚焦一项具体的运行约定：引入防火墙、隧道或访问协商机制，不得意外破坏在没有该设备时本可正常工作的、合法且符合标准的用法。如果发生这种故障，应修正防火墙或相关软件，不应要求修改既有协议或其实现。

这并不是要求所有数据包都放行。RFC 2979 明确承认，站点可以封锁自己认定为不合法的访问，即便相关流量符合标准。它也允许额外的认证、授权机制，例如 SOCKS，甚至允许某些配置要求使用这些机制；但还应有不强制要求该设施的配置。关键是把按策略作出的拒绝，与中间设备误解通信后造成的意外破坏分开。

被丢弃的 ICMP 错误会让有效流量陷入黑洞

路径 MTU 发现让问题变得具体。IPv4 发送端可以给数据包设置 Don't Fragment 位。如果后续链路无法承载该包，路由器会返回 ICMP“Destination Unreachable / Fragmentation Needed”，提示发送端减小包长。防火墙若放行出站数据包，却丢弃对应错误，发送端可能继续重发永远过大的流量——这形成了黑洞，而不是有意义的安全决策。

RFC 2979 并没有要求放行所有 ICMP。它区分了与合法出站流量相对应的错误，以及 Echo、Redirect 或与该流量无关的错误；后者仍可按策略封锁。上下文很重要：同一协议家族中，有些控制消息是有效通信的一部分，有些则可被安全政策拒绝。

SMTP 扩展协商把中间设备变成三方错配

SMTP 的例子更微妙。客户端用 EHLO 询问服务端支持哪些扩展；服务端列出能力；客户端随后可能选择一项。代理若只把 EHLO 加入允许命令，却不筛查服务端返回的扩展列表，就可能让客户端和服务端约定使用代理并不理解的扩展。两端看似都正确，中间设备却放行了一段它无法正确转送的对话。

这并不意味着每台防火墙都必须实现每个新扩展。RFC 2979 建议应用协议在不损害自身功能的前提下便于穿越防火墙；协议说明也可以指出防火墙需要满足什么条件。它还提醒，不能只因 80 端口可能开放，就把新协议包进 HTTP。安全子集、合适的穿越机制或单独注册的端口，可能是更坦诚的设计。

这份 RFC 说明了什么，又没有证明什么

RFC 2979 是 Informational 备忘录，并非互联网标准。草案历史记载 IESG 于 2000 年 8 月批准该文，最终于 10 月发布。记录证明当时提出了这项设计原则及相关示例，却不能证明产品采纳率、实现合规率、绕过行为减少，或安全效果得到改善。

它的历史贡献在于划分责任：安全策略可以拒绝一条流量，但意外的不兼容不应默默变成应用开发者必须绕行的问题。今天的运维者可据此先给故障分类：这是有意的策略拒绝，还是过滤器、代理或解析器破坏了合规通信？这是从 RFC 推导出的诊断方法，不是对当年运维实践的实证描述。

RFC 3093 是相邻但不同的材料：这份发表于 2001 年 4 月 1 日的 Informational RFC 提出了将 IP/TCP 封装进 HTTP 的 Firewall Enhancement Protocol。它不能证明 RFC 2979 失败，也不能证明该隧道曾经部署。防火墙过滤也不能和 NAT 混为一谈：RFC 2979 明确区分两者，即使某台设备同时执行它们。

来源：RFC 2979；RFC 2775；RFC 3093；草案历史；RFC 1191；RFC 1869。