Summary

  • RFC 5204 uses a rendezvous server as an initial contact point: it looks up a responder's HIT, rewrites and relays I1, then leaves the remaining base exchange to the two peers.
  • A current registration and valid RVS_HMAC authenticate the client-to-RVS relay context. They do not prove that the stored locator is live, the responder received I1, R1 returned, the HIP association completed or an application worked.
  • Operations should preserve the chain from DNS and registration epoch through exact relay transformation, responder receipt, direct return, I2/R2, protected data and observed service outcome.

The green light belonged to the relay

Imagine a mobility dashboard that reports a host as reachable. Its evidence is precise: DNS named a rendezvous server, that RVS found the requested Host Identity Tag in its registration table, rewrote an I1 packet, protected the original source address and transmitted the result toward the registered IP address. Every check at the RVS is green.

The host moved thirty seconds earlier. Its registration update has not arrived. No responder received I1, no R1 came back and no application session exists.

This is a constructed scenario, not a reported incident. It exposes the authority problem in a familiar operational word. “Reachable” sounds like an end-to-end fact. The evidence described only a successful decision and send event at an initial-contact intermediary.

RFC 5204 supplies a disciplined mechanism for that intermediary. A mobile or multihomed HIP node registers a mapping from its HIT to a current IP address with a rendezvous server. Another node can discover the RVS through the responder's HIP DNS information and send the first HIP base-exchange packet, I1, to the RVS. The server checks whether the destination HIT has an appropriate registration and, if so, relays the packet to the registered locator.

That improves the chance of contact. The word “improves” matters. The RVS does not become the responder, and the stored address does not become a live observation merely because it remains inside a valid registration lifetime.

The route changes after the first packet

RFC 5204's diagram is an antidote to vague architecture descriptions. I1 travels from initiator to RVS to responder. R1 travels directly from responder to initiator. I2 and R2 are also direct. After the initial relay, the base exchange should complete without further RVS assistance.

This produces at least four distinct path claims:

  1. the initiator could send to the RVS;
  2. the RVS selected a registered locator and sent I1 toward it;
  3. the responder could return R1 directly to the initiator;
  4. both peers could exchange the remaining messages and later data.

One cannot be substituted for another. A successful first path says nothing conclusive about the reverse path. A packet leaving the RVS says nothing conclusive about delivery at the responder. An R1 visible at the initiator still does not prove that I2 and R2 completed. Even a completed HIP association does not by itself prove that the intended application exchanged useful data.

The specification also draws an explicit boundary around NAT and firewall traversal. It does not define a client initiating through its own RVS for those cases. A product that labels the RFC 5204 mechanism as a general relay service has silently enlarged the protocol's authority.

FROM preserves an address claim, not the whole path

Egress filtering can prevent the RVS from forwarding I1 with the initiator's source IP address intact. RFC 5204 therefore allows the RVS to replace that source address with one of its own. Because the rewrite would otherwise conceal the initiator's address, the RVS appends a FROM parameter carrying the original source.

That parameter must be protected by RVS_HMAC, using an integrity key established during rendezvous registration. If another RVS has already added a FROM, the next one appends rather than overwrites. The ordered values can therefore preserve a represented relay chain.

The HMAC has a specific authority. It lets the rendezvous client verify that a party holding the registration integrity key protected the packet and the inserted address within the RVS-client relationship. It does not turn the original address into a cryptographic Host Identity. It does not prove that the initiator controlled that address beyond the evidence available to the RVS. It does not attest every IP hop. It does not establish that the destination received the packet.

This is not a criticism of RVS_HMAC. It is the reason to retain it accurately. A narrow proof is useful when a dashboard does not inflate it into an end-to-end verdict.

The first HIP packet begins with deliberately limited protection

The RVS can modify I1 because that packet does not contain the HIP base exchange's end-to-end HMAC or signature parameters. It recomputes the relevant checksum after rewriting headers and adding rendezvous parameters. The responder later authenticates the exchange through the base protocol.

Operationally, that creates two security scopes. The registration-scoped integrity check protects the transformation between RVS and its client. The HIP base exchange authenticates the endpoints. A valid RVS check is not a successful endpoint authentication, just as endpoint authentication is not proof of the application's later result.

RFC 5204's security discussion treats the RVS as a sensitive control point. It considers redirection, amplification, reflection and attacks on the HIP exchange. These risks are another reason not to convert “RVS accepted and relayed” into “peer authenticated.” A compromised or stale coordination plane can issue a mechanically valid action toward the wrong present location.

VIA_RVS is a diagnostic breadcrumb

When the responder sends R1 after receiving a relayed I1, it appends a VIA_RVS parameter naming the RVS address. The RFC describes the parameter's main purpose as helping operators diagnose establishment problems.

That is a modest but important semantic. A breadcrumb can say which intermediary was represented in the exchange. It cannot prove that the breadcrumb is a complete network trace. It cannot prove that every listed server behaved correctly. Its appearance in R1 is evidence that a responder constructed a reply under the specified processing path, but the initiator still needs to receive and validate that R1.

Observability systems often turn diagnostic context into success state because the context is easy to index. The safer model keeps VIA_RVS present, R1 received, R1 validated, I2 sent, R2 received, association established and application outcome observed as separate fields.

A registration has an epoch, not eternal truth

The RVS consults its current registration database. That phrase can be misread. “Current” describes the server's accepted state, not a live measurement of the host at query time.

A registration has a creation or renewal event, a lifetime, a set of locators and a last accepted update. Between the host's movement and the server's next accepted update, the database can be internally consistent yet externally stale. A packet can also fail after lookup because of routing, filtering, congestion, interface state or responder policy.

DNS adds another layer. Publishing an RVS address gives an initiator a place to try. DNS data has its own signer, resolver path, cache state and TTL. It does not prove that the RVS presently holds the requested HIT, that its registration points to a usable locator or that the responder consents to a new association.

The minimum defensible record therefore binds both epochs: the DNS evidence used to choose the RVS and the registration evidence used to choose the client locator. A bare address loses the time and authority of each decision.

Obsolescence is part of the evidence

RFC 5204 is an Experimental RFC from 2008 and was obsoleted by RFC 8004. The later specification retains the initial-contact idea while updating the HIP suite around it. An inventory that says only “supports HIP rendezvous” omits which protocol generation and processing rules were implemented.

Obsolescence does not prove that an old implementation is deployed, vulnerable or failing. Nor does a reference to RFC 8004 prove that running code migrated. Those are separate implementation and operations facts.

This is where lifecycle evidence matters. A useful receipt records protocol version, enabled registration types, parameter processing, algorithm suite, policy and observed behavior. A standards citation is a design reference. It is not a deployment attestation.

The compact receipt is a chain of refusals

A reliable system does not need to narrate every packet in prose. It needs enough structure to refuse false equivalence:

  • DNS RVS record, signer or trust basis, resolver time and cache epoch;
  • destination HIT and the exact I1 fingerprint received at the RVS;
  • rendezvous registration ID, client HIT, accepted locators, lifetime and last update;
  • lookup result and policy decision;
  • original and rewritten IP headers;
  • ordered FROM values and RVS_HMAC verification context;
  • relay transmission time and interface;
  • independent responder-receive evidence;
  • R1 fingerprint, VIA_RVS, initiator receipt and validation;
  • I2/R2 completion and negotiated HIP state;
  • protected data-plane observation;
  • application-specific success or failure.

Each field denies one shortcut. The server selected a locator; it did not observe the peer there. The responder replied; the initiator may not have received it. The association completed; the application may still have failed. The format is not bureaucracy added to a simple green light. It is what makes the green light honest.

Sources