| Abstract: | This specification defines an approach for a pair of servers to eliminate initial handshakes and associated data transfer when using the XMPP S2S Protocol. This approach may only be used with a priori agreement and configuration of the two servers involved. This is of significant benefit in high latency environments. |
| Author: | Steve Kille |
| Copyright: | © 1999 – 2017 XMPP Standards Foundation. SEE LEGAL NOTICES. |
| Status: | Experimental |
| Type: | Informational |
| Version: | 0.2 |
| Last Updated: | 2015-07-18 |
WARNING: This Informational document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the best practice or protocol profile described herein is encouraged in exploratory implementations, although production systems are advised to carefully consider whether it is appropriate to deploy implementations of this protocol before it advances to a status of Draft.
1. Introduction
2. Requirements
3. Use Cases
4. Business Rules
4.1. General
4.2. Identity Determination
4.3. Connection Direction
4.4. Multiple Domains
4.5. Message Validation
4.6. Use of TLS
5. Security Considerations
6. IANA Considerations
7. XMPP Registrar Considerations
8. Acknowledgements
Appendices
A: Document Information
B: Author Information
C: Legal Notices
D: Relation to XMPP
E: Discussion Venue
F: Requirements Conformance
G: Notes
H: Revision History
This specification arose from work on deploying XMPP in high latency environments, with round trips of several second. Even with data transfer rates as low as 2400 bit per second, XMPP works well once connections are established as compressed messages are small and the protocols are fully asynchronous. However the combination of low data rate and high latency led to connection establishment times of several minutes. This was unworkable, particularly when connections were prone to failure.
The solution set out here is to eliminate all the intial handshaking and to start the S2S communication as if the handshaking had been correctly completed. This cannot be used for communication between an arbitrary pair of servers, as in general the negotiation associated with the handshaking is vital for correctly determining a variety of parameters for use in the connection. However, a pair of servers may operate by locally configuring information that would have been negotiated. This enables the pair of servers to eliminate initial handshaking and data exchange.
This specification can be considered as a profile for server to server XMPP communication, to enable XMPP deployment over high latency links. This profile MUST only be used where its use has been pre-agreed and configured for both participating servers.
An example scenario where this protocol is important is to support use of XMPP communication on an aircraft which only has slow high latency air ground communication, with round trips of several seconds (e.g., UHF or Satcom). Use of stanard XMPP protocols (server to server or client to server) leads to long setup times. This protocol can be deployed between an XMPP server on the aircraft and one on the ground. This will be operated over a closed private network, where security considerations can be addressed primarily at the network level.
In simple terms, this can be considered as operation of RFC 6121 communication between a pair of XMPP servers without the preliminary negotiation done in RFC 6120. It might be considered that the start point is the DONE box in Figure 3 of RFC 6121. The TCP connection is opened and messages start to flow, as if the preceding RFC 6120 exchanges had taken place. All configuration informaition, including choice of port is handled by the a priori configuration.
Note that stream open is not sent. The interaction takes place as if this had completed. All XML elements received over the stream are treated as if they were inside a normal S2S stream that has been opened with the following stream opening tag, defining the default namespace of jabber:server and the stream namespace of <stream:stream xmlns:stream='...' xmlns='...'>. When a stream is closed, a stream close SHOULD be exchanged.
A connection between a pair of servers will be by TCP, with or without TLS. The pair of servers need to identify each other at the connection level. Three mechanisms are noted:
The server will then associate one or more XMPP domains with this connection level identity.
Connections may be opened by one server only or by either server. The choice is part of the a priori configured agreement. It is generally recommended to allow connections to be opened by either server. However policy or network constraints may require that the connection is initiated by one server only. When a server initiates a connection it will generally use this connection to send messages to the other server. The server opening a connection is responsible for closing it at the end of its use.
Consider a scenario with two servers: server A and server B. When a connection is opened by server A to server B, the server B MAY use this connection to send messages to server A or MAY open a connection to server A. It is recommended that only a single connection is used in this scenario and so in many cases this protocol will proceed with a single bidirectional TCP connection and messages flowing in both directions. In the event of both servers opening connections at the same time, both TCP connections SHOULD be used unidirectional with messages sent on the connection opened by the message sender only.
Typically a pair of XMPP servers connecting using this protocl will communcicate with multiple domains (e.g., a base domain and a MUC domain). It is generally desirable to configure things so that all communications will share the same link, rather than establishing separate links for each domain, essentially piggy-backing multiple logical connections onto a single TCP connection. Two or more connections MAY be initiated from one server to the other but this is NOT RECOMMENDED.
An XMPP server receiving data over such a link should appropriately validate to and from elements of stream child elements. The rules for this SHOULD be controlled by an priori agreement. An inbound connection will generally be associated with several peer domains. A RECOMMENDED approach is to consider each of these peers in turn and validate in the manner of a peer XMPP server connected using RFC 6020 for that domain. In the event that an inbound message is not considered to be valid, it should be handled in a manner that this invalid message would be handled if it arrived over standard S2S.
This protocol MAY be deployed directly over TCP. This will often be appropriate for environments where network security is handled at IP or lower layers or where the system is operated in closed network environment.
This protocol may be deployed over TLS operating over TCP. If this is done, TLS client and or server X.509 based authentication may be used, with certificate validation achieved by PKI or simply pinning (configuring) a trusted certificate. This configuration and authentication is a part of the a priori configuration.
This protocol operates without the standard XMPP security negotiation. It is imperative that consideration is given to link security whenever this protocol is set up. The identity verification facilities of Server Dialback and SASL EXTERNAL are not available in this protocol so other mechanisms are needed. Use of TLS with mutual authentication is the approach that provides best security with this protocol.
When TLS is not used, the only option available is for the responder to identify the initiator based on source IP address and port. This mechanism is prone to attacks, and so should be used with care. Where source IP address is checked, this may be done directly by match of IP address or by use of reverse DNS lookup to identify the connecting server. If reverse DNS Lookup is used, it is RECOMMENDED to use DNS SEC to mitigate against DNS attacks.
None.
None.
Dave Cridland, Curtis King, Kevin Smith and Kurt Zeilenga worked out and validated the approach documented in this XEP.
Kevin Smith and Kurt Zeilenga provided review and input to this document.
Series: XEP
Number: 0361
Publisher: XMPP Standards Foundation
Status:
Experimental
Type:
Informational
Version: 0.2
Last Updated: 2015-07-18
Approving Body: XMPP Council
Dependencies: RFC 6120, RFC 6121
Supersedes: None
Superseded By: None
Short Name: X2X
Source Control:
HTML
This document in other formats:
XML
PDF
Email:
steve.kille@isode.com
JabberID:
steve.kille@isode.com
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 <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>.
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".
Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/
Assume an open <stream:stream>, implicitly parenting all XML elements received and sent.
(sek)Initial published version approved by the XMPP Council.
(XEP Editor (mam))First draft.
(sek)END