This specification defines an XMPP Usage of REsource LOcation And Discovery (RELOAD). The XMPP usage provides an ability for XMPP clients to discover other peers' location through the peer-to-peer overlay. Once a peer location is determined, the RELOAD AppAttach method is used to establish a direct connection between peers through which XMPP streams are exchanged.
Evgeny Khramtsov
© 1999 – 2020 XMPP Standards Foundation. SEE LEGAL NOTICES.


WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document is not yet an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <http://xmpp.org/extensions/> and announced on the <standards@xmpp.org> mailing list.
Standards Track
0.0.1 (2019-02-08)
Document Lifecycle
  1. Experimental
  2. Proposed
  3. Draft
  4. Final

1. Introduction

REsource LOcation And Discovery (RELOAD) (RFC6940) specifies a peer-to-peer (P2P) signaling protocol for general use on the Internet. This document defines an XMPP Usage of RELOAD that allows XMPP clients to establish peer-to-peer XMPP streams without routing them through XMPP servers.

The XMPP Usage involves two basic functions:

  1. Address Location: XMPP clients can use the RELOAD data storage functionality to store a mapping from their XMPP address to their Node-ID in the overlay and to retrieve the Node-ID of other clients.
  2. Rendezvous: Once an XMPP client has identified the Node-ID for an XMPP address it wishes to contact, it can use the RELOAD message routing system to set up a direct connection for exchanging XMPP streams.

Mappings are stored in the XmppLocation Resource Record defined in this document. All operations required to perform an XMPP address location or rendezvous are standard RELOAD protocol methods.

Note: XMPP stanzas are not routed through the overlay and are not stored therein.

For example, Romeo registers location of his XMPP address, "romeo@montague.lit", for his Node-ID "1234". When Juliet wants to contact Romeo, she queries the overlay for "romeo@montague.lit" and receives Node-ID "1234" in return. She then uses the overlay routing to establish a direct connection with Romeo and can directly start a standard XMPP stream. In detail, this works along the following steps:

 Juliet      Peer1     ...          PeerN    Romeo
 (5678)                                     (1234)
 AppAttach ->
             AppAttach ->
                       AppAttach ->
                                   AppAttach ->
                                      <- AppAttach
                             <- AppAttach
                  <- AppAttach
      <- AppAttach

 <------------------ ICE Checks ----------------->
 ---------------- XMPP stream start ------------->
 <--------------- XMPP stream start --------------
 ---------------- XMPP stream end --------------->
 <--------------- XMPP stream end ----------------

Direct XMPP streams exchange will be documented in follow-up extensions. So far, a possible way is described in Link-Local Messaging (XEP-0174) [1], although this method interacts badly with the ordinary XMPP client-to-server connection and message replication accross user devices.

It is important to note that the XMPP Usage of RELOAD is not intended to replace the existing XMPP servers infrastructure as it looks unrealistic, at least currently. Instead, the overlay connection is designed to be working along with the ordinary XMPP client-to-server connection in order to provide backward compatibility, reliable offline message delivery and multicasting. However, some clients MAY decide to maintain the overlay connection only. As an example, such scenario is possible in the video game industry where all clients are stationary (e.g. desktop) clients with persistent broadband Internet connection, without battery restrictions and no need to receive offline messages.

2. Requirements


3. Glossary

REsource LOcation And Discovery (RFC6940) - a P2P signaling protocol for general use on the Internet. The terminology and definitions from this protocol are used extensively in this document.
Address Location
One or many RELOAD Node-IDs to which a peer-to-peer connection can be established in order to contact an owner of the XMPP address.

4. Storing an Address Location

4.1 Overview

In XMPP Core RFC 6120 [2], a client fully relies on servers for its XMPP address location. In XMPP Usage of RELOAD, this location function is provided by the overlay as a whole. To register its location, a RELOAD peer stores an XmppLocation Resource Record for its own XMPP address using the XMPP-LOCATION Kind, which is formally defined below. Note that if a client wishes to set the location lifetime it MUST use lifetime of the basic RELOAD StoredData structure (see Section 7 of RFC6940).

