IPSec协议技术分析文档

文档名称 IPSec协议技术分析文档

版本 V1.0

日期 2026年3月

参考标准 RFC 4301（IPSec架构）、RFC 7296（IKEv2）、RFC 4302（AH）、RFC 4303（ESP）

1协议核心定位与作用

1.1基本定义

IPSec（IP Security，IP安全协议）是IETF定义的【网络层安全协议簇】，是IPv6的强制内置安全机制，在IPv4中为可选扩展，旨在为IP报文提供端到端的安全防护，对上层协议（TCP/UDP/ICMP等）完全透明。

1.2核心安全能力

IPSec可提供以下5类安全服务，可根据场景按需组合：

访问控制：仅允许授权的流量通过IPSec隧道传输
数据源认证：验证报文发送方的身份合法性，防止伪造
数据完整性：校验报文在传输过程中是否被篡改
抗重放攻击：阻止攻击者重复发送截获的合法报文
机密性：加密报文内容，防止传输过程中被窃听
流量保密性（隧道模式专属）：隐藏内部通信的源/目的IP地址，避免网络拓扑泄露

1.3典型应用场景

站点到站点VPN：企业分支与总部、跨地域数据中心之间的加密互联
远程访问VPN：企业员工在外网安全访问内部办公系统
端到端安全通信：两台主机之间直接传输敏感数据，无需中间网关参与

2基本通信模型

IPSec分为【控制平面】和【数据平面】两个独立的逻辑平面，整体是【基于安全关联（SA，Security Association）拆建的传输模型】，而非一问一答的事务型模型：SA建立完成后，双方可连续传输任意数量的受保护报文，无需每次传输前重复协商。

2.1核心逻辑流程

IPSec通信分为三个阶段：

**SA建立阶段**：

-动态协商（主流场景）：通过IKE（Internet Key Exchange，互联网密钥交换）协议交互协商，先后建立IKE SA（保护后续协商报文）和IPSec SA（保护业务数据）

-静态配置（小规模静态场景）：手动在两端配置IPSec SA的密钥、算法等参数，无需IKE参与

**数据传输阶段**：基于已建立的IPSec SA，对匹配策略的业务报文进行封装、加密后传输，对端接收后解封装、校验、解密还原原始报文
**SA拆除阶段**：SA生命周期到期、流量结束或主动触发拆除时，删除对应SA，停止保护该流量

【说明】SA为单向逻辑实体，因此双向通信需要一对SA（入方向、出方向各1个）。

2.2两种封装模式对应的通信模型

IPSec支持两种封装模式，适配不同场景：

|------|-------------------------------------------|-----------------|
| 模式 | 封装逻辑 | 适用场景 |
| 传输模式 | 安全头（AH/ESP）插入【原IP头和上层协议头之间】，原IP头直接暴露在公网 | 端到端主机通信、远程访问VPN |
| 隧道模式 | 整个原始IP包被封装在安全头之后，新增外层IP头（IPSec网关地址）作为传输地址 | 站点到站点VPN、网关互联场景 |

【说明】控制平面的IKE协商本身为一问一答的交互逻辑，但仅用于SA管理，不属于数据平面的传输模型。

3状态属性分析

IPSec是【强有状态协议】，核心依据是其需要全程维护「安全关联（SA）」这一核心状态实体，所有报文的处理都依赖SA状态，不存在SA时报文会被直接丢弃。

3.1控制平面状态

控制平面维护IKE SA的全生命周期状态：

-协商状态：IKE协商的阶段、已交换的密钥材料、对等体身份信息

-运行状态：IKE SA的生命周期、协商的算法套件、共享密钥、DPD（对等体存活检测）状态

-策略状态：匹配的感兴趣流规则、后续IPSec SA的协商参数

3.2数据平面状态

数据平面为每个IPSec SA维护独立的运行状态：

-基础参数：SPI（安全参数索引）、对端地址、安全协议类型（AH/ESP）、加密/认证算法、共享密钥

-运行状态：当前发送序列号、接收端抗重放窗口、剩余生命周期（时间/流量阈值）

-匹配规则：关联的感兴趣流策略，用于判断哪些报文需要被IPSec保护

