RFC 6079

HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE)

📅 published January 2011, from ietf

🦋 HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE) 🦋

RFC 6079 ✨ is an Experimental doc from the IETF, dated January 2011. The authors are G. Camarillo, P. Nikander, J. Hautakorpi, and A. Keranen from Ericsson, plus A. Johnston from Avaya. The ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates. 💅

Abstract 🌸

okay so this doc lays out a framework for building HIP-based overlay networks 🫶 HIP handles the connection management part, and the other stuff (like storing and retrieving data, or keeping the overlay healthy) gets handled by other protocols. People loosely call those other protocols "peer protocols" 🧚

Status of This Memo 🎀

bestie, this one is not an Internet Standards Track spec 😭 It's being shared so people can look at it, try building it, and test it out.

It defines an Experimental Protocol for the Internet community. It's a product of the Internet Engineering Task Force (IETF) and it reflects the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🤓

Want the latest status, errata, or a place to send feedback? Head to http://www.rfc-editor.org/info/rfc6079 🔗

Copyright (c) 2011 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 were on the date it was published. Read these carefully, because they spell out your rights and restrictions for this doc 📜 Code components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License.

Table of Contents 🍓

1. Introduction ....................................................3
2. Terminology .....................................................3
3. Background on HIP ...............................................4
   3.1. ID/Locator Split ...........................................4
        3.1.1. Identifier Format ...................................5
        3.1.2. HIP Base Exchange ...................................5
        3.1.3. Locator Management ..................................6
   3.2. NAT Traversal ..............................................6
   3.3. Security ...................................................7
        3.3.1. DoS Protection ......................................7
        3.3.2. Identifier Assignment and Authentication ............7
        3.3.3. Connection Security .................................9
   3.4. HIP Deployability and Legacy Applications ..................9
4. Framework Overview .............................................10
5. The HIP BONE Framework .........................................13
   5.1. Node ID Assignment and Bootstrap ..........................13
   5.2. Overlay Network Identification ............................14
   5.3. Connection Establishment ..................................15
   5.4. Lightweight Message Exchanges .............................15
   5.5. HIP BONE Instantiation ....................................16
6. Overlay HIP Parameters .........................................17
   6.1. Overlay Identifier ........................................17
   6.2. Overlay TTL ...............................................17
7. Security Considerations ........................................18
8. Acknowledgements ...............................................19
9. IANA Considerations ............................................19
10. References ....................................................19
    10.1. Normative References .....................................19
    10.2. Informative References ...................................20

1. Introduction ✨

okay so the Host Identity Protocol (HIP) [RFC5201] adds a brand new name space between the network and transport layers 🫶 It gives upper layers mobility, multihoming, NAT (Network Address Translation) traversal, and security. The big idea is the identifier/locator (ID/locator) split: IP addresses are only used as locators, never as host identifiers. That makes HIP a great fit for building overlay networks that do identifier-based overlay routing on top of IP networks, which in turn do locator-based routing 💅

Using HIP-Based Overlay Networking Environment (HIP BONE), instead of a peer protocol, for connection management in an overlay has some real perks 🎀 HIP BONE can be used by any peer protocol, so each peer protocol doesn't have to define its own connection management primitives (like primitives to set up connections and tunnel messages through the overlay) or its own NAT traversal. Having that stuff at a lower layer means multiple upper-layer protocols can all use it at once 🧚

Mobility and multihoming also matter a lot in lots of scenarios 🌸 Peer protocols usually don't specify a mobility or multihoming solution. If you bolt a peer protocol with NAT traversal onto a separate mobility mechanism and a separate multihoming mechanism, things can get weird fast, in unexpected (and unpleasant) ways 😭

Here's how the rest of this doc is laid out 🗺️ Section 3 gives background on HIP. Section 4 gives an overview of the HIP BONE (HIP-Based Overlay Networking Environment) framework and architecture, and Section 5 goes into the framework in more detail. Last but not least, Section 6 introduces new HIP parameters for overlay usage 👑

2. Terminology 🦋

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]. 📖

