Subject: RTSP denial-of-service attacks: never mind

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 21 Apr 1997 21:25:55 -0400

Not sure why this didn't occur to me before, but as long as we use
Session headers with non-guessable identifiers rather than dynamic URLs,
the denial-of-service attacks I described earlier are not possible,
since the client has to issue a PLAY with the right session id. (I can
still flood my 'friends' on a local broadcast network if I can snoop
RTSP responses, but that's not nearly as big a problem, particularly
since I mostly hurt myself with that.) Unless I missed something here,
text to this effect will find its way into the security considerations
section.

---

From: Anup Rao <[email-masked]>
Date: Tue, 22 Apr 1997 09:39:22 -0700

> text to this effect will find its way into the security considerations

Not sure I understand this.(Or am I possibly correlating this to the
wrong earlier message ?). The Session: header is returned by the 
server, in response to SETUP. The client then uses it in subsequent
control messages, one of which may direct the stream at an unsuspecting
third party. There is no need to snoop on responses.

-- 
-----------------------------------------------------------------
  Anup Rao                                                      
  Netscape Communications Corp.                   
  email : [email-masked]         Phone : (415) 937 3129       
-----------------------------------------------------------------

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 22 Apr 1997 12:52:38 -0400

> third party. There is no need to snoop on responses.

You are right, third-party dumping is still possible, but at least I'll
know the right network address of the person who did it (unlike, say,
SYN flood attacks).

Sequence would be:

C->S: SETUP
S->C: give Session ID back to entity where command claims to originate
from

C->S: PLAY (only if you have the right session ID)
S:    data starts flowing

---

From: Sampo Syreeni <[email-masked]>
Date: Wed, 23 Apr 1997 17:03:19 +0300 (EET DST)

>know the right network address of the person who did it (unlike, say,

But such third-party dumps are precisely of the worst kind. If the server
operator is too busy to co-operate or no logs are kept, there is no way to
find about the originator of the stream. And even if there is, it is all
too easy to dump a couple of hundreds of machines dead in an afternoon
using methods like this; that can happen long before anyone catches you.
And what does it matter, anyway, if you're, for example, in another
country when the poor users cry out?

>C->S: PLAY (only if you have the right session ID)

...at 100Mbps to someone on the other side of the globe with a networks
operator that charges immense sums on incoming traffic. The user decides
not to accept the data, but cannot stop the stream as he doesn't possess
the appropriate session ID. The costs go up, the user goes bankrupt and
ends up as an alcoholic at the park bench, dying poor and unknown at some
later point in future.

No possibilities for third party flooding, thank you. ;)

Sampo Syreeni (Decoy/dAWN), student, <[email-masked]>

---

From: Anup Rao <[email-masked]>
Date: Wed, 23 Apr 1997 10:06:25 -0700

> Sampo Syreeni (Decoy/dAWN), student, <[email-masked]>

This is an issue that has been talked about quite a bit, including the
seemingly  *DIIIIIIIRRRRRRRRE*  consequences.  Lets step back a bit and
look at points from Henning's previous message:

a) Such an  attack is also possible by spoofing the source address of a
UDP control message. Therefore, there is no additional significant
security burden  imposed.

b) The correct means to prevent this is to *authenticate*. 

There is nothing to preclude the server from refusing to send data to a
destination(that is not the source of control messages) ie. either
request authentication or refuse altogether. Or support only control
messages over TCP, possibly with SSL. This way, it would not contribute
to any byterrorism.

---

From: Sampo Syreeni <[email-masked]>
Date: Thu, 24 Apr 1997 13:54:50 +0300 (EET DST)

>UDP control message. Therefore, there is no additional significant

Known.

>request authentication or refuse altogether.

Agreed. Separate, well engineered, general authentication protocols would
be the ideal solution. And of course, the server can, as you say, always
refuse to send data to a destination that cannot authenticate itself.

>Or support only control messages over TCP, possibly with SSL. This way,
>it would not contribute to any byterrorism.

That is something I don't agree with. In many cases, especially when
working over LANs, it is highly desirable that one be able to use UDP
instead of TCP for the control messages. So one shouldn't impose such
limitations on the control transport. Furthermore, regarding your
suggestion of using SSL, I think SSL is proprietary enough not to be
referrred to in an open standard like RTSP.