0.2

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1030 4b5297f7-1745-476d-ba37-a9c6900126ab

xep-0205.xml

@@ -21,6 +21,12 @@
   <supersededby/>
   <shortname>N/A</shortname>
   &stpeter;
+  <revision>
+    <version>0.2</version>
+    <date>2007-07-10</date>
+    <initials>psa</initials>
+    <remark><p>Add recommendation regarding multiple messages to distinct recipients; removed numerical recommendations since they are a matter of implementation or deployment.</p></remark>
+  </revision>
   <revision>
     <version>0.1</version>
     <date>2007-01-31</date>
@@ -41,7 +47,7 @@
   </revision>
 </header>
 <section1 topic='Introduction' anchor='intro'>
-  <p>A key factor in the reliability and security of network infrastructure is its resilience in the face of denial of service attacks (see &rfc4732;). Although the existing network of servers and clients that communicate via the Extensible Messaging and Presence Protocol (XMPP; see &rfc3920;) has not yet been subject to such attacks, that is no cause for complacency. Therefore this document specifies a set of best practices that XMPP server implementations and deployments can follow in order to reduce the likelihood of denial of service attacks on the Jabber network.</p>
+  <p>A key factor in the reliability and security of network infrastructure is its resilience in the face of denial of service attacks (see &rfc4732;). Although the existing network of servers and clients that communicate via the Extensible Messaging and Presence Protocol (XMPP; see &rfc3920;) has not yet been subject to such attacks, that is no cause for complacency. Therefore this document specifies a set of best practices that server implementations and deployments can follow in order to reduce the likelihood of denial of service attacks on the Jabber network.</p>
 </section1>
 <section1 topic='Potential Attacks' anchor='attacks'>
   <p><cite>RFC 4732</cite> defines denial of service as follows:</p>
@@ -50,7 +56,7 @@
   <ol start='1'>
     <li>Exploiting poor software quality (e.g., buffer overlow attacks).</li>
     <li>Exhausting application or operating system resources (e.g., memory, CPU cycles, disk space, configured maximum simultaneous connections).</li>