As a simple example, consider Juliet with an XMPP address "juliet@capulet.lit" at Node-ID "1234". She might store the mapping "juliet@capulet.lit -> 1234" telling anyone who wants to contact her to establish a direct XMPP stream with node "1234".

RELOAD peers can store two kinds of XMPP mappings,

The meaning of the first kind of mapping is "in order to contact me, form a connection with this Peer". The meaning of the second kind of mapping is "in order to contact me, dereference this XMPP address". The latter allows for forwarding. For instance, if Juliet wants her messages to be forwarded to Romeo, she might insert the following mapping: "juliet@capulet.lit -> romeo@montague.lit".

4.2 Data Structure

The XmppLocation Resource Record is defined as follows:

 enum {
 } XmppLocationType;

 select (XmppLocation.type) {
   case xmpp_location_address:
     opaque            address<0..2^16-1>;

   case xmpp_location_route:
     uint8             priority;
     Destination       destination_list<0..2^16-1>;

   /* This type can be extended */

 } XmppLocationData;

 struct {
    XmppLocationType   type;
    uint16             length;
    XmppLocationData   data;
 } XmppLocation;

The contents of the XmppLocation Resource Record are:

the type of the location
the length of the rest of the PDU
the location data

4.3 Multiple Locations

The XMPP Usage explicitly supports multiple locations for a single XMPP address. The locations are stored in a dictionary with Node-IDs as the dictionary keys. Consider, for instance, the case where Juliet has two Peers:

Juliet might store the following in the overlay at resource "juliet@capulet.lit":

4.4 Access Control

In order to prevent hijacking or other misuse, locations are subject to access control rules. Two kinds of restrictions apply:

Before a Store is permitted, the Storing Peer MUST check that:

If any of these checks fail, the request MUST be rejected with an Error_Forbidden error.

The Storing Peer MUST NOT apply the PRECIS profile to any XMPP addresses. It is the responsibility of the Peer issuing the Store request. This allows to join XMPP agnostic RELOAD nodes to the overlay and protects intermediate peers from excessive computations, as well as possible bugs related to XMPP addresses comparison.

5. Looking Up an Address Location

In order to locate a peer in the current overlay, a RELOAD Peer MUST execute the following steps:

  1. MUST remove the resource part of the XMPP address and prepare it for comparison using PRECIS rules defined in RFC 7622 [3].
  2. MUST perform a Fetch for Kind XMPP-LOCATION at the Resource-ID corresponding to this prepared bare XMPP address. This Fetch SHOULD NOT indicate any dictionary keys, so that it will fetch all the stored values.
  3. MUST remove duplicate destination lists and MUST initiate direct connections to all Peers as described in the following sections.

6. Forming a Direct Connection

6.1 Setting Up a Connection

Once the Peer has translated the XMPP address into a set of destination lists, it then uses the overlay to route AppAttach messages to each of those Peers. It is RECOMMENDED to route AppAttach messages to the Peers in parallel. If the Peer chooses sequential routing, it is RECOMMENDED to sort the destination lists by priority in ascending order and perform the routing and connection attempts in this order (i.e. from the destination list with the smallest priority to the biggest, assuming standard integer comparison).

The "application" field of AppAttach message MUST be 5222. The responding Peer MUST present a certificate with a Node-ID matching the terminal entry in the destination list. Otherwise, the connection MUST NOT be used and MUST be closed.

Once the AppAttach succeeds, the Peer MUST start TLS-encrypted XMPP connection. A STARTTLS procedure MUST NOT be used. For better censorship resistance, the Peer MUST NOT use ALPN extension (RFC 7301 [4]): since the endpoints are negotiated during the ICE phase, protocol multiplexing is not needed at all.

A peer (device) of an XMPP user at any time MAY close connections to some peers (devices) of another user while keeping the rest of connections to this user's peers opened. However, only connections corresponding to the destination lists with higher priorities (biggest integer values) MUST be considered for closing as redundant.

At startup, the peer MUST try to establish connections to all its user's devices. The Peer MUST strive to maintain connections to all its user's devices. It MUST NOT voluntary close some of them.

6.2 Stanza Routing

