Host Identity Protocol (HIP) Rendezvous Extension
obsoletes
- rfc-5204 — Host Identity Protocol (HIP) Rendezvous Extension
Extracted elements (25)
Rendezvous servers (RVS) are introduced to improve reachability for mobile or multihomed HIP nodes. A HIP node registers its HIT-to-IP mappings with an RVS, and peers can initiate a base exchange using the RVS's IP address instead of the node's current (possibly unknown) IP address.
The RVS_HMAC parameter has a different type code than the standard HMAC so that it is positioned after the FROM parameter in the HIP packet. This ordering ensures the FROM parameter is covered by the HMAC integrity check while still allowing the Responder to validate the I1 checksum without parsing FROM parameters.
The RVS only relays I1 packets in the base exchange; subsequent packets (I2, R1, R2) are sent directly between Initiator and Responder without further RVS involvement. This specification does not address scenarios where a client initiates a base exchange through its own RVS (e.g., for NAT/firewall traversal).
A rendezvous client acting as Responder SHOULD drop opportunistic I1s (NULL destination HIT) that include a FROM parameter, as this indicates the I1 was relayed via an RVS.
After receiving a relayed I1 packet, the Responder MUST append a VIA_RVS parameter to the R1 packet containing the IP address of the RVS that relayed the I1, primarily to allow operators to diagnose issues in RVS-assisted HIP exchanges.
After rewriting IP header fields, the RVS MUST recompute the IP checksum using the updated HIP header and a pseudo-header containing the updated source and destination IP addresses.
An Initiator SHOULD NOT send an opportunistic I1 with a NULL destination HIT to an IP address known to be a rendezvous server, unless it wants to establish a HIP association with the RVS itself.
An RVS MUST add a FROM parameter when it rewrites the source IP address. If one or more FROM parameters are already present, the new FROM parameter MUST be appended after the existing ones, and an RVS_HMAC MUST be inserted to protect the packet.
An RVS that receives an I1 packet whose destination HIT is not its own MUST check its current registrations to determine if it needs to relay the packet to the registered IP address.
Because ingress filtering may be present on the path from RVS to client, a HIP RVS SHOULD replace the source IP address of the I1 with one of its own IP addresses, and MUST then append a FROM parameter containing the original source IP address.
Both the rendezvous client and the RVS SHOULD protect packets with an RVS_HMAC, and the RVS_HMAC MUST be present when a FROM parameter is processed.
The FROM parameter added by the RVS MUST be integrity-protected by an RVS_HMAC keyed with the corresponding rendezvous registration integrity key.
When a HIP node has registered with an RVS, it SHOULD record the IP address of its RVS in its DNS record using the HIP DNS resource record type defined in RFC 8005.
When a rendezvous client receives an I1, it MUST validate any present RVS_HMAC. If verification fails and a FROM parameter is present, the packet MUST be dropped; if no FROM parameter is present, the packet SHOULD be dropped.
When a Responder replies to a relayed I1, it MUST append a VIA_RVS parameter to the R1 containing the IP addresses of the traversed RVSs.
When an R1 is replying to a relayed I1, the check that a system has sent an I1 to the R1's originator (state I1-SENT check) SHOULD be based on HITs only; if IP addresses are also checked, the source IP address MUST be checked against the IP address in the VIA_RVS parameter.
When an RVS receives an I1 whose destination HIT is not its own, it consults its registration database; if a matching registration is found it relays the packet, otherwise it drops the packet.
When an RVS rewrites the source IP address of an I1 due to egress filtering, it MUST add a FROM parameter containing the Initiator's source IP address, protected by an RVS_HMAC keyed with the integrity key from rendezvous registration.
The RVS_HMAC parameter (type 65500, variable length) is identical to the HIP HMAC parameter except for its type code, which positions it after the FROM parameter. It is keyed with the HIP-lg or HIP-gl integrity key established at rendezvous registration.
The RENDEZVOUS registration type (value 1) is defined in the 'Registration Types' subregistry under 'Host Identity Protocol (HIP) Parameters', originally reserved by RFC 5204 and now updated to reference this document.
Three HIP parameter types are reserved in the 'Parameter Types' subregistry under 'Host Identity Protocol (HIP) Parameters': FROM (65498, length 16), RVS_HMAC (65500, variable), and VIA_RVS (65502, variable), originally defined by RFC 5204 and now referencing this document.
Opportunistic Initiators (those without prior knowledge of the Responder's host identity) cannot authenticate public keys exchanged via an RVS, making MITM defense nearly impossible. For this reason, the specification explicitly does not support opportunistic HIP association establishment via an RVS.
RVS extensions may enable redirection, amplification, and reflection attacks at the IP layer, as well as man-in-the-middle attacks against the HIP base exchange at the HIP layer. If the Initiator has prior knowledge of the Responder's host identity, signature verification during the base exchange mitigates MITM attacks.
The FROM parameter (type 65498, length 16) carries an IPv6 address or an IPv4-in-IPv6 format IPv4 address representing the original source IP address of the relayed HIP packet.
The VIA_RVS parameter (type 65502, variable length) contains one or more IPv6 or IPv4-in-IPv6 addresses of the rendezvous servers that relayed the I1 packet. It is appended to R1 packets for diagnostic purposes.