[Standards] Security consideration for XEP-0198

John Williams (johnwi3) johnwi3 at cisco.com
Thu May 8 01:47:26 UTC 2014



> -----Original Message-----
> From: Standards [mailto:standards-bounces at xmpp.org] On Behalf Of Georg
> Lukas
> Sent: Wednesday, May 07, 2014 2:46 PM
> To: standards at xmpp.org
> Subject: Re: [Standards] Security consideration for XEP-0198
> 
> * 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.

Although not mentioned, I would expect many server implementations would choose to impose limits on how much unacknowledged traffic they will buffer. XEP-0198 leaves a lot of freedom to the implementer. 

The primary goal of XEP-0198 is to optimize reconnection for clients with unreliable connection (or hopping from wired/wireless). A resume may fail, but if it succeeds quite often then it is a useful optimization.

If you assume you have no evidence that the client connection has failed (but your buffer has hit its limit), you could simply discard the oldest unacked packet and make space for the newer packet. In many cases the client will catch up and no harm is done. If you are not so lucky, and you need a stanzas you discarded for a resume request - oh well the resume will fail. This simple implementation is sufficient for optimizing reconnection most of the time, but occasionally it means someone has to take the slower session recreation path.

I don’t believe it was the goal of XEP-0198 to guarantee a stanza is either delivered or bounced. I am not sure if you are trying to achieve this guarantee by bouncing new stanzas once the buffer overflows.

I don’t think this will work well.  This implementation is liable to fail to deliver traffic the client, and the client would be totally oblivious. Events from pub-sub nodes might have been missed, changes in occupants and roles within a chat room, etc....

I believe the only way to make this guarantee is to kill the session upon overflow. All the unacked packets are available to bounce, the client will have to reconnect and establish a new session (resume would fail), and the client would rebuild their state. The price of this guarantee is that it could cause a bad experience for users on slow connections, or cause problems when there are heavy bursts of traffic.

Dave's suggestion could help detect dead/unresponsive connections sooner, but you still have to deal with the problem of buffering stanzas while you are waiting. You probably want to send <r> stanzas anytime your buffer creeps up so that you can solicit an <a> stanza well before you hit your overflow point.

Note: 
xep-0198 allows clients to send <a> stanzas even if there was no <r> from the server. When you see an <a> from the client that might not correlate to the <r> you sent. I suppose you could keep waiting for the <a> that has 'h' equal to the  value you would expect for the <r> you sent.

== Jock Williams ==


More information about the Standards mailing list