RFC 精读 · IPsec · Proposed Standard
RFC 4303
IP Encapsulating Security Payload (ESP) —— IPsec 的加密载荷。明文只剩 SPI 和序列号；传输模式留原 IP 头，隧道模式再包一层。
读这一篇的目标：能画出 ESP 明文头（SPI + 序列号）和加密载荷，分清传输模式与隧道模式谁被包进去，并说明抗重放窗口为什么必须配合完整性。4303 把后来常说的 AEAD 叫做 combined mode。
§1 Introduction
插在 IP 头之后；机密性不是唯一服务
The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6 [DH98]. ESP may be applied alone, in combination with AH [Ken-AH], or in a nested fashion (see the Security Architecture document [Ken-Arch]). Security services can be provided between a pair of communicating hosts, between a pair of communicating security gateways, or between a security gateway and a host. For more details on how to use ESP and AH in various network environments, see the Security Architecture document [Ken-Arch]. The ESP header is inserted after the IP header and before the next layer protocol header (transport mode) or before an encapsulated IP header (tunnel mode). These modes are described in more detail below. ESP can be used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and (limited) traffic flow confidentiality. The set of services provided depends on options selected at the time of Security Association (SA) establishment and on the location of the implementation in a network topology.
注解
ESP 提供的是一组可选服务：机密性、数据源认证、无连接完整性、抗重放（一种部分的序列完整性），以及有限的流量机密性。选哪些，在建立 SA 时定，不是“开了 ESP 就全有”。
位置一句话：插在 IP 头后面。后面跟的是下一层协议头（传输模式），或再包一个 IP 头（隧道模式）。
4303 明确允许只加密、不带完整性，但紧接着警告：面对主动攻击，没有完整性的机密性不可靠。现代部署把完整性（或 AEAD）当成默认。
§2 Figure 1
外层协议号 50；明文只有 SPI 和序列号
The (outer) protocol header (IPv4, IPv6, or Extension) that immediately precedes the ESP header SHALL contain the value 50 in its Protocol (IPv4) or Next Header (IPv6, Extension) field (see IANA web page at http://www.iana.org/assignments/protocol-numbers). Figure 1 illustrates the top-level format of an ESP packet. The packet begins with two 4-byte fields (Security Parameters Index (SPI) and Sequence Number). Following these fields is the Payload Data, which has substructure that depends on the choice of encryption algorithm and mode, and on the use of TFC padding, which is examined in more detail later. Following the Payload Data are Padding and Pad Length fields, and the Next Header field. The optional Integrity Check Value (ICV) field completes the packet.
[……下接 Figure 1 顶层格式]
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| Security Parameters Index (SPI) | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| Sequence Number | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
| Payload Data* (variable) | | ^
~ ~ | |
| | |Conf.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
| | Padding (0-255 bytes) | |ered*
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | Pad Length | Next Header | v v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
| Integrity Check Value-ICV (variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Top-Level Format of an ESP Packet注解
IPv4 Protocol / IPv6 Next Header = 50 就是 ESP。包以两个 4 字节明文场开头：SPI、Sequence Number。后面 Payload、Padding、Pad Length、Next Header 在机密性开启时是密文；可选 ICV 挂在包尾。
图右侧的 Int.Covered / Conf.Covered 标明完整性覆盖 SPI 起直到 Next Header，机密性从 Payload 起。ICV 本身不加密。
抓到一个协议号 50 的包，你能读的通常只有 SPI 和序列号。TCP/UDP 端口、HTTP 方法都在密文里，过滤器 tcp / http 看不到内层。
§2 Combined Mode · Table 2
加密和完整性合成一次运算
As noted above, the Payload Data may have substructure. An encryption algorithm that requires an explicit Initialization Vector (IV), e.g., Cipher Block Chaining (CBC) mode, often prefixes the Payload Data to be protected with that value. Some algorithm modes combine encryption and integrity into a single operation; this document refers to such algorithm modes as "combined mode algorithms". Accommodation of combined mode algorithms requires that the algorithm explicitly describe the payload substructure used to convey the integrity data. Some combined mode algorithms provide integrity only for data that is encrypted, whereas others can provide integrity for some additional data that is not encrypted for transmission. Because the SPI and Sequence Number fields require integrity as part of the integrity service, and they are not encrypted, it is necessary to ensure that they are afforded integrity whenever the service is selected, regardless of the style of combined algorithm mode employed. When any combined mode algorithm is employed, the algorithm itself is expected to return both decrypted plaintext and a pass/fail indication for the integrity check. For combined mode algorithms, the ICV that would normally appear at the end of the ESP packet (when integrity is selected) may be omitted. When the ICV is omitted and integrity is selected, it is the responsibility of the combined mode algorithm to encode within the Payload Data an ICV-equivalent means of verifying the integrity of the packet.
[……下接 Table 2 Combined Mode Algorithms]
Table 2. Combined Mode Algorithms
What What What
# of Requ'd Encrypt Integ is
bytes [1] Covers Covers Xmtd
------ ------ ------ ------ ------
SPI 4 M plain
Seq# (low-order bits) 4 M plain p
--- a
IV variable O Y plain | y
IP datagram [2] variable M or D Y Y cipher |-l
TFC padding [3] variable O Y Y cipher | o
--- a
Padding 0-255 M Y Y cipher d
Pad Length 1 M Y Y cipher
Next Header 1 M Y Y cipher
Seq# (high-order bits) 4 if ESN [4] Y [5]
ICV Padding variable if need Y [5]
ICV variable O [6] plain
[1] M = mandatory; O = optional; D = dummy
[2] If tunnel mode -> IP datagram
If transport mode -> next header and data
[3] Can be used only if payload specifies its "real" length
[4] See Section 2.2.1
[5] The algorithm choices determines whether these are
transmitted, but in either case, the result is invisible
to ESP
[6] The algorithm spec determines whether this field is
present注解
4303 把“一次运算同时做加密和完整性”叫做 combined mode。后来的 AES-GCM、ChaCha20-Poly1305 就是这一类，今天口语里叫 AEAD。规范本文没有写 AEAD 这个词。
用 combined mode 时，图 1 末尾那个显式 ICV 可以省略：算法在 Payload 里自己带等价校验。SPI 和序列号仍是明文，但必须被完整性覆盖；若算法只保护密文，就要在 Payload 里复制这两项。
Table 2 对照：隧道模式 Payload 是整个内层 IP 数据报；传输模式是 next header + 数据。两种模式的 SPI / 低 32 位序列号都明文发送。
§2.1 Security Parameters Index
接收方用 SPI 找到 SA
2.1. Security Parameters Index (SPI) The SPI is an arbitrary 32-bit value that is used by a receiver to identify the SA to which an incoming packet is bound. The SPI field is mandatory.
[……下接保留值]
The set of SPI values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use; a reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. The SPI value of zero (0) is reserved for local, implementation-specific use and MUST NOT be sent on the wire. (For example, a key management implementation
注解
SPI 是接收方选的 32 比特任意值，用来把入站包绑到某个 SA。单播时可以只靠 SPI，也可以 SPI + 协议（AH/ESP）一起查。组播查找还可能加上目的 / 源地址，按“最长 SA 标识”匹配。
1–255 留给 IANA；0 保留给本地实现，不得上线。这和 IKEv2 在 UDP/4500 上用四个 0 字节区分 IKE 报文是两件事：那四个 0 不是 ESP 的 SPI 场。
§2.2 / §3.4.3 Sequence Number
每包加一；抗重放靠滑动窗口
2.2. Sequence Number This unsigned 32-bit field contains a counter value that increases by one for each packet sent, i.e., a per-SA packet sequence number. For a unicast SA or a single-sender multicast SA, the sender MUST increment this field for every transmitted packet. Sharing an SA among multiple senders is permitted, though generally not recommended. ESP provides no means of synchronizing packet counters among multiple senders or meaningfully managing a receiver packet counter and window in the context of multiple senders. Thus, for a multi-sender SA, the anti-replay features of ESP are not available (see Sections 3.3.3 and 3.4.3.) The field is mandatory and MUST always be present even if the receiver does not elect to enable the anti-replay service for a specific SA. Processing of the Sequence Number field is at the discretion of the receiver, but all ESP implementations MUST be capable of performing the processing described in Sections 3.3.3 and 3.4.3. Thus, the sender MUST always transmit this field, but the receiver need not act upon it (see the discussion of Sequence Number Verification in the "Inbound Packet Processing" section (3.4.3) below). The sender's counter and the receiver's counter are initialized to 0 when an SA is established. (The first packet sent using a given SA will have a sequence number of 1; see Section 3.3.3 for more details on how the sequence number is generated.) If anti-replay is enabled (the default), the transmitted sequence number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA.
[……下接入站校验]
All ESP implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. This service MUST NOT be enabled unless the ESP integrity service also is enabled for the SA, because otherwise the Sequence Number field has not been integrity protected.
[……下接窗口启用时的入站处理]
If the receiver has enabled the anti-replay service for this SA, the receive packet counter for the SA MUST be initialized to zero when the SA is established. For each received packet, the receiver MUST verify that the packet contains a Sequence Number that does not duplicate the Sequence Number of any other packets received during the life of this SA. This SHOULD be the first ESP check applied to a packet after it has been matched to an SA, to speed rejection of duplicate packets.
[……下接滑动窗口]
Duplicates are rejected through the use of a sliding receive window. How the window is implemented is a local matter, but the following text describes the functionality that the implementation must exhibit. The "right" edge of the window represents the highest, validated Sequence Number value received on this SA. Packets that contain sequence numbers lower than the "left" edge of the window are rejected. Packets falling within the window are checked against a
注解
序列号对每个 SA 从 0 起，第一包发 1。发送方必须带这个场，即使接收方关掉抗重放。抗重放是默认开启的；开着就不允许回绕，232 包之前必须换 SA / 换密钥。
抗重放必须和完整性一起开：没有完整性，序列号能被改，窗口没有意义。实现必须支持该服务，但是否启用由接收方按 SA 决定。
窗口右沿是目前验证过的最大序列号；小于左沿的丢，窗口内的查已收清单。多发送方共用一个 SA 时，4303 不提供抗重放。扩展序列号（ESN）线上仍只发低 32 位，高 32 位由接收方推算，须由 SA 管理协议协商。
§3.1 Transport / Tunnel
谁被包进去，决定你在外层能看见什么
ESP may be employed in two ways: transport mode or tunnel mode.
[……下接传输模式]
In transport mode, ESP is inserted after the IP header and before a next layer protocol, e.g., TCP, UDP, ICMP, etc. In the context of IPv4, this translates to placing ESP after the IP header (and any options that it contains), but before the next layer protocol. (If AH is also applied to a packet, it is applied to the ESP header, Payload, ESP trailer, and ICV, if present.) (Note that the term "transport" mode should not be misconstrued as restricting its use to TCP and UDP.) The following diagram illustrates ESP transport mode positioning for a typical IPv4 packet, on a "before and after" basis.
[……下接 IPv4 传输模式图]
BEFORE APPLYING ESP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING ESP
-------------------------------------------------
IPv4 |orig IP hdr | ESP | | | ESP | ESP|
|(any options)| Hdr | TCP | Data | Trailer | ICV|
-------------------------------------------------
|<---- encryption ---->|
|<-------- integrity ------->|[……下接隧道模式]
In tunnel mode, the "inner" IP header carries the ultimate (IP) source and destination addresses, while an "outer" IP header contains the addresses of the IPsec "peers", e.g., addresses of security gateways. Mixed inner and outer IP versions are allowed, i.e., IPv6 over IPv4 and IPv4 over IPv6. In tunnel mode, ESP protects the entire inner IP packet, including the entire inner IP header. The position of ESP in tunnel mode, relative to the outer IP header, is the same as for ESP in transport mode. The following diagram illustrates ESP tunnel mode positioning for typical IPv4 and IPv6
[……下接隧道模式 IPv4 / IPv6 图]
BEFORE APPLYING ESP
----------------------------
IPv4 |orig IP hdr | | |
|(any options)| TCP | Data |
----------------------------
AFTER APPLYING ESP
-----------------------------------------------------------
IPv4 | new IP hdr* | | orig IP hdr* | | | ESP | ESP|
|(any options)| ESP | (any options) |TCP|Data|Trailer| ICV|
-----------------------------------------------------------
|<--------- encryption --------->|
|<------------- integrity ------------>|
BEFORE APPLYING ESP
---------------------------------------
IPv6 | | ext hdrs | | |
| orig IP hdr |if present| TCP | Data |
---------------------------------------
AFTER APPLYING ESP
------------------------------------------------------------
IPv6 | new* |new ext | | orig*|orig ext | | | ESP | ESP|
|IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV|
------------------------------------------------------------
|<--------- encryption ---------->|
|<------------ integrity ------------>|
* = if present, construction of outer IP hdr/extensions and
modification of inner IP hdr/extensions is discussed in
the Security Architecture document.注解
传输模式：原 IP 头留下，ESP 插在它和 TCP/UDP/ICMP 之间。加密从 TCP 起，到 ESP trailer；完整性从 ESP 头起到 ICV 前。外层仍是原来的源/目的地址，中间盒能看见“这两台主机在用 ESP”，看不见端口。
隧道模式：新的外层 IP 头写 IPsec 对等体（安全网关），整个原 IP 包进 Payload。站点到站点 VPN 用这个。混合版本允许（IPv6 包进 IPv4 隧道，或反过来）。
易误解：“隧道模式才加密”是错的。两种模式都可以加密；差别是原 IP 头还在不在明文里。
抓包对照
ESP 加密之后，Wireshark 默认只能解到 ESP 头。内层 L4 要 SA 密钥；过 NAT 时看的是 UDP/4500 封装，不是裸协议 50。
裸 ESP（无 NAT）:
ip.proto == 50
esp
esp.spi
esp.sequence
IPv4 首部:
Protocol = 50 (0x32)
能看见:
SPI 4 字节 明文
Sequence 4 字节 明文
其后 密文（含原 L4）
可选 ICV 包尾
看不见（无密钥）:
TCP/UDP 端口、HTTP、内层 IP（隧道模式）
NAT-T（RFC 3948 / IKEv2 §2.23）:
udp.port == 4500
若 UDP 载荷前 4 字节非 0 → 后面是 ESP
若前 4 字节全 0 → 后面是 IKE
tcpdump: ip proto 50
udp port 4500
Wireshark: esp 或 udp.port == 4500 && !isakmp
- 过滤器从
esp或ip.proto == 50起手。概要栏到 ESP 就停，是正常的：没有 SAD 密钥解不开 Payload。 - 不要因为看不到
tcp.port == 443就说“这不是 HTTPS”。它可能在 ESP 里面。 - 家用 / 穿越 NAT 的 IPsec 几乎都走 UDP/4500。此时外层不是协议 50，是 UDP。用四个 0 字节区分 IKE 与 ESP（见 RFC 7296）。
- 传输模式还能看见原 IP 五元组里的地址；隧道模式外层地址是网关，内层地址在密文里。
考点与易错点
- IPv4 协议号 / IPv6 Next Header
50= ESP。明文头只有 SPI 和序列号。 - 4303 的 combined mode 就是后来常说的 AEAD；显式 ICV 在这类算法下可以省略。
- 抗重放默认开，必须配合完整性；窗口右沿是已验证的最大序列号。多发送方 SA 没有本规范的抗重放。
- SPI = 0 不得上线。1–255 留给 IANA。
- 传输模式保留原 IP 头；隧道模式再包一个外层 IP 头。两种模式都可以加密。
- 加密后抓包看不到 L4。过 NAT 看 UDP/4500，不要只滤
ip.proto == 50。