-    <li>Triggering lockouts and quota exhaustion (e.g., quotas associated with the bandwidth limits common in numerous XMPP server implementations, which are often called "karma").</li>
+    <li>Triggering lockouts and quota exhaustion (e.g., quotas associated with the bandwidth limits common in numerous XMPP server implementations.</li>
     <li>Hijacking the TCP connection of a client or server (see &tcprobust;).</li>
     <li>Attacking the Domain Name System (DNS) infrastructure on which XMPP typically depends.</li>
     <li>Poisoning blacklists.</li>
@@ -62,11 +68,12 @@
   <ol start='1'>
     <li><p>Limiting the number of connections that a server will accept from a given IP address at any one time. Such a limit may help to prevent automated processes from exhausting the server's resources (such as available ports or XML parser processing resources).</p></li>
     <li><p>Limiting the number of connection attempts (via the TCP binding specified in <cite>RFC 3920</cite> or via the &xep0124;) that a server will accept from a given IP address in a given time period. Such a limit may help to prevent automated processes from exhausting the server's resources (such as available ports or XML parser processing capacity).</p></li>
-    <li><p>Limiting the number of authentication attempts for a given Jabber ID in a given time period. While such a limit may seem beneficial, in fact it might result in locking out the legitimate owner of a Jabber ID if a malicious entity attempts a large number of illegitimate authentication attempts for the Jabber ID; therefore such a limit is not recommended and it is instead recommended to limit the number of connections and connection attemps on a per-IP basis.</p></li>
+    <li><p>Limiting the number of authentication attempts for a given Jabber ID in a given time period. While such a limit may seem beneficial, in fact it might result in locking out the legitimate owner of a Jabber ID if a malicious entity attempts a large number of illegitimate authentication attempts for the Jabber ID; therefore such a limit is not recommended and it is instead recommended to limit the number of connections and connection attempts on a per-IP basis.</p></li>
     <li><p>Disallowing unauthenticated connections from clients and from peer servers; as mentioned below, this is required by <cite>RFC 3920</cite>.</p></li>
     <li><p>Limiting the number of XMPP resource identifiers allowed to an account at any one time. This may help to prevent a rogue account from creating an unlimited number of sessions and therefore exhausting the resources of the server's session manager.</p></li>
     <li><p>Limiting the absolute size in bytes of XML stanzas accepted by the server, or of particular aspects of an XML stanza (e.g., attribute values, element names, XML character data). Limits on particular aspects of an XML stanza are probably not needed, as long as it is possible to limit the absolute size of each XML stanza, since such a limit may help to prevent exhaustion of server resources (e.g., XML parser processing capacity).</p></li>
     <li><p>Limiting the number of bytes or XML stanzas that a server will accept over a given TCP connection or for a given JabberID in a given time period. Such a limit, which helps to prevent rogue accounts or hijacked clients from flooding the server, is common in existing XMPP server implementations and often goes by the name "karma".</p></li>
+    <li><p>Limiting the number of of XML stanzas that a connected client may send to different recipients in a given time period. Such a limit may help to prevent automated processes (e.g., bots) from sending unsolicited bulk communications (known in the instant messaging domain as "spim").</p></li>
     <li><p>Limiting or prohibiting the sending of certain stanzas based on payload, type, or other appropriate features.</p></li>
     <li><p>Restricting access to services (such as multi-user chat and publish-subscribe) that enable traffic amplification.</p></li>
     <li><p>More strictly limiting the proposed restrictions depending on connection type, authentication type, or user class.</p></li>
@@ -75,18 +82,18 @@
 <section1 topic='Recommendations' anchor='rec'>
   <p>The following recommendations are presented roughly in order of interaction (e.g., recommendations related to the number of TCP connections or connection attempts are presented before recommendations related to authentication, which are presented before recommendations related to XML stanza handling).</p>
   <section2 topic='Simultaneous Connections' anchor='rec-connections'>
-    <p>A server implementation SHOULD enable a server administrator to limit the number of connections that it will from a given IP address at any one time. <note>Alternatively, it is possible to limit the number of connections at the TCP layer rather than at the XMPP application layer. Care must be taken in doing so, since limits at the TCP layer might result in an inability to access non-XMPP services.</note> The maximum number of connections per IP address is a matter of deployment policy, and no recommendations are provided herein.</p>
+    <p>A server implementation SHOULD enable a server administrator to limit the number of connections that it will accept from a given IP address at any one time. <note>Alternatively, it is possible to limit the number of connections at the TCP layer rather than at the XMPP application layer. Care must be taken in doing so, since limits at the TCP layer might result in an inability to access non-XMPP services.</note></p>
     <p>If an entity attempts to connect but the maximum number of connections has been reached, the receiving server MUST NOT allow the new connection to proceed. There are no XMPP errors associated with this behavior, since it occurs at the binding (TCP or HTTP) level before an XML stream is initiated.</p>
   </section2>
   <section2 topic='Connection Attempts' anchor='rec-attempts'>
-    <p>A server implementation SHOULD enable a server administrator to limit the number of connection attempts that it will from a given IP address in a given time period (e.g., one hour). <note>Alternatively, it is possible to limit the number of connections at the TCP layer rather than at the XMPP application layer. Care must be taken in doing so, since limits at the TCP layer might result in an inability to access non-XMPP services.</note> It is RECOMMENDED for a deployment to set the maximum number of connection attempts per IP address to 120 per hour.</p>
+    <p>A server implementation SHOULD enable a server administrator to limit the number of connection attempts that it will accept from a given IP address in a given time period (e.g., one hour). <note>Alternatively, it is possible to limit the number of connections at the TCP layer rather than at the XMPP application layer. Care must be taken in doing so, since limits at the TCP layer might result in an inability to access non-XMPP services.</note></p>
     <p>If an entity attempts to connect but the maximum number of connections has been reached, the receiving server MUST NOT allow the new connection to proceed. There are no XMPP errors associated with this behavior, since it occurs at the binding (TCP or HTTP) level before an XML stream is initiated.</p>
   </section2>
   <section2 topic='Unauthenticated Connections' anchor='rec-auth'>
-    <p>In accordance with <cite>RFC 3920</cite>, a server MUST NOT process XML stanzas from clients that have not provided appropriate authentication credentials, and MUST NOT process XML stanzas from peer servers whose identity it has not either authenticated via SASL or verified via server dialback.</p>
+    <p>In accordance with <cite>RFC 3920</cite>, a server MUST NOT process XML stanzas from clients that have not provided appropriate authentication credentials, and MUST NOT process XML stanzas from peer servers whose identity it has not either authenticated via SASL (see &rfc4422;) or verified via server dialback.</p>
   </section2>
   <section2 topic='Simultaneous Resources' anchor='rec-resources'>
-    <p>A server implementation MUST enable a server administrator to limit the number of resources it will allow an account to bind at any one time. The allowable range for simultaneous resources MAY vary by server implementation. It is RECOMMENDED for a deployment to set the maximum number of connected resources to a number less than 20.</p>
+    <p>A server implementation SHOULD enable a server administrator to limit the number of resources it will allow an account to bind at any one time.</p>
     <p>If a connected client attempts to bind a resource but has already reached the configured number of allowable resources, the receiving server MUST return a &notallowed; stanza error, which in turn SHOULD include an application-specific error condition of &lt;resource-limit-exceeded/&gt;, as shown in the following example:</p>
     <example caption='Resource number limit violation'><![CDATA[
 <iq type='error' id='bind_2'>
@@ -101,7 +108,7 @@
     ]]></example>
   </section2>
   <section2 topic='Stanza Size' anchor='rec-stanzasize'>
-    <p>A server implementation MUST enable a server administrator to limit the size of stanzas it will accept from a connected client or peer server. It is RECOMMENDED for a deployment to set the upper limit on stanza size to a number in the range of 20 kilobytes and 200 kilobytes.</p>
+    <p>A server implementation SHOULD enable a server administrator to limit the size of stanzas it will accept from a connected client or peer server.</p>
     <p>If a connected client or peer server sends a stanza that violates the upper limit, the receiving server SHOULD NOT process the stanza and instead SHOULD return a &notallowed; stanza error, which in turn SHOULD include an application-specific error condition of &lt;stanza-too-big/&gt;, as shown in the following example:</p>
     <example caption='Stanza size limit violation: stanza error'><![CDATA[
 <message from='shakespeare.lit' to='iago@shakespare.lit/evilos'>
@@ -111,7 +118,7 @@
   </error>
 </message>
     ]]></example>
-    <p>Note: In the case of a stanza size limit, the server SHOULD NOT include the original stanza.</p>
+    <p>Note: In the case of a stanza size limit, the server SHOULD NOT include the original payload in the error stanza.</p>
     <p>Alternatively (e.g., if the sender has sent an egregiously large stanza), the server MAY instead return a &lt;policy-violation/&gt; stream error:</p>
     <example caption='Stanza size limit violation: stream error'><![CDATA[
 <stream:error>
@@ -121,9 +128,21 @@
 </stream:stream>
     ]]></example>
   </section2>
+  <section2 topic='Multiple Recipients' anchor='rec-recipients'>
+    <p>A server implementation SHOULD enable a server administrator to limit the number of XML stanzas that a connected client may send to distinct recipients within a given time period.</p>
+    <p>If a connected client sends too many stanzas to distinct recipients in a given time period, the receiving server SHOULD NOT process the stanza and instead SHOULD return a &unexpected; stanza error, which in turn SHOULD include an application-specific error condition of &lt;too-many-stanzas/&gt;, as shown in the following example:</p>
+    <example caption='Stanza recipients violation: stanza error'><![CDATA[
+<message from='iago@shakespeare.lit/evilos' to='juliet@capulet.lit'>
+  <error type='wait'>
+    <unexpected-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
+    <too-many-stanzas xmlns='http://jabber.org/protocol/errors'/>
+  </error>
+</message>
+    ]]></example>
+  </section2>
   <section2 topic='Bandwidth Limits' anchor='rec-bandwidth'>
-    <p>A server implementation MUST enable a server administrator to limit the amount of bandwidth it will allow a connected client or peer server to use in a given time period.</p>
+    <p>A server implementation SHOULD enable a server administrator to limit the amount of bandwidth it will allow a connected client or peer server to use in a given time period.</p>
-    <p>Bandwidth limits in existing XMPP servers can be somewhat complex, since they dynamically respond to usage patterns, take into account temporary traffic bursts, enable the server administrator to modify recovery times and penalty lengths, etc. An example of low average bandwidth limits would be 1k-2k per second, of medium limits 4k-6k per second, of high limits 8k-10k per second. For details, see documentation for existing implementations.</p>
+    <p>Bandwidth limits in existing XMPP server implementations (often called "karma") can be somewhat complex, since they dynamically respond to usage patterns, take into account temporary traffic bursts, enable the server administrator to modify recovery times and penalty lengths, etc. An example of low average bandwidth limits would be 1k-2k per second, of medium limits 4k-6k per second, of high limits 8k-10k per second. For details, see documentation for existing implementations.</p>
   </section2>
   <section2 topic='Stanza Limits' anchor='rec-stanzas'>
     <p>A server implementation SHOULD enable a server administrator to limit the types of stanzas (based on payload etc.) it will allow a connected client send over an active connection. Possible restrictions include:</p>
@@ -135,11 +154,9 @@
       <li>Limiting the number of presence subscription requests that a user may send in a given time period.</li>
       <li>Limiting the number of stanzas that a user may generate in a given time period that are intended for unknown or non-existent JIDs, that are intended for JIDs at remote domains, or that are intended for distinct JIDs.</li>
     </ul>
-    <p>Such limits and restrictions are a matter of deployment policy, and no recommendations are provided herein.</p>
   </section2>
   <section2 topic='Service Restrictions' anchor='rec-services'>
-    <p>An implementation of a service that enables traffic amplification (e.g., multi-user chat or publish-subscribe) SHOULD enable an administrator of that service to limit (based on JabberID or other characteristics) what entities may send information through the service.</p>
+    <p>An implementation of a service that enables traffic amplification (e.g., multi-user chat or publish-subscribe) SHOULD enable an administrator of that service to limit (based on JabberID or other characteristics) what entities may send information through the service. (See <cite>XEP-0045</cite> regarding methods of banning users from multi-user chat rooms and <cite>XEP-0060</cite> regarding methods for prohibiting users from interacting with publish-subscribe nodes.)</p>
-    <p>Such restrictions are a matter of deployment policy, and no recommendations are provided herein (however, see <cite>XEP-0045</cite> regarding methods of banning users from multi-user chat rooms and <cite>XEP-0060</cite> regarding methods for prohibiting users from interacting with publish-subscribe nodes).</p>
   </section2>
 </section1>
 <section1 topic='Implementation Considerations' anchor='impl'>
@@ -167,10 +184,19 @@
   <element>resource-limit-exceeded</element>
   <desc>the account is not allowed to bind more resources at this time</desc>
   <doc>XEP-0205</doc>
+</condition>
+<condition>
+  <ns>http://jabber.org/protocol/errors</ns>
+  <element>too-many-stanzas</element>
+  <desc>
+      a connected client has attempted to send multiple stanzas to too many 
+      different intended recipients in a given time period
+  </desc>
+  <doc>XEP-0205</doc>
 </condition>
   ]]></code>
 </section1>
 <section1 topic='Acknowledgements' anchor='ack'>
-  <p>Special thanks to Chris Mullins for calling attention to the need for a specification detailing best practices such as those recommended herein. Thanks also to Thiago Camargo, Bruce Campbell, Gustavo Felisberto, Justin Karneges, Pedro Melo, and Michael Vorner for their suggestions.</p>
+  <p>Special thanks to Chris Mullins for calling attention to the need for a specification detailing best practices such as those recommended herein. Thanks also to Thiago Camargo, Bruce Campbell, Gustavo Felisberto, Justin Karneges, Pedro Melo, Kevin Smith, and Michael Vorner for their suggestions.</p>
 </section1>
 </xep>