【IPSec】IKEv2 握手：IKE_SA_INIT 与 IKE_AUTH

架构篇 把 SPD/SAD 钉成策略与关联两张表。自动填充 SAD 的主流协议是 IKEv2（RFC 7296，由 RFC 4306/5996 演进而来）。相对 IKEv1，IKEv2 砍掉 Main/Aggressive 多模式，把「建立 IKE SA + 认证 + 首个 Child SA」收成两个交换。本文只钉初始握手；密钥树与 CREATE_CHILD_SA 见 第 3 篇。

一、角色与通道

• Initiator / Responder：一次 IKE SA 的发起方与响应方；角色在后续 CREATE_CHILD_SA 中可与业务方向解耦。
• IKE SA：保护后续 IKE 消息的密码上下文（SK_e/SK_a 等，见第 3 篇）。
• Child SA：保护用户 IP 流量的 ESP/AH SA；首个 Child SA 通常在 IKE_AUTH 中一并建立。
• UDP/500：默认 IKE；NAT 后常改用 UDP/4500（第 4 篇）。

IKE 消息由 HDR（SPI、版本、交换类型、消息 ID、标志）后接一串 载荷。加密后的 IKE 用 SK{…} 表示：大括号内载荷在 IKE SA 密钥下受保护。

二、IKE_SA_INIT（交换类型 34）

目标：协商密码套件、交换临时 DH 公钥与 Nonce，派生用于保护后续 IKE 的密钥材料；此交换本身在明文中进行（仅完整性/加密协商尚未完成）。

Initiator                                                      Responder

HDR, SAi1, KEi, Ni                      -->
                                        <--  HDR, SAr1, KEr, Nr, [CERTREQ]

成功后双方可计算 SKEYSEED 并展开 IKE SA 密钥（细节见第 3 篇）。此后 IKE_AUTH 及后续 IKE 消息使用这些密钥。

失败与重试：提议无交集、DH 组不被接受时，响应方返回 Notify（如 NO_PROPOSAL_CHOSEN、INVALID_KE_PAYLOAD）。Initiator 应按 Notify 调整后重开 IKE_SA_INIT（消息 ID 规则见 RFC 7296）。

三、IKE_AUTH（交换类型 35）

目标：认证对端身份，交换身份与 AUTH，并通常携带首个 Child SA 的 SA 与流量选择器（TS）。

Initiator                                                      Responder

HDR, SK {IDi, [CERT,] [CERTREQ,]
         [IDr,] AUTH, SAi2, TSi, TSr}   -->
                                        <--  HDR, SK {IDr, [CERT,] AUTH,
                                                      SAr2, TSi, TSr}

两交换共四条消息后：IKE SA 已认证，首个 Child SA 参数已定，内核侧应出现对应 ESP state 与 policy（第 5–6 篇）。

可选路径：若使用 EAP，IKE_AUTH 可拉长为多轮（RFC 7296 §2.16）；本系列不展开 EAP 全谱，只承认远程接入常见变体存在。

四、AUTH：PSK 与证书

RFC 7296 定义多种认证方法。工程上最常见两类：

预共享密钥（PSK）
双方持有同一秘密。AUTH 载荷是对「约定八位组串」用 PRF 与 PSK 派生密钥计算的结果。配置简单，但密钥分发与轮换是运维问题；大规模主机时不如证书。

数字签名（证书）
AUTH 是对约定八位组串的签名；CERT 载荷携带（或指向）验证用证书。信任锚、CRL/OCSP、SAN 与 ID 匹配是额外故障面——也是合规审计常要求看到的那一层。WireGuard 故意把信任锚留在带外；IKEv2 把 PKI 接进协议。

AUTH 计算覆盖的八位组串包含：对方在 IKE_SA_INIT 中的消息、Nonce、以及由 PRF 得到的 SignedOctets 相关材料（RFC 7296 §2.15）。实现必须与规范逐字节一致，否则表现为「提议都对但 AUTH 失败」。

五、Cookie 与 DoS 边界

响应方在资源压力下可对 IKE_SA_INIT 先回 COOKIE Notify，要求发起方带着 Cookie 重发。其目的是：在分配昂贵 DH 状态前，验证对端能接收发往其声称地址的包（RFC 7296 §2.6）。

这与 WireGuard 的 MAC1/MAC2 cookie（WireGuard 协议篇）同属「抗地址伪造 DoS」，但挂在不同状态机上：IKE 有明确重传与消息 ID；WireGuard 把未认证包默认静默。

Cookie 不替代身份认证，也不防止已通过 Cookie 检查的对端耗尽 CPU（仍可发起合法外形的握手）。

六、与 WireGuard 握手的对照

不要把「四条消息」理解成「一定比 WireGuard 多一倍延迟」——Child SA 已在第二次交换捎带；额外 RTT 常来自证书验证、EAP 或 NAT 探测，而不是 HDR 计数本身。

七、本文边界

• 不罗列全部 Notify 类型与状态机边角。
• 不展开 MOBIKE（RFC 4555）、IKEv2 Redirect、Session Resumption 的完整流程。
• 不给出伪造的抓包 hex；字段语义以 RFC 7296 为准，实测抓包见 运维篇。

下一篇展开 SKEYSEED、prf+ 与 Child SA rekey。

参考资料

规范

• RFC 7296, Internet Key Exchange Protocol Version 2 (IKEv2)，尤其 §1.2、§2.1–2.6、§2.15–2.17。

对照

• WireGuard 协议：Noise IKpsk2
• VPN 工程对比 · IKEv2 小节