A stanza to an XMPP user MUST be sent to all connected peers (devices) of this user. Upon reception of a stanza, the peer MUST forward it to all its user's devices. An XMPP peer MUST be prepared to deal with duplicates and forwards. The follow-up extensions are supposed to clarify this.

7. Interaction with XMPP Core

The XMPP Usage of RELOAD is designed to work along with standard XMPP client-to-server (c2s) connection defined in RFC 6120 [2]. Depending on the user preferences or application usage, a peer MAY treat either c2s or RELOAD connection as primary.

8. Enrollment and Authentication

Sybil attacks are the major threat of any peer-to-peer system. A successful Sybil attack may degrade or completely paralyze the overlay, e.g. by mounting a consequent Eclipse attack. It is asserted that under realistic assumptions, without a logically centralized authority, Sybil attacks are always possible in peer-to-peer systems [5]. To address this, the RELOAD specification relies on certificate-based authentication with a central authority. The authority's ability to ensure attackers cannot get a large number of certificates for the overlay is one of the cornerstones of RELOAD's security.

In the case of a public XMPP overlay based on existing network of federated XMPP servers, RELOAD peers MUST rely on e2e authentication defined in XEP-EAX. The document also specifies a location of the enrollment server.

In order to build an isolated XMPP overlay the reader is suggested to follow directly the approach described in the RELOAD document itself.

9. XMPP-LOCATION Kind Definition

This section defines the XMPP-LOCATION Kind.

Kind IDs
The Resource Name for the XMPP-LOCATION Kind-ID is the bare XMPP address of the user prepared for comparison using PRECIS. The data stored is an XmppLocation, which can contain either another XMPP address or a destination list to the Peer that is acting for the user.
Data Model
The data model for the XMPP-LOCATION Kind-ID is a dictionary. The dictionary key is the Node-ID of the Storing Peer. This allows each Peer (presumably corresponding to a single device) to store a single route mapping.
Access Control
USER-NODE-MATCH. Note that this matches the XMPP address against the "id-on-xmppAddr" Object Identifier (as defined in RFC 6120 [2]) in the X.509 v3 certificate.

Data stored under the XMPP-LOCATION Kind is of type XmppLocation, containing one of two data types:

An XMPP address that the user can be reached at.
A destination list that can be used to reach the user's Peer.

10. Security Considerations

10.1 RELOAD Security

This Usage for RELOAD does not define new protocol elements or operations. Hence, no new threats arrive from message exchanges in RELOAD.

10.2 SPAM

Successful SPAM dissemination is possible as long as the malicious entity is able to create a lot of accounts in the overlay. In other words, SPAM is a derivative of a Sybil attack. Since the overlay is designed to be Sybil resistant, SPAM is expected to be negligible.

10.3 Accounts Harvesting


10.4 Network Address Disclosure


11. IANA Considerations

11.1 Data Kind-ID

The specification introduces the following code point in the "RELOAD Data Kind-ID" Registry (cf., RFC6940) to represent the XMPP-LOCATION Kind:

Table 1: Code Points
Kind Kind-ID Reference

12. XMPP Registrar Considerations

This document defines no new XMPP namespaces.


Appendix A: Document Information

XMPP Standards Foundation
Standards Track
Last Updated
Approving Body
XMPP Council
XMPP Core, XEP-0001, RFC 6940
Superseded By
Short Name

This document in other formats: XML  PDF

Appendix B: Author Information

Evgeny Khramtsov


This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF).


Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).

Visual Presentation

The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Given that this XMPP Extension Protocol normatively references IETF technologies, discussion on the <xsf-ietf@xmpp.org> list might also be appropriate.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes

1. XEP-0174: Link-Local Messaging <https://xmpp.org/extensions/xep-0174.html>.

2. RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc6120>.

3. RFC 7622: Extensible Messaging and Presence Protocol (XMPP): Address Format <http://tools.ietf.org/html/rfc7622>.

4. RFC 7301: Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension <https://tools.ietf.org/html/rfc7301>.

5. Douceur, John R. "The sybil attack." International workshop on peer-to-peer systems. Springer, Berlin, Heidelberg, 2002.

Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

  1. Version 0.0.1 (2019-02-08)

    First draft.