RFC 7086

Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD)

📅 published January 2014, from ietf

RFC 7086 🦋 Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD)

Okay bestie, this one's from January 2014, written by A. Keranen, G. Camarillo, and J. Maenpaa at Ericsson 💅. It's an Experimental doc (ISSN 2070-1721), so it's giving "try it out and see what happens" energy 🧪✨.

Abstract ✨

This doc is the HIP-Based Overlay Networking Environment (HIP BONE) instance spec for the REsource LOcation And Discovery (RELOAD) protocol 🌸. It gives you all the details you need to build a RELOAD-based overlay that uses HIP 🫶.

Status of This Memo

Okay so this one is NOT an Internet Standards Track spec 😭. It's published so people can examine it, try implementing it, and evaluate it 🔬.

It defines an Experimental Protocol for the Internet community 🧚. It's a product of the Internet Engineering Task Force (IETF), it represents IETF community consensus, and it got public review and was approved 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 for the full tea ☕.

For the current status, errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7086 💜.

Copyright (c) 2014 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 stand on the publication date 📜. Read these carefully, because they spell out your rights and restrictions for this doc 👀. Code Components pulled out of this doc must include the 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
3.  Peer Protocol . . . . . . . . . . . . . . . . . . . . . . . .   3
4.  Node ID Generation  . . . . . . . . . . . . . . . . . . . . .   3
5.  Mapping between Protocol Primitives and HIP Messages  . . . .   3
  5.1.  Forwarding Header . . . . . . . . . . . . . . . . . . . .   4
  5.2.  Security Block  . . . . . . . . . . . . . . . . . . . . .   4
  5.3.  Replaced RELOAD Messages  . . . . . . . . . . . . . . . .   5
6.  Securing Communication  . . . . . . . . . . . . . . . . . . .   5
7.  Routing HIP Messages via the Overlay  . . . . . . . . . . . .   5
8.  Enrollment and Bootstrapping  . . . . . . . . . . . . . . . .   6
9.  NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . .   7
10. RELOAD Overlay Configuration Document Extension . . . . . . .   7
11. Security Considerations . . . . . . . . . . . . . . . . . . .   8
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
13. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
14. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
  14.1.  Normative References . . . . . . . . . . . . . . . . . .   8
  14.2.  Informative References . . . . . . . . . . . . . . . . .   9

1. Introduction 🌈

The HIP-Based Overlay Networking Environment (HIP BONE) spec [RFC6079] gives you a high-level framework for building HIP-based [RFC5201] overlays 🧩. It doesn't get into the nitty-gritty of how to combine a specific peer protocol with HIP to make an overlay. That's left to docs called HIP BONE instance specifications 📚. As [RFC6079] explains, a HIP BONE instance spec needs to define, at 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.
  • how the overlay identifier is generated.

This doc covers all of those items and adds the extra details you need to build RELOAD-based HIP BONEs, which we call RELOAD HIP BONEs 💖. How the different RELOAD modules hook into a HIP implementation, and what APIs sit between them, is left to implementers or other docs 🫠.

2. Terminology 🔤

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are interpreted as described in [RFC2119] 🫶. This doc also uses the terms defined in [RFC5201], [RFC6079], [RFC6028], and [RFC6940] 📖.

3. Peer Protocol 🧚

The peer protocol here is REsource LOcation And Discovery (RELOAD) [RFC6940] 💜. When you use RELOAD, HIP replaces RELOAD's Forwarding and Link Management Layer (the one described in Section 6.5 of [RFC6940]) 🔁.

4. Node ID Generation 🪪

This doc specifies two modes for generating Node and Resource IDs ✨. Which mode you use in a real overlay is set by the overlay configuration 🎛️. Both modes are based on the 16-byte ID mode of RELOAD, so only 16-byte RELOAD Node and Resource IDs MUST be used in a RELOAD HIP BONE 🙈.

