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

Waqas Hussain waqas20 at gmail.com
Tue Jan 13 12:50:55 UTC 2009

On Tue, Jan 13, 2009 at 3:56 PM, Alexey Melnikov
<alexey.melnikov at isode.com> wrote:
> 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.

The text is arguing against locking down an account on a large number
of failed attempts. That is, someone other than me making the failed
attempts, and the account being locked (for me as well as the one
making the failed attempts). Even if you only block the IP from which
the failed attempts are coming, it would still allow someone behind
the same router as me to lock me out of my account (which is one of
the problems with IP based blocking).


More information about the Standards mailing list