[Standards-JIG] NEW: JEP-0170 (Recommended Order of Stream Feature Negotiation)
hildjj at gmail.com
Sun Jan 15 06:36:44 UTC 2006
It's unlikely that you're going to save that many bytes by
compressing SASL, since the stanzas aren't repeated, and the actual
large blocks of data will look more-or-less random.
You'll save a little on one of the stream:stream's, but we're talking
on the order of 10 bytes or so. It's much better to protect against
the CPU DoS.
On Jan 11, 2006, at 1:47 PM, Jacek Konieczny wrote:
> On Wed, Jan 11, 2006 at 12:55:06PM -0700, Peter Saint-Andre wrote:
>> Jesus Cea wrote:
>>> Since compression can add a lot of overhead to the server,
>>> memory, I would rather suggest to first autenticate and then
>>> compression. I imagine a trivial attact: simply open a lot of
>>> connections to a jabber server, negociate compression and go to
>>> Each connection can eat easily 500 Kbytes. 1000 connections eats 500
>> Good point. In fact the server probably should not even advertise the
>> compression feature until after authentication...
> IMHO that could be a deployment source. Some may want to compress all
> the SASL data, when the bandwith is expensive. The <stream:features/>
> element may occur before and after SASL, so why not allow using
> compression in those two places? Announcing compression when it is
> already in use should be forbidden only.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1883 bytes
Desc: not available
More information about the Standards