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.
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. :-)
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.
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).
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.
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