These are the terms used in the context of HIP BONEs 💜

  • Overlay network: A network built on top of another network. For HIP BONEs, the underlying network is an IP network, and the overlay can be, e.g., a peer-to-peer (P2P) network 🌐
  • Peer protocol: A protocol that nodes in an overlay network use for things like data storage and retrieval or overlay maintenance 🧚
  • HIP BONE instance: A HIP-based overlay network that uses a particular peer protocol and is built on the framework in this document 🌸
  • Node ID: A value that uniquely identifies a node in an overlay network. It's usually not human-friendly. For example, it might be a hash of a public key 🔑
  • HIP association: An IP-layer communications context created using the Host Identity Protocol 🤝
  • Valid locator: A locator (as defined in [RFC5206]; usually an IP address or an address and a port number) where a host is known to be reachable, for example, because there's an active HIP association with that host 📍
  • Final recipient: A node is the final recipient of a HIP signaling packet if one of its Host Identity Tags (HITs) matches the receiver's HIT in the HIP packet header 🎯

3. Background on HIP 🌈

This section is the background on HIP 📚 Since it's tutorial-ish, readers who already know what HIP provides and how it works can totally skip it. Every description links back to the relevant HIP specs, so if you want the deep dive on any topic, go there 🤓

3.1. ID/Locator Split 🎀

In an IP network, IP addresses usually do two jobs at once: they're host identifiers and host locators 🫠 They're locators because an address tells you where in the network a host sits, and IP networks route based on those locators. They're also used to identify remote hosts. Using the same address as both identifier and locator is what makes mobility and multihoming so complicated 😭 For example, when a host opens a TCP connection, it identifies the remote end by the remote IP address (plus port). If the remote host changes its IP address, the TCP connection won't survive, because the transport layer identifier of the remote end has changed.

Mobility solutions like Mobile IP keep the remote IP address from changing, so it can still be used as an identifier. HIP takes a different route: it uses IP addresses only as locators and defines a new identifier space 💅 This approach is called the ID/locator split, and it makes mobility and multihoming feel way more natural. Back to the TCP example: the connection would be bound to the remote host's identifier, which doesn't change when the remote host moves to a new IP address (a new locator). That's why the TCP connection can survive locator changes: the remote host's identifier stays the same ✨

3.1.1. Identifier Format 🔑

HIP uses 128-bit ORCHIDs (Overlay Routable Cryptographic Hash Identifiers) [RFC4843] as identifiers 🦋 ORCHIDs look like IPv6 addresses, but they can't collide with regular IPv6 addresses, because ORCHID spaces are registered with the IANA. In other words, a chunk of the IPv6 address space is reserved for ORCHIDs 👑 The ORCHID spec lets you create multiple disjoint identifier spaces, and each one is identified by its own Context Identifier. The Context Identifier can be drawn implicitly from the context the ORCHID is used in, or it can be carried explicitly in a protocol 🌸

HIP defines a native socket API [HIP-NATIVE-API] that applications can use to set up and manage connections 🎀 HIP can also be used through the traditional IPv4 and IPv6 TCP/IP socket APIs. Section 3.4 explains how an application using those traditional APIs can still make use of HIP 🧚 Figure 1 shows all of these APIs sitting between the application and the transport layers 🗺️

            +-----------------------------------------+
            |               Application               |
            +----------------+------------------------+
            | HIP Native API | Traditional Socket API |
            +----------------+------------------------+
            |             Transport Layer             |
            +-----------------------------------------+

                        Figure 1: HIP API

3.1.2. HIP Base Exchange 💖

okay so, before two HIP hosts start swapping upper-layer traffic, they do a four-way handshake called the HIP base exchange 🤝✨ Figure 2 shows the whole thing. The initiator sends an I1 packet and gets an R1 packet back from the responder. Then the initiator sends an I2 packet and gets an R2 packet back. It's giving very organized energy 🎀

            Initiator                    Responder

                |            I1             |
                |-------------------------->|
                |            R1             |
                |<--------------------------|
                |            I2             |
                |-------------------------->|
                |            R2             |
                |<--------------------------|

                 Figure 2: HIP Base Exchange

Of course, the initiator needs the responder's locator (or locators) before it can send its I1 packet 📍 The initiator can get those locators in a bunch of different ways 🗺️ For example, under the current HIP specifications, the initiator can grab the locators straight from the DNS [RFC5205], or it can go the indirect route by sending packets through a HIP rendezvous server [RFC5204]. But HIP is an open-ended architecture, bestie 🦋 The HIP architecture lets locators be obtained by any means at all (e.g., from packets traveling across an overlay network, or as part of the candidate address collection process in a NAT traversal scenario). So many options, no drama 💅

3.1.3. Locator Management 🧭

