Subject: Re: [Bug 11] Protection against XML Denial Of Service attacks

From: Julian Reschke <[email-masked]>
Date: Thu, 01 Dec 2005 18:25:42 +0100

[email-masked] wrote:
> http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=11
> 
> [email-masked] changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>          [email-masked]      [email-masked]
>              Status|ASSIGNED                    |NEW
> 
> 
> 
> ------- Additional Comments From [email-masked]  2005-11-30 14:42 -------
> I didn't understand the part about removing the section on 503 -- what's wrong
> with it?  
> 
> The part about XML entities I've fixed.

We discussed this during the conference call: 5xx is a server error, in 
particular 503 means "not now but maybe later". If a server detects a 
DOS attack, that's the last thing it would want to tell the client.

Servers are free to do whatever they want should they detect a DOS 
attack. If they want to be friendly, a 4xx with explanation would be right.

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 1 Dec 2005 10:58:04 -0800

Sorry about that -- I'll blame both a brain fart and I lost access to  
bugzilla immediately after I entered this so I couldn't change it.  I  
do see how a 4xx error is better because the same request won't succeed  
later.  Which 4xx response though?

Lisa

On Dec 1, 2005, at 9:25 AM, Julian Reschke wrote:

>> with it?  The part about XML entities I've fixed.
>
> We discussed this during the conference call: 5xx is a server error,  
> in particular 503 means "not now but maybe later". If a server detects  
> a DOS attack, that's the last thing it would want to tell the client.
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 01 Dec 2005 20:26:57 +0100

Lisa Dusseault wrote:
> bugzilla immediately after I entered this so I couldn't change it.  I do 
> see how a 4xx error is better because the same request won't succeed 

I think 400 is just fine.

See 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#rfc.change.bz011.1>.

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 2 Dec 2005 11:33:41 -0800

How about adding to the DOS section?

    WebDAV servers need to be aware of the possibility of a denial of
    service attack at all levels. The proper response to such an attack  
MAY be to simply
       drop the connection, or if the server is able to make a response,
       the server MAY use a 400-level status request such as 400 (Bad
       Request) and indicate why the request was refused (a 500-level
       status response would indicate that the problem is with the  
server,
       whereas unintentional DOS attacks are something the client is  
capable of remedying).

On Dec 1, 2005, at 11:26 AM, Julian Reschke wrote:

>> do see how a 4xx error is better because the same request won't  
>> succeed later.  Which 4xx response though?
>> Lisa
>

---

From: Julian Reschke <[email-masked]>
Date: Sat, 03 Dec 2005 22:18:22 +0100

Lisa Dusseault wrote:
>       status response would indicate that the problem is with the server,

Hm. What is an "unintential DOS attack"?

---

From: Lisa Dusseault <[email-masked]>
Date: Sat, 3 Dec 2005 21:48:32 -0800

Perhaps there's a better phrase for that -- I meant a client request 
that the server decided to consider a DOS attack but the client didn't. 
  E.g. a PROPFIND depth infinity on root.

Lisa

On Dec 3, 2005, at 1:18 PM, Julian Reschke wrote:

>>    service attack at all levels. The proper response to such an 
>> attack MAY be to simply

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 13 Dec 2005 16:00:23 -0800

>> a DOS attack, that's the last thing it would want to tell the client.

Hmm, there might be some places you want this. This is not a Chair comment -
just take it as a random individual comment.

Imagine you had say 40,000 phones that all got their config information over
DAV in some enterprise. And when the building power cycles, they all go and
hit the server at the same time. I call this a Start of Service attack (SOS)
but it is a lot like DDOS from server point of view. Some other protocols
have found that returning a 5xx with a Retry-After time is very useful here.
The retry time can be adjusted based on the depth of the queue in the server
and the length of time the server has been in an overload state to push out
the retries out to a point where the server has a chance of processing them
instead of just sending the 503. The load balancer can realize the servers
are overloaded and switch traffic to servers that can send the 503 at
extremely high rates.

There are also systems build to deal with very large DDOS attacks that do
things like the following. Imagine that an ISP has a client with server with
address X. The server tells the ISP that the server is under DDOS attack.
The ISP has a system that "steals" address X and routes all traffic to that
system. The first thing it does with any request is does some bounce back,
such as a 503 with a retry after 0 seconds, if the client retries again, at
least the client is doing some work. This often help differentiate good
clients from DDOS attackers. Then the ISP system forwards the request down
the original server but keeps track of where the requests are coming from.
Now the ISP can see that 90% of the request are coming into it's network
from one particular other AS. The ISP can rate limit down the request from
the one AS at the edge of ISP and it can allow the other request from all
the other AS to not be rate limited. This allows valid clients that are
coming from different AS to not be effected, and clients in the same AS as
attacker to be severely rate limited. It takes advantage of the 5xx to
verify that there is a valid client at the sender of a request. This
approach has been used to stop some very large scale DDOS attacks on large
web sites. It works well for HTTP.

Anyways, other protocols have found 5xx with Retry-After one of the best way
to handle temporarily overload on the servers. I agree, if you know
something is a DOS attack, the best thing might be not to respond but it is
very difficult to distinguish which particular request during a DDOS attack
is a bad one and which is good.

Cullen (not as chair)