[Standards-JIG] Re: The Ack Hack.

Pavel Šimerda pavel.simerda.lists at centrum.cz
Wed May 10 16:45:38 UTC 2006


On 2006-05-10 16:53, Dave Cridland wrote:
> 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.

That's what I expect. I want the server to tell others that I am offline, when 
I am disconnected.

Rooms would work just as the work now... when I reconnect manually. Client 
handles all my groupchats by sending <presence/>.

If someone wants to be viewed as online when he's not... pleas make it 
optional... and maybe even separately from per-hop acking.

Many people are looking forward to reliable messaging.

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

I think the server should ping silent connections too... just use longer 
timeouts... like 2 minutes... or 5 minutes... or whatever.

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

Pavel

-- 
Keep it simple... http://www.pavlix.net/



More information about the Standards mailing list