[Standards] LAST CALL: XEP-0205 (Best Practices to Discourage Denial of Service Attacks)
stpeter at stpeter.im
Fri Dec 19 22:40:03 UTC 2008
Matthew Wild wrote:
> On Wed, Oct 22, 2008 at 9:51 PM, XMPP Extensions Editor <editor at xmpp.org> wrote:
>> This message constitutes notice of a Last Call for comments on XEP-0205 (Best Practices to Discourage Denial of Service Attacks).
>> Abstract: This document recommends a number of practices that can help discourage denial of service attacks on XMPP-based networks.
>> URL: http://www.xmpp.org/extensions/xep-0205.html
>> This Last Call begins today and shall end at the close of business on 2008-11-07.
>> Please consider the following questions during this Last Call and send your feedback to the standards at xmpp.org discussion list:
>> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
>> 2. Does the specification solve the problem stated in the introduction and requirements?
>> 3. Do you plan to implement this specification in your code? If not, why not?
>> 4. Do you have any security concerns related to this specification?
>> 5. Is the specification accurate and clearly written?
> Is not:
> 4.3 Unauthenticated Connections
> In accordance with RFC 3920, a server MUST NOT process XML stanzas
> from clients that have not provided appropriate authentication
> credentials, and MUST NOT process XML stanzas from peer servers whose
> identity it has not either authenticated via SASL (see RFC 4422 )
> or verified via server dialback.
> misleading? I mean, you need to process incoming stanzas in order to
> authenticate, etc. I know this is obvious, but perhaps the text should
> mention presence/iq/message explicitly instead.
> ...or maybe I'm just being fussy :)
TLS and SASL negotiation elements are not stanzas as defined in RFC 3920
and rfc3920bis. But we can mention presence/message/iq if that helps
make things clearer.
> I also agree with Pedro that type='modify' seems wrong in example 1.
> The RFC states modify means "retry after changing the data sent ".
> Changing the data sent will not fix this error. However I do not think
> it should be 'cancel' either (RFC: "do not retry (the error cannot be
> remedied)") - rather I think it should be 'wait' (one of the other
> resources may log out, for example).
That's nothing you can count on -- the other resource might be logged in
for 3 years with long-lived TCP connections. So I think "cancel" is more
> Also note that RFC3920bis specifies a completely different error in this case:
More information about the Standards