摘要

  • RFC 2408 的 Cookie 对用于抗资源拥塞并定位 ISAKMP SA；Message ID 用于第二阶段的进行中协商；Next Payload 链决定解析顺序。它们都不是身份凭据。
  • 完整结论还要连接强认证、本地政策、提案选择、SA 安装、运行时 SPI、真实报文与应用结果。即使 CONNECTED 或 Delete 出现在受保护消息中，也只证明有限的一段事实。

一个 ISAKMP 报文可以从头到尾都“看起来对”。Cookie 能被接收方验证，版本合法，Exchange Type 存在，Message ID 也落在某个进行中的第二阶段协商里。Next Payload 指向一条结构完整的载荷链。解析器没有报错。

这仍然不是对端身份的证明，更不是安全服务已经生效的证明。

RFC 2408 的设计价值，恰恰在于它没有把这些问题混成一个状态。固定头部让实现先找到上下文，再检查语法，再进入载荷。认证机制随后绑定参与者。政策决定接受什么。密钥管理把结果装入运行状态。最后，安全协议与应用才产生可观察后果。

Cookie 最先处理资源问题。RFC 把它称为 anti-clogging token：服务器应在昂贵的公钥操作前，用便宜的方法判断一个请求是否带回了自己能够接受的令牌。生成算法由实现决定，但必须依赖具体双方、使用外界无法推导的本地秘密，而且要足够快。

建议的材料包括源和目的地址、UDP 端口、本地随机秘密以及时间。每次 SA 建立都应产生独特 Cookie，以降低旧消息重放的风险。八个字节被放入 Initiator Cookie 或 Responder Cookie 字段。

这些性质能证明“接收方认可这个由自己规则生成的令牌”，却不能证明“发件人就是某个永久身份”。地址只是生成材料，不是证书。能返回令牌的人可能只是收到过它的人。时间变化减少重放，也不证明路径长期稳定。

RFC 甚至明确否认绝对抗拒绝服务。攻击者仍可能用伪造地址诱导服务器建立状态，所以实现还需要垃圾状态回收与积极的内存管理。Cookie 成功率如果脱离状态占用、过期速度与 CPU 成本，就不能证明抗压能力。

在第一阶段开始时，发起方放入 Initiator Cookie；Responder Cookie 与 Message ID 为零。响应方加入自己的 Cookie。第一阶段完成后，双方 Cookie 的组合标识 ISAKMP SA，后续管理消息都携带它。

这里的“标识”是状态定位，而非身份认证。RFC 2408 另行要求强认证，并指出没有认证就不能信任实体的 identification。Cookie 对可能在认证完成之前已经稳定。审计系统因此必须保留两个判定：状态是否匹配，身份是否被所选机制与凭据绑定。

Message ID 又属于更窄的范围。第一阶段必须为零；第二阶段由发起方随机生成，用于标识进行中的协议状态。在同一 ISAKMP SA 下，双方可能几乎同时发起第二阶段协商；不同 Message ID 使两条协商都能向前推进。

于是形成一棵状态树：Cookie 对找到父级 ISAKMP SA，Message ID 找到一个第二阶段子协商，Proposal 中的 SPI 指向正在建立的协议 SA；协商完成后，ESP 或 AH 报文头里的运行时 SPI 选择真正的处理状态。

把这些值统一显示成“隧道 ID”，会抹掉故障发生的层级。错误可能是父关联不认识、子协商串线、提案 SPI 不一致、内核安装失败，或运行时 SPI 从未被任何报文使用。原协议提供了区分，监控不应主动丢失。

Next Payload 链体现了另一种边界。固定头部只说第一个载荷类型，每个通用载荷头再说下一个。SA、Proposal、Transform、Key Exchange、Identification、Certificate、Hash、Signature、Nonce、Notification、Delete 与 Vendor ID 因而能按 Exchange Type 组成不同语法。

接收顺序也很清楚：验证 Cookie，再检查 Next Payload、版本、Exchange Type、Flags 与 Message ID，然后才沿载荷链继续。通过前一项不会自动通过后一项。结构完整也不等于签名正确。签名正确也不等于本地政策允许。

