前言
        本文详解 IPsec，IKEv2 和 ESP 网络协议，其中重点讲解 IKEv2 控制平面与 ESP 数据平面，文中包含对伪随机数函数（PRF），IKEv2 四大交换，IKEv2 身份认证、密钥派生、完美前向保密（PFS）以及基于策略与基于路由的隧道模式的区别等一系列内容的精讲，但不包含对旧版 AH 与 IKEv1 协议的讲解。

目录
        一、IPsec（Internet Protocol Security）详解
                （1.1）简介
                （1.2）安全通信简介
                （1.3）安全网关
                （1.4）IPsec 术语名词
                （1.5）伪随机数函数（PRF）与 PRF+
        二、IKEv2（Internet Key Exchange Version 2）详解
                （2.1）简介
                （2.2）IKEv2 报文标准格式
                （2.3）IKE_SA_INIT 交换
                （2.4）IKE_AUTH 交换
                （2.5）CREATE_CHILD_SA 交换（1）
                （2.6）CREATE_CHILD_SA 交换（2）
                （2.7）CREATE_CHILD_SA 交换（3）
                （2.8）INFORMATIONAL 交换
                （2.9）IKEv2 的 NAT 穿越检测
                （2.10）IKEv2 密钥交换与派生与 PFS 中的新密钥处理
                （2.11）IKEv2 身份认证
                （2.12）使用 EAP 认证的 IKEv2
        三、ESP（Encapsulate Secure Payload）详解
                （3.1）简介
                （3.2）ESP NAT-T 模式
                （3.3）ESP 报文封装标准格式
                （3.4）算法
                （3.5）ESP 出入站处理
                （3.6）基于策略与基于路由的隧道模式

---

一、IPsec（Internet Protocol Security）详解
（1.1）简介
IPsec（Internet Protocol Security，互联网协议安全）是一套工作在网络层的安全协议簇，核心是为 IP 网络通信提供原生的端到端安全保障，更独立的双通道分离，是站点间 VPN、远程接入 VPN 最主流的底层实现技术之一。它还为两个通信实体提供了一种交换密钥的方法、一个加密套件以及一种镖局使用压缩的方法。通信实体可以是一台个人主机，也可以是一个在受保护与不受保护网络区域提供界限的安全网关。它能为通信提供四项核心安全能力：数据机密性（加密防止内容泄露）、数据完整性（校验防止报文被篡改）、数据源身份认证（确认通信方身份可信）、抗重放攻击（防止历史合法报文被重复利用）。IPsec 是一个协议族，它主要包括 IKE、AH 和 ESP 三个协议，本文不讲解 AH。

（1.2）安全通信简介
IPsec 为了建立一个安全通信，首先需要一个对等方之间协商出一个 SA，通常使用 IKE 进行协商，得益于 IPsec 的双通道分离机制，使用 IKE 协议维护控制通道与管理数据通道，使用ESP 作为数据通道主流协议，进行业务数据的封装。所有加密数据都需要经过 IPsec 内核的加密引擎进行加密，IKE、ESP 等协议本质上主要用于维护、管理 IPsec 的操作。

（1.3）安全网关
IPsec 安全网关（SG），是部署在网络边界、代表身后整个内网网段执行 IPsec 加解密与隧道封装的网络设备。企业级防火墙、出口路由器、云厂商 VPN 网关、分支网关设备，本质上都是承担 SG 的角色。SG 工作在 IP 转发模式，默认使用 ESP 隧道模式，保护背后的整个内网，且内网对于 SG 的加密转发行为完全无感知。SG 的 ESP、IKE 工作流程与部署在主机上的IPsec 几乎无区别，唯一的区别是 SG 开启了 IP 转发功能，转发目的 IP 不是自己的流量并对流量执行 IPsec 正常流程。

（1.4）IPsec 术语名词

