AH 还是 ESP？由数据包需要保护什么来决定

两套 IPsec 提案可以点名同一个基于 SHA 的完整性算法，却要求不同的保护协议；AH 与 ESP 并不是同一项认证设置的两个拼写。先读协议，再读它的算法，然后读它的模式，大部分歧义就会消失。AH 认证数据包，包括传输途中保持不变的那些 IP 首部字段；ESP 则认证并加密它所封装的内容，而对外层首部不做处理。正是这一差别决定的实际部署，比任何哈希名称都多。

AH 覆盖而 ESP 不覆盖的部分

AH 提供完整性、数据来源认证以及它自己定义的抗重放服务，完全不提供机密性。它的覆盖范围包括上层数据，以及其规则视为不可改变的 IP 首部字段，也就是 ESP 在传输模式下留在外面的那部分。当需求说必须认证 IP 首部本身时，能够回应的是 AH。

这一覆盖范围也正是 AH 在实践中脆弱的原因。TTL、首部校验和以及某些选项属于可变字段，路由器可以重写，因此无法认证，协议在计算校验之前会把这些字段清零。所以任何重写地址的做法都会破坏计算，而不只是破坏策略。

NAT 让选择变成约束

地址转换会重写 AH 刚刚认证过的 IP 首部中的源或目的地址，因此完整性检查在另一端失败，而且是以协议错误的形式失败，不是可读的报错信息。ESP 不认证外层首部，所以带 NAT 穿越的 ESP 可行，而 NAT 之后的 AH 不行。两端都位于普通路由器之后的隧道，正是这种情况最先出现的地方。因此第一个问题不是哪种协议更强，而是两端之间是否存在转换设备。

如果有，AH 就出局，讨论转向 ESP 及其算法选择。这是约束而不是偏好，所以它应当放在决策的开头而不是结尾。

模式让问题成倍增加

ESP 在传输模式下保护上层载荷，不动 IP 首部；在隧道模式下封装整个内部数据包，包括内部 IP 首部，并对其加以保护。AH 也有同样的两种模式，所以在选择任何算法之前，AH 或 ESP 实际上就是四种组合。

组合模式的 ESP 算法随后无需第二个协议即可确定完整性。AES-GCM 与 ChaCha20-Poly1305 在一次构造中同时认证和加密，因此在其上再加 AH 并不能换来什么，却要多一个首部和一轮协商。架构允许 AH 与 ESP 并用，而实际问题是 你的网关和版本是否支持这种组合，以及之后是否有人能维护它。

对纯 AH 的诚实替代

只做完整性的 ESP 变体保留算法，放弃加密的主张而不是假装具备它，并且能穿过 NAT。如果旧设计使用 AH 是因为需要不带机密性的认证，那么这个变体就是直接的翻译，而不是附带说明的加密隧道。

在提案里看到 ESP 同样不是加密的证据。要读加密算法：NULL 条目只表示完整性，组合模式条目才表示两者兼备。

用三个问题做决定

问是否需要机密性、路径上是否有转换设备、以及哪些首部字段必须被认证。这三个答案指向一种协议和一种模式，把它们写下来比日后重读 RFC 更省时间。

然后核对被接受的东西，而不是被提议的东西。ip xfrm state 显示已安装关联的协议、模式和算法；不匹配时什么都不会装上，这比一条缺少预期保护却照样起来的隧道更干净。

把认证失败、选择器覆盖范围和路由故障与这个选择分开。它们给出的症状不同，把选择器的问题归咎于协议，是毫无理由花一整天更换哈希的可靠方式。