[Standards-JIG] Re: The Ack Hack.

Dave Cridland dave at cridland.net
Wed May 10 14:53:39 UTC 2006

On Wed May 10 14:56:51 2006, Bruce Campbell wrote:
> On Wed, 10 May 2006, Richard Dobson wrote:
>> Nope I was just commenting on Dave's proposal to include a "quick 
>> reconnect" mechanism along with the acks, and how it is not really 
>> required (and personally not really desired either), having quick 
>> reconnect as he suggests could result in even more instances of 
>> what are effectively ghost connections on the server, personally I 
>> think that as soon as a connection is detected by the server as 
>> being dead (using the acks) that the particular user in
>> question should immediately go offline rather than buffering the 
>> traffic and giving the user a couple of minutes to reconnect.
> On re-reading Dave's proposal, nothing is mentioned about what the 
> server should do about the online/offline state of the JID between 
> detecting a disconnection and the presentation of a 'now where were 
> we?' token from a new connection.  However, since offlining the JID 
> will break various things (eg, client thinking still part of chat 
> room, chat room thinking client has disconnected), the connection 
> should not be continued if the JID has been offlined in the interim.
I have to confess, I hadn't even considered that, I'd just assumed 
that the server would declare the JID offline as soon as the 
connection died. I suppose it might be nice to keep the JID online 
for a little longer, and really continue the session in that sense, 
but I'd actually assumed that the client would have to go through an 
essentially normal startup, declaring presence etc as usual.

Of course, even if a session is offlined, a reconnecting client still 
benefits from knowing which stanzas were lost, since those may 
contain important messages, or non-idempotent iq stanzas.

>> If connections are over connections that are this unreliable (that 
>> they keep getting disconnected every couple of minutes) maybe 
>> those clients should be connecting using JEP-0124 which wouldn't 
>> have this problem.
> Theres also a subtle attack vector there depending on the size of 
> the buffer that the server keeps track of; all the eviluser has to 
> do is to ack at a much slower rate than the packets being sent.  
> Eventually the server will have an excessive number of buffered, 
> un-acked packets, particularly if multiple connections are doing 
> this.

There's three issues with this.

Firstly, in discussion about this, a few people wanted to tighten up 
the rather loose language concerning when a stanzas should have an 
implicit/unsolicited ack attribute - basically, it should have one 
whenever there's anything new to ack.

This means that if the remote end is sending no unsolicited acks in 
its stanzas, the server has to assume that none of its stanzas are 
getting through, and will, presumably, take some kind of action, like 
explicitly soliciting an ack, and using the absence of any 
acknowledgement to timeout the connection.

To avoid that happening, the remote end would have to remain silent, 
which also will cause a probe of the connection (an explicitly 
solicited ack, this time acting more like a ping) - essentially, the 
server is going to get worried something's gone wrong. (Note - for 
silent on both sides, the server ought to do nothing - it's only when 
there's a build up of unacked stanzas that the server needs to worry).

Secondly, in order to get this far, the client has to authenticate, 
which at least means the server can observe multiple connections 
(and/or registrations) and shut down the hosts and/or accounts 
involved; also the attacker must actually get the stanzas coming, 
which is equally difficult to do without being strikingly obvious.

Thirdly, with or without acks, sequence numbering, or whatever, a 
heavy volume of stanzas is still potentially a denial of service 

           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

More information about the Standards mailing list