Once a HIP connection is set up between two hosts with a HIP base exchange, the hosts can start exchanging higher-layer traffic 🚀 If either host changes its set of locators, it runs an update exchange [RFC5206], which is made up of three messages. If a host is multihomed, it just includes more than one locator in its exchanges, easy 🌈 But if both endpoints move at the same time, or for some other reason both lose track of the peers' currently active locators, they need to fall back on a rendezvous server or get new peer locators some other way 😭

3.2. NAT Traversal 🌐

HIP's NAT traversal mechanism [RFC5770] is built on ICE (Interactive Connectivity Establishment) [RFC5245] 🧩 Hosts gather address candidates, and as part of the HIP base exchange, they perform an ICE offer/answer exchange where they swap their respective address candidates. Then hosts run end-to-end STUN-based [RFC5389] connectivity checks to figure out which address candidate pairs actually yield connectivity ✅

Here's the lowkey tricky part 🙈 Architecturally, HIP sits below the transport layer (i.e., HIP packets are carried directly in IP packets). But in the presence of NATs, HIP sometimes needs to be tunneled inside a transport protocol (i.e., HIP packets are carried by a transport protocol such as UDP). Plot twist, but it's still HIP 🎭

3.3. Security 🔐

Security is an essential part of HIP, no cap 👑 The following sections describe the security-related functionality that HIP provides.

3.3.1. DoS Protection 🛡️

HIP protects against DoS (denial-of-service) attacks by making initiators resolve a cryptographic puzzle before the responder stores any state 🧩 When a responder receives an I1 packet, it sends a pre-generated R1 packet that contains a cryptographic puzzle, and it deletes all the state associated with processing that I1 packet. The initiator has to resolve the puzzle in the R1 packet in order to generate an I2 packet. The difficulty of the puzzle can be adjusted, so if a receiver is under a DoS attack, it can increase the difficulty of its puzzles 📈 Main character defense energy 💪

On receiving an I2 packet, a receiver checks that the solution in the packet corresponds to a puzzle the receiver generated, and that the solution is correct ✔️ If it is, the receiver processes the I2 packet. Otherwise, it silently discards it 🤫

In an overlay scenario, there are multiple ways this mechanism can be used within the overlay 🕸️ One possibility is to cache the pre-generated R1 packets within the overlay and let the overlay respond directly to I1s with R1s. That way, the responder isn't bothered at all until the initiator sends an I2 packet with the puzzle solution 😌 A more sophisticated overlay could also verify that an I2 packet has a correctly solved puzzle before forwarding the packet to the responder. Iconic overlay behavior 👑

3.3.2. Identifier Assignment and Authentication 🪪

As discussed earlier, HIP uses ORCHIDs [RFC4843] as the main representation for identifiers ✨ HIP can potentially use different types of ORCHIDs, as long as the probability of finding collisions (i.e., two nodes with the same ORCHID) is low enough. One way to completely avoid this type of collision is to have a central authority generate and assign ORCHIDs to nodes 🏛️ To secure the binding between ORCHIDs and any higher-layer identifiers, every time the central authority assigns an ORCHID to a node, it also generates and signs a certificate stating who owns the ORCHID 📜 The owner of the ORCHID then includes the corresponding certificate in its R1 (when acting as responder) and I2 packets (when acting as initiator), to prove that it is actually allowed to use the ORCHID and, implicitly, the associated public key 🔑

Having a central authority works well for completely avoiding collisions. However, a central authority is impractical in some scenarios 🙃 As defined today, HIP systems generally use a self-certifying ORCHID type called HIT (Host Identity Tag), which does not require a central authority (but still allows one to be used) 🦋

A HIT is the hash of a node's public key 🧁 A node proves that it has the right to use a HIT by showing that it can sign data with its associated private key. This scheme is secure thanks to the so-called second-preimage resistance property of hash functions. That is, given a fixed public key K1, finding a different public key K2 such that hash(K1) = hash(K2) is computationally very hard 🥵 Optimally, a preimage attack on the 100-bit hash function used in ORCHIDs will take on the order of 2^100 operations to succeed, and can be expected to take 2^99 operations on average. Since each operation requires the attacker to generate a new key pair, the attack is fully impractical with current technology and techniques (see [RFC4843]). Not happening, bestie 💀