名称	介绍
SA	Security Association，安全关联，用于保存隧道或对等方之间协商出的安全参数如加密算法、密钥、工作模式等
SPI	Security Parameter Index，安全参数索引，用于指示一个32位或64位的 SA
SG	Security Gateway，安全网关，部署 IPsec 的网关
SPD	Security Policy Database，安全策略数据库，保存数据包的处理规则，记录多条匹配规则（如源/目的网段等），用于确定一个包所需要进行什么操作（如加密，明文，丢弃等）
SAD	Security Association Database，安全关联数据库，保存曾经协商成功的 SA
IKE	Internet Key Exchange Version，Internet 密钥交换，一个用于建立一个 SA 的协议
AH	Authentication Head，认证头部，用于封装业务数据，仅提供完整性保护与数据源身份认证，当前基本已被弃用
ESP	Encapsulate Secure Payload，封装安全负载，用于封装业务数据，当前主流数据通道协议
DH	Diffie-Hellman 密钥交换算法，一种可以在不可靠的公网上安全传输密钥的算法
PRF	PseudoRandom Function，伪随机数函数，一种伪随机数生成器
a | b	连接运算符，用于连接a，b两个数据段

  

（1.5）伪随机数函数（PRF）与 PRF+
伪随机数函数是指那些在算法上无法区别于真正随机函数的函数，它的输出结果在统计分布上与真随机没有区别，攻击者即使看到大量输出样本，也无法反推出密钥，更无法预测下一个输出。 PRF 相当于一种由密钥驱动的确定性随机数生成器，它有两个输入参数，分别为密钥与种子，格式为 prf ( key，seed )，只要两个函数中密钥与种子分别相同，输出也相同，但只要密钥未知，这串数据在攻击者眼里就和真正的随机数毫无区别。它比较类似与哈希函数，但哈希函数是无密钥的。PRF 通常用于密钥派生，即使用一个已知的密钥通过 PRF 生成一个新的密钥以防止密钥相同，也常用于 HMAC。
PRF+ 则为 PRF 的递归，通常用于解决一个 PRF 生成的随机数不够长的问题，它通过反复调用底层的标准 PRF，并把上一次计算的结果投递给下一次计算，同时附加一个递增的数字，它可以生成任意长度的伪随机数，它的公式为 prf+ ( key，seed ) = T1 | T2 | T3 | ... | Tn，T1 = prf ( key，seed | 0x01 )，T2 = prf ( key，T1 | seed | 0x02 )
，Tn = prf ( key，T(n-1) | seed | 0x0n )。

---

二、IKEv2（Internet Key Exchange Version 2）详解
（2.1）简介
IKEv2 协议属于一种混合型协议，它综合了 ISAKMP（Internet Security Association and Key Management Protocol）、Oakley 协议和 SKEME 协议这三个协议。其中，ISAKMP 定义了 IKE_SA 的建立过程，Oakley 和 SKEME 协议的核心是 DH（Diffie-Hellman）算法，主要用于在 Internet上安全地分发密钥、验证身份，以保证数据传输的安全性（安全地建立一个 CHILD_SA）。IKE_SA 和 CHILD_SA 需要的加密密钥和验证密钥都是通过 DH 算法生成的，它还支持密钥动态刷新以实现完美正向防护（PFS）。     

（2.2）IKEv2 报文标准格式
（2.2.1）IKEv2 报文整体标准格式
[HDR] [0个或多个负载]
    
（2.2.2）IKEv2 主头部标准格式（HDR）（长度：28 Bytes）

名称	长度	用途
SPIi（发起者的IKE_SA的SPI）	8 Bytes	记录发起者的IKE_SA的SPI
SPIi（响应者的IKE_SP的SPI）	8 Bytes	记录响应者的IKE_SP的SPI
Next Payload（下一个负载）	1 Byte	记录下一个负载的类型数值，0为没有下一个负载
Version（版本号）	1 Byte	分为主要版本与次要版本，记录使用的IKE版本
Exchange Type（交换类型）	1 Byte	记录当前正在进行哪一轮交换，IKE_SA_INIT（34），IKE_AUTH（35），CREATE_CHILD_SA（36），INFORMATIONAL（37）
Flags（标志位）	1 Byte	其中R位用于区分请求/响应报文，I位用于区分是否是第一轮协商
Message ID（消息ID）	4 Bytes	从0开始，每一个报文段加一，用于匹配请求与响应与防止重放攻击，类似于TCP中的序列号
Length（总长度）	4 Bytes	记录整个IKE报文包括头部的长度，用于确定报文边界

  