3.3与无状态协议的差异

与普通IP协议这类无状态协议不同：IPSec处理每个报文时都需要查询对应SA、校验序列号合法性、更新SA的运行状态（如序列号递增、抗重放窗口滑动），而非独立处理每个报文。即使是手动配置的静态SA，也需要维护序列号、抗重放窗口等状态，因此仍属于有状态协议。

4核心事务与承载消息

IPSec的事务分为【控制平面SA管理类事务】和【数据平面数据传输类事务】两大类，当前主流使用IKEv2作为控制平面协议，IKEv1已逐步淘汰。

4.1控制平面事务（基于IKEv2）

所有IKE报文均封装在UDP报文中，默认使用500端口，存在NAT时切换为4500端口。

|------|------------------------------|--------------------------------------------------------------------------|--------------------------|-------------------------------------|
| 事务ID | 事务名称 | 核心作用 | 触发条件 | 承载消息类型 |
| 1 | IKE SA初始协商（IKE_SA_INIT） | 协商IKE SA的算法套件、交换Diffie-Hellman密钥材料、生成共享密钥、通过Cookie机制防DoS，建立第一层受保护的IKE SA | 有新的感兴趣流需要保护，且无可用IKE SA | IKE_SA_INIT请求、IKE_SA_INIT响应 |
| 2 | IPSec SA初始协商（IKE_AUTH） | 在IKE SA保护下完成双方身份认证（预共享密钥、数字证书、EAP等），协商IPSec SA参数，建立用于数据传输的IPSec SA | IKE_SA_INIT协商成功 | IKE_AUTH请求、IKE_AUTH响应 |
| 3 | SA重协商/新SA创建（CREATE_CHILD_SA） | IPSec SA生命周期到期前重协商新SA，或为新的感兴趣流创建独立IPSec SA，也可用于重协商IKE SA | IPSec SA即将到期、有新的感兴趣流需要保护 | CREATE_CHILD_SA请求、CREATE_CHILD_SA响应 |
| 4 | SA管理与通知（INFORMATIONAL） | 主动删除到期/无用的SA、发送DPD对等体存活检测、上报错误（如认证失败、算法不支持）、传递NAT穿越通知 | SA到期、长时间未收到对端报文、协商出错 | INFORMATIONAL请求、INFORMATIONAL响应 |

4.2数据平面事务

|---------|-------------------------------------|--------------------------------------------------------------------|
| 事务名称 | 核心作用 | 承载消息类型 |
| 受保护数据传输 | 封装 / 加密业务报文并传输，对端接收后解封装、校验、解密还原原始报文 | AH（认证头）报文：IP 协议号 51，仅提供认证 / 完整性 / 抗重放，不支持加密和 NAT 穿越 |
| 受保护数据传输 | 封装 / 加密业务报文并传输，对端接收后解封装、校验、解密还原原始报文 | ESP（封装安全载荷）报文：IP 协议号 50，可同时提供加密 / 认证 / 完整性 / 抗重放，支持 NAT 穿越，为当前主流选择 |

5消息格式详细分析

5.1 IKEv2控制消息格式

IKEv2报文整体结构为：「UDP头」→「IKE固定头」→「1~N个IKE载荷」

5.1.1 IKE固定头（共28字节）

|---------------|-----|-------------------------------------------------------------------------|
| 字段名 | 长度 | 说明 |
| 发起者SPI（I_SPI） | 8字节 | 发起方生成的唯一标识，用于区分不同的IKE SA |
| 响应者SPI（R_SPI） | 8字节 | 响应方生成的唯一标识，初始请求时为0 |
| 下一个载荷 | 1字节 | 标识紧跟固定头之后的第一个载荷类型，如SA载荷=33、密钥交换载荷=34等 |
| 版本 | 1字节 | 高4位为主版本号，低4位为次版本号，IKEv2固定为【0x20】 |
| 交换类型 | 1字节 | 标识当前交换类型：34=IKE_SA_INIT、35=IKE_AUTH、36=CREATE_CHILD_SA、37=INFORMATIONAL |
| 标志位 | 1字节 | 共8位：I位（0位）=1表示发起方请求；R位（1位）=1表示响应报文；V位（2位）=1表示支持更高版本 |
| 消息ID | 4字节 | 用于匹配请求和响应，同一交换的请求/响应消息ID相同，新请求ID自动递增 |
| 总长度 | 4字节 | 整个IKE报文（含固定头和所有载荷）的总长度，单位字节 |

