This commit is contained in:
stpeter 2011-08-26 11:12:46 -06:00
parent 26ce4b9a2d
commit 96ae7a5a5d
1 changed files with 164 additions and 194 deletions

View File

@ -9,8 +9,8 @@
<title>XMPP Quickstart</title>
<abstract>This document defines methods for speeding the process of connecting or reconnecting to an XMPP.</abstract>
&LEGALNOTICE;
<number>XXXX</number>
<status>ProtoXEP</status>
<number>0305</number>
<status>Experimental</status>
<type>Standards Track</type>
<sig>Standards</sig>
<dependencies>
@ -23,6 +23,12 @@
<supersededby/>
<shortname>N/A</shortname>
&stpeter;
<revision>
<version>0.1</version>
<date>2011-08-25</date>
<initials>psa</initials>
<remark><p>Initial published version, incorporating improvements based on list discussion and removing the concept of stream management tickets.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2011-08-10</date>
@ -35,213 +41,177 @@
<p>Note: Various parts of this document might be moved to separate documents at some point.</p>
</section1>
<section1 topic='Preparing to Connect' anchor='prepare'>
<p>In accordance with &rfc6120;, before attempting to establish a stream the initiating entity needs to determine the IP address and port at which to connect. Implementations SHOULD cache the results of DNS lookups in order to avoid this step whenever possible.</p>
<p>XMPP clients SHOULD also cache whatever information they can, especially the roster (see &xep0237;) and &xep0030; information. Servers SHOULD support &xep0237; and SHOULD include &xep0115; data in stream features to facilitate such caching. (Caching of service discovery data also applies to server-to-server connections.)</p>
<p>In accordance with &rfc6120;, before attempting to establish a stream the initiating entity needs to determine the IP address and port at which to connect, usually by means of DNS lookups as described in Section 3.2 of <cite>RFC 6120</cite>. Implementations SHOULD cache the results of DNS lookups in order to avoid this step whenever possible.</p>
<p>XMPP applications SHOULD cache whatever information they can about the peer, especially stream features data and &xep0030; information. To facilitate such caching, servers SHOULD include &xep0115; data in stream features as shown in Section 6.3 of <cite>XEP-0115</cite>. Note that for maximum benefit the server MUST include all of the stream features it supports in its replies to "disco#info" queries (i.e., not advertise such features only during stream establishment).</p>
<p>XMPP clients SHOULD cache roster information, and servers SHOULD make such caching possible, using &xep0237; as subsequently included in Section 2.1.1 of &rfc6121;.</p>
</section1>
<section1 topic='Pipelining' anchor='pipelining'>
<p>One method of speeding the connection process is pipelining of requests, as in &rfc2920; and the QUICKSTART extension proposed for SMTP &smtpquickstart;. The application of similar principles to XMPP was originally suggested by Tony Finch in February 2008 &lt;<link url='http://mail.jabber.org/pipermail/standards/2008-February/017966.html'>http://mail.jabber.org/pipermail/standards/2008-February/017966.html</link>&gt;..</p>
<p>In essence, pipelining lets an initiating entity assume that the receiving entity supports the same (or almost the same) features it did on the previous connection attempt. As a result, the initiating entity can proactively send multiple XMPP-related "commands" in a single TCP packet, thus reducing the number of round trips.</p>
<p>If an XMPP server supports pipelining, then it MUST advertise a stream feature of &lt;pipelining xmlns='urn:xmpp:pipelining:0'/&gt;.</p>
<p>If both parties support pipelining, they can proceed as follows (the examples use the XML from the client-server stream establishment section of <cite>RFC 6120</cite>, although the same principles apply to server-to-server streams).</p>
<example caption='Pipelining for Stream Establishment'><![CDATA[
STEP 1
C: <stream:stream
from='juliet@im.example.com'
to='im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
STEP 2
S: <stream:stream
from='im.example.com'
id='t7AMCin9zjMNwQKDnplntZPIDEI='
to='juliet@im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
<required/>
</starttls>
<pipelining xmlns='urn:xmpp:pipelining:0'/>
<c xmlns='http://jabber.org/protocol/caps'
hash='sha-1'
node='http://prosody.im/'
ver='ItBTI0XLDFvVxZ72NQElAzKS9sU='/>
</stream:features>
<proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
STEP 3
[client and server complete TLS negotiation over the existing TCP connection]
STEP 4
S: <stream:stream
from='im.example.com'
id='vgKi/bkYME8OAj4rlXMkpucAqe4='
to='juliet@im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>SCRAM-SHA-1-PLUS</mechanism>
<mechanism>SCRAM-SHA-1</mechanism>
<mechanism>PLAIN</mechanism>
</mechanisms>
<pipelining xmlns='urn:xmpp:pipelining:0'/>
<c xmlns='http://jabber.org/protocol/caps'
hash='sha-1'
node='http://prosody.im/'
ver='ItBTI0XLDFvVxZ72NQElAzKS9sU='/>
</stream:features>
STEP 5
C: <stream:stream
from='juliet@im.example.com'
to='im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl"
mechanism="SCRAM-SHA-1">
biwsbj1qdWxpZXQscj1vTXNUQUF3QUFBQU1BQUFBTlAwVEFBQUFBQUJQVTBBQQ==
</auth>
STEP 6
S: <challenge xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
cj1vTXNUQUF3QUFBQU1BQUFBTlAwVEFBQUFBQUJQVTBBQWUxMjQ2OTViLTY5Y
TktNGRlNi05YzMwLWI1MWIzODA4YzU5ZSxzPU5qaGtZVE0wTURndE5HWTBaaT
AwTmpkbUxUa3hNbVV0TkRsbU5UTm1ORE5rTURNeixpPTQwOTY=
</challenge>
STEP 7
C: <response xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
Yz1iaXdzLHI9b01zVEFBd0FBQUFNQUFBQU5QMFRBQUFBQUFCUFUwQUFlMTI0N
jk1Yi02OWE5LTRkZTYtOWMzMC1iNTFiMzgwOGM1OWUscD1VQTU3dE0vU3ZwQV
RCa0gyRlhzMFdEWHZKWXc9
</response>
STEP 8
S: <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
dj1wTk5ERlZFUXh1WHhDb1NFaVc4R0VaKzFSU289
</success>
<stream:stream
from='im.example.com'
id='gPybzaOzBmaADgxKXu9UClbprp0='
to='juliet@im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<stream:features>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
<pipelining xmlns='urn:xmpp:pipelining:0'/>
<c xmlns='http://jabber.org/protocol/caps'
hash='sha-1'
node='http://prosody.im/'
ver='ItBTI0XLDFvVxZ72NQElAzKS9sU='/>
</stream:features>
STEP 9
C: <stream:stream
from='juliet@im.example.com'
to='im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<iq id='yhc13a95' type='set'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>balcony</resource>
</bind>
</iq>
STEP 10
S: <iq id='yhc13a95' type='result'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<jid>
juliet@im.example.com/balcony
</jid>
</bind>
</iq>
<p>One method of speeding the connection process is pipelining of requests, as in &rfc2920; and the QUICKSTART extension proposed for SMTP (&smtpquickstart;). The application of similar principles to XMPP was originally suggested by Tony Finch in February 2008 &lt;<link url='http://mail.jabber.org/pipermail/standards/2008-February/017966.html'>http://mail.jabber.org/pipermail/standards/2008-February/017966.html</link>&gt;.</p>
<p>In essence, pipelining relies on two assumptions:</p>
<ol>
<li>The parties to a stream can proactively send multiple XMPP-related "commands" in a single TCP packet (as one simple example, the receiving entity can send both the response stream header and stream features in a single packet).</li>
<li>The features that the receiving entity supports (e.g., stream features and SASL mechanisms) are stable over time, which means the initiating entity can assume support for certain features and send certain XMPP-related commands without discovering again that the receiving entity supports them.</li>
</ol>
<p>Together, these assumptions enable the parties to reduce the number of round trips needed to complete the stream negotiation process.</p>
<p>If an XMPP server supports pipelining, it MUST advertise a stream feature of &lt;pipelining xmlns='urn:xmpp:features:pipelining'/&gt;.</p>
<p>If both parties support pipelining, they can proceed as follows (the examples use the XML from Section 9.1 of <cite>RFC 6120</cite> for the client-server stream establishment, but the same principles apply to server-to-server streams).</p>
<p>In Step 1, the client assumes that the server supports the XMPP STARTTLS extension so it pipelines its initial stream header, the &lt;starttls/&gt; command, and the TLS ClientHello message.</p>
<example caption='Step 1: Client Initiation'><![CDATA[
<stream:stream
from='juliet@im.example.com'
to='im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
TLS ClientHello
]]></example>
<p>As can be seen, pipelining needs 10 steps to complete session establishment, as opposed to 16 steps for the non-pipelined process described in <cite>RFC 6120</cite>.</p>
<p>Naturally, additional round trips are needed for XMPP clients to gather service discovery information, retrieve the roster, etc.</p>
<p>In Step 2, the server pipelines its response stream header, stream features advertisement, STARTTLS &lt;proceed/&gt; response, and TLS ServerHello messages (which might include ServerHello, Certificate, ServerKeyExchange, CertificateRequest, and ServerHelloDone -- see &rfc5246; for details).</p>
<example caption='Step 2: Server Response to Initiation'><![CDATA[
<stream:stream
from='im.example.com'
id='t7AMCin9zjMNwQKDnplntZPIDEI='
to='juliet@im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
<required/>
</starttls>
<pipelining xmlns='urn:xmpp:features:pipelining'/>
<c xmlns='http://jabber.org/protocol/caps'
hash='sha-1'
node='http://prosody.im/'
ver='ItBTI0XLDFvVxZ72NQElAzKS9sU='/>
</stream:features>
<proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
TLS ServerHello
]]></example>
<p>In Step 3, the parties complete the TLS negotiation.</p>
<example caption='Step 3: TLS Handshake'><![CDATA[
Client might send some combination of Certificate, ClientKeyExchange, CertificateVerify, ChangeCipherSpec, and Finished -- see RFC 5246
]]></example>
<p>In Step 4, the server knows that the client will need to restart the stream so it proactively attaches its response stream header and stream features after the TLS Finished message.</p>
<example caption='Step 4: Server Proactively Restarts Stream'><![CDATA[
TLS Finished
<stream:stream
from='im.example.com'
id='vgKi/bkYME8OAj4rlXMkpucAqe4='
to='juliet@im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>SCRAM-SHA-1-PLUS</mechanism>
<mechanism>SCRAM-SHA-1</mechanism>
<mechanism>PLAIN</mechanism>
</mechanisms>
<pipelining xmlns='urn:xmpp:features:pipelining'/>
<c xmlns='http://jabber.org/protocol/caps'
hash='sha-1'
node='http://prosody.im/'
ver='ItBTI0XLDFvVxZ72NQElAzKS9sU='/>
</stream:features>
]]></example>
<p>In Step 5, the client pipelines its initial stream header with the command for initiating the SASL authentication process (including SASL "initial response" data as explained in Section 6.3.10 of <cite>RFC 6120</cite> to reduce the number of round trips).</p>
<example caption='Step 5: Client Initiates SASL Authentication'><![CDATA[
<stream:stream
from='juliet@im.example.com'
to='im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl"
mechanism="SCRAM-SHA-1">
biwsbj1qdWxpZXQscj1vTXNUQUF3QUFBQU1BQUFBTlAwVEFBQUFBQUJQVTBBQQ==
</auth>
]]></example>
<p>At this point the client and server might exchange multiple SASL-related messages, depending on the SASL mechanism in use. This specification does not attempt to reduce the number of round trips involved in the challenge-response sequence.</p>
<example caption='Step 6: Server Sends SASL Challenge'><![CDATA[
<challenge xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
cj1vTXNUQUF3QUFBQU1BQUFBTlAwVEFBQUFBQUJQVTBBQWUxMjQ2OTViLTY5Y
TktNGRlNi05YzMwLWI1MWIzODA4YzU5ZSxzPU5qaGtZVE0wTURndE5HWTBaaT
AwTmpkbUxUa3hNbVV0TkRsbU5UTm1ORE5rTURNeixpPTQwOTY=
</challenge>
]]></example>
<p>When the client suspects that it is sending its final SASL response, it SHOULD append an initial stream header and resource binding request.</p>
<example caption='Step 7: Client Sends Final SASL Response with Stream Header and Bind Request'><![CDATA[
<response xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
Yz1iaXdzLHI9b01zVEFBd0FBQUFNQUFBQU5QMFRBQUFBQUFCUFUwQUFlMTI0N
jk1Yi02OWE5LTRkZTYtOWMzMC1iNTFiMzgwOGM1OWUscD1VQTU3dE0vU3ZwQV
RCa0gyRlhzMFdEWHZKWXc9
</response>
<stream:stream
from='juliet@im.example.com'
to='im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<iq id='yhc13a95' type='set'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>balcony</resource>
</bind>
</iq>
]]></example>
<p>In Step 8, the server informs the client of SASL success (including "additional data with success" as explained in Section 6.3.10 of <cite>RFC 6120</cite> to reduce the number of round trips), sends a response stream header and stream features, and informs the client of successful resource binding.</p>
<example caption='Step 8: Server Accepts Bind Request'><![CDATA[
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
dj1wTk5ERlZFUXh1WHhDb1NFaVc4R0VaKzFSU289
</success>
<stream:stream
from='im.example.com'
id='gPybzaOzBmaADgxKXu9UClbprp0='
to='juliet@im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<stream:features>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
<sm xmlns='urn:xmpp:sm:3'/>
<pipelining xmlns='urn:xmpp:features:pipelining'/>
<c xmlns='http://jabber.org/protocol/caps'
hash='sha-1'
node='http://prosody.im/'
ver='ItBTI0XLDFvVxZ72NQElAzKS9sU='/>
</stream:features>
<iq id='yhc13a95' type='result'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<jid>
juliet@im.example.com/balcony
</jid>
</bind>
</iq>
]]></example>
<p>The XMPP stream negotiation process in <cite>RFC 6120</cite> required at least 19 round trips (including 4 for TLS negotiation). With pipelining, the number of round trips is reduced to 8.</p>
<p>Naturally, for typical client-to-server sessions, additional round trips are needed so that the client can gather service discovery information, retrieve the roster, etc. As noted, these steps can be reduced or eliminated by using entity capabilities and roster versioning.</p>
</section1>
<section1 topic='Reconnection' anchor='reconnection'>
<p>The pain of multiple round trips is magnified if the initiating entity needs to reconnect frequently (e.g., because of intermittent network outages). Although &xep0124; can be used to mitigate the pain, BOSH is not appropriate for all scenarios and is not currently used in others (e.g., server-to-server streams).</p>
<p>The minimize the speed of reconnection, implementations are strongly encouraged to support TLS Session Resumption (&rfc5077;) in addition to the technologies already mentioned.</p>
</section1>
<section1 topic='Stream Management Tickets' anchor='tickets'>
<p>If &xep0198; is used, including support for stream resumption, the server can treat the stream management identifier as a "ticket" for stream resumption (similar to the use of a ticket for TLS session resumption). Here's how.</p>
<p>First, if an XMPP server allows stream management IDs as stream resumption tickets, then it MUST advertise a stream feature of &lt;tickets xmlns='urn:xmpp:sm:tickets:0'/&gt;.</p>
<p>During the stream management negotiation, the server will deliver a stream management ID for stream resumption.</p>
<example caption='Sending a Stream Management ID'><![CDATA[
C: <enable xmlns='urn:xmpp:sm:3'/>
S: <enabled xmlns='urn:xmpp:sm:3' id='37c69b1cf07a3f67c04a5ef5902fa5114f2c76fe4a2686482ba5b89323075643' resume='true'/>
]]></example>
<p>The server SHOULD do send an ID if TLS has already been negotiated, since the SM-ID might be used as a session resumption ticket.</p>
<p>Now, when the client reconnects it includes the SM-ID in its opening stream header.</p>
<example caption='Using the Stream Management ID as a Ticket'><![CDATA[
C: <stream:stream
from='juliet@im.example.com'
sm:id='37c69b1cf07a3f67c04a5ef5902fa5114f2c76fe4a2686482ba5b89323075643'
to='im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:sm='urn:xmpp:sm:3'>
xmlns:stream='http://etherx.jabber.org/streams'>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
]]></example>
<p>If the server accepts the SM-ID as a ticket, it MUST echo the identifier in its response stream header.</p>
<example caption='EX'><![CDATA[
S: <stream:stream
from='im.example.com'
id='t7AMCin9zjMNwQKDnplntZPIDEI='
sm:id='37c69b1cf07a3f67c04a5ef5902fa5114f2c76fe4a2686482ba5b89323075643'
to='juliet@im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:sm='urn:xmpp:sm:3'>
xmlns:stream='http://etherx.jabber.org/streams'>
<stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
<required/>
</starttls>
<pipelining xmlns='urn:xmpp:pipelining:0'/>
<tickets xmlns='urn:xmpp:sm:tickets:0'/>
<c xmlns='http://jabber.org/protocol/caps'
hash='sha-1'
node='http://prosody.im/'
ver='k2Ozf7u+7+uAaYPFbcb9RczI7sY='/>
</stream:features>
<proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
]]></example>
<p>After the client and server negotiate TLS to protect the stream (preferably using TLS session resumption to reduce the number of round trip), the server SHOULD immediately allow the client to start sending stanzas and SHOULD also immediately send a new SM-ID to the client.</p>
<example caption='Sending a New Stream Management ID'><![CDATA[
S: <enabled xmlns='urn:xmpp:sm:3' id='9b1cf07a3f67c04a5ef5902fa5114f2c76fe4a2686482ba5b8932307564337c6' resume='true'/>
]]></example>
<p>Reconnection can be further enhanced by using the stream resumption feature described in &xep0198;. <cite>XEP-0198</cite> does not legislate exactly when it is safe for the server to allow the client to send the &lt;resume/&gt; request. Clearly, sending it before the stream is encrypted would increase the possibility of replay attacks. However, sending it after TLS negotiation (Step 4 above) but before SASL authentication and resource binding (Steps 5 through 8) would enable the client to begin sending stanzas more quickly. It is a matter of server policy whether to advertise the SM feature after TLS negotiation or only after SASL negotiation.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>A server MUST NOT treat a stream management identifier as a stream resumption ticket unless the original stream was protected by means of TLS.</p>
<p>A server MUST time out a stream management identifier after a configurable amount of time (typically no more than a few minutes).</p>
<p>To follow.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>To follow.</p>
<p>This specification defines the following XML namespace:</p>
<ul>
<li>urn:xmpp:features:pipelining</li>
</ul>
<p>Upon advancement of this specification from a status of Experimental to a status of Draft, the &REGISTRAR; shall add the foregoing namespace to the registry located at &STREAMFEATURES;, as described in Section 4 of &xep0053;.</p>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>Special thanks to Tony Finch for suggesting this work and providing the initial outline of how pipelining would work. Thanks also to Kevin Smith for his early feedback.</p>
<p>Special thanks to Tony Finch for suggesting this work and for providing the initial outline of how pipelining would work. Thanks also to Waqas Hussain, Jehan Pagès, and Kevin Smith for their feedback.</p>
</section1>
</xep>