（2.2.3）IKEv2 负载头部标准格式（长度：4 Bytes）

名称	长度	用途
Next Payload（下一个负载）	1 Byte	记录下一个负载的类型数值，0为没有下一个负载
RESERVED（保留）	1 Byte	保留字段，全置为0
Payload Length（负载长度）	2 Bytes	记录整个负载的长度

    

（2.2.4）IKEv2 负载类型

数值	符号	用途
33	SA	安全关联负载，包含一个 SPI 数值与一套提议（发起者通常有多个，响应者通常只有一个），每个提议都有一个转换列表（加密算法，完整性保护算法、密码派生算法和DH组）
34	KE	Diffie-Hellman 负载，包含 DH 组编号与公钥
35	IDi	发起者身份负载，包含发起者身份如IP地址、域名等
36	IDr	响应者身份负载，包含响应者身份如IP地址、域名等
37	CERT	证书负载，包含发起方的证书链
38	CERTREQ	证书请求负载，请求对方的证书链
39	AUTH	认证负载，双方对相同数据块签名，用于认证双方身份，向对方证明自己拥有合法密钥，同时确保协商参数完整性
40	Ni,Nr	随机数负载，用于双方派生密钥的随机数，提供密码学新鲜性，保证每次协商生成的密钥都独一无二，防止重放攻击
41	N	通知负载，用于传输错误信息（消息码<8192）、IKE协商状态（消息码>16383）以及IKE处理能力指示（消息码>16383），如处理能力指示包含路径上是否包含NAT
42	D	删除负载，包含一个SA列表，表示要删除的SA，或用于关闭一个隧道
43	V	厂商标识符负载，包含每个扩展功能对应唯一的Vendor ID，声明厂商私有扩展或协议扩展能力，用于不同设备间的特性协商与兼容
44	TSi	发起者流量选择器负载，发起方包含自己意愿通过该 SA 发送数据的源流量选择器的匹配源网段，响应者包含最终确定的源/目的网段
45	TSr	响应者流量选择器负载，发起方包含自己意愿通过该 SA 发送数据的目的流量选择器的匹配目的网段，响应者包含最终确定的源/目的网段，如果发起者的TSr的超过了响应者的最大接受网段范围则会进行 TS 收窄机制
46	SK{}	控制通道加密与认证负载，控制通道中所有需要加密与认证的负载（如 IKE_AUTH 等交换的大部分负载）都记录在 SK 负载中
47	CP	配置负载，用于远程访问 VPN 情况下，服务端向客户端分配内网配置信息（如 IP 地址、DNS、默认网关等），客户端配置虚拟接口，使用请求-响应方式，在 IKE_AUTH 交换中使用，类似 PPTP 中的 IPCP 协议
48	EAP	可扩展身份认证协议负载，封装 EAP 报文，使得 IKE 支持使用 EAP 认证

（后缀加 i 表示来自发起方的负载，后缀加 r 表示响应方的负载）

（2.3）IKE_SA_INIT 交换
该交换主要用于协商并建立一个安全的控制通道（IKE_SA），以及协商出一个用于派生所有子密钥的根密钥，其他交换必须要在该交换之后才能被任意一方发起。

发起方		响应方
HDR，SAi1，KEi，Ni	--1-->
	<--2--	HDR，SAr1，KEr，Nr，CERTREQ

      
