Summary

  • In RFC 5201 and its successor RFC 7401, the responder may choose a precomputed R1 after I1 and remain stateless. A valid R1 signature proves provenance at some time, not current liveness or a reservation for this initiator.
  • The evidence boundary advances in steps: valid I2 can cause responder state, verified R2 completes the HIP base exchange for the initiator, and a separate payload association plus observed traffic is needed to establish a usable data path.

A green response built from no session

HIP was designed to separate a host identifier from its changing IP locator. Its base exchange uses four packets. I1 triggers the exchange. R1 presents the responder's challenge, Diffie–Hellman material, choices and signature. I2 returns the puzzle solution and the initiator's authenticated contribution. R2 completes the exchange.

The tempting monitoring shortcut is to treat the first authenticated-looking answer as a session event. The protocol makes that interpretation unsafe by design. RFC 5201's exchange diagram says that the responder selects a precomputed R1 and remains stateless. RFC 7401 preserves the same property in HIPv2.

This is not a weakness accidentally leaking through the handshake. It is the denial-of-service defence. A responder facing forged I1 packets should not have to allocate association state, perform public-key verification or calculate a fresh Diffie–Hellman result for every trigger. It can send a prepared challenge and postpone expensive commitment until the initiator returns a valid I2.

The operational mistake begins when a telemetry system erases that purpose. R1 signature valid is a cryptographic observation. Responder alive for this probe, capacity reserved, peer admitted and secure service available are later claims. A single green state cannot honestly represent all five.

What the R1 signature actually dates

The R1 signature proves that the responder's Host Identity key generated the covered material. Both RFCs state the narrower consequence: the R1 was once generated by the responder. Because the response may be precomputed and does not cover association-specific information from I1, the signature does not by itself prevent replay.

That word “once” matters. It denies the monitoring system a hidden clock. A captured, still-acceptable R1 may be authentic without being evidence that the responder processed this I1 at the moment shown on the probe. Some fields are intentionally outside the signature so that the puzzle can be adjusted and prepared responses can be reused within their validity policy.

HIP supplies an R1 generation counter so an initiator can prefer a newer puzzle generation. The counter is useful replay discipline, but it is not synchronized wall time. HIPv2 discusses preservation, reset and rollover behavior, and deliberately omits a timestamp to avoid requiring global time synchronization. A generation coordinate cannot silently become an SLA timestamp.

For a defensible receipt, retain the responder HIT, R1 signature verification result, signature and hash algorithms, R1 generation counter, puzzle lifetime, difficulty and opaque value. Also retain the local receive time, but label it correctly: it is the time this observer received those bytes, not the time the responder created per-initiator state.

The puzzle proves expenditure, not entitlement

The puzzle makes the initiator search for a value whose hash with the challenge and both HITs has the required number of zero bits. Verification is cheap for the responder. Solving is deliberately more expensive for the initiator. This gives the responder a filter against spoofed or cheaply multiplied I2 traffic.

RFC 5201 uses “sincere” as shorthand for having churned CPU cycles. That term must not escape its protocol boundary. A valid solution proves work on a particular challenge construction. It does not prove that a human meant well, that an account is authorized, that billing passed, that an access policy admitted the host, or that capacity exists behind the responder.

Even the DoS conclusion is bounded. Both versions note that the HIT-bound puzzle frustrates one pattern in which an attacker reuses one exchange to forge many identities. It does not protect against every attacker using fixed HITs. An implementation may choose to retain local failure state, trading memory for computation. “Puzzle valid” is therefore neither a universal attack verdict nor a business-trust score.

The clean receipt separates the initiator's work from the responder's decision. Record the R1 challenge coordinate, the returned solution, the one-hash validation result and the policy that selected the difficulty. Then record whether the responder proceeded to signature verification, DH computation and HIP-association creation. Those are distinct effects.

I2 is where the responder can begin to commit

After receiving I2, the responder can verify the puzzle before doing expensive public-key or DH work. If the solution and signed initiator material pass, it derives shared keying material and creates the corresponding HIP association. This is a materially stronger observation than R1.

Still, it has a viewpoint. A responder-side log saying I2 accepted proves a state transition at the responder under a named implementation and policy. It does not prove that R2 reached the initiator. An initiator that verifies R2 obtains evidence that the responder possessed the shared result and completed its side of the base exchange. The two receipts should be correlated, not collapsed.

