[Standards] LAST CALL: XEP-0205 (Best Practices to Discourage Denial of Service Attacks)
stpeter at stpeter.im
Fri Dec 19 22:48:06 UTC 2008
Pedro Melo wrote:
> 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
Changed per rfc3920bis.
> 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.
For example, at the jabber.org service we limit stanzas to 65k. If you
send a stanza that's 66k, it seems unfriendly to end your session.
> 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'm not sure about that. I could write a spam bot that sends hundreds of
small stanzas (say, presence subscription requests).
> 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.
Or, I think, even different payloads (e.g., toggling back and forth
between priority 0 and priority 1 or whatever).
> 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.
OK, I'll work those in.
More information about the Standards