Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD)
Combining HIP and RELOAD to build peer-to-peer networks where devices are identified by cryptographic credentials instead of IP addresses.
Keranen, A., Camarillo, G., and J. Maenpaa, "Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD)", RFC 7086, DOI 10.17487/RFC7086, January 2014, <https://www.rfc-editor.org/info/rfc7086>.
@misc{rfc7086,
series = {Request for Comments},
number = 7086,
howpublished = {RFC 7086},
publisher = {RFC Editor},
doi = {10.17487/RFC7086},
url = {https://www.rfc-editor.org/info/rfc7086},
author = {A. Keranen and G. Camarillo and J. Maenpaa},
title = {{Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD)}},
pagetotal = 10,
year = 2014,
month = jan,
} RFC text
Contents
Internet Engineering Task Force (IETF) A. Keranen
Request for Comments: 7086 G. Camarillo
Category: Experimental J. Maenpaa
ISSN: 2070-1721 Ericsson
January 2014
Host Identity Protocol-Based Overlay Networking Environment (HIP BONE)
Instance Specification for REsource LOcation And Discovery (RELOAD)
Abstract
This document is the HIP-Based Overlay Networking Environment (HIP
BONE) instance specification for the REsource LOcation And Discovery
(RELOAD) protocol. The document provides the details needed to build
a RELOAD-based overlay that uses HIP.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. This document is a product of the Internet Engineering
Task Force (IETF). It represents the consensus of the IETF
community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are a candidate for any level of
Internet Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7086.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without 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) specification
[RFC6079] provides a high-level framework for building HIP-based
[RFC5201] overlays. The HIP BONE framework does not address the
specification of the details on how to combine a particular peer
protocol with HIP to build an overlay. It leaves this up to
documents referred to as HIP BONE instance specifications. As
discussed in [RFC6079], a HIP BONE instance specification needs to
define, minimally:
o the peer protocol to be used.
o what kind of Node IDs are used and how they are derived.
o which peer protocol primitives trigger HIP messages.
o how the overlay identifier is generated.
This document addresses all the previous items and provides
additional details needed to build RELOAD-based HIP BONEs, referred
to here as RELOAD HIP BONEs. The details on how different RELOAD
modules would be integrated to a HIP implementation and what kind of
APIs are used between them are left as implementation details or to
be defined by other documents.
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 [RFC2119]. In
addition, this document uses the terms defined in [RFC5201],
[RFC6079], [RFC6028], and [RFC6940].
3. Peer Protocol
The peer protocol to be used is REsource LOcation And Discovery
(RELOAD) [RFC6940]. When used with RELOAD, HIP replaces the RELOAD's
Forwarding and Link Management Layer (described in Section 6.5 of
[RFC6940]).
4. Node ID Generation
This document specifies two modes for generating Node and Resource
IDs. Which mode is used in an actual overlay is defined by the
overlay configuration. Both of the modes are based on 16-byte ID
mode of RELOAD; hence, 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 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, including Resource IDs, are prefixed with
the ORCHID prefix, and the lower 100 bits of the IDs defined by
RELOAD usage documents are used after the prefix.
In the other Node ID mode, namely "RELOAD", all 128 bits are
generated as defined in [RFC6940]. This results in a larger usable
address space than using the ORCHID mode, but the resulting Node IDs
cannot 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 replaces the RELOAD protocol primitives taking care
of connection establishment with the HIP base exchange, whereas the
rest of the RELOAD messages are conveyed within HIP messages. The
Forwarding and Link Management Layer functionality of RELOAD,
including all the NAT traversal functionality, is replaced by HIP,
existing extensions of HIP, and the extensions defined in this
document.
The standard RELOAD messages consist of three parts: the forwarding
header, the message contents, and the security block. When RELOAD
messages are sent in a RELOAD HIP BONE overlay, the RELOAD message
contents are used as such within HIP DATA [RFC6078] messages, but the
functionality of the forwarding header and security block are
replaced with the HIP header, HIP Destination and Via lists
[RFC6028], CERT [RFC6253], TRANSACTION_ID [RFC6078], and the
OVERLAY_ID and OVERLAY_TTL [RFC6079] parameters, as defined in the
following sections.
5.1. Forwarding Header
The RELOAD forwarding header is used for forwarding messages between
peers and to their final destination. The forwarding header's
overlay field value MUST be used as such in an OVERLAY_ID parameter
and the transaction_id field in a TRANSACTION_ID parameter. That is,
all RELOAD HIP BONE messages MUST contain these parameters; and, the
length of the OVERLAY_ID parameter's identifier field is 4, and the
length of the TRANSACTION_ID parameter is 8 octets. HIP Destination
and Via lists are used for the same purpose as the destination_list
and via_list in the forwarding header, with the exception that all
Resource IDs MUST be of the same length as Node IDs, and compressed
IDs MUST NOT be used. The Time to Live (TTL) value in the
OVERLAY_TTL parameter is used like the ttl field in the forwarding
header.
The functionality of the fragment and length fields are provided by
the HIP headers. The relo_token, version, and max_response_length
are not needed with HIP. The forwarding header's options field, if
needed eventually for some extensions, can be substituted with
additional HIP parameters.
5.2. Security Block
The RELOAD security block contains certificates and digital
signatures of the message. All the HIP DATA messages are digitally
signed by the originator of the message and contain the HOST_ID
parameter with the identifier that can be used for verifying the
signature. Certificates are delivered in a HIP CERT parameter as
defined in [RFC6253] or stored to the overlay using the RELOAD
Certificate Storage Usage.
Note that when the RELOAD mode for Node ID generation is used, the
certificate certifying that a host is allowed to use a certain Node
ID MUST contain the host's Node ID instead of the Host Identity Tag
(HIT) in the "subjectAltName" field of the certificate as described
in Section 11.3 of [RFC6940], while the "Subject" field contains the
HIT calculated from the Host Identity.
5.3. Replaced RELOAD Messages
The Attach procedure in RELOAD establishes a connection between two
peers. This procedure is performed using the AttachReq and AttachAns
messages. When HIP is used, the Attach procedure is performed by
using a HIP base exchange. That is, peers send HIP first Initiator
(I1) messages instead of RELOAD AttachReq messages. This behavior
replaces the one described in Section 6.5 of [RFC6940].
The AppAttach procedure in RELOAD is used for creating a connection
for other applications than RELOAD. Also, the AppAttach procedure is
replaced with the HIP base exchange, and after the base exchange,
peers can exchange any application layer data using the normal
transport layer ports over the NAT traversing IPsec connection.
This specification does not 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 all other RELOAD messages, the message contents are used as such
within HIP DATA messages.
6. Securing Communication
RELOAD uses Transport Layer Security (TLS) [RFC5246] connections for
securing the hop-by-hop messaging and certificates and signatures for
providing integrity protection for the overlay messages and for the
data stored in the overlay.
With a RELOAD HIP BONE, instead of using TLS connections as defined
in [RFC6940], all HIP overlay messages MUST be sent using encrypted
connections [RFC6261].
The data objects stored in the RELOAD HIP BONE overlay are signed,
and the signatures are stored as defined in [RFC6940] with the
exception that SignerIdentity is carried in the HIP DATA message's
HOST_ID parameter instead of using the RELOAD security block. Where
certificates are needed, they are sent using the HIP CERT parameter.
7. Routing HIP Messages via the Overlay
If a host has no valid locator for the receiver of a new HIP packet,
and the receiver is part of a RELOAD HIP BONE overlay the host is
participating in, the host can send the HIP packet to the receiver
using the overlay routing.
When sending a HIP packet via the overlay, the host MUST add an empty
ROUTE_VIA parameter [RFC6028] to the packet with the SYMMETRIC and
MUST_FOLLOW flags set and an OVERLAY_ID parameter containing the
identifier of the right overlay network. The host consults the
RELOAD Topology Plugin for the next hop and sends the HIP packet to
that host.
An intermediate host receiving a HIP packet with the OVERLAY_ID
parameter checks if it is participating in that overlay and SHOULD
drop packets sent to unknown overlays. If the host is not the final
destination of the packet (i.e., the Receiver HIT in the HIP header
does not match to any of its HITs), it checks if the packet contains
a ROUTE_DST parameter. Such packets are forwarded to the next hop as
specified in [RFC6028]. If the packet does not contain a ROUTE_DST
parameter, the host finds the next hop from the RELOAD Topology
Plugin and forwards the packet there. As specified in [RFC6028], 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 present.
When the final destination host receives the HIP packet, the host
processes it as specified in [RFC5201]; and, if the packet is a HIP
DATA packet, the contents are processed as specified in [RFC6940].
If the HIP packet generates a response, the response is routed back
on the same path using the ROUTE_DST parameter as specified in
[RFC6028].
8. Enrollment and Bootstrapping
The RELOAD HIP BONE instance uses the enrollment and bootstrap
procedure defined by RELOAD [RFC6940] with the exceptions listed
below.
o In RELOAD, a node wishing to enroll in an overlay starts with
obtaining a configuration document as explained in [RFC6940].
This specification extends the RELOAD overlay configuration
document as defined in Section 10.
o The X.509 certificates used by the RELOAD HIP BONE instance are
similar to those of RELOAD except that they contain HITs instead
of RELOAD URIs. The HITs are included in the SubjectAltName field
of the certificate as described in [RFC6253].
o When contacting a bootstrap node, instead of forming a Datagram
Transport Layer Security (DTLS) or TLS connection, the host MUST
perform a HIP base exchange with the bootstrap node. The base
exchange MAY be performed using a HIP rendezvous or relay server.
9. NAT Traversal
RELOAD relies on the Forwarding and Link Management Layer providing
NAT traversal capabilities. Thus, the RELOAD HIP BONE instance
implementations MUST implement some reliable NAT traversal mechanism.
To maximize interoperability, all implementations SHOULD implement at
least [RFC5770].
HIP relay servers are not necessarily needed with this HIP BONE
instance since the overlay network can be used for relaying the base
exchange, and further HIP signaling can be done directly between the
peers. However, if it is possible that a bootstrap peer is behind a
NAT, it MUST register with a HIP relay so that there is a reliable
way to connect to it.
10. RELOAD Overlay Configuration Document Extension
This document modifies the bootstrap-node element of the RELOAD
overlay configuration document. The modified bootstrap-node element
contains the following 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 does not contain a HIT, the
opportunistic mode (as specified in [RFC5201]) SHOULD be used for
contacting the bootstrap node. If the element does not contain 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 configuration document's overlay-link-protocol element.
The enrolling node MUST check the overlay-link-protocol element and
proceed with procedures defined in this document only if the "HIP"
link type is found.
This document also adds a new element inside the configuration
element that defines which mode (see Section 4) is used for
generating the Node and Resource IDs. The name of the element is
"hipbone-id-mode" and the content is the identifier of the mode:
"ORCHID" for the ORCHID prefixed IDs and "RELOAD" for the IDs that
use the whole 128 bits as defined by the RELOAD specification. The
NodeIdLength MUST be set to 16 in the configuration document, and the
16 bytes are used, depending on the generation mode, as defined in
Section 4.
11. Security Considerations
The security considerations of RELOAD (Section 13 of [RFC6940]), with
the exception of TLS-specific features, also apply to RELOAD HIP BONE
instances.
Limiting the Node ID and Resource ID space into 128 bits (or 100 bits
with ORCHID prefixes) results in a higher probability for ID
collisions, both unintentional and intentional, than using larger
address spaces.
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 have provided
valuable reviews and comments on the document.
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
AI ELI5
On this page
§1Introduction
RFC 7086 is an instance specification for the HIP BONE (Host Identity Protocol Based Overlay Networking Environment) framework. HIP BONE is a method of building overlay networks using the Host Identity Protocol (HIP) as the foundation. This RFC takes that framework and shows how to plug in RELOAD (REsource LOcation And Discovery), a protocol designed for peer-to-peer resource discovery and DHT-like overlays.
HIP separates identity from location by assigning each host a fixed 128-bit identifier called a Host Identity Tag (HIT), derived from the host's public key. This HIT is decoupled from the IP address, so a host can move, change networks, or have multiple addresses while keeping its HIT the same. RELOAD is a base protocol for distributed hash tables and resource discovery in peer-to-peer networks; it was originally designed to work with TLS for security and hop-by-hop messaging.
HIP BONE RELOAD combines them: RELOAD overlays use HIP for transport, identity, and link management instead of TLS and IP-based routing, allowing nodes to discover each other and share data without relying on stable IP addresses or centralized infrastructure.
HIP gives devices a permanent ID card they carry wherever they go. RELOAD is a way for devices to find each other and share lists of things they know about. This RFC tells you how to use HIP cards inside a RELOAD network.
§2Core Design
In a RELOAD HIP BONE overlay, RELOAD replaces its standard Forwarding and Link Management Layer (which uses TLS and RELOAD-specific messages) with HIP. Two nodes wanting to communicate perform a HIP base exchange to establish an encrypted, authenticated connection, and then all subsequent RELOAD messages are wrapped in HIP DATA messages. This design gives the overlay several properties: every message is signed and can be verified to come from a specific HIT, encryption is transparent and mandatory, and nodes can route HIP packets through intermediate overlay peers without needing direct IP connectivity.
The specification also defines how RELOAD's core procedures map to HIP. The Attach procedure, which in standard RELOAD uses AttachReq/AttachAns messages to establish connections between peers, is replaced by the HIP base exchange (I1, R1, I2, R2 messages). AppAttach, which RELOAD uses for generic applications, is also replaced by the HIP base exchange followed by encrypted communication over a NAT-traversing tunnel.
Instead of having RELOAD build its own connections, it borrows HIP's strong, encrypted handshake. After the handshake, RELOAD packets just ride inside HIP messages. This way, every step is cryptographically signed and nobody has to set up TLS on the side.
§3Node Identifiers and Message Structure
RELOAD uses 16-byte node IDs (128 bits) to locate peers in the hash table. HIP BONE RELOAD specifies two modes for generating these IDs. In ORCHID mode, the Node ID is a HIP ORCHID (Overlay Routable Cryptographic Hash Identifier), a 128-bit value with a fixed ORCHID prefix in the first 28 bits, leaving 100 bits for the overlay-specific ID. In RELOAD mode, all 128 bits are generated as plain RELOAD would define them, giving a larger usable space but at the cost of incompatibility with legacy HIP applications that expect ORCHID format.
When a RELOAD HIP BONE message is sent, the RELOAD forwarding header (which carries transaction IDs, destination lists, and TTL) is replaced by HIP parameters: OVERLAY_ID for the overlay identifier, TRANSACTION_ID for message correlation, and HIP Destination and Via lists (from RFC 6028) for multi-hop routing. The security block that would normally contain RELOAD certificates and signatures is replaced by HIP's HOST_ID parameter (which carries the sender's HIT) and HIP CERT parameter (for certificates).
A node's address in the overlay is based on its HIP identity card. There are two ways to write the address: the strict way (ORCHID) that HIP apps understand, or the full way (RELOAD) that gives more room. When passing messages, HIP headers carry the routing info instead of RELOAD's header.
§4Routing and Connectivity
In HIP BONE RELOAD, message forwarding relies on HIP's multi-hop routing extension (RFC 6028). When a peer wants to send a message to a peer it knows only by HIT and not by IP address, it adds an OVERLAY_ID parameter and a ROUTE_VIA parameter to the HIP packet and sends it to the next hop in the RELOAD topology. Intermediate peers check the OVERLAY_ID to verify the packet is for their overlay, and if they are not the final destination, they consult the RELOAD Topology Plugin to find the next hop and forward the packet, appending their own HIT to the ROUTE_VIA list.
NAT traversal is handled by HIP's existing extensions, primarily RFC 5770, which allows HIP packets to be sent over UDP and provides mechanisms for traversing firewalls and NATs. The document recommends that implementations support at least RFC 5770 for maximum interoperability. HIP relay servers can assist with NAT traversal, particularly when bootstrap nodes are behind NATs.
Responses travel back along the reverse path encoded in ROUTE_DST, ensuring that even if the return path has changed, the response still reaches the originator. This design allows overlay peers to relay each other's traffic, solving the problem of peer discovery and communication in networks where direct IP paths may not exist.
When one node sends to another, it might not have a direct path. So it sends the message through the overlay network, hopping from peer to peer. Each hop adds a note saying 'I forwarded this,' so the response knows how to get back. HIP's built-in NAT tricks help peers find each other even if they are behind firewalls.
§5Enrollment, Bootstrapping, and Configuration
When a new node wants to join a HIP BONE RELOAD overlay, it first obtains an overlay configuration document (as in standard RELOAD) that describes the overlay's topology, certificate authorities, and parameters. This document is extended with two new elements: the hipbone-id-mode element, which specifies whether the overlay uses ORCHID or RELOAD mode for node IDs, and updated bootstrap-node specifications that include the bootstrap peer's HIT and the HIP port, instead of RELOAD URIs.
Instead of forming a DTLS or TLS connection to a bootstrap node, the new node performs a HIP base exchange with the bootstrap node. After the exchange, the two peers can communicate over an encrypted HIP connection. The enrolling node then obtains the overlay configuration document and any certificates needed to authenticate itself to other peers. The certificates used in HIP BONE RELOAD are X.509 certificates but with HITs in the SubjectAltName field instead of RELOAD URIs; when RELOAD mode is used, the certificate's subject field contains the HIT but the subjectAltName contains the node's assigned RELOAD Node ID.
A RELOAD HIP BONE overlay MUST declare the overlay-link-protocol type as HIP in the configuration document. An enrolling node checks for this element and proceeds only if the overlay specifies HIP, ensuring compatibility between the client and the overlay operator's expectations.
A new member asks a friend for the rulebook and the password. The rulebook says 'we use HIP IDs' and lists a few friends to ask. The new member shakes hands with a friend (HIP base exchange), gets the rules and a certificate, and is in.
§6Security Considerations
HIP BONE RELOAD inherits the security model of both RELOAD and HIP. All overlay messages are cryptographically signed by their originator (using the HOST_ID parameter) and can be verified against that peer's HIT. Communication between peers is encrypted using HIP's encrypted transport modes (RFC 6261). Unlike standard RELOAD, which uses TLS for hop-by-hop encryption and RELOAD certificates for application-level authentication, HIP BONE RELOAD uses only HIP-level encryption, so the encryption is uniform across all peers and requires no separate TLS setup.
The RFC inherits RELOAD's security considerations regarding identity verification, data integrity, and overlay management. However, limiting node and resource IDs to 128 bits (or 100 bits with ORCHID prefixes) introduces a higher collision probability than larger address spaces, both for accidental collisions and intentional attacks. The document defers detailed security analysis to the base RELOAD and HIP specifications.
Every message carries a signature, like a wax seal. Encryption happens automatically between peers. Because everyone is known by a cryptographic ID, forging a message is hard. But with 128 bits instead of larger numbers, two people might randomly get the same ID—unlikely but not impossible.