The order also explains why an alarm can disagree with a packet capture without either being corrupt. The capture may show an authentic R1. The responder may have created no session record because the I2 never arrived, expired, failed the puzzle or failed the signature. Searching a session database for an R1-only probe should legitimately return nothing.

An audit should therefore model at least four states: trigger observed; challenge authenticated; initiator work returned; base exchange completed. Handshake seen is too imprecise to be useful during an incident.

A HIP association is not the user-data path

The base exchange establishes HIP state and shared keying material. It does not, by itself, define the actual user-data transmission format. RFC 7401 says that separate specifications do so and requires implementations to support the ESP transport described by RFC 7402. After restart, its operational text says that a host can create a new payload association after the base exchange, then start sending data.

That sequence creates another evidence boundary. Verified R2 is not a receipt for installed ESP Security Associations on both peers. Installed SAs are not proof of bidirectional reachability. A protected outbound packet is not proof that the remote application received or accepted it. Each layer can fail while the previous one remains cryptographically correct.

For a path-readiness claim, collect the negotiated transport format, transform identifiers, SPI values or protected equivalents, installation outcomes on both endpoints, locator pair, policy version, key epoch and first authenticated packet in each direction. For service readiness, add an application acknowledgement that is safe to generate and specific to the intended service.

This follows the reality-layer discipline: the signature, protocol state, transport state and observed service effect are related, but they are not interchangeable symbols for one fact.

Build an evidence ladder, not a success flag

Receipt Narrow fact established Claim still unsupported
I1 transmit record The initiator emitted a trigger The responder received it
R1 signature verified Responder key generated the covered response material at some time Present liveness or per-initiator state
Puzzle solved Initiator performed the required work Responder acceptance or authorization
Responder accepted I2 Named validation and state-creation path succeeded Initiator received R2
Initiator verified R2 HIP base exchange completed from that endpoint's view Payload association or data delivery
Payload SA installed A named transport state exists Bidirectional application success
Protected request and response A bounded service effect occurred Continued availability or wider mandate

Every row needs the implementation version, local monotonic time, relevant protocol coordinate, policy identifier and failure reason. Cross-host wall times may assist correlation, but protocol order and cryptographic bindings should carry the causal claim.

This also prevents a false negative. Precomputed R1 behavior should not be flagged as evidence of compromise merely because the responder has no matching session record. The absence is expected until a valid I2 crosses the commitment boundary.

Read the historical document at its correct status

RFC 5201 was published in April 2008 as Experimental and explicitly says it is not an Internet Standard. Its IESG note identifies concerns including SHA-1, MAC agility, RSA choices and interaction with IP-address-based policy. RFC 6253 later added a certificate parameter.

RFC 7401 obsoleted it in April 2015, incorporated implementation experience and made HIPv2 a Proposed Standard with stronger negotiation and crypto agility. Later certificate and identifier work appears in RFC 8002 and RFC 9374. The article's lesson does not depend on treating the 2008 algorithm suite as current. The successor retains the precomputed-R1 and stateless-responder mechanics, so the provenance-versus-commitment boundary remains intentional.

The minimum useful specification for an operations console is therefore not “HIP success”. It is a state machine whose labels say what ran, what state was created, what peer evidence returned and what data effect was observed. Anything broader launders one layer into another.

Sources

  1. RFC 5201 HTML
  2. RFC 5201 text
  3. RFC 5201 information page
  4. IETF Datatracker: RFC 5201
  5. RFC 5201 history
  6. RFC 5201 references
  7. RFC 5201 errata
  8. RFC 7401 — HIPv2
  9. RFC 7401 text
  10. RFC 7401 information page
  11. RFC 7401 errata
  12. RFC 7402 — ESP transport for HIP
  13. RFC 4423 — HIP architecture
  14. RFC 4987 — TCP SYN flooding countermeasures
  15. RFC 6253 — HIP certificates
  16. RFC 8002 — HIPv2 certificates
  17. RFC 9374 — DRIP Entity Tag
  18. Heng Lu — reality layers and symbolic power
  19. Heng Lu — minimum initial specification
  20. Heng Lu — running-code primacy