IPsec是个协议套装，其内协议工作在网络层，这些协议主要用来为IP协议提供加密和认证服务。
本文介绍IPsec协议套装内常见的AH和ESP协议。
首先作一点说明，本文后续出现的{0,1}表示“出现0次或者1次”。
一、AH协议
AH（Authentication Header）协议：扩展IP协议报文提供无连接数据完整性、消息认证以及防重放攻击保护能力。
讨论AH协议须涉及4种情况：1）工作场景——“IPv4报文 VS IPv6报文”；2）工作模式——“隧道模式 VS 传输模式”。
AH报文整体格式为：
+-------------+---------------+---+ | AH Header | AH Payload Data | +-------------+---------------+---+
接下来介绍AH协议报文详细格式。
| Offsets | Octet | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Octet | Bit | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | Next Header (8 bits) | Payload Length (8 bits) | Reserved (16 bits) | |||||||||||||||||||||||||||||
| 4 | 32 | Security Parameters Index (SPI, 32 bits) | |||||||||||||||||||||||||||||||
| 8 | 64 | Sequence Number (32 bits) | |||||||||||||||||||||||||||||||
| 12 | 96 |
Integrity Check Value (ICV, variable bits)
... | |||||||||||||||||||||||||||||||
| ... | ... | ||||||||||||||||||||||||||||||||
| ... | ... | Payload Data (variable bits) | |||||||||||||||||||||||||||||||
| ... | ... | ||||||||||||||||||||||||||||||||
| ... | ... | ||||||||||||||||||||||||||||||||
AH报文格式说明如下：
- Next Header：下一个首部的类型值，指明载荷数据中数据协议类型
- Payload Length：名字太有歧义，实际是首部长度。首部长度=
(Payload Length + 2) * 4 - Reserved：保留值，当前为全0
- Security Parameters Index（SPI）：安全参数索引用于定位
具体的SA（Security Association，指定了可被通信双方识别的安全属性集合） - Sequence Number：序列号
- Integrity Check Value（ICV）：完整性验证值。另有：1）其具体长度不由具体的SA指出；2）可能存在填充数据使AH首部长度满足字节对齐条件（具体见扩展说明）
- Payload Data：AH报文的载荷数据
扩展说明：
- 当在IPv4报文工作场景中时，整个首部长度须是4字节倍数，不满足则在ICV中填充；当在IPv6报文工作场景中时，整个首部长度须是8字节倍数，不满足则在ICV中填充
- 示例可见Pcap文件
1.1、IPv4报文
在IPv4报文中AH报文首部作为一般协议首部。
1.1.1、传输模式
在传输模式中，对原IPv4报文的载荷数据进行AH运算，然后添加一个AH首部。
+---------------+-+-+---------+-+-+---------------+
| | | |
| IPv4 Header | AH Header | AH Payload Data |
| | | |
+---------------+-+-+---------+-+-++------------+-+
| |
<--------New IPv4 Payload Data---->
AH Payload Data：对原IPv4报文载荷数据进行AH运算获得。
1.1.2、隧道模式
在隧道模式中，对原IPv4报文整体进行AH运算，然后添加一个新IPv4首部和一个AH首部。
+-----------------+-+-----------+-+-+-------------+---+
| | | |
| New IPv4 Header | AH Header | AH Payload Data |
| | | |
+-----------------+-+-----------+-+-+-----------+-+---+
| |
<-------New IPv4 Payload Data----->
AH Payload Data：对原IPv4报文整体进行AH运算获得。
1.2、IPv6报文
在IPv6报文中AH报文首部作为扩展首部[4]。
1.2.1、传输模式
在传输模式中，对原IPv6报文的载荷数据（不存在扩展首部情形）/原IPv6报文中最内层扩展首部对应的载荷数据（存在扩展首部情形）进行AH运算，然后添加一个AH首部。
+---------------+--+--------------------------------+----------------+--+
| | | |
| | Hop-by-Hop Options Header{0,1} | |
| | Destination Options Header{0,1} | |
| | Routing Header{0,1} | |
| | Fragment Header{0,1} | |
| IPv6 Header | AH Header | AH Payload Data |
| | | |
+---------------+--+--------------------------------+----------------+--+
| |
<----------------New IPv6 Payload Data------------------>
AH Payload Data：在不存在扩展首部情形下，对原IPv6报文的载荷数据进行AH运算获得；在存在扩展首部情形下，对原IPv6报文中最内层扩展首部对应的载荷数据进行AH运算获得，比如“最内存扩展首部是Fragment Header，那么对Fragment Header对应的载荷数据进行AH运算获得AH Payload Data”。
1.2.2、隧道模式
在隧道模式中，对原IPv6报文整体进行AH运算，然后添加一个新IPv6首部和一个AH首部。
+-----------------+-+-----------+-+---------------+---+
| | | |
| New IPv6 Header | AH Header | AH Payload Data |
| | | |
+-----------------+-+-----------+-+---+---------+-+--++
| |
<-------New IPv6 Payload Data----->
AH Payload Data：对原IPv6报文整体进行AH运算获得。
另外须注意：我们知道在IPv6报文中扩展首部具有数量和顺序限制，在以上情形中——1）AH Payload Data内嵌IPv6报文扩展首部遵循该限制；2）“AH Header”和“AH Payload Data内嵌IPv6报文扩展首部”两者互相独立，无需遵循该限制。
二、ESP协议
ESP（Encapsulating Security Payload）协议：为IP协议报文提供源可靠性、完整性和保密性支持。
讨论ESP协议须涉及4种情况：1）工作场景——“IPv4报文 VS IPv6报文”；2）工作模式——“隧道模式 VS 传输模式”。
ESP报文整体格式为：
+-------------++--------------+---+-+---------------+-----------+ | ESP Header | ESP Payload Data | ESP Trailer | ESP ICV | +-------------++--------------+---+-+---------------+-----------+
后续为了叙述简单，可简化为：
+-------------++--------------+---+-+ | ESP Header | ESP Payload Data | +-------------++--------------+---+-+
接下来介绍ESP协议报文详细格式。
| Offsets | Octet | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Octet | Bit | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | Security Parameters Index (SPI, 32 bits) | |||||||||||||||||||||||||||||||
| 4 | 32 | Sequence Number (32 bits) | |||||||||||||||||||||||||||||||
| 8 | 64 | Payload Data (variable bits) | |||||||||||||||||||||||||||||||
| ... | ... | ||||||||||||||||||||||||||||||||
| ... | ... | ||||||||||||||||||||||||||||||||
| ... | ... | Padding (0-255 bytes) | |||||||||||||||||||||||||||||||
| ... | ... | Pad Length (8 bits) | Next Header (8 bits) | ||||||||||||||||||||||||||||||
| ... | ... |
Integrity Check Value (ICV, multiple of 32 bits)
... | |||||||||||||||||||||||||||||||
| ... | ... | ||||||||||||||||||||||||||||||||
ESP报文格式说明如下：
- Security Parameters Index（SPI）：安全参数索引用于定位
具体的SA（Security Association，指定了可被通信双方识别的安全属性集合） - Sequence Number：序列号
- Payload Data：ESP报文的载荷数据
- Padding：填充数据
- Pad Length：填充长度
- Next Header：下一个首部的类型值，指明载荷数据中数据协议类型
- Reserved：保留值，当前为全0
- Integrity Check Value（ICV）：完整性验证值。跟AH首部中的
Integrity Check Value不一样：1）其具体长度须由具体的SA指出；2）不处于ESP首部中，故无需存在填充数据使ESP首部长度满足字节对齐条件（具体见扩展说明）
扩展说明：
- ESP首部的长度为8字节，自然满足“当在IPv4报文工作场景中时，整个首部长度须是4字节倍数；当在IPv6报文工作场景中时，整个首部长度须是8字节倍数”
- 示例可见Pcap文件。ESP ICV区域长度由具体的SA指出，这是可解析出ESP报文的关键信息。以上例子中ESP报文不能被完整解析就是因为我们本地缺失通信双方当初协商确定的具体SA信息
2.1、IPv4报文
在IPv4报文中ESP报文首部作为一般协议首部。
2.1.1、传输模式
在传输模式中，对原IPv4报文的载荷数据进行ESP运算，然后添加一个ESP首部。
+---------------+-+-+----------++-+---------------+-+
| | | |
| IPv4 Header | ESP Header | ESP Payload Data |
| | | |
+---------------+-+-+----------++-++------------+-+-+
| |
<-------New IPv4 Payload Data------->
ESP Payload Data：对原IPv4报文载荷数据进行ESP运算获得。
2.1.2、隧道模式
在隧道模式中，对原IPv4报文整体进行ESP运算，然后添加一个新IPv4首部和一个ESP首部。
+-----------------+-+-----------+-+++-------------+---+-+
| | | |
| New IPv4 Header | ESP Header | ESP Payload Data |
| | | |
+-----------------+-+-----------+-+++-----------+-+---+-+
| +
<--------New IPv4 Payload Data------>
ESP Payload Data：对原IPv4报文整体进行ESP运算获得。
2.2、IPv6报文
在IPv6报文中ESP报文首部作为扩展首部[4]。
2.2.1、传输模式
在传输模式中，对原IPv6报文的载荷数据（不存在扩展首部情形）/原IPv6报文中最内层扩展首部对应的载荷数据（存在扩展首部情形）进行ESP运算，然后添加一个ESP首部。
+---------------+-----------------------------------+-------------+---+--+
| | | |
| | Hop-by-Hop Options Header{0,1} | |
| | Destination Options Header{0,1} | |
| | Routing Header{0,1} | |
| | Fragment Header{0,1} | |
| IPv6 Header | ESP Header | ESP Payload Data |
| | | |
+---------------+-----------------------------------+--------------+---+-+
| |
<------------------New IPv6 Payload Data----------------->
ESP Payload Data：在不存在扩展首部情形下，对原IPv6报文的载荷数据进行ESP运算获得；在存在扩展首部情形下，对原IPv6报文中最内层扩展首部对应的载荷数据进行ESP运算获得，比如“最内存扩展首部是Fragment Header，那么对Fragment Header对应的载荷数据进行ESP运算获得ESP Payload Data”。
2.2.2、隧道模式
在隧道模式中，对原IPv6报文整体进行ESP运算，然后添加一个新IPv6首部和一个ESP首部。
+-----------------+-+-----------+-++--------------+---+-+
| | | |
| New IPv6 Header | ESP Header | ESP Payload Data |
| | | |
+-----------------+-+-----------+-++--+---------+-+---+-+
| |
<--------New IPv6 Payload Data------>
ESP Payload Data：对原IPv6报文整体进行ESP运算获得。
另外须注意：我们知道在IPv6报文中扩展首部具有数量和顺序限制，在以上情形中——1）ESP Payload Data内嵌IPv6报文扩展首部遵循该限制；2）“ESP Header”和“ESP Payload Data内嵌IPv6报文扩展首部”两者互相独立，无需遵循该限制。
参考文献
[1]https://en.wikipedia.org/wiki/IPsec
[2]https://datatracker.ietf.org/doc/html/rfc4302
[3]https://datatracker.ietf.org/doc/html/rfc4303
[4]《IPv6报文》
[5]https://www.twingate.com/blog/ipsec-tunnel-mode
[6]https://www.redhat.com/sysadmin/ipv6-packets-and-ipsec
