IP Encapsulating Security Payload
ESP is the workhorse of IPsec — every encrypted VPN tunnel uses it. When your cloud VPN shows 'Phase 2 SA established', that's an ESP SA. Understanding ESP's SPI, sequence numbers, and algorithm negotiation is key to VPN troubleshooting.
What It Defines
Defines ESP — the primary IPsec protocol that provides confidentiality (encryption), data integrity, authentication, and optional anti-replay protection. In tunnel mode, ESP encrypts the entire inner IP packet and appends an ESP header (SPI + sequence number), an IV, encrypted payload, padding, and an ICV (Integrity Check Value). Supports AES-GCM, AES-CBC + HMAC-SHA256, ChaCha20-Poly1305, and other algorithm suites negotiated via IKE. ESP (IP protocol 50) has largely replaced AH because it provides both encryption and authentication.
Canonical (Normative)
Related References
The canonical publication point for finalized RFCs. If a protocol is standardized as an RFC, the RFC Editor text is the normative final reference. Published by the IETF, IRTF, IAB, and independent stream.
Related Specs
IPsec is the dominant VPN technology for enterprise site-to-site links (AWS VPN, Azure VPN Gateway, on-prem firewalls). Understanding tunnel vs transport mode, SAs, and the SPD is essential for configuring and debugging VPN connectivity.
AH is mostly historical — ESP does everything AH does and adds encryption. However, AH appears in legacy configurations and exam material. Understanding why it was replaced helps explain modern IPsec design decisions.
IKEv2 is how IPsec tunnels are established and rekeyed. Every cloud VPN gateway (AWS, GCP, Azure), enterprise firewall, and mobile VPN client uses IKEv2. Phase 1/Phase 2 failures are the #1 VPN debugging scenario.