RFC 8004
Host Identity Protocol (HIP) Rendezvous Extension
Host Identity Protocol (HIP) Rendezvous Extension 💖
Okay bestie, this is RFC 8004 🎀 It's a Standards Track doc from the IETF, published in October 2016 (ISSN 2070-1721). It was written by J. Laganier of Luminate Wireless, Inc. and L. Eggert of NetApp. It also obsoletes RFC 5204, so that's the older version it replaces 🦋
Abstract ✨
Okay so this doc defines a rendezvous extension for the Host Identity Protocol (HIP) 💅 It extends HIP and the HIP Registration Extension so HIP nodes can start talking to each other through HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multihomed or mobile, which is giving main character energy 🌸 This document obsoletes RFC 5204.
Status of This Memo 🌈
This is an Internet Standards Track document. It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 7841.
If you want the current status of this doc, any errata, or a way to send feedback, go to http://www.rfc-editor.org/info/rfc8004 🧚
Copyright Notice 💜
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the date of publication. Please actually read these, because they lay out your rights and restrictions for this document 👀 Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They're also provided without warranty, as described in the Simplified BSD License.
Table of Contents 🍓
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Rendezvous Server Operation . . . . . . . . . . . 3
3.1. Diagram Notation . . . . . . . . . . . . . . . . . . . . 5
3.2. Rendezvous Client Registration . . . . . . . . . . . . . 5
3.3. Relaying the Base Exchange . . . . . . . . . . . . . . . 6
4. Rendezvous Server Extensions . . . . . . . . . . . . . . . . 7
4.1. RENDEZVOUS Registration Type . . . . . . . . . . . . . . 7
4.2. Parameter Formats and Processing . . . . . . . . . . . . 7
4.2.1. RVS_HMAC Parameter . . . . . . . . . . . . . . . . . 7
4.2.2. FROM Parameter . . . . . . . . . . . . . . . . . . . 8
4.2.3. VIA_RVS Parameter . . . . . . . . . . . . . . . . . . 9
4.3. Modified Packets Processing . . . . . . . . . . . . . . . 9
4.3.1. Processing Outgoing I1 Packets . . . . . . . . . . . 9
4.3.2. Processing Incoming I1 Packets . . . . . . . . . . . 10
4.3.3. Processing Outgoing R1 Packets . . . . . . . . . . . 10
4.3.4. Processing Incoming R1 Packets . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Changes from RFC 5204 . . . . . . . . . . . . . . . 14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 141. Introduction 🦋
Okay so the HIP Architecture doc [HIP-ARCH] introduces the rendezvous mechanism to help a HIP node reach a HIP node that's always on the move 🏃♀️ The mechanism brings in a third party, the rendezvous server (RVS), which acts as an initial contact point ("rendezvous point") for its clients.
The clients of an RVS are HIP nodes that use the HIP Registration Extension [RFC8003] to register their HIT->IP address mappings with the RVS. Once that's done, other HIP nodes can start a base exchange using the RVS's IP address instead of the node's current IP address. So basically, the clients of an RVS become reachable at the RVS's IP address ✨ Peers start a HIP base exchange with the RVS's IP address, the RVS relays that first message, and the base exchange can finish successfully 💖
2. Terminology 🎀
This section defines the terms used through the rest of the spec 📖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
Besides the terminology from the HIP specification [RFC7401] and the HIP Registration Extension [RFC8003], this doc defines and uses these terms:
Rendezvous Service A HIP service that an RVS provides to its rendezvous clients 🌸 The RVS offers to relay some of the base exchange packets that arrive between the Initiator and the Responder.
Rendezvous Server (RVS) A HIP registrar that provides rendezvous service 🧚
Rendezvous Client A HIP requester that has registered for rendezvous service at an RVS 💅
Rendezvous Registration A HIP registration for rendezvous service, set up between an RVS and a rendezvous client ⭐
3. Overview of Rendezvous Server Operation 🌸
Figure 1 shows a plain HIP base exchange with no RVS. The Initiator starts things by sending an I1 packet straight to the Responder's IP address, as the HIP specification [RFC7401] says to do 🫶
+-----+ +-----+
| |-------I1------>| |
| I |<------R1-------| R |
| |-------I2------>| |
| |<------R2-------| |
+-----+ +-----+
Figure 1: HIP Base Exchange without a Rendezvous ServerThe End-Host Mobility and Multihoming with the HIP specification [HIP-HOST-MOB] lets a HIP node tell its peers when its set of IP addresses changes 🔥 This spec assumes the two nodes can already reach each other.
But a HIP node MAY also want to be reachable by future correspondent peers who don't know about its location change 👀 The HIP Architecture [HIP-ARCH] brings in RVSs, which a HIP node MAY register its Host Identity Tags (HITs) and current IP addresses with. An RVS relays HIP packets that arrive for those HITs to the node's registered IP addresses. Once 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 the HIP DNS Extension [RFC8005] 🦋
+-----+
+--I1--->| RVS |---I1--+
| +-----+ |
| v
+-----+ +-----+
| |<------R1-------| |
| I |-------I2------>| R |
| |<------R2-------| |
+-----+ +-----+
Figure 2: HIP Base Exchange with a Rendezvous ServerFigure 2 shows a HIP base exchange that goes through an RVS 🎀 Here we assume HIP node R already registered its HITs and current IP addresses with the RVS, using the HIP Registration Extension [RFC8003]. When the Initiator I wants to reach the Responder R, I has to send the I1 of the base exchange either to one of R's IP addresses (if it knows them via DNS or some other means) or to one of R's RVSs. In this case, I gets the IP address of R's RVS from R's DNS record and sends the I1 packet to the RVS 💖
The RVS notices that the HIT in the incoming I1 packet isn't one of its own, so it MUST check its current registrations to see whether it needs to relay the packet 👀 Here it finds that the HIT belongs to R, so it relays the I1 packet to the registered IP address. R then finishes the base exchange without any more help from the RVS, by sending an R1 straight to I's IP address (which it got from the I1 packet) ✨
In this spec, the client of the RVS is always the Responder. There might be reasons, though (like NAT and firewall traversal), to let a client start a base exchange through its own RVS. This spec doesn't cover those scenarios, which should be specified in other documents 🙈
3.1. Diagram Notation 📝
Notation Significance
-------- ------------
I, R I and R are the respective source and destination IP
addresses in the IP header.
HIT-I, HIT-R HIT-I and HIT-R are the Initiator's and the
Responder's HITs in the packet, respectively.
REG_REQ A REG_REQUEST parameter is present in the HIP header.
REG_RES A REG_RESPONSE parameter is present in the HIP header.
FROM:I A FROM parameter containing the IP address I is
present in the HIP header.
RVS_HMAC An RVS_HMAC parameter containing an Hashed Message
Authentication Code (HMAC) keyed with the appropriate
registration key is present in the HIP header.
VIA:RVS A VIA_RVS parameter containing the IP address RVS of
a rendezvous server is present in the HIP header.3.2. Rendezvous Client Registration 🦋
Before an RVS starts relaying HIP packets to a rendezvous client, the client needs to register with the RVS to get rendezvous service. It does this with the HIP Registration Extension [RFC8003], as shown in this schema 💅
+-----+ +-----+
| | I1 | |
| |--------------------------->| |
| |<---------------------------| |
| I | R1(REG_INFO) | RVS |
| | I2(REG_REQ) | |
| |--------------------------->| |
| |<---------------------------| |
| | R2(REG_RES) | |
+-----+ +-----+
Rendezvous Client Registering with a Rendezvous Server3.3. Relaying the Base Exchange
okay so this is where the RVS actually does its job, bestie 🧚 if a HIP node and one of its RVSs have a rendezvous registration, the RVS relays inbound I1 packets that carry one of the client's HITs. it does this by rewriting the IP header. it swaps the destination IP address for one of the IP addresses of the HIT owner, i.e., the rendezvous client 💖 and it MUST also recompute the IP checksum accordingly. no skipping that, periodt 💅
because of ingress filtering on the path from the RVS to the client [RFC2827] [RFC3013] 🌸, a HIP RVS SHOULD replace the source IP address (the IP address of I) with one of its own IP addresses. the replacement SHOULD be chosen according to the relevant IPv4 and IPv6 specifications [RFC1122] [RFC6724]. this is the part that's lowkey sneaky: because the replacement conceals the Initiator's IP address, the RVS MUST append a FROM parameter containing the original source IP address of the packet 🕵️♀️ and this FROM parameter MUST be integrity protected by an RVS_HMAC keyed with the corresponding rendezvous registration integrity key [RFC8003] 🔐
I1(RVS, R, HIT-I, HIT-R
I1(I, RVS, HIT-I, HIT-R) +---------+ FROM:I, RVS_HMAC)
+----------------------->| |--------------------+
| | RVS | |
| | | |
| +---------+ |
| V
+-----+ R1(R, I, HIT-R, HIT-I, VIA:RVS) +-----+
| |<---------------------------------------------| |
| | | |
| I | I2(I, R, HIT-I, HIT-R) | R |
| |--------------------------------------------->| |
| |<---------------------------------------------| |
+-----+ R2(R, I, HIT-R, HIT-I) +-----+
Rendezvous Server Rewriting IP Addressesngl this rewriting can be kinda risky because HIP uses integrity checks 👀 but the I1 doesn't include HMAC or SIGNATURE parameters, so these two end-to-end integrity checks are unaffected by what the RVS does 🙌
the RVS SHOULD verify the checksum field of an I1 packet before doing any modifications 🔍 after modification, it MUST recompute the checksum field using the updated HIP header (which possibly included new FROM and RVS_HMAC parameters) and a pseudo-header containing the updated source and destination IP addresses. this is what lets the Responder validate the checksum of the I1 packet "as is" without having to parse any FROM parameters. iconic engineering, honestly ✨
4. Rendezvous Server Extensions ✨
this section is the glow-up 🦋 it describes extensions to the HIP Registration Extension [RFC8003], which let a HIP node register with an RVS for rendezvous service and tell the RVS aware of changes to its current location. it also describes an extension to the HIP specification [RFC7401] itself, allowing establishment of HIP associations via one or more HIP RVSs. main character energy 👑
4.1. RENDEZVOUS Registration Type 🎀
this spec defines an additional registration for the HIP Registration Extension [RFC8003] that lets you register with an RVS for rendezvous service.
Number Registration Type
------ -----------------
1 RENDEZVOUS4.2. Parameter Formats and Processing 🍓
4.2.1. RVS_HMAC Parameter 💜
the RVS_HMAC is a non-critical parameter. its only difference from the HMAC parameter defined in the HIP specification [RFC7401] is its "type" code 🙈 that change is what moves it after the FROM parameter (as opposed to the HMAC):
Type 65500
Length Variable. Length in octets, excluding Type, Length, and
Padding.
HMAC HMAC computed over the HIP packet, excluding the
RVS_HMAC parameter and any following parameters. The
HMAC is keyed with the appropriate HIP integrity key
(HIP-lg or HIP-gl) established when rendezvous
registration happened. The HIP "checksum" field MUST be
set to zero, and the HIP header length in the HIP common
header MUST be calculated not to cover any excluded
parameter when the HMAC is calculated. The size of the
HMAC is the natural size of the hash computation
output depending on the used hash function.so to let a rendezvous client and its RVS verify the integrity of packets flowing between them, both SHOULD protect packets with an added RVS_HMAC parameter keyed with the HIP-lg or HIP-gl integrity key established during registration. a valid RVS_HMAC SHOULD be present on every packet flowing between a client and a server, and MUST be present when a FROM parameter is processed. 🫶
4.2.2. FROM Parameter 🌈
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 65498
Length 16
Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address.an RVS MUST add a FROM parameter containing the original source IP address of a HIP packet whenever the source IP address in the IP header is rewritten. if one or more FROM parameters are already present, the new FROM parameter MUST be appended after the existing ones. 📝
whenever an RVS inserts a FROM parameter, it MUST insert an RVS_HMAC protecting the packet integrity, especially the IP address included in the FROM parameter. this part is non-negotiable, bestie 🔐
4.2.3. VIA_RVS Parameter 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 65502
Length Variable
Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address.once the Responder gets a relayed I1, it can start sending HIP packets straight to the Initiator's IP address, no more help from an RVS needed ✨ for debugging purposes, it MUST append a newly created VIA_RVS parameter at the end of the R1 packet, containing the IP address of the RVS that relayed the I1 packet. including more than one IP address in the VIA_RVS parameter is outside the scope of this specification. the main goal of VIA_RVS is to let operators diagnose possible issues encountered while establishing a HIP association via an RVS 🔍
4.3. Modified Packets Processing 💅
the following subsections describe how processing of I1 and R1 differs while an RVS is involved in the base exchange.
4.3.1. Processing Outgoing I1 Packets 🌸
an Initiator SHOULD NOT send an opportunistic I1 with a NULL destination HIT to an IP address that is known to be a rendezvous server address, unless it wants to establish a HIP association with the RVS itself and does not know its HIT. 🙅♀️
when an RVS rewrites the source IP address of an I1 packet due to egress filtering, it MUST add a FROM parameter to the I1 containing the Initiator's source IP address. this FROM parameter MUST be protected by an RVS_HMAC keyed with the integrity key established at rendezvous registration.
4.3.2. Processing Incoming I1 Packets 👀
when an RVS receives an I1 whose destination HIT is not its own, it consults its registration database to find a registration for the rendezvous service established by the HIT owner. if it finds an appropriate registration, it relays the packet to the registered IP address. if it doesn't find one, it drops the packet. 💀
an RVS SHOULD interpret any incoming opportunistic I1 (i.e., an I1 with a NULL destination HIT) as an I1 addressed to itself, and SHOULD NOT attempt to relay it to one of its clients. 🧚
when a rendezvous client receives an I1, it MUST validate any present RVS_HMAC parameter. if the RVS_HMAC cannot be verified, the packet SHOULD be dropped. if the RVS_HMAC cannot be verified and a FROM parameter is present, the packet MUST be dropped. 🛑
a rendezvous client acting as Responder SHOULD drop opportunistic I1s that include a FROM parameter, because this indicates that the I1 has been relayed. ⚠️
4.3.3. Processing Outgoing R1 Packets 💖
when a Responder replies to an I1 relayed via an RVS, it MUST append to the regular R1 header a VIA_RVS parameter containing the IP addresses of the traversed RVSs. 🎀
4.3.4. Processing Incoming R1 Packets 🌟
the HIP specification [RFC7401] mandates that a system receiving an R1 MUST first check whether it has sent an I1 to the originator of the R1 (i.e., the system is in state I1-SENT). when the R1 is replying to a relayed I1, this check SHOULD be based on HITs only. in case the IP addresses are also checked, then the source IP address MUST be checked against the IP address included in the VIA_RVS parameter. 🫧
5. Security Considerations 🔒
Okay bestie, this section is the serious-but-make-it-fashion part 💅 It covers the known threats these HIP extensions bring with them and what that means for HIP's overall security. The main argument is that the extensions in this document do not add any new threats to HIP 🫶
Rendezvous Servers (RVSs) are tricky to cover fully ngl, because they touch both the IP layer and the HIP layer 🌈 These extensions might open the door to redirection, amplification, and reflection attacks at the IP layer. They could also enable attacks on HIP itself, like man-in-the-middle attacks on the HIP base exchange 😭
If an Initiator already knows the Responder's host identity when it first reaches out to the Responder through an RVS, it can check the signatures in the HIP base exchange. That protects against man-in-the-middle attacks, so it's a major W 🙌
Now the messy part: if an Initiator does not know the Responder's host identity beforehand (these are the so-called "opportunistic Initiators" 🙈), defending the HIP exchange against these attacks is almost impossible. The public keys being swapped can't be authenticated, so there's nothing to check them against. The one option left is to limit hijacking of HIP state by requiring that an R1 answering an opportunistic I1 comes from the same IP address that originally sent the I1. That keeps a level of security equivalent to what the Internet has today 🦋
Still, for simplicity, this specification does not allow setting up a HIP association through an RVS in an opportunistic way. No cap, that's the cleanest way to keep things simple 💖
6. IANA Considerations 🧚
Okay so [RFC5204], which this document obsoletes, made some definitions and reservations in the "Parameter Types" subregistry under "Host Identity Protocol (HIP) Parameters" 🎀 Here they are:
Value Parameter Type Length
----- -------------- --------
65498 FROM 16
65500 RVS_HMAC variable
65502 VIA_RVS variableIn that same "Parameter Types" subregistry, every reference to [RFC5204] has been swapped out for a reference to this document ✨
[RFC5204] also made one definition and one reservation in the "Registration Types" subregistry under "Host Identity Protocol (HIP) Parameters" 🌸
Value Registration Type
----- -----------------
1 RENDEZVOUSAnd yep, in the "Registration Types" subregistry, references to [RFC5204] have been replaced by references to this document too 💜
7. References 📚
7.1. Normative References
The normative ones are the must-read sources this document leans on 🫶
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<http://www.rfc-editor.org/info/rfc6724>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015,
<http://www.rfc-editor.org/info/rfc7401>.
[RFC8003] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Registration Extension", RFC 8003, DOI 10.17487/RFC8003,
October 2016, <http://www.rfc-editor.org/info/rfc8003>.
[RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name
System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005,
October 2016, <http://www.rfc-editor.org/info/rfc8005>.7.2. Informative References
These ones are the helpful background reads, not strictly required 🦋
[HIP-ARCH] Moskowitz, R. and M. Komu, "Host Identity Protocol
Architecture", Work in Progress, draft-ietf-hip-rfc4423-
bis-14, June 2016.
[HIP-HOST-MOB]
Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with
the Host Identity Protocol", Work in Progress, draft-ietf-
hip-rfc5206-bis-14, October 2016.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <http://www.rfc-editor.org/info/rfc2827>.
[RFC3013] Killalea, T., "Recommended Internet Service Provider
Security Services and Procedures", BCP 46, RFC 3013,
DOI 10.17487/RFC3013, November 2000,
<http://www.rfc-editor.org/info/rfc3013>.
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", RFC 5204, DOI 10.17487/RFC5204,
April 2008, <http://www.rfc-editor.org/info/rfc5204>.Appendix A. Changes from RFC 5204 🌟
Here's the tea on what changed since [RFC5204] 🍓
- Updated HIP references to revised HIP specifications.
Acknowledgments 💖
Huge shoutout to these people, who shared thoughtful, helpful discussions and/or suggestions that made this document better 🫶
Marcus Brunner, Tom Henderson, Miika Komu, Mika Kousa, Pekka Nikander, Juergen Quittek, Justino Santos, Simon Schuetz, Tim Shepard, Kristian Slavov, and Martin Stiemerling.
Lars Eggert has received funding from the European Union's Horizon 2020 research and innovation program 2014-2018 under grant agreement No. 644866. This document reflects only the authors' views, and the European Commission is not responsible for any use that may be made of the information it contains.
Thanks to Joel M. Halpern for performing the Gen-ART review of this document as part of the publication process ✨
Authors' Addresses 🎀
Julien Laganier
Luminate Wireless, Inc.
Cupertino, CA
United States of America
Email: julien.ietf@gmail.com
Lars Eggert
NetApp
Sonnenallee 1
Kirchheim 85551
Germany
Phone: +49 151 12055791
Email: lars@netapp.com
URI: http://eggert.org📦 where this page comes from
- ietf: rfc8004 2016-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms