mirror of https://github.com/moparisthebest/xeps
Updated ProtoXEP: XMPP over RELOAD
This commit is contained in:
Jonas Schäfer
parent
b7a3256501
commit
c0bda7c567
|
|
@ -2,6 +2,7 @@
|
|||
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
||||
<!ENTITY % ents SYSTEM 'xep.ent'>
|
||||
%ents;
|
||||
<!ENTITY research "<note>Douceur, John R. "The sybil attack." International workshop on peer-to-peer systems. Springer, Berlin, Heidelberg, 2002.</note>">
|
||||
]>
|
||||
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
||||
<xep>
|
||||
|
|
@ -30,13 +31,13 @@
|
|||
</author>
|
||||
<revision>
|
||||
<version>0.0.1</version>
|
||||
<date>2019-02-04</date>
|
||||
<date>2019-02-08</date>
|
||||
<initials>evk</initials>
|
||||
<remark><p>First draft.</p></remark>
|
||||
</revision>
|
||||
</header>
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>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 document also suggests a possible way for managing distributed certficate authorities (CA) issuing X.509 certficates for XMPP accounts in the "Jabber" network.</p>
|
||||
<p>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.</p>
|
||||
<p>The XMPP Usage involves two basic functions:</p>
|
||||
<ol>
|
||||
<li><strong>Address Location</strong>: 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.</li>
|
||||
|
|
@ -68,20 +69,20 @@
|
|||
<--------------- XMPP stream end ----------------
|
||||
]]></code>
|
||||
<p>Direct XMPP streams exchange will be documented in follow-up extensions. So far, a possible way is described in &xep0174;, although this method interacts badly with the ordinary XMPP client-to-server connection and message replication accross user devices.</p>
|
||||
<p>It is important to note that the XMPP Usage of RELOAD is not intended to replace the existing XMPP servers infrastructure as it currently looks unrealistic. Instead, the overlay connection is designed to be working along with the ordinary XMPP client-to-server connection in order to provide backward compatibility and reliable offline message delivery. 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.</p>
|
||||
<p>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.</p>
|
||||
</section1>
|
||||
<section1 topic='Requirements' anchor='reqs'>
|
||||
<p>TBD</p>
|
||||
</section1>
|
||||
<section1 topic='Glossary' anchor='glossary'>
|
||||
<dl>
|
||||
<di><dt>RELOAD</dt><dd>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.</dd></di>
|
||||
<di><dt>RELOAD</dt><dd>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.</dd></di>
|
||||
<di><dt>Address Location</dt><dd>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.</dd></di>
|
||||
</dl>
|
||||
</section1>
|
||||
<section1 topic='Storing an Address Location' anchor='addr-loc'>
|
||||
<section2 topic='Overview' anchor='addr-loc-overview'>
|
||||
<p>In XMPP Core &rfc6120;, 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 in [RFC6940]).</p>
|
||||
<p>In XMPP Core &rfc6120;, 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).</p>
|
||||
<p>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".</p>
|
||||
<p>RELOAD peers can store two kinds of XMPP mappings,</p>
|
||||
<ul>
|
||||
|
|
@ -162,36 +163,32 @@
|
|||
<ol>
|
||||
<li>MUST remove the resource part of the XMPP address and prepare it for comparison using PRECIS rules defined in &rfc7622;.</li>
|
||||
<li>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.</li>
|
||||
<li>MUST remove duplicate destination lists and MUST initiate direct connections to all Peers as described in the following sections. It is RECOMMENDED to perform connection attempts in parallel. If the Peer chooses sequential connection attemps, it is RECOMMENDED to sort the destination lists by priority in ascending order and perform the attempts in this order (i.e. from the destination list with the smallest priority to the biggest, assuming standard integer comparison).</li>
|
||||
<li>MUST remove duplicate destination lists and MUST initiate direct connections to all Peers as described in the following sections.</li>
|
||||
</ol>
|
||||
</section1>
|
||||
<section1 topic='Forming a Direct Connection' anchor='direct-conn'>
|
||||
<section2 topic='Setting Up a Connection' anchor='conn-setup'>
|
||||
<p>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. 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.</p>
|
||||
<p>Once the AppAttach succeeds, the Peer MUST start TLS-encrypted XMPP connection. A STARTTLS procedure MUST NOT be used.</p>
|
||||
<p>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).</p>
|
||||
<p>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.</p>
|
||||
<p>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 (&rfc7301;): since the endpoints are negotiated during the ICE phase, protocol multiplexing is not needed at all.</p>
|
||||
<p>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.</p>
|
||||
<p>At startup, the peer MUST establish connections to all its user's peers. The Peer MUST strive to maintain connections to all its user's peers. It MUST NOT voluntary close some of them.</p>
|
||||
<p>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.</p>
|
||||
</section2>
|
||||
<section2 topic='Stanza Routing' anchor='stanza-routing'>
|
||||
<p>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 peers. An XMPP peer MUST be prepared to deal with duplicates and forwards. The follow-up extensions are supposed to clarify this.</p>
|
||||
<p>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.</p>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Interaction with XMPP Core' anchor='c2s-interact'>
|
||||
<p>The XMPP Usage of RELOAD is designed to work along with standard XMPP client-to-server (C2S) connection defined in &rfc6120;. Depending on the user preferences or application usage, a peer MAY treat either C2S or RELOAD connection as primary. If the C2S connection is primary, the Peer MAY use the overlay in the case when its XMPP server is unavailable. If the RELOAD connection is considered as primary, a client MAY use the C2S connection to send stanzas when it has failed to locate the destination XMPP address in the overlay or when all connection attempts to the destination peer have failed.</p>
|
||||
<p>The XMPP Usage of RELOAD is designed to work along with standard XMPP client-to-server (c2s) connection defined in &rfc6120;. Depending on the user preferences or application usage, a peer MAY treat either c2s or RELOAD connection as primary.</p>
|
||||
<ul>
|
||||
<li>If the c2s connection is primary, the Peer MAY use the overlay in the case when its XMPP server is unavailable. This allows the XMPP service to "degrade gracefully": it is better to keep basic functionality working rather than completely halt the whole service. This is assumed to be the main use case of the current specification.</li>
|
||||
<li>If the RELOAD connection is considered as primary, a client MAY use the c2s connection to send stanzas when it has failed to locate the destination XMPP address in the overlay or when all connection attempts to the destination peer have failed.</li>
|
||||
</ul>
|
||||
</section1>
|
||||
<section1 topic='Authentication' anchor='auth'>
|
||||
<p class='box'>TODO: This section suggests some XSF actions and most likely should be moved into a separate document. The section is also far from completeness and basically only introduces some ideas.</p>
|
||||
<p>Sybil attacks are the major threat of any peer-to-peer system. A successful Sybil attack may degrade or completely paralyze the overlay. It is asserted that under realistic assumptions, without a logically centralized authority, Sybil attacks are always possible in peer-to-peer systems [J. Douceur, 2002]. 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.</p>
|
||||
<p>This section suggests how this authority can be built within existing network of XMPP servers (so called "Jabber" network). In order to create an isolated XMPP overlay the reader is suggested to follow the approach described in the RELOAD document itself.</p>
|
||||
<section2 topic='Enrollment' anchor='enrollment'>
|
||||
<p>RELOAD suggests an existence of a central enrollment server which a joining peer contacts in order to retrive the Overlay Configuration document. The document defines root certificates, bootstrapping nodes, mandatory extensions and so on. The enrollment server is suggested to be maintained by the XSF. Since this is a matter of maintaining of an HTTP server holding a single static file, the operational costs are expected to be low.</p>
|
||||
</section2>
|
||||
<section2 topic='Certificate Authority' anchor='ca'>
|
||||
<p>The root certificate of the overlay MUST be created by the XSF. All intermediate authority's certificates MUST be signed by this root certficate.</p>
|
||||
<p>A server operator who wishes to run the RELOAD node (either separately or along with an XMPP server) and who also wants to issue X.509 certificates to the XMPP accounts of the domain being managed (and thus, becoming an "intermediate" CA), MUST create a certificate request and ask the XSF to sign it using the root certificate of the overlay. This operation will typically require some effort from the XSF. This is because signing a certificate of a server operator who doesn't control account creation (or even creates them massively on purpose) may lead to a Sybil attack on the overlay. The XSF should be extremely careful in this regard.</p>
|
||||
<p>The XSF takes responsibility on revocation of any intermediate certificate. The rules for this MUST be very clear. Since the idea of the XSF central authority is to protect the overlay from Sybil attacks, the only reason for revocation SHOULD be massive account creation by the intermediate authority in question. The XSF MUST NOT perform any kind of censorship.</p>
|
||||
<p>The XSF maintains a list of "bad nodes" in the Overlay Configuration document. It's not very easy to define the "bad" behaviour of a node. As a rule of thumb the peer is considered for a ban if it exploits vulnerabilites of other peers of the overlay, especially when the vulnerability may lead to significant degradation of the overlay.</p>
|
||||
</section2>
|
||||
<section1 topic='Enrollment and Authentication' anchor='enroll-auth'>
|
||||
<p>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 &research;. 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.</p>
|
||||
<p>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.</p>
|
||||
<p>In order to build an isolated XMPP overlay the reader is suggested to follow directly the approach described in the RELOAD document itself.</p>
|
||||
</section1>
|
||||
<section1 topic='XMPP-LOCATION Kind Definition' anchor='kind-def'>
|
||||
<p>This section defines the XMPP-LOCATION Kind.</p>
|
||||
|
|
@ -223,7 +220,7 @@
|
|||
</section1>
|
||||
<section1 topic='IANA Considerations' anchor='iana'>
|
||||
<section2 topic='Data Kind-ID' anchor='data-kind-id'>
|
||||
<p>The specification introduces the following code point in the "RELOAD Data Kind-ID" Registry (cf., [RFC6940]) to represent the XMPP-LOCATION Kind:</p>
|
||||
<p>The specification introduces the following code point in the "RELOAD Data Kind-ID" Registry (cf., RFC6940) to represent the XMPP-LOCATION Kind:</p>
|
||||
<table caption='Code Points'>
|
||||
<tr>
|
||||
<th>Kind</th>
|
||||
|
|
@ -233,7 +230,7 @@
|
|||
<tr>
|
||||
<td>XMPP-LOCATION</td>
|
||||
<td>0x5</td>
|
||||
<td>XEP-XXXX</td>
|
||||
<td>XEP-XOR</td>
|
||||
</tr>
|
||||
</table>
|
||||
</section2>
|
||||
|
|
|
|||
Loading…
Reference in New Issue