moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00
Code Issues Releases Wiki Activity

0.3

Browse Source
This commit is contained in:
Peter Saint-Andre 2013-03-01 14:12:47 -07:00
parent 22f4c7efc8
commit e317176d73
1 changed files with 13 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
xep-0305.xml
View File

@ -25,6 +25,12 @@
<supersededby/>
<shortname>N/A</shortname>
&stpeter;
<revision>
<version>0.3</version>
<date>2013-03-01</date>
<initials>psa</initials>
<remark><p>Clarified the text in several places.</p></remark>
</revision>
<revision>
<version>0.2</version>
<date>2012-12-19</date>
@ -46,7 +52,7 @@
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Establishing an XMPP session requires a fairly large number of round trips between the initiating entity and the receiving entity. In many deployment scenarios, it would be helpful to reduce the number of round trips and therefore the time needed to establish a session. This document defines protocols and best practices to do just that.</p>
<p>Establishing an XMPP session can require a fairly large number of round trips between the initiating entity and the receiving entity. However, in many deployment scenarios it would be helpful to reduce the number of round trips and therefore the time needed to establish a session. This document describes protocol optimizations and best practices to do just that.</p>
</section1>
<section1 topic='Preparing to Connect' anchor='prepare'>
@ -56,13 +62,13 @@
</section1>
<section1 topic='Pipelining' anchor='pipelining'>
<p>The primary 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>The primary method of speeding the connection process is pipelining of requests, along the lines of &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 in a message to the standards@xmpp.org discussion list &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 at the time of each connection attempt 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>Together, these assumptions enable the parties to reduce the number of round trips needed to complete the stream negotiation process by "pipelining" XMPP-related commands over the stream.</p>
<p><em>Note well that pipelining at the XMPP layer is not to be confused with HTTP pipelining, which was added to HTTP in version 1.1 and which is not encouraged when using the HTTP bindings for XMPP.</em></p>
</section1>
@ -109,7 +115,7 @@ TLS ClientHello
TLS ServerHello
]]></example>
<p>Without pipelining, the foregoing exchange would require 3 round trips; with pipelining it requires 1 round trip.</p>
<p>Now the parties complete the TLS negotiation; for our purposes we don't count these round trips because they are the same no matter whether we use pipelining or not (i.e., some combination of the TLS messages specified in RFC 5246).</p>
<p>Now the parties complete the TLS negotiation (i.e., some combination of the TLS messages specified in RFC 5246); for our purposes we don't count these round trips because they are the same no matter whether we use pipelining or not.</p>
<p>At the end of the TLS negotiation, the server knows that the client will need to restart the stream so it proactively attaches its response stream header and stream features in the same TCP packet at the TLS Finished message, thus starting the next exchange.</p>
<example caption='Server Proactively Restarts Stream and Sends Stream Features'><![CDATA[
TLS Finished
@ -405,11 +411,11 @@ Content-Length: 674
<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 XEP-0124 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>
<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>
<p>To minimize the speed of reconnection, implementations are strongly encouraged to support TLS Session Resumption (&rfc5077;) in addition to the technologies already mentioned.</p>
<p>Reconnection can be further enhanced by using the stream resumption feature defined 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>Because pipelining does not skip any channel encryption or authentication steps, but merely packs them into a smaller number of TCP packets or HTTP request/response pairs, it is unlikely that the foregoing quickstart methods introduce security vulnerabilities. However, the server must be careful not to send stream features that it would not otherwise send before a security context is established.</p>
<p>Because pipelining does not skip any channel encryption or authentication steps, but merely packs them into a smaller number of TCP packets or HTTP request/response pairs, it is unlikely that the foregoing quickstart methods introduce security vulnerabilities. However, the server needs to be careful not to send stream features that it would not otherwise send before a security context is established.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>