HIP nodes using HITs as ORCHIDs don't typically use certificates during their base exchanges 📭 Instead, they use a leap-of-faith mechanism, similar to the Secure Shell (SSH) protocol [RFC4251]. Under this mechanism, a node somehow authenticates remote nodes the first time they connect to it, and then remembers their public keys 🫶 A user-assisted leap-of-faith mechanism (such as in SSH) can be used to facilitate a human-operated offline path (such as a telephone call) 📞 Automated leap-of-faith mechanisms, on the other hand, can be combined with a reputation management system to create an incentive to behave 🌟 However, such considerations go well beyond the current HIP architecture, and even beyond this proposal. For the purposes of the present document, we merely want to point out that, architecturally, HIP supports both self-generated opportunistic identifiers and administratively assigned ones 🎀

3.3.3. Connection Security 🔒

Once two nodes complete a base exchange between them, the traffic they exchange is encrypted and integrity protected 🥰 The security mechanism used to protect the traffic is IPsec Encapsulating Security Payload (ESP) [RFC5202]. There is ongoing work on specifying how to use other protection mechanisms, so stay tuned 👀

3.4. HIP Deployability and Legacy Applications 📱

As discussed earlier, HIP defines a native socket API [HIP-NATIVE-API] that applications can use to establish and manage connections ✨ New applications can implement this API to get the full advantage of HIP. However, in most cases, legacy (i.e., non-HIP-aware) applications [RFC5338] can use HIP through the traditional IPv4 and IPv6 socket APIs 🧚

