[Standards] Security consideration for XEP-0198

Kevin Smith kevin at kismith.co.uk
Thu May 8 10:28:33 UTC 2014

On Wed, May 7, 2014 at 10:46 PM, Georg Lukas <georg at op-co.de> wrote:
> * Dave Cridland <dave at cridland.net> [2014-05-07 23:05]:
>> It's probably worth noting, yes. The solution is to request an
>> acknowledgement, and if one isn't forthcoming, to ditch the connection, of
>> course.
> It is not that easy, unfortunately. If the client is currently
> disconnected, the ultimate purpose of the stanza queue is to cache
> stanzas until the client reconnects. If you ditch the connection, you
> undermine the purpose of the XEP.
> It is wise to have a timeout mechanism for the client not responding to
> ack requests. However, the session should be kept for a defined time
> after that, to allow for a reconnection.
> IMHO, there should be a stanza limit per session/per JID, however once
> the limit is reached, new stanzas for that client should be rejected
> with an error without terminating the connection.
> If you do terminate the connection, you make the process susceptible to
> DoS attacks against clients on slow connections (or currently in the
> process of reconnecting).

No, if you start bouncing stanzas that you would have delivered to the
client if it was connected, you need to kill the resume and bounce
them all.

Consider the case of a paused client in a MUC. The MUC sends a
message, and gets a bounce because the buffer's full. The client
resumes the session, but now its out of sync - it thinks its in the
MUC and the MUC has removed it due to bounces.

198 resumption is an all-or-nothing job.


More information about the Standards mailing list