XEP-xxxx: XMPP Over RELOAD (XOR)

RELOAD

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.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,

• from an XMPP address to a destination list (a single Node-ID is just a trivial destination list), or
• from one XMPP address to another.

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 {
     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:

• If the location is of type "xmpp_location_address", then the contents are an opaque string containing the XMPP address. The address MUST be bare (i.e. without a resource part) and MUST be prepared for comparison using PRECIS rules from RFC 7622 [3].
• If the location is of type "xmpp_location_route", then the contents are an integer representing a route priority and an opaque string containing a destination list for the Peer. The meaning of a priority is described below in this document.

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:

• her desktop client (1234)
• her cell phone (5678)

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

• an XmppLocation of type "xmpp_location_route" with dictionary key "1234" and value "1234", both referring to Node-IDs
• an XmppLocation of type "xmpp_location_route" with dictionary key "5678" and value "5678"

4.4 Access Control¶

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

• A Store is permitted for the owner of this XMPP address, e.g. its certificate is signed by the trusted CA.
• Storing requests are performed according to the USER-NODE-MATCH access control policy of RELOAD.

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

• The XMPP address of the request is a valid Resource Name, e.g. the corresponding certificate is signed by the trusted CA.
• The certificate contains a username that is an XMPP address that hashes to the Resource-ID it is being stored at.
• The certificate contains a Node-ID that is the same as the dictionary key it is being stored at.

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.

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.

Name

XMPP-LOCATION

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.

xmpp_location_address

An XMPP address that the user can be reached at.

xmpp_location_route

A destination list that can be used to reach the user's Peer.

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¶

TBD

10.4 Network Address Disclosure¶

TBD

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:

Copyright

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

Permissions

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.

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.