[standards-jig] JEP-0060 PubSub: Denial of Service weakness in error handling...

Bob Wyman bob at wyman.us
Wed Mar 26 22:07:46 UTC 2003


Peter Millard wrote:
> The primary reason for doing errors the way we do 
> is just because "thats the way we've always done it"...
	I can see that inertia is often a powerful motivator... However,
I wonder if now is not a good moment to give up traditions that may not
be contributing a great deal of utility while introducing potential
problems... My guess is that most clients probably only pay attention to
the fact that an error was returned and simply ignore the copied body of
the message that generated the error. Does anyone have an implementation
that actually does something useful with the copied bodies?

> If someone attempts to publish a node which is several 
> megabytes, almost all systems will interupt this as 
> start rate limiting the actual socket
	A malicious user could, of course, do a bit of detective work to
determine what sizes trigger rate limits and then simply send erroneous
packets of the appropriate size. The point here is that the requirement
to echo the erroneous packet reduces by half the number of nodes that
must cooperate to take down any given server. Also, are the rate
limiting metrics applied to both sides of the exchange? i.e. would the
size of the error packets be included in the computing whether a rate
limit was triggered?

		bob wyman

-----Original Message-----
From: standards-jig-admin at jabber.org
[mailto:standards-jig-admin at jabber.org] On Behalf Of Peter Millard
Sent: Friday, March 21, 2003 6:03 PM
To: standards-jig at jabber.org
Subject: Re: [standards-jig] JEP-0060 PubSub: Denial of Service weakness
in error handling...


Bob Wyman wrote:
> While "success" messages in JEP-0060 are often very short and succinct

> it appears that when errors occur, the server must copy much of the 
> message held to be in error and return it as part of the error 
> message. This makes DOS attacks relatively easy to launch.

Jabber as a system has always followed this convention :) That said,
however, most client connection managers typically rate limit
connections which prevents clients from ever sending in packets which
can not be handled by the server implementation. These rate limits also
typically enforce "hard-coded" XML node size limitations which exist in
most servers. If someone attempts to publish a node which is several
megabytes, almost all systems will interupt this as start rate limiting
the actual socket, or just disconnect the socket.

The primary reason for doing errors the way we do is just because "thats
the way we've always done it"... If others feel that this is a problem,
I can certainly change the draft, so that the original request is not
echoed during error conditions. What do others think about this???

pgm.

_______________________________________________
Standards-JIG mailing list
Standards-JIG at jabber.org
http://mailman.jabber.org/listinfo/standards-jig




More information about the Standards mailing list