All specs
RFC 4302RFCShould KnowBack Office2005

IP Authentication Header

VPN & Tunneling·RFC Editor
WHY YOU NEED THIS

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.

What It Defines

Defines AH (IP protocol 51) — the IPsec protocol for connectionless integrity, data origin authentication, and optional anti-replay for IP packets. AH authenticates the entire IP packet including most header fields (unlike ESP, which only covers the payload). Does NOT provide confidentiality (no encryption). Largely superseded by ESP with null encryption or ESP with combined-mode algorithms that provide both authentication and encryption.

Canonical (Normative)

ahipsecauthenticationintegrityvpn
Standards Body
RFC Editor

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.

Visit

Related Specs

RFC 4301RFCMust Know

IPsec Architecture

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.

Back OfficeProductVPN & Tunneling
Details
RFC 4303RFCMust Know

ESP

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.

Back OfficeProductVPN & Tunneling
Details