[Standards-JIG] NEW: JEP-0170 (Recommended Order of Stream Feature Negotiation)

Joe Hildebrand 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,  
>>> especially
>>> memory, I would rather suggest to first autenticate and then  
>>> negociate
>>> compression. I imagine a trivial attact: simply open a lot of
>>> connections to a jabber server, negociate compression and go to  
>>> sleep.
>>> Each connection can eat easily 500 Kbytes. 1000 connections eats 500
>>> Megabytes.
>> 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.
> Greets,
>         Jacek

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1883 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060114/8e78e572/attachment.bin>

More information about the Standards mailing list