REsource LOcation And Discovery (RELOAD) Base Protocol
Extracted elements (29)
RELOAD uses a single protocol for both peers and clients to simplify implementation for devices that may act in either role and to allow clients to inject messages directly into the overlay using the same security mechanisms. Clients are not first-class entities from a peer's perspective, localizing routing and storage complexity to nodes that opt into full peer participation.
Symmetric recursive routing was chosen over iterative routing because it naturally supports NAT traversal (responses follow the existing request path without the responder initiating a new connection), keeps state low on intermediate peers, and allows re-routing in unstable topologies via end-to-end retransmission.
The Message Transport layer omits end-to-end congestion control because RELOAD is a request-response protocol with at most two request-response pairs per typical transaction, providing no opportunity to observe and react to congestion. Congestion control is handled at the link layer between overlay neighbors.
The Topology Plug-in architecture was chosen to allow structured (DHT) and unstructured overlay algorithms to share a common RELOAD protocol framework. Chord is mandatory-to-implement for baseline interoperability while the pluggable interface allows algorithm selection optimized for specific applications.
TLS over TCP and DTLS over UDP are the only currently defined mandatory overlay link protocols. The specification defines extension points for future overlay link protocols (HIP, ICE-TCP, message-oriented transports, tunneled transports) via the IANA Overlay Link Protocols registry and the overlay Configuration Document.
Connections between RELOAD nodes MUST be secured with TLS or DTLS at the overlay link layer. Each node uses its certificate for peer authentication, forming TLS or DTLS associations with mutual client authentication.
Each node MUST have a certificate containing its Node-ID in a subjectAltName extension, unique within the overlay instance. The Node-ID is tightly coupled to the certificate and serves for addressing, topology placement, and resource responsibility determination.
Each stored data value MUST be individually digitally signed by the node that created it, and the signature MUST be stored alongside the data value. This allows any reader to verify data integrity and the responsible peer to verify Store authorization.
Every RELOAD message MUST be signed by its originating node, providing message-level integrity and authentication. Objects stored in the overlay are additionally signed by the creating node at the object level.
The Chord-based DHT algorithm is mandatory to implement for all RELOAD implementations. This promotes interoperability while still allowing extensibility for alternative overlay algorithms specified via configuration.
The initial Configuration Document MUST be fetched over HTTPS or manually provisioned via an out-of-band method that provides authentication and integrity, because the document contains the trust anchors used by the overlay.
When self-signed certificates are used, the Node-ID MUST be computed as a digest of the public key to prevent Node-ID theft. The required cryptographic property is partial preimage resistance; collision resistance is not needed.
A Destination List is a strict-ordered list of Node-IDs, Resource-IDs, and Opaque IDs through which a message is routed, providing loose source routing. The minimal Destination List contains a single value; the list is reduced hop-by-hop and does not include the source.
Each intermediate peer appends to the Via List as a message traverses the overlay. A peer may optionally truncate the Via List into an Opaque ID (e.g., an encryption of the full list), storing the mapping internally keyed by transaction ID to recover the path when the response arrives.
Four access control policies are defined: USER-MATCH (only the certificate owner matching the stored user name may write), NODE-MATCH (only the node whose Node-ID matches may write), USER-NODE-MATCH (both user name and Node-ID must match), and NODE-MULTIPLE (each node may store one value under its own Node-ID key).
RELOAD defines four data storage methods: Store (write data to the overlay), Fetch (retrieve data values), Stat (retrieve metadata without values), and Find (locate the peer responsible for a given Resource-ID). Each has distinct request and response message formats.
RELOAD defines three data models for overlay storage: single value (at most one item, new value overwrites previous), array (multiple values addressed by numeric index), and dictionary (values indexed by a key, often derived from the storing node's certificate).
RELOAD uses symmetric recursive routing as its primary routing mechanism: requests traverse the overlay hop-by-hop toward the destination, and responses follow the same path back. Each intermediate peer appends its identity to the Via List, which is inverted to form the response Destination List.
The Attach method uses ICE to establish direct RELOAD connections through NATs. The initiating node gathers ICE candidates and routes an Attach request through the overlay; the responding node returns its candidates in the response and ICE connectivity checks then proceed between the two nodes.
The Chord topology plugin uses a ring DHT where each peer maintains a neighbor table of immediately adjacent peers and a finger table for O(log N) routing. Routing proceeds by forwarding messages to the peer closest to the target Resource-ID in the identifier space.
IANA created numerous registries for RELOAD, including: Overlay Algorithm Types (with 'CHORD-RELOAD' as initial entry), Access Control Policies (USER-MATCH, NODE-MATCH, USER-NODE-MATCH, NODE-MULTIPLE), Data Kind-ID (SIP Registration, TURN Service), Message Codes, Error Codes, Overlay Link Protocols, Forwarding Options, Probe Information Types, and Message Extensions.
IANA registered the 'reload' URI scheme for RELOAD resource addressing, the 'application/p2p-overlay+xml' media type for Configuration Documents, the well-known URI 'reload-config', and port 6084 for RELOAD over both TLS/TCP and DTLS/UDP.
RELOAD's certificate-based security relies on a central enrollment server issuing unique Node-IDs and certificates. The enrollment server's ability to prevent attackers from obtaining large numbers of certificates is a primary defense against Sybil attacks on the P2P overlay.
Routing security is protected through admissions control (certificate-based enrollment limits who can join), peer identification and authentication (TLS/DTLS with mutual auth on every connection), and protection against routing loops and DoS amplification. Residual attacks from compromised insiders that hold valid certificates cannot be fully prevented.
Self-signed certificate mode is subject to Sybil attacks and is safe only in closed, mutually trusting networks. Even in this mode, all security mechanisms (TLS/DTLS and message signatures) remain active; the only difference is that certificate verification does not chain to a single trusted root.
Storage security is addressed through authorization (every Store request is verified against the Kind's access control policy via the stored digital signature), distributed quota enforcement (limiting storage burden per node), and correctness verification (readers can check data integrity via signatures). Residual attacks include the responsible peer silently losing data.
The overlay join process for a new peer proceeds through states: connect to a bootstrap node, send a Join request to the Admitting Peer (AP), receive Join response and data Stores from AP, receive routing table Updates from AP, then form independent connections to become a full peer. The first node in an overlay is a special case that skips connecting to bootstrap nodes.
A Framing Header encapsulates RELOAD messages at each overlay link hop, supporting per-hop reliability, congestion control, and flow control. It has meaning only in the context of a single link and is used with both DTLS/UDP and TLS/TCP overlay link protocols.
Each RELOAD message consists of three parts: a Forwarding Header (routing metadata including Destination List, Via List, and configuration sequence numbers), a Message Contents block (method-specific payload and response/error codes), and a Security Block (certificates and message signatures).