Summary

  • RFC 2410 standardized the identity function as ESP's NULL encryption transform, with a zero-bit key and zero-bit IV. It made “no confidentiality” an explicit endpoint agreement rather than an omission or private convention.
  • ENCR_NULL did not mean no security: ESP could pair it with a strong integrity/authentication algorithm, and later ESP rules prohibited encryption and integrity from both being NULL. Nor did an ordinary ESP packet deterministically advertise this choice to intermediaries.

The test vector in RFC 2410 is almost insulting in its simplicity. Feed the algorithm a string. Receive the same string. The authors wrap the specification in a story about Roman cryptographers and missing zeroes, but the mathematics is exact: NULL(b) = I(b) = b.

Nothing was concealed. That was the point.

In the 1998 IPsec family, ESP had independent places for confidentiality and authentication. Operators might want data-origin authentication, connectionless integrity and replay protection without encrypting the payload. The protocol needed a way to express that choice through the same negotiation machinery used for other transforms. Silence would be ambiguous. A named no-op was interoperable.

RFC 2410 therefore specified more than the phrase “do not encrypt.” It fixed the key size at zero bits for IKE extraction, fixed the IV size at zero bits, described the transform as stateless and gave it a one-byte block size. ESP padding could still appear, but the algorithm itself required no padding or synchronization state. Independent implementations could arrive at the same packet layout without inventing a private absence convention.

This is minimum specification in a particularly pure form. The common layer said exactly what had to be common: the identity transform and its operational parameters. It did not decide whether a particular network should prefer confidentiality, whether an intermediary might inspect traffic, or whether an application would accept a packet. Those remained later, local decisions.

The distinction begins with the word “encryption.” NULL was registered as an encryption transform because that was the slot it occupied in ESP and IKE negotiation. The label did not grant confidentiality. RFC 2410 states the opposite: the transform itself offers no confidentiality and no other security service.

That did not make ESP_NULL equivalent to raw IP. Pair it with a strong authentication algorithm and ESP could protect data origin and integrity while leaving content visible. The 1998 specification compared this use with AH, while noting a different coverage boundary: ESP_NULL authentication did not include the IP header portions that AH covered.

The comparison was scoped. It did not say the protocols produced identical packets, traversed every network identically or satisfied every policy. It said that, using the same authentication algorithm, ESP_NULL need not be cryptographically weaker merely because confidentiality was absent. The security claim belonged to the selected integrity mechanism, not to NULL.

That separation prevented one dangerous configuration. RFC 2406 required an ESP Security Association to select at least one cryptographically strong encryption or authentication algorithm. RFC 4303 preserved the invariant in clearer terms: confidentiality and integrity might each be optional in defined circumstances, but they must not both be NULL.

An audit record that says only ENCR_NULL is therefore incomplete. It proves which confidentiality transform was selected if the record is authentic and attached to the right SA. It does not reveal the integrity algorithm, replay policy, key provenance, selector authorization or installation result. “No encryption” can coexist with strong integrity, weak integrity, misconfiguration or no active SA at all. The remaining fields decide which reality exists.

The number 11 illustrates the same boundary. The IKEv1/IPsec DOI registry assigned transform identifier 11 to ESP_NULL. The current IKEv2 transform registry also lists ENCR_NULL at 11 for ESP, while saying it is not allowed for protecting IKEv2 itself. A number without its registry, transform type and protocol context is not a security statement.

Registry state is vocabulary, not runtime evidence. It tells implementations what a proposal value means. It does not show that two peers offered it, selected it, installed it or processed traffic with it. RFC 9395 later deprecated IKEv1 and closed the old ISAKMP registries, yet it did not list ENCR_NULL among the obsolete encryption algorithms it deprecated. The integrity-only ESP mechanism continued in later ESP guidance.

RFC 8221 made ENCR_NULL mandatory to implement for ESP so implementations could interoperate in authenticated-only mode, especially where ESP's behavior with NAT made it preferable to AH. Mandatory to implement was not mandatory to deploy. The specification preserved a common capability; the operator still decided whether a given policy permitted its use.

That local choice is where downgrade analysis must begin. Seeing ENCR_NULL does not by itself prove an attack. If the policy intentionally selected integrity-only ESP, the transform is working as designed. If a proposal or configuration was supposed to require confidentiality and an implementation accepted NULL instead, the evidence may show an unauthorized downgrade. The same transform identifier supports both stories; only policy, transcript and state decide between them.

The endpoints could know the choice from their Security Association state. A middlebox had a different epistemic position. Ordinary ESP did not put a simple public flag in each packet saying “this payload is encrypted” or “this payload uses NULL.” The SPI selected state at the endpoint, but an unrelated observer did not necessarily possess that state.