1 发起方通过 UDP 500 端口发送 IKE_SA_INIT 报文，用于 IKE_SA 提议，SKEYSEED 值协商与 NAT 检测（NAT-D，N负载的一种）
2 响应方通过 UDP 500 端口接收报文；响应方通过UDP 500端口发送 IKE_SA_INIT 报文，用于告知发起方选中的 IKE_SA 提议 ，IKE_SA的密钥交换，请求发起方的证书链与NAT检测
3 如果 NAT-D 负载检测到穿越过 NAT，双方进入 NAT-T（NAT穿越）模式，IKE 控制通道端口转为 UDP 4500，否则保持源端口（下文都以 UDP 4500 端口作为IKE控制通道端口）

（2.4）IKE_AUTH 交换（正常形式，使用 EAP 的认证参见 2.12 节）
该交换主要用于协商并建立首个安全的数据通道（CHILD_SA），认证双方身份，TS协商与配置内网信息等

发起方		响应方
HDR，SK{ IDi，CERT，CERTREQ，AUTH，SAi2，TSi，TSr }	--1-->
	<--2--	HDR，SK{ IDr，CERT，AUTH，SAr2，TSi，TSr }

1 发起方通过 UDP 4500 端口发送 IKE_AUTH 报文，用于 CHILD_SA 提议，证书链交换，TS 提议，认证双方身份请求内网配置信息等。
2 响应方通过 UDP 4500 端口接收报文；响应方通过 UDP 4500 端口发送 IKE_AUTH 报文，用于告知发起方选中的 CHILD_SA 提议，证书链交换，最终 TS ，认证双方身份与响应内网信息等

（2.5）CREATE_CHILD_SA 交换（新建 CHILD_SA）
该交换主要用于新建一个 CHILD_SA，以创建多个数据通道，以对应新的业务网段。

发起方		响应方
HDR，SK{ SAi，Ni，KEi，TSi，TSr }	--1-->
	<--2--	HDR，SK{ SAr，Nr，KEr，TSi，TSr }

     
1 发起方通过 UDP 4500 端口发送 CREATE_CHILD_SA 报文，用于新 CHILD_SA 提议，DH 协商一个新的 CHILD_SA 密钥（处理新密钥参见 2.10 节 PFS 新密钥处理），TS协商与请求内网信息等
2 响应方通过 UDP 4500 端口接收报文；响应方通过 UDP 4500 端口发送 CREATE_CHILD_SA 报文，用于用于告知发起方选中的 CHILD_SA 提议，DH 协商一个新的 CHILD_SA 密钥，最终 TS 与响应内网信息等
执行新的 DH 密钥交换可选但推荐

（2.6）CREATE_CHILD_SA 交换（CHILD_SA 重密钥）
该交换主要用于 CHILD_SA 重密钥，在 CHILD_SA 生命周期到期后更新密钥以实现数据通道的 PFS。重密钥请求报文仅比新建 CHILD_SA 的请求报文中添加一个 N（REKEY_SA）通知负载以向响应方表达重密钥的意愿，响应报文同新建 CHILD_SA 的响应报文，重密钥会新建 CHILD_SA，但会覆盖原来的 CHILD_SA。执行新的 DH 密钥交换可选但推荐。（处理新密钥参见 2.10 节 PFS 新密钥处理）

（2.7）CREATE_CHILD_SA 交换（IKE_SA 重密钥）
该交换主要用于 IKE_SA 重密钥，在 IKE_SA 生命周期到期后更新密钥以实现控制通道的 PFS，不包含流量选择器负载，使用旧 IKE_SA 进行安全传输。（处理新密钥参见 2.10 节 PFS 新密钥处理）

发起方		响应方
HDR，SK{ SAi，KEi，Ni }	--1-->
	<--2--	HDR，SK{ SAr，KEr，Nr }

