On Nov 12, 2008, at 2:42 PM, Dave Cridland wrote:
On Wed Nov 12 12:20:11 2008, Pedro Melo wrote:
Hello,
Some comments regarding version 0.2 (2007-07-10):
1. Section 4.4, Simultaneous Resources
The error type in Example 1 is 'modify'. I think it should be
cancel because the request will never succeed no matter what you
change in that session.
This depends... If the client could reuse an existing resource and
disconnect the original session, still, then it's a "modify", since
the client could simply change the resource.
Ok.
2. Section 4.5, Stanza Size
The first response, sending back a stanza of type='error' requires
the server to keep parsing the invalid stanza to know when it
ends. With a never ending stanza, this will cause DoS for servers.
I think the only response to Stanza Size is the second one: as soon
as you detect an ongoing big stanza, give the stream error and
close the stream and the underlying connection.
Ah... I suspect that not all servers are capable, and in addition,
some might have a lower level for stanzas they're willing to process
locally but not forward, etc. But indeed, if the stanza is simply
"way too big", then the intent of that text seems to be to shutdown
the connection.
Tell me, did you (as a non-native speaker) know the word
"egregiously"? I ask because, as a native speaker, I didn't. I think
I might know how to pronounce it. :-)
yes, I do know the meaning of word. The portuguese version is similar
phonetically. But I wouldn't be able to spell it if you asked me.
As for pronouncing it, forget about it. :)
3. Section 4.6, Multiple Recipients
Although I prefer to keep this section in case I'm missing
something, I think the problem is already covered by 4.7 and 4.8
combined.
I think if the administrator uses the facilities in 4.8 and 4.7,
then they won't need this one, but this one on its own may still be
useful.
Ok.
4. Section 4.9, Service Restrictions
One amplifier service not mentioned is the session manager itself.
The server should limit the number of presence changes.
In particular the server should filter several presences with the
exact same payload.
The section only mentions access control features, and not DoS
protection schemes.
Regarding MUCs, we should mention per participant limits on
presence changes and messages as concrete examples of limits to
provide.
Regarding PubSub, number of published items per time period should
also be limited.
That's interesting - could we do presence damping? (ie, the more you
change your presence, the more we delay relaying it, and drop
"overlapped" presence changes entirely).
ejabberd does that for MUCs. I like the concept and it helped SAPO at
the time, where a F8 key in a well-known Delphi-based windows client
would toggle the presence at the maximum speed between avaialble/away :)
I honestly can't remember the name of the client right now.
I also noted (when reading through the XEP alongside your review)
that in section 5, it suggests that stream compression might relax
limits - it's possibly worth noting that it's possible to use
DEFLATE as a traffic amplification attack, so I'm not convinced this
is good advice.
I meant to comment on that and missed my marker. I think the limits of
bandwidth should be applied after decompression.
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: [EMAIL PROTECTED]
Use XMPP!
