[Standards] LAST CALL: XEP-0205 (Best Practices to Discourage Denial of Service Attacks)

Alexey Melnikov alexey.melnikov at isode.com
Tue Jan 13 10:56:10 UTC 2009

On Fri, Nov 7, 2008 at 11:46 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> This Last Call has ended, with no feedback received.
> XMPP Extensions Editor wrote:
>> This message constitutes notice of a Last Call for comments on
>> XEP-0205 (Best Practices to Discourage Denial of Service Attacks).
>> Abstract: This document recommends a number of practices that can
>> help discourage denial of service attacks on XMPP-based networks.
>> URL: http://www.xmpp.org/extensions/xep-0205.html
>> This Last Call begins today and shall end at the close of business on
>> 2008-11-07.
>> Please consider the following questions during this Last Call and
>> send your feedback to the standards at xmpp.org discussion list:
>> 1. Is this specification needed to fill gaps in the XMPP protocol
>> stack or to clarify an existing protocol? 2. Does the specification
>> solve the problem stated in the introduction and requirements? 3. Do
>> you plan to implement this specification in your code? If not, why
>> not? 4. Do you have any security concerns related to this
>> specification? 5. Is the specification accurate and clearly written?
>> Your feedback is appreciated!

One quick (and late) note:

In Section 3, bullet 3 says:

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

I think this text is also arguing against counting the number of
failed authentication attempts on a single connection, which is wrong.
Limiting the number of authentications on a single connection doesn't
result in lockout (the client can disconnect and reconnect) and it
only punishes malicious (or broken) clients. This is also much easier
to implement than a counter across multiple connections.

More information about the Standards mailing list