1 发起方通过 UDP 4500 端口发送 IKE_SA_INIT 报文，用于新 IKE_SA 提议，SKEYSEED 值协商与 NAT 检测（NAT-D，N负载的一种）
2 响应方通过 UDP 4500 端口接收报文；响应方通过UDP 500端口发送 IKE_SA_INIT 报文，用于告知发起方选中的新 IKE_SA 提议 ，IKE_SA的密钥交换
RFC 强制规则：IKE SA 重密钥必须执行全新的 Diffie-Hellman 交换，禁止省略 KE 载荷，严格保障完美前向保密。

（2.8）INFORMATIONAL 交换
该交换主要用于交换信息，报告错误，状态通知，存活检测或删除一个 SA 或隧道，主要包含 N 负载， D 负载或 CP 负载。

发起方		响应方
HDR，SK{ N，D ... }	--1-->
	<--2--	HDR，SK{ N ... }

（2.9）IKEv2 的 NAT 穿越检测
IKE 使用 N 负载的 NAT_DETECTION_SOURCE_IP（16388）与 NAT_DETECTION_DESTINATION_IP（16389），分别用于检测源地址/端口与目的地址/端口是否被 NAT 修改，它首先基于发起者的发起方视角看到的 SPIi | SPIr | 源 IP 地址 | 源端口号 计算哈希值并复制进 NAT_DETECTION_SOURCE_IP N负载，再将发起方视角看到的 SPIi | SPIr | 目的 IP 地址 | 目的端口号 计算哈希值并复制进 NAT_DETECTION_DESTINATION_IP N负载，一并发送至响应方，响应方根据自己视角看到的地址/端口进行一样的哈希值计算，如果两个值都一样，说明两方都不在 NAT 之后，如果其中至少一个值不一样，就说明有至少有一方在 NAT 之后，双方都进入 NAT-T 模式，IKE控制通道端口转为 UDP 4500。

（2.10）IKEv2 密钥交换与派生与 PFS 中的新密钥处理
IKE_SA 或是 CHILD_SA 所需要的所有密钥都通过从 SKEYSEED 值派生，协商 SKEYSEED 值发生在 IKE_SA_INIT 交换中的 KE 负载（用于 DH 密钥协商）与 Ni，Nr 负载（随机数，用于密码学新鲜性与防重放攻击）交换，一旦交换完成，两方都能计算出 SKEYSEED 值，该值用来生成所有与 IKE_SA 相关的子密钥， 两方分别需要派生出 7 个密钥：SK_d，SK_ai，SK_ar，SK_ei，SK_er，SK_pi，SK_pr，这些值将按照该公式进行计算：SKEYSEED = prf ( Ni | Nr , g^ir )，{ SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } = prf+ ( SKEYSEED, Ni | Nr | SPIi | SPIr )，在开启 PFS 的情况下新的 SKEYSEED = prf( SK_d (old)，g^ir (new) | Ni | Nr )，其他所有密钥同时更新，其中，g^ir 为 Diffie-Hellman 的共享秘密值，Ni，Nr 的值取最近一次交换的值，SK_d 用于派生 CHILD_SA 相关的子密钥，SK_ai 与 SK_ar 分别作为双方用于完整性保护的密钥，SK_ei 与 SK_er 分别作为双方用于加密与解密的密钥，SK_pi 与 SK_pr 分别作为双方用于为 AUTH 负载签名的密钥（使用生成密钥的 EAP 方法认证不使用该密钥签名，参见 2.12 节）。
CHILD_SA 的所有密钥都需要从 SK_d 中派生，在不开启 PFS 的情况下公式为 KEYMAT = prf+ ( SK_d, Ni | Nr )，Ni，Nr 的值取最近一次交换的值（如 IKE_AUTH 或 CREATE_CHILD_SA 交换中的）。如果开启 PFS，公式变为 KEYMAT = prf+ ( SK_d, g^ir (new) | Ni | Nr)，g^ir (new) 值为最近一次协商 CHILD_SA 重密钥的 Diffie-Hellman 共享秘密值，其中，KEYMAT 为密钥材料总输出，后续会按规则拆分为不同方向，不同协议的功能密钥，发起方→响应方方向的密钥截取优先级高于响应方→发起方方向的密钥