This became an operational issue as security appliances wanted to distinguish encrypted ESP from integrity-only ESP. If the payload was ESP_NULL, an enterprise might want to perform malware scanning or access control. If it was encrypted, the same bytes would not expose transport or application structure. Guessing wrong could bypass inspection or parse ciphertext as plaintext.

RFC 5840 was written because ordinary ESP offered no deterministic packet-visible distinction. WESP added a wrapper that could explicitly signal whether confidentiality was in use and support inspection of integrity-only traffic. The existence of that later protocol is historical evidence of a missing observation surface, not evidence that every deployment adopted it.

RFC 5879 took another path. It documented heuristics for detecting ESP-NULL packets without changing existing endpoints. The word “heuristic” matters. The method tried plausible inner-protocol structures and validation rules. Its result was inference, not authenticated disclosure from the SA owner.

The document also narrowed the administrative setting. Deep inspection without confidentiality was most plausible in a controlled enterprise domain whose policy forbade peers from evading checks by choosing encrypted ESP. An observer could not turn mere access to bytes into authority. The network needed a policy relationship with the endpoints, and that relationship still needed enforcement.

Visibility and permission are separate receipts. A WESP indication could make classification deterministic without deciding whether this observer was entitled to read the payload. A heuristic could find plausible plaintext without establishing consent, purpose limitation or retention rules. Conversely, a valid inspection policy did not make an encrypted packet intelligible.

This is where the history departs from the easy phrase “ESP means encryption.” ESP is a security-service framework, not a promise that every service is active. RFC 4303 explicitly required integrity-only ESP to remain configurable and negotiable. The on-wire protocol number described the envelope. The installed SA described the selected algorithms. Neither fact alone described the whole policy.

The separation also protects incident analysis. Suppose an appliance reports that a flow is ESP_NULL. The first question is how it knows. Was the claim derived from authenticated endpoint state, a negotiated WESP marker, an RFC 5879-style heuristic or a product guess? Those evidence classes have different failure modes.

Next ask which SA the observation belongs to. The SPI and destination help locate state, but state can be stale, rekeyed or direction-specific. Inbound and outbound SAs are separate. A configuration database may show intended policy while the kernel holds a different transform after partial update or failed installation.

Then ask what integrity protected the packet. NULL contributes nothing. A successful integrity check under an authorized key can support claims about data origin and modification within the algorithm's coverage. A displayed transform name cannot. If integrity is absent too, the configuration violates the core ESP invariant rather than creating a harmless “transparent” mode.

Replay handling is another receipt. Sequence numbers can support anti-replay, but receiver state and policy decide whether checks are enabled and whether a packet falls inside the window. A readable payload is not evidence that the receiver accepted its sequence or delivered it upward.

Finally ask what happened after IPsec. Integrity verification does not prove that a firewall permitted the inner flow, that a transport endpoint accepted it or that an application committed a result. Those are later decisions by different components. The phrase “authenticated traffic” must stop at the boundary its evidence supports.

Lu Heng's reality-layer argument gives the history a disciplined vocabulary. The RFC and registry occupy the symbolic layer: they define a shared meaning. The negotiated proposal occupies the agreement layer. The installed SA occupies the running-code layer. A packet check occupies the observation layer. Inspection policy occupies the authority layer. Application processing occupies the outcome layer.

Confusion begins when one layer borrows another's mandate. The registry number does not create an SA. The SA does not publicly announce itself to every observer. Visibility does not authorize inspection. Integrity does not prove confidentiality. Inspection does not prove application acceptance.

The agency problem is equally concrete. Standards authors specify transforms. IKE implementations negotiate. Kernel teams install SAs. Security operations set policy. Middlebox vendors classify traffic. Compliance teams define inspection authority. Application owners judge success. A single green icon called “IPsec protected” lets one agent speak for all the others without holding their evidence.

Running-code primacy is not an argument against the standard. It is the correct way to honor the standard's restraint. Preserve the proposal and selection transcript, the policy revision, the inbound and outbound SA records, integrity algorithm and key provenance, replay state, packet counters, observer classification method, inspection authorization and application result. Let each record make only the claim it can verify.

The history continued because no single layer became omniscient. RFC 4835 and RFC 8221 updated algorithm requirements without rewriting ESP. RFC 5840 supplied an explicit visibility option. RFC 5879 documented a transition technique for observers that lacked it. RFC 6071 mapped those documents without pretending they were universally deployed.

RFC 2410's joke survived because the design was serious. It standardized nothing as something: a deterministic transform whose output equaled its input. That made endpoint agreement precise. It did not make the packet confess that agreement to strangers.

Sources