Summary

  • RFC 5202, and its Standards Track successor RFC 7402, deliberately leave HIP ESP rekey information readable because intermediary systems may need the new SPI values. HMAC and signature protect integrity and provenance; they do not provide confidentiality.
  • Operators should separate four statements: payload encrypted, control message authenticated, rekey metadata observable, and retained mapping deleted. No one statement proves the other three.

The visible seam in an encrypted system

ESP creates an attractive shorthand. Application content is encrypted, so a product panel labels the connection private. Yet every working encrypted system retains coordinates that let a receiver find state, reject replay and move packets. RFC 4303 puts the Security Parameters Index and Sequence Number ahead of the encrypted payload. They receive integrity protection, but they are not encrypted.

HIP gives the SPI more work. RFC 5202 says it is a compressed representation of a pair of Host Identity Tags. An intermediary may use it for address mapping. The exact coordinate is bounded: destination address plus SPI identifies the receiver-side HIT context at a particular time. The same numeric SPI can occur at other hosts, and a destination/SPI pair can mean something else later.

That precision prevents two equal errors. The SPI is not harmless noise; it is operationally meaningful. It is also not a permanent global identity, a person, an encryption key or proof that an application accepted traffic.

Why the UPDATE remains readable

During a HIP ESP rekey, ESP_INFO communicates the old SPI, the new SPI and a key-material index. The initiating UPDATE also carries sequence state, an optional Diffie–Hellman value, HMAC and HIP signature. The response carries its own sequence and acknowledgement state along with another ESP_INFO.

RFC 5202 states the trade directly. Intermediate systems that use the SPI have to inspect the HIP packets carrying rekey information. The packet is signed for their benefit. Because they may need the new SPI values, the contents cannot be encrypted. RFC 7402 repeats the same language after the experiment became a Standards Track specification.

This is not a cryptographic accident. Readability is part of the deployed function. The signature helps a device trust the transition it is reading. It does not place an opaque envelope around the transition. Indeed, authentication can make visible metadata more useful because the consumer can distinguish an authorized mapping update from unauthenticated noise.

The correct control statement is therefore narrow: the UPDATE is protected against undetected modification under the named association and algorithms. It is not: nobody on path can observe the rekey coordinate.

What an observer may infer

RFC 6973 defines traffic analysis as inference from presence, direction, timing, size, composition or frequency, even when flows are encrypted. A rekey UPDATE gives that analysis a structured event. The HIP header supplies endpoint identity tags; ESP_INFO supplies an old-to-new selector transition; network headers supply locators and time.

A HIP-aware firewall or NAT with association context can use this information as designed. RFC 9063 says such middleboxes may passively observe on-path traffic and keep soft state between control and data planes. A more generic sensor may still correlate the visible transition with the ESP packets that follow.

The inference must not be inflated. These facts do not show that every observer knows the natural person or organization behind a HIT. They do not show that one SPI remains meaningful after an address change or timeout. They do not reveal encrypted payload content. They do show that “encrypted traffic” is not the same claim as “unobservable relationship change.”

Rotation creates a coordinate; it does not erase a record

Both versions recommend random SPI selection, a different SPI for each exchange with a peer, and a mandatory SPI change on rekey. Those rules reduce reuse and replay risk. They do not make the current change invisible.

Once a capture or middlebox table records old SPI → new SPI beside a HIT pair and locator pair, later randomness cannot reach backward and delete that record. Retention decides whether a momentary operational coordinate becomes a durable history. Export to a SIEM, flow collector or support bundle may lengthen that history far beyond the middlebox soft-state timer.

HIP's current architecture separately recommends rotating unpublished Host Identities to disrupt linkability or trackability. That endpoint policy is useful, but it is not a deletion policy for every intermediary that saw earlier state. Identity rotation, SPI rotation and evidence retention are three different control surfaces.

Build a disclosure ledger

An operator should be able to answer five questions for every component that consumes ESP_INFO:

Question Evidence
What was visible? Exact HIP header and ESP_INFO fields parsed
Why was it needed? Address-mapping, firewall or diagnostic purpose
Who could read it? Device role, administrator role and export destination
How long did it persist? Soft-state timeout, capture retention and downstream retention
How was removal proved? Table expiry, log deletion and export tombstone or audit

The event receipt should record observation point, direction, locators, protected HIT reference, old and new SPI, UPDATE sequence/ack coordinate, verification outcome, rule version, mapping expiry and deletion result. If policy permits raw HIT storage, say so. If it substitutes a protected reference, preserve enough correlation for incident response without manufacturing indefinite identity.

This ledger should not report new-SA installation merely because the control packet was readable. Endpoint Security Association state, first authenticated packet on the new SPI, last packet on the old SPI and old-state deletion need their own receipts. RFC 5202's migration sequence is operational evidence, not permission to collapse control observation into data-plane success.

Read the historical boundary correctly

RFC 5202 was Experimental in 2008 and is obsolete. Its held erratum changes one editorial use of “transport” to “transform”; it does not touch the visibility rule. RFC 7402 replaced it in 2015, uses HIPv2 and sits on the Standards Track. The fact that the successor retained the inspectable signed UPDATE is what makes the lesson current.

RFC 6538 and RFC 9063 also show the wider tension. HIP can improve endpoint authentication and support privacy-oriented identity practices, while a middlebox may still require control-plane participation or passive state. There is no contradiction if the claims remain at their proper layers. There is a serious governance failure when one green encrypted badge is allowed to speak for all of them.

The decision for leadership

Approve separate service claims for payload confidentiality, control-message authenticity, metadata visibility and retention. Require every product and managed service to state which one it means. Fund deletion evidence with the same seriousness as signature verification.

The minimum common protocol may expose a mapping needed for interoperability. That does not grant an unlimited secondary-use mandate. Local policy should name the consumer, purpose, fields, expiry and onward transfer. Running code decides what exists; the inventory and audit decide whether that existence remains justified.

Sources

  1. RFC 5202 HTML
  2. RFC 5202 text
  3. RFC 5202 information page
  4. IETF Datatracker: RFC 5202
  5. RFC 5202 history
  6. RFC 5202 references
  7. RFC 5202 errata
  8. RFC 7402 HTML
  9. RFC 7402 text
  10. RFC 7402 information page
  11. IETF Datatracker: RFC 7402
  12. RFC 7402 history
  13. RFC 7402 references
  14. RFC 7402 errata
  15. RFC 4303 — ESP
  16. RFC 4301 — IPsec architecture
  17. RFC 9063 — HIP architecture
  18. RFC 6538 — HIP experiment report
  19. RFC 6973 — privacy considerations
  20. Heng Lu — reality layers and symbolic power
  21. Heng Lu — minimum initial specification
  22. Heng Lu — running-code primacy