[Standards] LAST CALL: XEP-0205 (Best Practices to Discourage Denial of Service Attacks)

Peter Saint-Andre stpeter at stpeter.im
Fri Dec 19 22:48:06 UTC 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.

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.

Good point.

> 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.

Peter



More information about the Standards mailing list