HIP uses 128-bit Overlay Routable Cryptographic Hash Identifiers (ORCHIDs) [RFC4843] as its identifiers 🔐. In a RELOAD HIP BONE, a peer's ORCHID can be used as a RELOAD Node ID (the "ORCHID" mode) 🦋. In this mode, all the RELOAD IDs, Resource IDs included, get the ORCHID prefix, and the lower 100 bits of the IDs that RELOAD usage docs define come after that prefix 🌸.

The other Node ID mode is "RELOAD", where all 128 bits are generated as defined in [RFC6940] 🍓. That gives you a bigger usable address space than ORCHID mode does, but these Node IDs can't be used with legacy applications and APIs, as discussed in Section 5.1 of [RFC6079] 😭.

5. Mapping between Protocol Primitives and HIP Messages 🗺️

RELOAD HIP BONE swaps out the RELOAD protocol primitives that handle connection establishment for the HIP base exchange 🤝. The rest of the RELOAD messages ride inside HIP messages 🚀. The Forwarding and Link Management Layer functionality of RELOAD, NAT traversal included, is replaced by HIP, existing HIP extensions, and the extensions defined in this doc 💅.

A standard RELOAD message has three parts: the forwarding header, the message contents, and the security block 🎀. When RELOAD messages go over a RELOAD HIP BONE overlay, the RELOAD message contents get used as-is inside HIP DATA [RFC6078] messages 💌. The forwarding header and security block functionality is handled by the HIP header, HIP Destination and Via lists [RFC6028], CERT [RFC6253], TRANSACTION_ID [RFC6078], and the OVERLAY_ID and OVERLAY_TTL [RFC6079] parameters, as described in the sections below 👑.

5.1. Forwarding Header 🧭

The RELOAD forwarding header is for forwarding messages between peers and on to their final destination 📮. The forwarding header's overlay field value MUST be used as-is in an OVERLAY_ID parameter, and its transaction_id field goes in a TRANSACTION_ID parameter 🔑. So all RELOAD HIP BONE messages MUST contain these parameters 🫶. Also, the OVERLAY_ID parameter's identifier field is 4 long, and the TRANSACTION_ID parameter is 8 octets 📏. HIP Destination and Via lists do the same job as destination_list and via_list in the forwarding header, with one twist: all Resource IDs MUST be the same length as Node IDs, and compressed IDs MUST NOT be used 🙅‍♀️. The Time to Live (TTL) value in the OVERLAY_TTL parameter works like the ttl field in the forwarding header ⏳.

The fragment and length fields are handled by HIP headers 🧃. The relo_token, version, and max_response_length aren't needed with HIP 🙌. If the forwarding header's options field ends up being needed for some extensions, HIP parameters can stand in for it 🎉.

5.2. Security Block 🔏

The RELOAD security block holds the certificates and digital signatures for the message 🖋️. All HIP DATA messages are digitally signed by whoever originated them, and they contain the HOST_ID parameter with the identifier you need to verify the signature 🕵️‍♀️. Certificates get delivered in a HIP CERT parameter as defined in [RFC6253], or they can be stored in the overlay using the RELOAD Certificate Storage Usage 📦.

Note that when the RELOAD mode for Node ID generation is in use, the certificate proving a host can use a certain Node ID MUST contain the host's Node ID, not the Host Identity Tag (HIT), in the subjectAltName field, as described in Section 11.3 of [RFC6940] 🪄. The Subject field still holds the HIT calculated from the Host Identity 🧠.

5.3. Replaced RELOAD Messages 🔄

The Attach procedure in RELOAD sets up a connection between two peers, using AttachReq and AttachAns messages 🤙. With HIP, Attach is done with a HIP base exchange instead. Peers send HIP first Initiator (I1) messages in place of RELOAD AttachReq messages 🚪. This replaces the behavior described in Section 6.5 of [RFC6940] 💫.

The AppAttach procedure in RELOAD creates a connection for applications other than RELOAD 🧑‍💻. In this setup, AppAttach gets replaced by the HIP base exchange too. After that base exchange, peers can swap any application layer data over the normal transport layer ports, through the NAT-traversing IPsec connection 🔐.

