Subject: [MMUSIC] RTSP connections question.

From: Aravind Narasimhan <[email-masked]>
Date: Wed, 16 Feb 2005 17:34:30 -0500

Section 9.3 of rtsp-bis08 indicates the following:

> A server SHOULD NOT initiate a close of a connection directly after 
> responding to a TEARDOWN request for the whole session. A server 
> SHOULD NOT close the connection as a result of responding to a request 
> with an error code. Doing this would prevent or result in extra 
> overhead for the client when testing advanced or special types of 
> requests.

But this seems like a DoS security risk.  If a malicious user decided to 
send gibberish request or request that are almost correct and but not 
quite, the server may respond with an error code because it can't parse 
the request.  But if it cannot close its connection to the client, then 
the client may overload the server with many gibberish requests and 
eventually cause the server to not accept valid connections. 

What is the purpose of saying that the server SHOULD NOT close the 
connection as a result of responding to a request with an error code?  
It seems like it would be the right thing to do, no?

Aravind

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 17 Feb 2005 15:38:23 +0100

> It seems like it would be the right thing to do, no?

I agree that this is a risk, however there is a clearly trade off here. 
If you are very aggressive and treats all errors as an attack and boots 
the client, then you could easily boot clients that is trying something 
special that the server doesn't understand but is correct. If you go the 
other way then, you will be more vulnerable to attacks.

This is very similar to the TCP overload attack. You need to accept a 
TCP connections to be able to serve anyone, however if someone is trying 
to overload you using TCP connects, the server will need to block some 
of the request.

So this is something that needs to be included in the security 
consideration section as a possible venue of attack that needs to be 
handled by the server implementation.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Aravind Narasimhan <[email-masked]>
Date: Thu, 17 Feb 2005 13:45:37 -0500

Great answers folks.  I will try to work some of the background and 
rationale for the recommendation into the spec.  Now I wonder if we need 
to do something to try to actively prevent DoS in this scenario?  I'll 
think about this a bit, but I dont have an answer yet.

Aravind

Magnus Westerlund wrote:

>>> SHOULD NOT close the connection as a result of responding to a 
>>> request with an error code. Doing this would prevent or result in 
>>> extra overhead for the client when testing advanced or special types 
>>> of requests.
>>
>>
>>
>>
>> But this seems like a DoS security risk.  If a malicious user decided 
>> to send gibberish request or request that are almost correct and but 
>> not quite, the server may respond with an error code because it can't 
>> parse the request.  But if it cannot close its connection to the 
>> client, then the client may overload the server with many gibberish 
>> requests and eventually cause the server to not accept valid 
>> connections.
>> connection as a result of responding to a request with an error 
>> code?  It seems like it would be the right thing to do, no?
>>
>
> I agree that this is a risk, however there is a clearly trade off 
> here. If you are very aggressive and treats all errors as an attack 
> and boots the client, then you could easily boot clients that is 
> trying something special that the server doesn't understand but is 
> correct. If you go the other way then, you will be more vulnerable to 
> attacks.
>
> TCP connections to be able to serve anyone, however if someone is 
> trying to overload you using TCP connects, the server will need to 
> block some of the request.
>

---

From: Aravind Narasimhan <[email-masked]>
Date: Thu, 17 Feb 2005 17:18:17 -0500

> correct. If you go the other way then, you will be more vulnerable to 

Maybe the right way to approach this is to have something that indicates 
to the server that you are trying to do something special and that the 
server may not understand it. . .  But I think that with the OPTIONS 
request, and support for feature tags, it should be easy to indicate 
this without having to put a recommendation that the server should not 
close a connection on an error response.  I think it would be better to 
let the server decide what to do on a error response, but indicate the 
pros and cons.  My point is that a "SHOULD NOT" seems too strong.

> handled by the server implementation.

The question is what does a server do about this?  What is our 
recommendation?

Aravind

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 18 Feb 2005 09:31:51 +0100

Hi Aravind

> pros and cons.  My point is that a "SHOULD NOT" seems too strong.

I agree that we have procedures to check if certain things will happen. 
The problem is that there is a big difference between different types of 
error messages, if some one includes a Require header and you don't 
support a feature and respond with 551 (Option not supported), that is 
clearly a valid usage. However if you respond using the 400 "Bad 
Request" you have a higher risk that you are under attack. I think 
SHOULD NOT is the correct level. However I think we should include a 
reference to the security issues with this recommendation.

> The question is what does a server do about this?  What is our 

I think the common case, is that a server should monitor the situation, 
and if it determines if it is under a deliberate attack, in particular 
if there is many different sessions that receives garbage messages, then 
the server can be more harsh against errors. The server should also 
consider the strength of different error messages, as I pointed out in 
the above paragraph.

Cheers

Magnus Westerlund

---

From: Aravind Narasimhan <[email-masked]>
Date: Fri, 18 Feb 2005 11:18:18 -0500

That works for me.  I'll work this into the spec if there are no objections.

Aravind

Magnus Westerlund wrote:

>> Maybe the right way to approach this is to have something that 
>> indicates to the server that you are trying to do something special 
>> and that the server may not understand it. . .  But I think that with 
>> the OPTIONS request, and support for feature tags, it should be easy 
>> to indicate this without having to put a recommendation that the 
>> server should not close a connection on an error response.  I think 
>> it would be better to let the server decide what to do on a error 
>> response, but indicate the pros and cons.  My point is that a "SHOULD 
>> NOT" seems too strong.
>>
>
> I agree that we have procedures to check if certain things will 
> happen. The problem is that there is a big difference between 
> different types of error messages, if some one includes a Require 
> header and you don't support a feature and respond with 551 (Option 
> not supported), that is clearly a valid usage. However if you respond 
> using the 400 "Bad Request" you have a higher risk that you are under 
> attack. I think SHOULD NOT is the correct level. However I think we 
> should include a reference to the security issues with this 
> recommendation.
>
>>
>>> This is very similar to the TCP overload attack. You need to accept 
>>> a TCP connections to be able to serve anyone, however if someone is 
> I think the common case, is that a server should monitor the 
> situation, and if it determines if it is under a deliberate attack, in 
> particular if there is many different sessions that receives garbage 
> messages, then the server can be more harsh against errors. The server 
> should also consider the strength of different error messages, as I 
> pointed out in the above paragraph.
>
> Cheers
>
> Magnus Westerlund
>