Summary

  • RFC 5207 separates HIP control traffic from the ESP data phase; success in the base exchange is not evidence that the later protected flow has a usable forward and return path.
  • A NAT or firewall may see an outgoing SPI, learn negotiated values or install one rule, yet one-way SPI semantics, collisions, topology changes and default-deny policy can still break the reverse direction.
  • A defensible healthy-session verdict binds exact handshake packets, both-direction middlebox state, actual ESP observations, endpoint decrypt results and the application outcome.

Four packets made the dashboard green

Consider a branch host that begins a HIP session from inside a protected network. Its initial exchange is carried through UDP, the firewall observes the control messages, and both endpoints complete the base exchange. The monitoring system sees the expected four-message sequence and declares the peer secure and reachable.

Then multihoming changes the return locator. Protected data leaves through the first border, but return ESP arrives through another firewall that never learned the state. The packets disappear at that boundary. No application transaction completes.

This is a constructed scenario, not a reported incident. It isolates an authority error. The handshake can speak for endpoint authentication under a particular protocol exchange. It cannot speak for every middlebox on a later path, for bidirectional ESP delivery or for the service built above it.

RFC 5207 was written precisely because the clean Internet model was already incomplete. HIP was designed so ordinary routers did not need modification. NATs and firewalls were not ordinary routers: they inspected, translated, filtered and sometimes inserted state. The RFC therefore divided the problem into HIP control traffic and ESP data traffic. That division should remain visible in operational records.

Phase one and phase two ask different questions

HIP first runs a base exchange. Only after that exchange does it use ESP to carry application data. The two phases do not present the same fields to a middlebox.

For the original IPv4 design, HIP control packets used a distinct IP payload type rather than a familiar transport with ports. A basic address-only NAT could rewrite the outer IP header and pass the packet. A NAPT that depended on port numbers had no ordinary demultiplexing key. An inbound exchange also lacked the translation state normally created by an inside host's earlier packet.

IPv6 changed the packet form but not the evidence problem. HIP information in extension headers could encounter filters that rejected unknown headers or nonstandard payloads. A firewall configured to allow only recognized transports could block a valid endpoint exchange without making either endpoint incapable of HIP.

Once the base exchange completes, the question changes. ESP hides the upper-layer ports and payload that NATs and firewalls often use to recognize a flow. A device that understood or permitted phase one may still have no rule for phase two. “Handshake complete” and “protected data admitted” belong in different fields because they are decisions made from different observations.

One SPI is not a pair

The Security Parameter Index looks tempting as a replacement for a transport port. A middlebox can observe an outgoing ESP SPI and use it as part of a flow key. RFC 5207, drawing on the IPsec NAT analysis, stresses the limitation: an SPI has one-way significance.

The value on packets sent from A to B does not reveal the value chosen for packets from B to A. Seeing one therefore does not construct the return mapping. Multiple nodes behind the same NAT can also choose identical SPI values. Rewriting an SPI may resolve a local collision, but it creates another transformation whose direction, owner and lifetime must be recorded.

This is a useful example of a field carrying less authority than its visual precision suggests. A 32-bit number can identify a Security Association in the context that interprets it. It is not a global session identifier. It does not name an application. It does not prove the peer received a packet. It does not prove the corresponding reverse association exists.

An operator should retain at least two directed records: outbound SPI and inbound SPI, each tied to endpoint identities, addresses, observed boundary, rule version and time. If the path is asymmetric, the records may belong to different devices. Treating them as a single undirected “HIP session” erases the exact condition the network must satisfy.

Learning during the exchange is still a local act

RFC 5207 discusses an architectured NAT, or SPINAT, that observes the HIP base exchange and learns the SPI values negotiated by the peers. A firewall can apply a similar method. This is stronger than guessing from later ESP packets because the control exchange can expose both directions.

Yet “learned” is not “installed everywhere.” The middlebox needs HIP-specific parsing. It must associate the values with the right identities and addresses. Its policy must permit the requested state. The rule must survive long enough. Later packets must traverse that same enforcement point. In a multihomed network, a different border can see the data path from the one that saw the exchange.

The receipt therefore needs a device-level result: which box parsed which exchange, what state it proposed, whether policy accepted it, the exact match installed, its lifetime and whether packets later hit it. A controller's successful response is evidence about the controller. Only a dataplane observation shows that the rule affected the intended traffic.

Explicit signaling moves the uncertainty