失败后的动作更能看出权力归属。无效 Cookie、载荷类型、版本、交换类型、Flags 或 Message ID 都会导致丢弃。是否记日志、是否返回 Informational notification，往往只是 MAY，并由本地安全政策决定。RFC 统一了错误名称，却没有保证每个节点都留下同样的证据。

因此，INVALID-COOKIE 只是一方对一个上下文检查的报告。它不能单独说明攻击来源、通知是否到达、内存是否回收、凭据是否有效，或服务是否恢复。要重建事件，必须把报文、状态、政策、日志与资源变化连起来。

ISAKMP 故意独立于具体密钥交换。它规定建立、协商、修改和删除 SA 的程序与格式，可以传输密钥生成和认证材料，却不绑定一种算法或认证方法。这种分层让不同机制复用框架，也让每个机制只能为自己负责。

第一阶段建立 ISAKMP SA，用它保护后续管理活动；第二阶段建立其他协议的 SA。一个第一阶段可以承载多个第二阶段，从而分摊高昂认证成本。两阶段甚至可能认证不同主体：第一阶段是服务器或主机，第二阶段是用户或应用程序。

所以，把父级 Cookie 对绑定的名称复制给所有子 SA，是危险的捷径。正确记录应写明阶段、被认证主体、认证方法、凭据、政策与子协商 Message ID。否则一个主机身份会被误当成应用权限。

提案选择也不是语法自动执行。发起方可以只给一个提案，或按偏好给多个。给出多个后，响应方按自己的本地政策选择。Message ID 让选择回到正确协商，但它不赋予响应方政策合法性，也不证明选择已经安装。

Commit bit 说明“协商完成”与“可以发加密流量”之间存在真实同步缺口。一方设置后，另一方要等待受保护的 Informational Exchange 和 CONNECTED 通知；通知携带原第二阶段 Message ID，以便找到正确协商。

但最后一个消息仍可能丢失。RFC 没有规定唯一恢复算法：等待方可以验证随后出现的第二阶段消息或加密流量，也可以重传最后的协商消息。实现可能保留最后一条消息直到更有把握。CONNECTED 缩小不确定性，却不是不会丢失的最终判决。

Delete 的语义更加克制。发送方声明自己已经从本地 SA 数据库删除指定状态。它不是要求接收方删除，也不期待确认。接收方通常应清理本地数据库，但后续程序仍由本地政策决定。

因此抓到一个受保护 Delete，只能证明发送方在某个受保护上下文中发出了声明。它不能证明接收方处理过，更不能证明内核状态已消失。真正删除回执需要验证保护、接收方政策、数据库变更、受影响 SPI 与选择器、后续报文结果以及恢复路径。

Lu Heng 的现实分层可把这套框架转成审计语言。Cookie 是资源与关联层事实；Message ID 是协议状态事实；Next Payload 是解析事实；签名或 MAC 是认证事实；本地规则是授权事实；SA 数据库是执行状态事实；报文与应用是结果事实。

机构代理问题则解释了为何界面容易误报。协议登记者、凭据机构、政策管理员、协商进程、内核与应用各自代表不同权力。协商进程只能报告它看到的部分，却常被迫用一个“已连接”灯替所有组件背书。

运行代码优先不是丢弃标准，而是沿标准字段追到现实。保存 Cookie 对与 Message ID，同时保存认证结果、凭据指纹、政策版本、被选提案、安装回执、运行时 SPI、选择器、计数器、报文判定与应用观察。每层各自给出证据，标准字段才真正有价值。

RFC 2408 于 1998 年 11 月发布。RFC 4306 在 2005 年用 IKEv2 取代 RFC 2407、2408 与 2409 的分立组合。2023 年 IETF 将 IKEv1 家族转为 Historic，RFC 9395 关闭相关登记表；RFC 7296 后来成为 IKEv2 Internet Standard。这里讨论的是历史责任边界，不是当前算法建议。

Cookie 对上了会话，是一个真实而有限的成功。身份、授权、安装与结果仍需各自被证明。

来源