（2.11）IKEv2 身份认证
当不使用 EAP 认证时，双方通过交换对同一个数据段的签名完成身份认证，双方均对对方的随机数进行签名，这是保障交换过程安全性的核心设计。首先，对于发起方，它的待签名字节流生成规则为 InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI，其中，RealMessage1 为 IKE_SA_INIT 完整请求报文，如果为 NAT-T 模式，需要在前部补充 4 字节的 0 再参与拼接，NonceRData 为 IKE_SA_INIT 交换中的 Nr 纯数值不包含头部，MACedIDForI 为 发起方身份的 PRF 绑定值，计算公式为 MACedIDForI = prf ( SK_pi，RestOfInitIDPayload )，其中，RestOfInitIDPayload = 去掉头部后的 IDi 负载。
对于响应方，它的待签名字节流生成规则类似于发起方，为 ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR，其中，RealMessage2 为 IKE_SA_INIT 完整响应报文，NonceIData 为 IKE_SA_INIT 交换中的 Ni 纯数值不包含头部，MACedIDForR 为响应方身份的 PRF 绑定值，计算公式为 MACedIDForR = prf ( SK_pr，RestOfInitIDPayload )，其中，RestOfInitIDPayload = 去掉头部后的 IDr 负载，特殊修改情况与发起方相同。
当两方分别计算出自己的待签名字节流后便可进行签名，签名主要有 3 种主流方式，第一种方式，使用预共享密钥（PSK）进行对称 HMAC 运算签名，首先需要对 PSK 进行一次密钥派生，避免密钥复用，公式为 AuthKey = prf( PSK, "Key Pad for IKEv2" )，输入的种子为固定 17 字节的 ASCII 字符串，之后便可计算最终 AUTH 负载值，公式为 AUTH = prf ( AuthKey, 待签名字节流  )。
第二种方法，使用数字证书进行非对称数字签名，首先根据本地私钥的类型决定使用的签名算法（如 RSA 采用 RSASSA-PKCS1-v1_5 方案，ECDSA 采用对应曲线的签名算法），再使用与数字证书对应的私钥对待签名字节流签名，最后将签名结果填入 AUTH 负载，头部标记对应的认证方法编号（如 RSA 签名为 1，ECDSA 为 10 等）即可。
第三种方法，使用 EAP 认证，使用生成密钥的 EAP 方法认证，用生成的 MSK 替换 PSK 公式中的共享密钥，执行完全相同的两步运算即可。双方完全可以使用不同的认证方式。

（2.12）使用 EAP 认证的 IKEv2
除 IKEv2 原生公钥签名与共享密钥认证外，还支持使用功能更丰富的 EAP 认证。发起方使用 EAP 认证的意愿通过在首个 IKE_AUTH 报文中不携带 AUTH 负载表达给响应方，通过携带 IDi 负载而不携带 AUTH 负载，发起方可以声明自己的身份但不对其进行证明。如果双方都接受 EAP，那么响应方将会响应一个包含 EAP 负载的 IKE_AUTH 报文，并响应方推迟开始协商 SA、TS 等，直到基于 EAP 的认证完成。如果使用生成密钥的 EAP 方法认证，生成的 MSK 经过 PRF 派生后用于对 AUTH 中的签名对象进行 PRF 签名，不得用做其他任何用途。IKEv2 通常不建议使用不生成密钥的 EAP 方法认证，若确实使用，AUTH 载荷必须分别使用 SK_pi 与 SK_pr 生成。
使用 EAP 认证的 IKE_AUTH 流程图例：

发起方		响应方
HDR，SK{ IDi，CERT，CERTREQ，SAi2，TSi，TSr }	---->
	<----	HDR，SK{ IDr，CERT，AUTH，EAP }
HDR，SK{ EAP }	---->
	<----	HDR，SK{ EAP }
	......
	<----	HDR，SK{ EAP(success) }
