When traffic needs IPsec integrity without encryption, why do current specifications prefer ESP with NULL encryption over AH, and what does that give up?
answer
- integrity-only, readable payload
- a MUST that exists for this
- translation on the path
- what the outer header loses
basics
~20 sESP with ENCR_NULL and an integrity transform authenticates the payload, crosses NAT and is mandatory to implement; AH is optional and fails behind NAT. The cost: no outer-header integrity, and nothing in the packet shows it is unencrypted.
solid answer
~40 sRFC 4301 makes ESP mandatory and AH optional precisely because ESP can provide integrity without confidentiality, and RFC 8221 keeps `ENCR_NULL` at MUST "to enable the use of ESP with only authentication, which is preferred over AH due to NAT traversal". Built correctly it pairs `ENCR_NULL` with a real integrity transform — RFC 8221 recommends `AUTH_HMAC_SHA2_256_128` — because `AUTH_NONE` cannot be combined with NULL encryption. Overhead is about the same as AH. What you give up is AH's coverage of the outer header: the addresses and, on IPv6, extension headers such as routing headers are not authenticated, a gap RFC 3715 notes. And because ESP carries no algorithm identifier, a monitoring device cannot tell from the packet that the payload is readable; it has to be told the SA's parameters or guess.
go deeper
Recall that ESP can authenticate without encrypting by using NULL encryption, so AH is not required for integrity-only traffic.
Explain which bytes ESP-NULL covers compared with AH, and why ENCR_NULL must be paired with a real integrity transform.
Choose ESP-NULL for integrity-only SAs, account for the outer-header gap with source-address checks, and plan how monitoring will learn the SA's transforms.
Decide whether a requirement for outer-header integrity is real enough to justify AH and a translation-free path, or is better met by policy.
## The requirement Some traffic must be tamper-evident and attributable but stay readable — for an inspection device on the path, or because confidentiality is handled elsewhere. IPsec offers two ways: **AH**, or **ESP with NULL encryption** (often written ESP-NULL). Current guidance points at the second. ## What each one authenticates | | AH | ESP with `ENCR_NULL` | |---|---|---| | IP protocol number | 51 | 50 | | Payload authenticated | yes | yes | | Immutable outer IP header fields (addresses, lengths, protocol) | yes | no | | IPv6 extension headers before the security header | immutable parts, yes | no | | SPI and sequence number authenticated | yes | yes | | Payload readable on the path | yes | yes | | Survives address translation | no | yes, with UDP encapsulation | | RFC 4301 implementation requirement | MAY | ESP is MUST | ## Why the specifications prefer ESP-NULL - **RFC 4301** downgraded AH to MAY because "there are very few contexts in which ESP cannot provide the requisite security services", noting that ESP can provide integrity only, "making it comparable to AH in most contexts". - **RFC 8221** keeps `ENCR_NULL` at **MUST** "to enable the use of ESP with only authentication, which is preferred over AH due to NAT traversal". AH signs the addresses a NAT rewrites; ESP does not. - **RFC 3948** defines UDP encapsulation for ESP and leaves AH out of scope, so only ESP has a NAT traversal path. - One protocol is simpler to operate: the same ESP stack, policy and troubleshooting serve encrypted and integrity-only SAs. ## Building it correctly 1. Encryption transform `ENCR_NULL`: no confidentiality, and no IV, since there is nothing to synchronise. 2. A real integrity transform. RFC 8221 recommends `AUTH_HMAC_SHA2_256_128` with `ENCR_NULL`, and `ENCR_NULL_AUTH_AES_GMAC` as the choice for AES-GMAC in ESP. `AUTH_NONE` is allowed only with AEAD ciphers and "cannot be combined with ESP NULL encryption" — ESP-NULL with no integrity protects nothing. 3. Overhead is close to AH's. With a 16-byte ICV, ESP-NULL adds SPI 4 + sequence number 4 + 0-3 padding bytes for 4-byte alignment + `Pad Length` 1 + `Next Header` 1 + ICV 16 = **26-29 bytes**. AH adds 12 fixed bytes + a 16-byte ICV = **28 bytes** on IPv4; on IPv6 its length must be a multiple of 8, so it pads to **32**. ## What the choice gives up - **Outer-header integrity.** ESP's ICV starts at its SPI. The source and destination addresses and the immutable fields AH would sign are not authenticated. RFC 3715 (Informational) points out that ESP with null encryption "does not provide the same security properties as AH" — IPv6 source-routing risks that AH precludes are not precluded by ESP-NULL. - **Source-address assurance.** No ESP transform protects against source-address spoofing in the outer header, so RFC 3715 stresses checking that a packet's source matches the address the SA was established with, where that check is meaningful. - **Self-describing packets.** The ESP header holds only the SPI and sequence number. Nothing in it says which encryption transform the SA uses, so an intrusion-detection system cannot tell from the packet alone whether the payload is plaintext; it must be given the SA's parameters or infer them heuristically. ## The defender's view The ESP-NULL integrity check still does its main job: a packet altered or forged on the path, without the SA's key, fails verification and is discarded, and the anti-replay window catches resent packets. What an operator trades away is a guarantee about the outer header, which most designs cover instead through the SA's address checks and the policy applied to the decrypted traffic. Where a design genuinely needs outer-header integrity and the path has no translation, AH remains a defined, current protocol (RFC 4302) — but that combination is rare enough that RFC 4301 made AH optional. ## A trap to avoid Combining ESP with an unauthenticated cipher and AH for integrity is not a substitute. RFC 8221 marks ESP plus AH NOT RECOMMENDED and warns that some configurations of ESP without authentication under AH have been shown insecure.
- Why may AUTH_NONE not be paired with ENCR_NULL in an ESP proposal?That SA would provide neither confidentiality nor integrity: packets would cross the network readable and alterable, with only a sequence number and an SPI. RFC 8221 allows `AUTH_NONE` only alongside an AEAD cipher, whose tag supplies integrity, and states that `AUTH_NONE` cannot be combined with ESP NULL encryption. An integrity-only SA therefore needs `ENCR_NULL` plus a real integrity transform such as `AUTH_HMAC_SHA2_256_128`.
- How can an inspection device on the path tell whether an ESP flow uses NULL encryption?Not from the ESP header, which carries only the SPI and sequence number; the transforms are SA state the two peers negotiated. The device has to be given the SA's parameters by an operator or key-management integration, or guess by trying to parse the payload as plaintext. That ambiguity is a real operating cost of choosing ESP-NULL for visibility.
saying these in an interview costs you the question
- ESP with NULL encryption and AH authenticate exactly the same bytes.
- ESP-NULL can be run with no integrity algorithm at all.
- An observer can read from the ESP header that the payload is not encrypted.
- AH is obsolete and no longer defined by any current RFC.
- AH is the only IPsec option when traffic must stay readable.