Subject: [MMUSIC] A question of Remote denial of Service Attack in RTSP 2.0

From: Kylin Wei <[email-masked]>
Date: Fri, 02 Jun 2006 20:13:50 +0800

Dear mmusic experts:

I have a question of remote denial of service attack in RTSP 2.0.

>In rfc2326bis, section 20.1:
>The attacker may initiate traffic flows to one or more IP addresses
>by specifying them as the destination in SETUP requests. 
>The server SHOULD NOT allow the destination field to be set unless a
>mechanism exists in the system to authorize the request originator to
>direct streams to the recipient. It is preferred that this
>authorization be performed by the recipient itself and the
>credentials passed along to the server.

I don't understand how to perform this authorization by the recipient?
Will a server send a message to report the recipient and request its 
authorization?

Thanks.

Kylin Wei 

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

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 02 Jun 2006 16:26:26 +0200

Hi,

I think your cutting of the text made it a bit more cryptic than the 
complete one present in version 12:

20.1 Remote denial of Service Attack

    The attacker may initiate traffic flows to one or more IP addresses
    by specifying them as the destination in SETUP requests. While the
    attacker's IP address may be known in this case, this is not always
    useful in prevention of more attacks or ascertaining the attackers
    identity. Thus, an RTSP server MUST only allow client-specified
    destinations for RTSP-initiated traffic flows if the server has
    ensured that the specified destination address accepts receiving
    media through different security mechanisms. Security mechanism that
    are acceptable in an increased generality are; verification of the
    client's identity, either against a database of known users using
    RTSP authentication mechanisms (preferably digest authentication or
    stronger); a list of addresses that accept to be media destinations,
    especially considering user identity; and media path based
    verification.

    The server SHOULD NOT allow the destination field to be set unless a
    mechanism exists in the system to authorize the request originator to
    direct streams to the recipient. It is preferred that this
    authorization be performed by the recipient itself and the
    credentials passed along to the server. However, in certain cases,
    such as when recipient address is a multicast group, or when the
    recipient is unable to communicate with the server in an out-of-band
    manner, this may not be possible. In these cases server may chose
    another method such as a server-resident authorization list to ensure
    that the request originator has the proper credentials to request
    stream delivery to the recipient.

The intention with the following phrase:

   "It is preferred that this
    authorization be performed by the recipient itself and the
    credentials passed along to the server."

Is that the server should do the authorization directly with the media 
destination itself. The signalling client has no say in this as he is 
the attacker. Thus the server should send some type of authorization 
request to the client. The client if accepting media responds 
positively. Failure to respond or a negative response prevents delivery.

The foreseen mechanism to solve this, is to use STUN and ICE. In the ICE 
path verification the server will send STUN requests to the destination 
ports asking if there is someone there, including using a password and 
user ID that was only included in the SETUP request. Thus the media 
transport and signalling is bound and prevents the denial of service 
attack, unless the attacker is on the path and can respond himself.

I hope that clarifies the intentions. If you have a proposal for 
improved language of this paragraphs, please send it to me.

Cheers

Magnus

-- 

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]