This spec doesn't support flooding of configuration files, so ConfigUpdate requests and responses (Section 6.5.4 of [RFC6940]) MUST NOT be sent in the overlay 🚫. RELOAD Ping messages (Section 6.5.3 of [RFC6940]) MAY be used 🏓.

For every other RELOAD message, the message contents get used as-is inside HIP DATA messages 💕.

6. Securing Communication 🔒

RELOAD uses Transport Layer Security (TLS) [RFC5246] connections to secure the hop-by-hop messaging, and certificates and signatures to provide integrity protection for overlay messages and for data stored in the overlay 🛡️.

With a RELOAD HIP BONE, you don't use the TLS connections defined in [RFC6940] 🙅‍♀️. Instead, all HIP overlay messages MUST be sent over encrypted connections [RFC6261] 🔐✨.

Data objects stored in the RELOAD HIP BONE overlay are signed, and their signatures are stored as defined in [RFC6940]. The one difference is that SignerIdentity rides in the HIP DATA message's HOST_ID parameter instead of the RELOAD security block 🎯. When certificates are needed, they get sent in the HIP CERT parameter 💅.

7. Routing HIP Messages via the Overlay ✨

okay so, if a host has no valid locator for the receiver of a brand new HIP packet, and the receiver is part of a RELOAD HIP BONE overlay that the host is in, the host can send that packet using overlay routing 🦋 main character routing energy.

When a host sends a HIP packet via the overlay, it MUST add an empty ROUTE_VIA parameter [RFC6028] to the packet. That parameter needs the SYMMETRIC and MUST_FOLLOW flags set. It also needs an OVERLAY_ID parameter holding the identifier of the right overlay network 🎀. Then the host asks the RELOAD Topology Plugin who the next hop is and sends the packet there 💅.

An intermediate host that gets a HIP packet with the OVERLAY_ID parameter first checks whether it's even in that overlay. If it isn't, it SHOULD drop packets sent to unknown overlays 🙈. If the host isn't the final destination (so the Receiver HIT in the HIP header doesn't match any of its HITs), it looks for a ROUTE_DST parameter. Packets that have one get forwarded to the next hop as [RFC6028] says. If there's no ROUTE_DST parameter, the host grabs the next hop from the RELOAD Topology Plugin and forwards the packet there 🧚. And just like [RFC6028] describes, the host adds the HIT it uses on the HIP association with the next-hop host to the end of the ROUTE_VIA parameter, if one is present 🌈.

When the final destination gets the HIP packet, it processes it as [RFC5201] describes. If the packet is a HIP DATA packet, the contents get processed as [RFC6940] describes 😭. If the HIP packet makes a response, that response goes back the same way it came, using the ROUTE_DST parameter as specified in [RFC6028] 🔥.

8. Enrollment and Bootstrapping 🌸

The RELOAD HIP BONE instance uses the enrollment and bootstrap procedure from RELOAD [RFC6940], with a few exceptions listed below 💜.

  • In RELOAD, a node that wants to join an overlay starts by getting a configuration document, as [RFC6940] explains. This spec extends the RELOAD overlay configuration document, which is defined in Section 10 🫶.
  • The X.509 certificates used by the RELOAD HIP BONE instance are basically like RELOAD's, except they hold HITs instead of RELOAD URIs. The HITs go in the SubjectAltName field of the certificate, as described in [RFC6253] ✨.
  • When contacting a bootstrap node, a host MUST do a HIP base exchange with that node instead of forming a Datagram Transport Layer Security (DTLS) or TLS connection 🎀. The base exchange MAY be done through a HIP rendezvous or relay server 🦋.

9. NAT Traversal 🌈

RELOAD depends on the Forwarding and Link Management Layer to provide NAT traversal. So RELOAD HIP BONE instance implementations MUST implement some reliable NAT traversal mechanism 🔥. For the best interoperability, all implementations SHOULD implement at least [RFC5770] 💅.

