How does Authentication Header (AH) work?

How AH changes IP packet handling

AH sits between the IP layer and the payload as a security wrapper for the packet. Its job is to make tampering visible by binding the packet to an integrity check over the protected fields. That makes it useful when you need to know a packet arrived from the expected source and was not altered in transit, even if the content itself is not hidden.

The practical distinction is that AH protects authenticity and integrity, not confidentiality. Traffic can still be inspected in the clear, which means AH is not a substitute for encryption when the payload itself must be private. In environments that need both tamper detection and secrecy, AH by itself is incomplete and is usually evaluated alongside other IPsec protection choices.

One reason AH is sometimes misunderstood is that it protects selected header fields only when they are immutable end to end. Any device or feature that rewrites IP header values can interfere with verification. That is why AH behaves differently from simple checksum-style integrity, it is validating packet identity and stability across the path, not just detecting accidental corruption.

Where AH fits, and where it fails

AH is most relevant when the core problem is packet spoofing or in-transit modification. In those cases, a receiver can reject packets that fail authentication instead of trusting them because they look syntactically valid. It is therefore a control for trust in transit, not for access control, endpoint hardening, or content privacy.

Its biggest operational limitation is network path compatibility. NAT changes address-related header information, which can invalidate the authentication calculation and make AH unusable across translated paths. That means deployment often depends as much on network architecture as on crypto settings, especially in mixed perimeter, remote-access, or partner-connectivity designs.

AH also does not solve endpoint compromise. If an attacker can send packets from a trusted host, or if the sender itself is compromised, AH may faithfully authenticate malicious traffic. It reduces the chance of undetected packet tampering, but it does not create a trustworthy source on its own. That distinction matters when teams treat transport integrity as if it were source assurance.

Operational decisions that matter when using AH

Choosing AH is usually a decision about whether integrity is the primary requirement and whether the path can preserve the fields AH depends on. In practice, that means checking not only the cryptographic configuration but also whether NAT, load balancers, or intermediate gateways will break verification. If the answer is yes, the design must change before rollout rather than after failures appear.

For defenders, the real value of AH is strongest in tightly controlled networks where packet authenticity matters more than confidentiality and where path behavior is predictable. VPN Security Guide is useful background here because IPsec and VPN deployments often surface the same path-compatibility constraints that make AH succeed or fail.

When AH is part of a broader access path, treat it as one control in a chain, not the whole control set. If you need to protect both message secrecy and integrity, or if your routing topology includes translation, another security design is usually a better fit than trying to force AH into every segment. That is especially true where remote connectivity or edge devices are already doing address rewrites.

Risk and Threat Considerations

AH reduces packet spoofing and tampering risk, but it can fail operationally when network devices rewrite protected header values. In those environments, the failure is often silent until packets are rejected or tunnels stop working, which can create availability problems as well as integrity gaps.

Failure mechanism: NAT or other header-altering intermediaries change values that AH authenticates, so the receiver cannot validate the packet and drops it or treats it as invalid.

Impact: Legitimate traffic may fail to traverse the network, and teams may remove or bypass the control to restore connectivity, which can leave packet integrity weaker than intended.

Practitioner Guidance

What to verify: Confirm whether every hop between sender and receiver preserves the header fields AH covers. If any segment performs NAT, address pooling, or similar rewriting, validate the design in a lab before production rollout.

Decision rule: Use AH only when integrity and origin authentication are the priority and the path is stable enough to preserve verification. If confidentiality is also required, or if translation is unavoidable, choose a design that addresses those constraints directly rather than relying on AH alone.

Practitioner takeaway: AH is a packet-integrity control with strict path assumptions, so the deployment question is less “does it authenticate packets?” and more “can the network preserve the authenticated fields end to end?”

Related resources from NHI Mgmt Group

• Authentication Header (AH)
• Why do identity verification and passwordless authentication need to work together?
• Why do authentication controls fail when users work around them?
• How should teams use AI agents for authentication work without creating security debt?