Another approach is for endpoints to signal the required SPI values through a generic NAT or firewall control protocol. RFC 5207 mentions MIDCOM and the path-coupled NATFW NSLP work. Signaling can avoid teaching every device the full HIP exchange, but it does not remove the evidence chain.

The sender must know which middlebox controls the relevant path. RFC 5207 identifies this as a problem in multihomed environments with different borders. A request delivered to the wrong firewall can be authenticated, authorized and accepted while remaining irrelevant to the actual ESP path.

Path-coupled signaling narrows that risk by following the data route, but routes can change after signaling. A proxy can expand deployment reach, but it also introduces another principal whose authority must be bounded. The proper status is not signaling succeeded. It is a set of per-device records: request received, principal authenticated, policy decision, state installed, expiry, path still applicable and packets observed.

Opening a pinhole is security-sensitive. A system that automatically widens access from a handshake must record why the new traffic is authorized, not merely that protocol syntax was valid. Authentication of the peers, authorization for this network boundary and current operational need are related but separate claims.

UDP can rescue the first phase and expose the second

Legacy NAPTs know UDP. Encapsulating HIP control traffic in UDP gives them ports and outbound-created state they can understand. That can let the base exchange succeed where native HIP packets would not.

RFC 5207 then makes the crucial refusal: even when UDP encapsulation enables the base exchange, ESP still causes problems. Some devices offered IPsec “VPN pass-through” by learning flows and correlating SPIs. The technique could fail as more hosts shared one NAT and SPI collisions became possible.

UDP encapsulation of ESP was therefore discussed as a better path, and later HIP documents developed traversal mechanisms using ICE and UDP. But a standards lineage is not a deployment receipt. A product that cites RFC 5770, RFC 9028 or the modern HIP architecture may still have the feature disabled, partially implemented, blocked by policy or bypassed on one path.

Version evidence must bind specification, implementation, configuration and observation. “Supports HIP NAT traversal” is too broad. A useful inventory names the exact mode, encapsulation, port, keepalive behavior, locator set, path and successful bidirectional data observation.

The green control plane can misdirect repair

When a dashboard compresses the base exchange and application session into one status, the first operational casualty is attribution. A security engineer sees a successful authentication and assumes the network is open. An application engineer sees no response and assumes the remote process is broken. A network engineer sees an outgoing SPI and assumes the return association was learned.

Each team can hold a true fragment and reach a false whole.

The usual repair is then too broad: disable inspection, open ESP from anywhere, pin traffic to one border or turn on a generic VPN helper. Those changes can restore traffic while hiding the missing evidence. They may also create a durable exception whose authority extends beyond the original peer and session.

A better incident timeline refuses that collapse. It records the base-exchange packet fingerprints at each boundary, both negotiated SPIs, each rule installation, the forward and return ESP observations, endpoint anti-replay and integrity results, decrypted data counters and the application transaction. The first absent receipt localizes the failure without inventing a culprit.

Obsolescence and evolution are not running state

RFC 5207 describes the problem space as understood in 2008. It is Informational and an IRTF product, not an Internet Standard. Later documents supplied experimental and modern traversal mechanisms. None of those publication facts says what is running on a particular host or middlebox today.

This boundary matters in procurement and audit. A conformance statement can name a protocol generation. A configuration export can show a mode enabled. A packet capture can show encapsulation. A device log can show state installation. An endpoint counter can show accepted ESP. An application receipt can show useful work. Those are six different authorities.

The doctrine of running-code primacy does not mean ignoring specifications. It means letting a specification define what evidence should be sought while refusing to substitute the document for the observed system. RFC 5207 is valuable because it names the split. Operations completes the proof.

The compact receipt follows the packet twice

A defensible record can remain compact if it follows both phases and both directions:

  • HIP version, traversal mode, implementation and configuration revision;
  • initiator and responder HITs, chosen locators and discovery epoch;
  • I1, R1, I2 and R2 fingerprints, times and observation points;
  • NAT mapping or firewall state created for the control exchange;
  • outbound and inbound SPI values with explicit direction;
  • signaling request, authenticated principal and per-device policy result;
  • installed match, owner, approval, lifetime and expiry;
  • base-exchange path and ESP forward/return path identifiers;
  • ESP observations before and after every relevant boundary;
  • endpoint integrity, anti-replay and decrypt results;
  • application transaction and outcome;
  • unresolved gaps stated as unknown.

The receipt is not a demand that one component know the entire Internet. It is a rule against allowing one component to claim more than it observed. The endpoint can report authentication. The firewall can report state. The path can report packet passage. The application can report outcome. Joining those receipts is what turns a green light into evidence.

Sources