HIP relay servers aren't necessarily needed with this HIP BONE instance, since the overlay network can relay the base exchange, and further HIP signaling can happen directly between peers 🧚. But if a bootstrap peer might be behind a NAT, it MUST register with a HIP relay so there's a reliable way to reach it 😭🫶.

10. RELOAD Overlay Configuration Document Extension 📜

This document changes the bootstrap-node element of the RELOAD overlay configuration document 💖. The modified bootstrap-node element has these attributes:

  • address: The locator of the bootstrap node.
  • port: The HIP port of the bootstrap node.
  • hit: The HIT of the bootstrap node.

If the bootstrap-node element doesn't have a HIT, the opportunistic mode (as specified in [RFC5201]) SHOULD be used to contact the bootstrap node 👀. If the element doesn't have a port number, the bootstrap node SHOULD be contacted by starting the base exchange as defined in [RFC5201] ✨. Otherwise, the base exchange MUST be started with UDP encapsulation, as defined in [RFC5770], using the given port as the destination port number 🌸.

A RELOAD HIP BONE overlay MUST use the Overlay Link Protocol type "HIP" in the overlay-link-protocol element of the configuration document 🍓. The enrolling node MUST check the overlay-link-protocol element, and it should only follow the procedures in this document if it finds the "HIP" link type 🙈.

This document also adds a new element inside the configuration element. This one decides which mode (see Section 4) gets used to generate the Node and Resource IDs 🌈. The element is called hipbone-id-mode, and its content is the identifier of the mode. "ORCHID" means the ORCHID prefixed IDs, and "RELOAD" means the IDs that use the whole 128 bits, as RELOAD defines them 💜. The NodeIdLength MUST be set to 16 in the configuration document. Depending on the generation mode, the 16 bytes are used as defined in Section 4 🧚.

11. Security Considerations 💀

Okay, this part is serious bestie 🚨. The security considerations of RELOAD (Section 13 of [RFC6940]) also apply to RELOAD HIP BONE instances, except for the TLS-specific features 🔐.

Limiting the Node ID and Resource ID space to 128 bits (or 100 bits with ORCHID prefixes) means there's a higher chance of ID collisions. That goes for both accidental and intentional ones, compared to using larger address spaces 😱. So be careful with that 🫣.

12. IANA Considerations 📋

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

IANA has updated the "RELOAD Overlay Link Protocol Registry" [RFC6940] by assigning the new Overlay Link Protocol type "HIP" (see Section 10) 🎀.

13. Acknowledgements 🫶

Tom Henderson, Spencer Dawkins, and Christer Holmberg gave valuable reviews and comments on the document 💖 thank you queens 👑.

14. References 📚

14.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., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
  • [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
  • [RFC5770] Komu, M., Henderson, T., Tschofenig, H., Melen, J., and A. Keranen, "Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators", RFC 5770, April 2010.
  • [RFC6028] Camarillo, G. and A. Keranen, "Host Identity Protocol (HIP) Multi-Hop Routing Extension", RFC 6028, October 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.
  • [RFC6079] Camarillo, G., Nikander, P., Hautakorpi, J., Keranen, A., and A. Johnston, "HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE)", RFC 6079, January 2011.
  • [RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol Certificates", RFC 6253, May 2011.
  • [RFC6261] Keranen, A., "Encrypted Signaling Transport Modes for the Host Identity Protocol", RFC 6261, May 2011.
  • [RFC6940] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", January 2014.

14.2. Informative References

  • [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.

Authors' Addresses 🦋

Ari Keranen
Ericsson
Hirsalantie 11
02420 Jorvas
Finland

EMail: Ari.Keranen@ericsson.com


Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas  02420
Finland

EMail: Gonzalo.Camarillo@ericsson.com


Jouni Maenpaa
Ericsson
Hirsalantie 11
Jorvas  02420
Finland

EMail: Jouni.Maenpaa@ericsson.com

that's the whole spec, bestie 🌈💖✨ you did amazing 👑

📦 where this page comes from