XEP-0205: Best Practices to Discourage Denial of Service Attacks

NOTICE: This Informational specification defines a best practice or protocol profile that has been approved by the XMPP Council and/or the XSF Board of Directors. Implementations are encouraged and the best practice or protocol profile is appropriate for deployment in production systems.

Table of Contents

1. Introduction

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.

2. Potential Attacks

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:

1. Exploiting poor software quality (e.g., buffer overlow attacks).
2. Exhausting application or operating system resources (e.g., memory, CPU cycles, disk space, configured maximum simultaneous connections).
3. Triggering lockouts and quota exhaustion (e.g., quotas associated with the bandwidth limits common in numerous XMPP server implementations.
4. Hijacking the TCP connection of a client or server (see Improving TCP's Robustness to Blind In-Window Attacks [3]).
5. Attacking the Domain Name System (DNS) infrastructure on which XMPP typically depends.
6. Poisoning blacklists.
7. Amplifying network traffic (this could be done through reflectors such as Multi-User Chat (XEP-0045) [4] and Publish-Subscribe (XEP-0060) [5] services).

3. Potential Solutions

Numerous potential solutions have been suggested to deal with the threat of denial of service attacks against XMPP servers, including the following:

1. 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).

2. 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).

3. 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.

4. Disallowing unauthenticated connections from clients and from peer servers; as mentioned below, this is required by RFC 6120.

5. 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.

6. 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).

7. 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".

8. 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").

9. Limiting or prohibiting the sending of certain stanzas based on payload, type, or other appropriate features.

10. Restricting access to services (such as multi-user chat and publish-subscribe) that enable traffic amplification.

11. More strictly limiting the proposed restrictions depending on connection type, authentication type, or user class.

4. Recommendations

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).

<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>

<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>

<stream:error>
  <policy-violation xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
  <stanza-too-big xmlns='urn:xmpp:errors'/>
</stream:error>
</stream:stream>

<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>

5. Implementation Considerations

Implementations MAY enable administrators to configure appropriate exceptions to some of the recommendations specified in this document. Examples include:

• Less strict limits for server administrators compared to entities associated with registered accounts, and for entities associated with registered accounts compared to anonymous entities.
• Less strict limits for entities that authenticate via strong authentication methods (e.g., TLS + SASL EXTERNAL) compared to entities that authenticate via weaker authentication methods (e.g., TLS + SASL PLAIN or server dialback).
• Less strict limits for connections from known IP addresses.
• Less strict limits for connections made via the TCP binding compared to connections made via the HTTP binding.

6. Security Considerations

This entire document is about security.

7. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [12].

8. XMPP Registrar Considerations

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>

9. Acknowledgements

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.

Appendices

Appendix A: Document Information

Series: XEP
Number: 0205
Publisher: XMPP Standards Foundation
Status: Active
Type: Informational
Version: 1.0.1
Last Updated: 2018-11-21
Approving Body: XMPP Council
Dependencies: XMPP Core, XMPP IM
Supersedes: None
Superseded By: None
Short Name: N/A
Source Control: HTML
This document in other formats: XML  PDF

Appendix B: Author Information

Appendix C: Legal Notices

Appendix D: Relation to XMPP

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.

Appendix E: Discussion Venue

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>.

Appendix F: Requirements Conformance

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".

Appendix G: Notes

Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

END