A key factor in the reliability and security of network infrastructure is its resilience in the face of denial of service attacks (see RFC 4732 [1]). Although the existing network of servers and clients that communicate via the Extensible Messaging and Presence Protocol (XMPP Core [2]) 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.
RFC 4732 defines denial of service as follows:
A Denial-of-Service (DoS) attack is an attack in which one or more machines target a victim and attempt to prevent the victim from doing useful work. The victim can be a network server, client or router, a network link or an entire network, an individual Internet user or a company doing business using the Internet, an Internet Service Provider (ISP), country, or any combination of or variant on these.
The authors list a number of attacks, of which the following seem most likely against XMPP systems:
Numerous potential solutions have been suggested to deal with the threat of denial of service attacks against XMPP servers, including the following:
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).
Limiting the number of connection attempts (via the TCP binding specified in RFC 6120 or via the BOSH (XEP-0124) [6]) 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).
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 except as described in Section 6.4.5 of RFC 6120 [2], and it is instead recommended to limit the number of connections and connection attempts on a per-IP basis.
Disallowing unauthenticated connections from clients and from peer servers; as mentioned below, this is required by RFC 6120.
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.
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).
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".
Limiting the number 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").
Limiting or prohibiting the sending of certain stanzas based on payload, type, or other appropriate features.
Restricting access to services (such as multi-user chat and publish-subscribe) that enable traffic amplification.
More strictly limiting the proposed restrictions depending on connection type, authentication type, or user class.
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).
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. [7]
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.
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). [7]
If an entity attempts to connect but the maximum number of connection attempts 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.
In accordance with RFC 6120, a server MUST NOT process XML stanzas (i.e., <message/>, <presence/>, or <iq/>) from clients that have not yet provided appropriate authentication credentials, and MUST NOT process XML stanzas from peer servers whose identity it has not either authenticated via SASL (see RFC 4422 [8]) or verified via server dialback.
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.
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 <resource-constraint/> stanza error, where the XMPP <error/> element SHOULD also include an application-specific error condition of <resource-limit-exceeded/>, as shown in the following example:
<iq type='error' id='bind_2'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>someresource</resource>
</bind>
<error type='cancel'>
<resource-constraint xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<resource-limit-exceeded xmlns='urn:xmpp:errors'/>
</error>
</iq>
A server implementation SHOULD enable a server administrator to limit the size of stanzas it will accept from a connected client or peer server.
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 <not-allowed/> stanza error, where the XMPP <error/> element SHOULD also include an application-specific error condition of <stanza-too-big/>, as shown in the following example:
<message from='shakespeare.lit' to='iago@shakespare.lit/evilos'>
<error type='modify'>
<not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<stanza-too-big xmlns='urn:xmpp:errors'/>
</error>
</message>
Note: In the case of a stanza size limit, the server SHOULD NOT include the original payload in the error stanza.
Alternatively (e.g., if the sender has sent a seriously large stanza), the server MAY instead return a <policy-violation/> stream error:
<stream:error> <policy-violation xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> <stanza-too-big xmlns='urn:xmpp:errors'/> </stream:error> </stream:stream>
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.
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 an <unexpected-request/> stanza error, where the XMPP <error/> element SHOULD also include an application-specific error condition of <too-many-stanzas/>, as shown in the following example:
<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='urn:xmpp:errors'/>
</error>
</message>
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.
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.
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:
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 XEP-0045 regarding methods of banning users from multi-user chat rooms and XEP-0060 regarding methods for prohibiting users from interacting with publish-subscribe nodes.)
In fact, the "session manager" of an XMPP presence server also acts as just such an amplifier, since presence information is broadcast to all subscribers. Any such service SHOULD enable an administrator to limit the number of stanzas sent through the service in any given period of time (presence changes in a session manager, presence changes or messages in a chatroom, published items in a pubsub service).
Implementations MAY enable administrators to configure appropriate exceptions to some of the recommendations specified in this document. Examples include:
This entire document is about security.
This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [12].
The XMPP Registrar [13] includes <resource-limit-exceeded/> and <too-many-stanzas/> in its registry of application-specific error conditions (see <https://xmpp.org/registrar/errors.html>), where the element is qualified by the 'urn:xmpp:errors' namespace as described in Application-Specific Error Conditions (XEP-0182) [14].
The registry submission is as follows:
<condition>
<ns>urn:xmpp:errors</ns>
<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>urn:xmpp: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>
Special thanks to Chris Mullins for calling attention to the need for a specification on this topic. Thanks also to Thiago Camargo, Bruce Campbell, Dave Cridland, Gustavo Felisberto, Justin Karneges, Alexey Melnikov, Pedro Melo, Kevin Smith, Michal Vaner, and Matthew Wild for their suggestions.
This document in other formats: XML PDF
This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF).
Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.
## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##
In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.
This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).
The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.
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.
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".
1. RFC 4732: Internet Denial-of-Service Considerations <http://tools.ietf.org/html/rfc4732>.
2. RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc6120>.
3. Improving TCP's Robustness to Blind In-Window Attacks <http://tools.ietf.org/html/draft-ietf-tcpm-tcpsecure>. Work in progress.
4. XEP-0045: Multi-User Chat <https://xmpp.org/extensions/xep-0045.html>.
5. XEP-0060: Publish-Subscribe <https://xmpp.org/extensions/xep-0060.html>.
6. XEP-0124: Bidirectional-streams Over Synchronous HTTP <https://xmpp.org/extensions/xep-0124.html>.
7. 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.
8. RFC 4422: Simple Authentication and Security Layer (SASL) <http://tools.ietf.org/html/rfc4422>.
9. XEP-0008: IQ-Based Avatars <https://xmpp.org/extensions/xep-0008.html>.
10. XEP-0047: In-Band Bytestreams <https://xmpp.org/extensions/xep-0047.html>.
11. XEP-0077: In-Band Registration <https://xmpp.org/extensions/xep-0077.html>.
12. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
13. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <https://xmpp.org/registrar/>.
14. XEP-0182: Application-Specific Error Conditions <https://xmpp.org/extensions/xep-0182.html>.
Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/
Fix a typo in an example, namespace 'urn:xmpperrors' → 'urn:xmpp:errors'.
Per a vote of the XMPP Council, advanced specification to Active; also corrected errors namespace for consistency with XEP-0182.
Incorporated Last Call comments: removed paragraph about compression, added paragraph about rate limiting in message or presence amplifiers, corrected simultaneous connections error per revisions to RFC 3920.
Add recommendation regarding multiple messages to distinct recipients; removed numerical recommendations since they are a matter of implementation or deployment.
Initial published version.
Incorporated feedback; specified recommendations regarding bandwidths, payload types, and service access.
First draft.
END