5.1.2 IKE载荷通用结构

所有IKE载荷均遵循「通用头+自定义内容」的结构，通用头共3字节：

|-------|-----|----------------------------------------|
| 字段名 | 长度 | 说明 |
| 下一个载荷 | 1字节 | 标识后续载荷的类型，最后一个载荷的该字段为0 |
| 载荷长度 | 2字节 | 整个载荷（含通用头）的总长度，单位字节 |
| 载荷内容 | 可变 | 不同类型载荷的自定义内容，如SA载荷携带算法套件、身份载荷携带对等体身份信息 |

5.2 AH（认证头）报文格式

协议号为51，支持传输模式和隧道模式两种封装：

-传输模式：「原IP头」→「AH头」→「上层协议头+数据」

-隧道模式：「新IP头」→「AH头」→「原IP包（原IP头+上层头+数据）」

头字段定义：

|-------------|-----|-------------------------------------------------------------------------------|
| 字段名 | 长度 | 说明 |
| 下一个头 | 1字节 | 标识AH之后的载荷类型：传输模式下为上层协议号（如TCP=6、UDP=17），隧道模式下为原IP协议号（IPv4=4、IPv6=41） |
| 载荷长度 | 1字节 | AH头总长度，单位为4字节，计算规则为(AH头总长度/4)-2 |
| 保留字段 | 2字节 | 初始为0，预留扩展使用 |
| SPI（安全参数索引） | 4字节 | 目的IP、安全协议（AH）共同唯一标识对应的IPSec SA，协商阶段生成 |
| 序列号 | 4字节 | 单调递增计数器，每个SA的第一个报文序列号为1，用于抗重放攻击 |
| ICV（完整性校验值） | 可变 | 对整个报文（除IP头中可变字段如TTL、校验和）计算的带密钥哈希值，用于校验完整性和数据源真实性，长度由协商的认证算法决定（如SHA-256对应32字节） |

【说明】AH会校验外层IP头，因此NAT修改IP头会导致校验失败，AH不支持NAT穿越。

5.3 ESP（封装安全载荷）报文格式

ESP协议号为50，支持传输模式和隧道模式两种封装：

-传输模式：「原IP头」→「ESP头」→「加密部分（上层头+数据+填充+填充长度+下一个头）」→「ICV（可选）」

-隧道模式：「新IP头」→「ESP头」→「加密部分（原IP包+填充+填充长度+下一个头）」→「ICV（可选）」

ESP字段定义：

【ESP头】

|-------------|-----|-----------------------------------------|
| 字段名 | 长度 | 说明 |
| SPI（安全参数索引） | 4字节 | 与目的IP、安全协议（ESP）共同唯一标识对应的IPSec SA，协商阶段生成 |
| 序列号 | 4字节 | 同AH，单调递增计数器，用于抗重放攻击 |

【加密部分】

|-----------|----------|-----------------------------------------------------|
| 字段名 | 长度 | 说明 |
| 载荷数据 | 可变 | 传输模式下为上层协议头+业务数据，隧道模式下为整个原IP包 |
| 填充 | 0~255字节 | 用于对齐加密算法要求的块大小，也可隐藏实际载荷长度，提升流量保密性 |
| 填充长度 | 1字节 | 标识填充字段的长度，接收方解密后用于去除填充 |
| 下一个头 | 1字节 | 标识载荷数据的第一个头类型，规则同AH的下一个头字段 |
| 【ICV（可选）】 | 可变 | 对ESP头+加密部分计算的带密钥哈希值，用于完整性校验和数据源认证，开启认证时存在，长度由认证算法决定 |

【说明】ESP仅校验ESP头之后的内容，不校验外层IP头，因此支持NAT穿越，是当前IPSec的主流选择。NAT场景下ESP会被封装在UDP 4500报文中传输，解决NAT设备无法识别IP层ESP协议的问题。