HDR，SK{ AUTH }	---->
	<----	HDR，SK{ SAr2，AUTH，TSi，TSr }

---

三、ESP（Encapsulate Secure Payload）详解
（3.1）简介
ESP 为 IP报文提供数据完整性校验、身份验证、数据加密以及重放攻击保护等。 除了 AH 提供的所有服务外，还提供机密性服务。 ESP 可在传输模式以及隧道模式下使用。ESP 头部可以位于IP头与上层协议之间，或者用它封装整个IP数据报。ESP 的 IP 协议号为 50。

（3.2）ESP NAT-T 模式
ESP NAT-T 模式，一种用于 ESP 报文穿越 NAT 的模式。由于现代 NAT 普遍使用 PAT（端口地址转换），但 ESP 是三层封装协议，不具备端口号的概念，如果直接穿越 NAT，PAT无法对其改写端口号导致无法穿越 NAT。NAT-T 模式的解决方案是将 ESP 报文封装进 UDP 报文中进行传输，即在 IP 头部与 ESP 头部之间插入一个 UDP 头部，使用 UDP 4500 端口作为源和目的端口以便 NAT 识别以及改写端口号，UDP头部同IP头部不被加密也不被认证。

（3.3）ESP 报文封装标准格式
蓝色：被认证
红色：被认证且被加密
（3.3.1）ESP 传输模式封装标准格式（IPv4）
[IPv4公网头部] [ESP头部] [传输层头部] [业务数据] [ESP尾部] [ESP ICV]

（3.3.2）ESP 传输模式封装标准格式（IPv6）
[IPv6公网头部] [IPv6扩展头部] [ESP头部] [IPv6目的选项扩展头部] [传输层头部] [业务数据] [ESP尾部] [ESP ICV]

（3.3.3）ESP 隧道模式封装标准格式（IPv4）
[IPv4公网头部] [ESP头部] [IPv4原始头部] [传输层头部] [业务数据] [ESP尾部] [ESP ICV]

（3.3.4）ESP 隧道模式封装标准格式（IPv6）
[IPv4公网头部] [IPv6公网扩展头部] [ESP头部] [IPv6原始头部] [IPv6原始扩展头部] [传输层头部] [业务数据] [ESP尾部] [ESP ICV]

（3.3.5）ESP 头部标准格式（不被加密）(长度：8 Bytes)

名称	长度	用途
SPI（入站SPI）	4 Bytes	记录对方的入站 SPI，用于匹配对方的入站 SA
Sequence Numbe（序列号）	4 Bytes	从1开始，每一个报文段加一，用于匹配请求与响应与防止重放攻击

（3.3.6）ESP 尾部标准格式（被加密）（长度：可变）

名称	长度	用途
Padding（填充）	可变	若所采用的加密算法要求明文长度为某一字节数的整数倍（如 AES-128 分组密码的分组长度），则通过填充字段将明文（由载荷数据、填充、填充长度、下一个头部字段共同组成）补齐至算法要求的长度。
Pad Length（填充长度）	1 Byte	指示填充字段的字节数
Next Header（下一个头部）	1 Byte	标识内层载荷的协议类型，和 IP 头的协议号字段语义完全一致，TCP（6），UDP（17），IPv4（4），IPv6（41）

（3.3.7）ESP ICV 标准格式（不被加密）（长度：可变）

名称	长度	用途
ICV（完整性校验值）	取决于完整性保护算法	取决于完整性保护算法    校验整个ESP报文的完整性，计算范围覆盖头部和整个加密区（负载与尾部）

（3.4）算法
ESP 中加密算法与完整性保护算法均为可选服务项，以实现如仅需完整性保护算法的场景，但至少必须选择其中一种服务，因此两种算法不得同时设置为空（NULL）。

