REsource LOcation And Discovery (RELOAD) (RFC 6940 [1]) 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:
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:
Overlay
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) [2], 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.
TBD
In XMPP Core RFC 6120 [3], 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 RFC 6940 [1]).
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".
The XmppLocation Resource Record is defined as follows:
enum {
xmpp_location_address(1),
xmpp_location_route(2),
(255)
} 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 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":
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.
In order to locate a peer in the current overlay, a RELOAD Peer MUST execute the following steps:
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 [5]): 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.
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.
The XMPP Usage of RELOAD is designed to work along with standard XMPP client-to-server (c2s) connection defined in RFC 6120 [3]. Depending on the user preferences or application usage, a peer MAY treat either c2s or RELOAD connection as primary.
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 [6]. 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.
This section defines the XMPP-LOCATION Kind.
Data stored under the XMPP-LOCATION Kind is of type XmppLocation, containing one of two data types:
This Usage for RELOAD does not define new protocol elements or operations. Hence, no new threats arrive from message exchanges in RELOAD.
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.
TBD
TBD
The specification introduces the following code point in the "RELOAD Data Kind-ID" Registry (cf., RFC6940) to represent the XMPP-LOCATION Kind:
| Kind | Kind-ID | Reference |
|---|---|---|
| XMPP-LOCATION | 0x5 | XEP-0415 |
This document defines no new XMPP namespaces.
This document in other formats: XML PDF
This XMPP Extension Protocol is copyright © 1999 – 2024 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.
## 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. ##
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.
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).
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.
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.
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 <https://xmpp.org/community/> 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>.
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".
1. RFC 6940: REsource LOcation And Discovery (RELOAD) Base Protocol <http://tools.ietf.org/html/rfc6940>.
2. XEP-0174: Link-Local Messaging <https://xmpp.org/extensions/xep-0174.html>.
3. RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc6120>.
4. RFC 7622: Extensible Messaging and Presence Protocol (XMPP): Address Format <http://tools.ietf.org/html/rfc7622>.
5. RFC 7301: Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension <https://tools.ietf.org/html/rfc7301>.
6. Douceur, John R. "The sybil attack." International workshop on peer-to-peer systems. Springer, Berlin, Heidelberg, 2002.
Note: Older versions of this specification might be available at https://xmpp.org/extensions/attic/
First draft.
@report{khramtsov2019xep0415,
title = {XMPP Over RELOAD (XOR)},
author = {Khramtsov, Evgeny},
type = {XEP},
number = {0415},
version = {0.1.0},
institution = {XMPP Standards Foundation},
url = {https://xmpp.org/extensions/xep-0415.html},
date = {2019-02-08/2019-03-06},
}END