Here's the idea 💡 When a legacy IPv6 application tries to obtain a remote host's IP address (e.g., by querying the DNS), the DNS resolver passes the remote host's ORCHID (which was also stored in the DNS) to the legacy application. At the same time, the DNS resolver stores the remote host's IP address internally at the HIP module. Since the ORCHID looks like an IPv6 address, the legacy application treats it as one 🤭 It opens a connection (e.g., TCP) using the traditional IPv6 socket API. The HIP module running on the same host as the legacy application intercepts this call somehow (e.g., using an interception library, or by setting up the host's routing tables so that the HIP module receives the traffic). Then it runs HIP on behalf of the legacy application towards the IP address corresponding to the ORCHID 🪄 This mechanism works well in almost all cases. However, applications involving referrals (i.e., passing of IPv6 addresses between applications) present issues, which are discussed in Section 5 below 🙈 Additionally, management applications that care about the exact IP address format may not work well with such a straightforward approach.

In order to make HIP work through the traditional IPv4 socket API, the HIP module passes an LSI (Local Scope Identifier), instead of a regular IPv4 address, to the legacy IPv4 application 🎯 The LSI looks like an IPv4 address, but it's locally bound to an ORCHID. That means when the legacy application uses the LSI in a socket call, the HIP module intercepts it and replaces the LSI with its corresponding ORCHID 🔄 Therefore, LSIs always have local scope. They don't have any meaning outside the host running the application. The ORCHID is used on the wire, not the LSI 🫧 In the referral case, if it isn't possible to rewrite the application-level packets to use ORCHIDs instead of LSIs, it may be hard to make IPv4 referrals work in Internet-wide settings 😬 Still, IPv4 LSIs have been successfully used in existing HIP deployments within a single corporate network 🏢✨

4. Framework Overview ✨

okay so the HIP BONE framework basically takes HIP and pairs it with different peer protocols to build robust and secure overlay network solutions 💅 it's giving main character energy, fr

many overlays need three types of operations:

  • overlay maintenance
  • data storage and retrieval
  • connection management

overlay maintenance is all about nodes joining and leaving the overlay, plus keeping the overlay's routing tables in shape 🌸. data storage and retrieval is nodes storing, retrieving, and removing information in or from the overlay 📦. connection management covers setting up connections and swapping lightweight messages between the nodes of the overlay, potentially even when NATs are in the mix 🦋

the HIP BONE framework uses HIP for connection management. data storage and retrieval plus overlay maintenance are supposed to be done with protocols other than HIP. there isn't a better name yet, so these are called peer protocols 🧚

here's one way to picture how the peer protocol and the HIP modules fit together (see Figure 3). the peer protocol module handles building and maintaining the overlay, and maybe storage too if that particular protocol supports it. the HIP module checks the peer protocol's overlay topology part when it needs to make routing decisions. the peer protocol uses HIP for connection management and for sending its messages to other hosts. the HIP BONE API that applications use is a mix of the HIP Native API and the traditional socket API (see Figure 1), plus any extra API a particular implementation provides 💖

                    Application
         -------------------------------- HIP BONE API
          +---+   +--------------------+
          |   |   |    Peer Protocol   |
          |   |   +--------+ +---------+
          |   |<->|Topology| |(Storage)|
          |   |   +---------+----------+
          |   |             ^
          |   |             v
          |   +------------------------+
          |                HIP         |
          +----------------------------+

Figure 3: HIP with Peer Protocol

architecturally, HIP can be seen as a new thin "waist" layer sitting on top of the IPv4 and IPv6 networks (see Figure 4) ✨. the HIP layer is made up of the HIP signaling protocol and one or more data transport protocols (see Figure 5). HIP signaling packets and data transport packets can take different routes. in HIP BONE scenarios, HIP signaling packets are typically routed through the overlay first and then directly (if that's possible), while data transport packets are typically routed only directly between the endpoints 🛣️

         +--------------------------------------+
         |    Transport (using HITs or LSIs)    |
         +--------------------------------------+
         |                 HIP                  |
         +------------------+-------------------+
         |      IPv4        |       IPv6        |
         +------------------+-------------------+

Figure 4: HIP as a Thin Waist

         +------------------+-------------------+
         |  HIP signaling   |  data transports  |
         +------------------+-------------------+

Figure 5: HIP Layer Structure

in HIP BONE, the peer protocol creates a new signaling layer on top of HIP 👑. it's used to set up forwarding paths for HIP signaling messages. this is kind of like how an IP routing protocol such as OSPF relates to IP itself. in the HIP BONE case, the peer protocol plays the role that OSPF plays, and HIP plays the role that IP plays. the ORCHIDs (or, in general, Node IDs if the ORCHID prefix is not used) are used to forward HIP packets according to the information in the routing tables. the peer protocols exchange routing information based on Node IDs and use it to build the routing tables 🗺️

architecturally, the routing tables sit between the peer protocol and HIP (see Figure 6). the peer protocol builds the routing table and keeps it updated, and the HIP layer reads the routing table when it needs to make routing decisions. bootstrapping a HIP BONE overlay doesn't create circular dependencies between the peer protocol (which needs HIP to set up connections with other nodes) and HIP (which needs the peer protocol to know how to route messages to other nodes). that's for the same reason that bootstrapping an IP network doesn't create circular dependencies between OSPF and IP 🔄. the first connections the peer protocol sets up are with nodes whose locators are already known. HIP sets those connections up the same way it would for any two HIP nodes when no overlay is present. so the overlay doesn't need to provide a rendezvous service for those connections 🙌

         +--------------------------------------+
         |            Peer protocol             |
         +--------------------------------------+
         |            Routing table             |
         +--------------------------------------+
         |                 HIP                  |
         +--------------------------------------+

Figure 6: Routing Tables

different overlays can use different routing table formats. for example, the structure of the routing tables for two overlays built on different DHTs (Distributed Hash Tables) can be very different 🧩. to make routing decisions, the HIP layer needs to convert the routing table generated by the peer protocol into a forwarding table, so it can pick a next hop for any packet being routed 🎯

in HIP BONE, HIP's use of public keys and its deriving of ORCHIDs through a hash function can be used on the peer protocol side to better secure routing table maintenance and to protect against chosen-peer-ID attacks 🔐

HIP BONE is super flexible about how you arrange the different protocols. Figure 7 shows one possible stack structure 🥰

         +-----------------------+--------------+
         | peer protocols        |     media    |
         +------------------+----+--------------+
         | HIP signaling    |   data transport  |
         |                                      |
         +------------------+-------------------+
         | NAT    | non-NAT |                   |
         |                  |                   |
         |      IPv4        |       IPv6        |
         +------------------+-------------------+

Figure 7: Example HIP BONE Stack Structure

5. The HIP BONE Framework 🎀

okay so HIP BONE is a generic framework that lets you use different peer protocols 🌈. each particular HIP BONE instance uses one particular peer protocol. the details of how to implement HIP BONE with a given peer protocol go in a so-called HIP BONE instance specification. Section 5.5 covers what details those instance specifications need to include. for example, the HIP BONE instance specification for RELOAD [P2PSIP-BASE] is written up in [HIP-RELOAD-INSTANCE] 📝

5.1. Node ID Assignment and Bootstrap

nodes in an overlay are mainly identified by their Node IDs. overlays usually have an enrollment server that can generate Node IDs (or at least part of a Node ID) and sign certificates 🖋️. a certificate from an enrollment server authorizes a particular user to use a particular Node ID in a particular overlay. the peer protocol and HIP BONE instance specification define how users are identified 🪪

if the enrollment server of an overlay uses HITs derived from public keys as Node IDs, it can just authorize users to use the public keys and HITs tied to their nodes. a Node ID like that has the same self-certifying property as HITs, and it can also be used in the HIP and legacy APIs as an ORCHID 💜. this works well as long as the enrollment server is the one generating the public/private key pairs for all those nodes. if instead the enrollment server authorizes users to use HITs that the nodes generated themselves, the system is open to a type of chosen-peer-ID attack 😬

heads up: if the enrollment server authorizes users to use HITs that the nodes generate themselves, the system is open to a type of chosen-peer-ID attack.

if the overlay network or peer protocol has more specific requirements for the Node ID value that rule out HITs derived from public keys, each host will need a certificate (for example, in their HIP base exchanges) from the enrollment server. that certificate proves the host is authorized to use a particular identifier in the overlay 📜. depending on how the certificates are built, they typically also need to contain the host's self-generated public key. depending on how the Node IDs and public keys are attributed, different scenarios become possible. for example, Node IDs may be attributed to users, there may be user public key identifiers, and there may be separate host public key identifiers. authorization certificates can be used to bind those different types of identifiers together 🔗

HITs, as defined in [RFC5201], always start with the ORCHID prefix. that means there are 100 bits left in the HIT for different Node ID values 🔢. if an overlay network needs a bigger address space, it's also possible to use all 128 bits of a HIT for addressing peer layer identifiers. the nice thing about using the ORCHID prefix for Node IDs is that it lets them work with legacy socket APIs. but in this context, most applications are assumed to be HIP aware and able to use a more advanced API that supports full 128-bit identifiers 💅. even larger address spaces could be supported with an additional HIP parameter that gives the source and destination Node IDs, but defining such a parameter, if it's needed, is left for future documents 🔮

bootstrap issues, like how to locate an enrollment or bootstrap server, belong to the peer protocol 🥾

5.2. Overlay Network Identification

a HIP host can take part in multiple different overlay networks at the same time 🌸. it's also possible that some HIP traffic isn't meant to be forwarded over an overlay at all. so a host needs to know which overlay an incoming HIP message belongs to, and outgoing HIP messages need to be labeled as belonging to a certain overlay 🏷️. this document specifies a new generic HIP parameter (in Section 6.1) for directing HIP messages to the right overlay 🎯

an application using HIP BONE also needs to define, either implicitly or explicitly, the overlay it uses for communication. explicit configuration can happen, for example, by binding certain local HITs to certain overlays, or by defining the overlay identifier through advanced HIP socket options or other suitable APIs ⚙️. on the other hand, if there's no explicit configuration for a HIP association, a host may have a configured default overlay that all HIP messages without a valid locator are sent to 💫. how to implement this coordination for locally originated messages is out of scope for this document 🙈

5.3. Connection Establishment 🔗

Okay so nodes in an overlay need to set up connections with other nodes in different situations 💖. For example, a node usually has connections to the nodes in its forwarding table 🦋. Nodes also need to connect with other nodes so they can swap application-layer messages 💬.

As we covered earlier, HIP uses the base exchange to set up connections 🎀. A HIP endpoint (the initiator 👑) starts a HIP base exchange with a remote endpoint by sending an I1 packet ✨. It sends that I1 packet to the remote endpoint's locator 📍. Initiators that don't have any locator for the remote endpoint need a rendezvous service 🧚. Traditionally, a HIP rendezvous server [RFC5204] has been the one providing that rendezvous service. In HIP BONE, the overlay itself does it 🌈.

So in HIP BONE, a node uses an I1 packet (as usual!) to set up a connection with another node in the overlay 🫶. Overlay nodes forward I1 packets hop-by-hop according to the overlay's routing table, heading toward the destination 🧭. This way the overlay acts as the rendezvous service between the two nodes making the connection 💜. If the overlay nodes have active connections with other nodes in their forwarding tables, and those connections are protected (typically with IPsec ESP), I1 packets may be sent over those protected connections between nodes 🔐. Alternatively, if there's no such active connection but the node forwarding the I1 packet has a valid locator for the next hop, the I1 packets may be forwarded directly, kinda like how HIP rendezvous servers forward I1 packets today 🍓.

Since HIP supports NAT traversal, a HIP base exchange over the overlay will perform an ICE [RFC5245] offer/answer exchange between the nodes setting up the connection 🙈. To do this, the nodes first need to gather candidate addresses. Which nodes can be used to get reflexive address candidates, and which ones can be used to get relayed candidates, is defined by the peer protocol 💅.

5.4. Lightweight Message Exchanges 💌

Sometimes nodes need to do a quick query to another node (think a request followed by a single response) 🌸. In that situation, setting up a full connection with the mechanisms from Section 5.3 for a simple query would be overkill, no cap 😭. A better move is to forward a HIP message through the overlay carrying the query, and another one carrying the response to that query ✨. The payload of these HIP packets is integrity protected [RFC6078] 🔒.

Overlay nodes forward this HIP packet hop-by-hop according to the overlay's routing table, heading toward its destination. That usually happens over the protected connections set up between them 🛡️. Again, the overlay is acting as a rendezvous server between the nodes exchanging the messages 👑.

5.5. HIP BONE Instantiation 🧩

As we discussed in Section 5, HIP BONE is a generic framework that lets you use different peer protocols 🌈. A particular HIP BONE instance uses one particular peer protocol 🎀. The details on how to implement a HIP BONE with a given peer protocol need to be written up in a so-called HIP BONE instance specification 📜. A HIP BONE instance specification needs to define, at a minimum:

  • the peer protocol to be used,
  • what kind of Node IDs are used and how they are derived,
  • which peer protocol primitives trigger HIP messages, and
  • how the overlay identifier is generated.

A HIP BONE instance specification may also need to specify other details that are specific to the peer protocol being used 💫.

As an example, the HIP BONE instance specification for RELOAD [P2PSIP-BASE] is specified in [HIP-RELOAD-INSTANCE] 🦋.

Everything a particular HIP BONE instance specification doesn't cover is handled by the peer protocol or somewhere else 🫶. Those areas include:

  • the algorithm to create the overlay (e.g., a DHT),
  • overlay maintenance functions,
  • data storage and retrieval functions,
  • the process for obtaining a Node ID,
  • bootstrap function, and
  • how to select STUN and TURN servers for the candidate address collection process in NAT traversal scenarios.
Note that the border between a HIP BONE instance specification and a peer protocol specification is fuzzy 🙈. Depending on how generic the peer protocol's specification is, its HIP BONE instance specification may need to specify more or fewer details. Also, a HIP BONE instance specification may leave certain areas unspecified so that their configuration is up to each particular overlay 💅.

6. Overlay HIP Parameters 🎀

This section defines the generic format and protocol behavior for the Overlay Identifier and Overlay Time-to-Live (TTL) HIP parameters that can be used in HIP-based overlay networks 💖. HIP BONE instance specifications define the exact format and content of the Overlay Identifier parameter, the cases when the Overlay TTL parameter should be used, and any additional behavior for each packet 📜.

6.1. Overlay Identifier 🪪

To identify which overlay network a HIP message belongs to, all HIP messages that are sent via an overlay, or as part of operations specific to a certain overlay, MUST contain an OVERLAY_ID parameter with the identifier of the corresponding overlay network 🔥. Instance specifications define how the identifier is generated for different types of overlay networks. The generation mechanism MUST be such that it is unlikely to generate the same identifier for two different overlay instances, and any other means possible for preventing collisions SHOULD be used 💅.

The generic format of the OVERLAY_ID parameter is shown in Figure 8. Instance specifications define the valid length for the parameter and how the identifier values are generated 🧚.

       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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Identifier                          /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                                               |    Padding    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type        4592
      Length      Length of the Identifier, in octets
      Identifier  The identifier value
      Padding     0-7 bytes of padding if needed

                 Figure 8: Format of the OVERLAY_ID Parameter

6.2. Overlay TTL ⏳

HIP packets sent in an overlay network MAY contain an Overlay Time-to-live (OVERLAY_TTL) parameter whose TTL value is decremented on each overlay network hop 🦋. When a HIP host receives a HIP packet with an OVERLAY_TTL parameter, and the host is not the final recipient of the packet, it MUST decrement the TTL value in the parameter by one before forwarding the packet 🔁.

If the TTL value in a received HIP packet is zero, and the receiving host is not the final recipient, the packet MUST be dropped and the host SHOULD send a HIP Notify packet with NOTIFICATION error type OVERLAY_TTL_EXCEEDED (value 70) to the sender of the original HIP packet 💀.

The Notification Data field for OVERLAY_TTL_EXCEEDED notifications SHOULD contain the HIP header and the TRANSACTION_ID [RFC6078] parameter (if one exists) of the packet whose TTL was exceeded 🍓.

Figure 9 shows the format of the OVERLAY_TTL parameter. The TTL value is given as the number of overlay hops this packet has left, and it is encoded as an unsigned integer using network byte order 🌈.

       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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             TTL               |            Reserved           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type        64011
      Length      4
      TTL         The Time-to-Live value
      Reserved    Reserved for future use

                Figure 9: Format of the OVERLAY_TTL Parameter

The type of the OVERLAY_TTL parameter is critical (as defined in Section 5.2.1 of [RFC5201]), so all the HIP nodes forwarding a packet with this parameter MUST support it 🚨. If the parameter is used in a scenario where the final recipient does not support the parameter, the parameter SHOULD be removed before forwarding the packet to the final recipient 🧹.

7. Security Considerations 🔐

This document provides a high-level framework for building HIP-based overlays 🏗️. The security properties of HIP and its extensions used in this framework are discussed in their respective specifications. Those security properties can be affected by the way HIP is used in a particular overlay 😬. However, those properties are mostly affected by the design decisions made to build a particular overlay, not so much by the high-level framework specified in this document. Such design decisions are typically documented in a HIP BONE instance specification, which describes the security properties of the resulting overlay 🛡️.

Seriously, this part matters a lot 💀. The security of a HIP-based overlay is shaped mostly by the choices made when building that specific overlay, so the instance specification is where the real security story lives 🔥.

8. Acknowledgements 🫶

HIP BONE is based on ideas that came out of conversations and discussions with a number of people in the HIP and P2PSIP communities 💜. In particular, Philip Matthews, Eric Cooper, Joakim Koskela, Thomas Henderson, Bruce Lowekamp, and Miika Komu provided useful input on HIP BONE 🌸.

9. IANA Considerations 📋

This section is to be interpreted according to [RFC5226].

This document updates the IANA Registry for HIP Parameter Types [RFC5201] by assigning HIP Parameter Type values for the new HIP Parameters OVERLAY_ID (defined in Section 6.1) and OVERLAY_TTL (defined in Section 6.2) ✨. This document also defines a new HIP Notify Message Type [RFC5201], OVERLAY_TTL_EXCEEDED, in Section 6.2 🎀. This value is allocated in the error range 🙈.

10. References 📚

10.1. Normative References 💅

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", RFC 4843, April 2007.
  • [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
  • [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 5202, April 2008.
  • [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. Keranen, Ed., "Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators", RFC 5770, April 2010.
  • [RFC6078] Camarillo, G. and J. Melen, "Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS)", RFC 6078, January 2011.

10.2. Informative References 📚

Okay bestie, these are the informative references, so they're here for background and context. Here's the whole list, no skipping 💅

[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. 🔐

[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", RFC 5204, April 2008. 🌸

[RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions", RFC 5205, April 2008. 🌐

[RFC5206] Nikander, P., Henderson, T., Ed., Vogt, C., and J. Arkko, "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008. 🦋

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 📝

[RFC5338] Henderson, T., Nikander, P., and M. Komu, "Using the Host Identity Protocol with Legacy Applications", RFC 5338, September 2008. 🎀

[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. 🧚

[HIP-NATIVE-API] Komu, M. and T. Henderson, "Basic Socket Interface Extensions for Host Identity Protocol (HIP)", Work in Progress, January 2010. 🛠️

[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. 🌈

[P2PSIP-BASE] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", Work in Progress, November 2010. 🫶

[HIP-RELOAD-INSTANCE] Keranen, A., Camarillo, G., and J. Maenpaa, "Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD)", Work in Progress, January 2011. 💜

Authors' Addresses 🧚

Meet the squad who wrote this one, bestie. Here are their details, copied exactly 🫶

Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas  02420
Finland

EMail: Gonzalo.Camarillo@ericsson.com

Pekka Nikander
Ericsson
Hirsalantie 11
Jorvas  02420
Finland

EMail: Pekka.Nikander@ericsson.com

Jani Hautakorpi
Ericsson
Hirsalantie 11
Jorvas  02420
Finland

EMail: Jani.Hautakorpi@ericsson.com

Ari Keranen
Ericsson
Hirsalantie 11
Jorvas 02420
Finland

EMail: Ari.Keranen@ericsson.com

Alan Johnston
Avaya
St. Louis, MO  63124

EMail: alan.b.johnston@gmail.com
📦 where this page comes from