（3.4.1）加密算法
用于保护 ESP 报文机密性的算法，由报文收发对应的 SA 指定，ESP 既可以适配分组密码（如 AES‑CBC），也适配流密码（如 AES‑CTR）。由于 IP 报文可能乱序到达，在使用分组密码的情况下可能无法获取其 IV，因此 IV 可以显式承载在载荷字段中，也可以从（外层 IP 或 ESP）报文头部的明文部分派生。
 
（3.4.2）完整性保护算法
用于保护 ESP 报文完整性的算法，由报文收发对应的 SA 指定，与加密算法同理，所有适配 ESP 的完整性算法，都必须支持对乱序到达、存在丢包的报文进行处理。

（3.4.3）组合模式算法
若使用组合模式算法，将同时提供机密性与完整性服务。与加密算法同理，组合模式算法必须支持逐包的密码学同步，以适配乱序到达、存在丢包的报文解密场景。
不同的组合模式算法，对载荷、SPI 以及（扩展）序列号字段的完整性保护实现方式可能存在差异。为提供统一的、与算法无关的调用方式，ESP 协议不为组合模式定义额外的载荷子结构。例如，部分算法可能在密文封装范围内复制 SPI 与序列号字段，也可能将 ICV 追加在 ESP 尾部；这些实现细节对外都不可见。

（3.5）ESP 出入站处理

（3.5.1）ESP 出站处理

1. IP 协议栈收到来自上层协议栈的报文，正常封装后，根据路由表先对原始报文进行路由，在启用 IPsec 的情况下再投递给投递给 IPsec 内核处理
2. IPsec 内核提取原始报文的五元组并查询出站 SPD，如果命中规则则进入后续流程
3. 如果需要执行加密则查询 SAD ，如果有对应出站 SA 则进行后续流程，否则触发 IKEv2 建立 SA，最后投递给 ESP 内核
4. ESP 内核收到后查询 SAD，根据对应的入站 SA 构造头部，尾部，执行加密，计算 ICV 与计算序列号，构造出完整 ESP 报文后投递给 IP 协议栈，根据工作模式的不同，如果是传输模式 SA，那么直接投递给下层协议栈发送数据；如果是隧道模式 SA，投递 IP 协议栈并进入下一步
5. IP 协议栈根据路由表对外层公网 IP 头部进行路由，投递给下层协议栈发送数据

（3.5.2）ESP 入站处理

1. IP 协议栈收到来自下层协议栈的报文，正常解封后，根据协议字段 50 投递至 ESP 内核
2. ESP 内核收到后查询 SAD，根据对应的入站 SA 执行解密，校验 ICV，还原成原始 IP 报文后投递给 IP 协议栈，根据工作模式的不同，如果是传输模式 SA，那么直接投递给上层协议栈处理数据；如果是隧道模式 SA，投递 IP 协议栈并进入下一步
3. IP 协议栈正常解封原始 IP 报文，根据协议字段投递给上层协议栈处理数据

（3.6）基于策略与基于路由的隧道模式
IPsec 中 ESP 的“基于策略”和“基于路由”的隧道模式，是 VPN 的两种实现方式。它们在触发加密的方式、灵活性、以及支持的特性上有根本区别。

（3.6.1）基于策略的隧道模式
基于策略的隧道模式通常是通过安全策略（如访问控制列表 ACL 或 SPD）精确匹配“感兴趣流”的源/目的IP、协议等，核心是“策略”，将流量导入隧道是策略中的一个动作，数据包匹配策略后触发加密，但不支持动态路由协议，配置简单，一般系统默认

（3.6.2）基于路由的隧道模式
基于路由的隧道模式通常是创建一个虚拟的隧道接口（如 VTI 或是 Tunnel 虚拟接口），通过路由表决定哪些流量进入该接口，隧道是一个独立的三层逻辑接口（意思是进入该接口的所有流量都会进入 IPsec 内核进行加密等操作），数据包匹配路由，下一跳指向隧道接口后触发加密，支持动态路由协议（如 OSPF，BGP 等），配置稍复杂，但扩展性和灵活性更好

感谢您的阅读，如有勘误，欢迎指出