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

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Sun Jan 15 07:21:26 UTC 2006


I was also just thinking..  if you use SASL encryption, then you'd definitely 
want to compress afterwards.

-Justin

On Saturday 14 January 2006 22:36, Joe Hildebrand wrote:
> 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



More information about the Standards mailing list