RFC 4303

Q: What does the Introduction section cover in RFC 4303 — ESP?

The Introduction section provides detailed technical specifications, security considerations, and implementation guidance as documented in RFC 4303 — ESP. This content is part of the BLACKLABS RFC Reference Library.

Q: What does the ESP Packet Format section cover in RFC 4303 — ESP?

The ESP Packet Format section provides detailed technical specifications, security considerations, and implementation guidance as documented in RFC 4303 — ESP. This content is part of the BLACKLABS RFC Reference Library.

Q: What does the ESP Modes section cover in RFC 4303 — ESP?

The ESP Modes section provides detailed technical specifications, security considerations, and implementation guidance as documented in RFC 4303 — ESP. This content is part of the BLACKLABS RFC Reference Library.

Q: What does the 3GPP Algorithm Profile section cover in RFC 4303 — ESP?

The 3GPP Algorithm Profile section provides detailed technical specifications, security considerations, and implementation guidance as documented in RFC 4303 — ESP. This content is part of the BLACKLABS RFC Reference Library.

Q: What does the Anti-Replay section cover in RFC 4303 — ESP?

The Anti-Replay section provides detailed technical specifications, security considerations, and implementation guidance as documented in RFC 4303 — ESP. This content is part of the BLACKLABS RFC Reference Library.

BLACKLABS

IP Encapsulating Security Payload (ESP)

Standards Track Obsoletes: RFC 2406

December 2005

Abstract: This document describes the IP Encapsulating Security Payload (ESP). ESP provides confidentiality, data origin authentication, connectionless integrity, anti-replay protection, and limited traffic flow confidentiality. ESP is the sole IPsec protocol used in 3GPP NDS/IP (TS 33.210).

Canonical source: https://www.rfc-editor.org/rfc/rfc4303 | IETF Datatracker

1. Introduction

▶

ESP is the workhorse of IPsec, providing both encryption and authentication in a single protocol. Unlike AH, ESP can encrypt the payload, making it the preferred (and in 3GPP, the only) IPsec protocol for protecting network traffic.

2. ESP Packet Format

▶

The ESP header (SPI + Sequence Number) is not encrypted but is authenticated. The IV, payload, padding, pad length, and next header are encrypted. The ICV covers from the SPI through the Next Header field.

  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)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Initialization Vector (IV)                |
|                         (variable)                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                             |
~                    Encrypted Payload Data                   ~
|                                                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Padding (0-255 bytes)                                      |
+                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |  Pad Length   | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Integrity Check Value (ICV) (variable)              |
~                                                             ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3. ESP Modes

▶

Mode	Inner Header	Use Case	3GPP Usage
Tunnel	Full IP header encapsulated	Gateway-to-gateway, hides inner topology	Za interface (SEG-SEG) — MANDATORY
Transport	Original IP header preserved	Host-to-host, lower overhead	Zb interface (NE-NE) — optional

4. 3GPP Algorithm Profile

▶

Algorithm	Type	TS 33.210 Requirement
AES-GCM-128/256	AEAD (encrypt + auth)	SHOULD (preferred)
AES-CBC-128/256	Encryption	MUST support
HMAC-SHA-256-128	Authentication	MUST support (with CBC)
HMAC-SHA-384/512	Authentication	MAY support
NULL encryption	Authentication only	MAY (integrity-only mode)
DES / 3DES	Encryption	MUST NOT use

5. Anti-Replay

▶

ESP uses a sliding window mechanism for anti-replay protection. The receiver maintains a window of received sequence numbers and rejects duplicates or packets that fall before the window.

Minimum window size is 64 packets (MUST support)
Extended Sequence Numbers (ESN) support 64-bit counters for high-speed links
Anti-replay MAY be disabled by the receiver but MUST be supported

6. Security Considerations

▶

ESP without authentication (encryption-only) is NOT RECOMMENDED — vulnerable to bit-flipping attacks
AEAD algorithms (AES-GCM) are preferred as they combine encryption and authentication atomically
Padding oracle attacks are mitigated by always authenticating before decrypting
Traffic flow confidentiality (TFC) padding can be used to hide true payload sizes