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

From: Eric Fleischman <[email-masked]>
Date: Wed, 23 Apr 1997 15:28:42 -0700

There seems to be general concurrence that this is a serious concern and
that the proper solution is to require authentication. What isn't clear
to me is how the RTSP community wishes to respond to this. Two obvious
possibilities are:

1) to purposefully not add this capability to RTSP until/unless an
authentication mechanism is defined for it.

2) to add this capability to RTSP but to do so with warning messages
that it probably shouldn't be implemented until such a time as an
authentication mechanism is defined.

Does this summary represent the consensus of our community? 
Which alternative does the community feel is preferential?

My 2 cents worth: The only problem I have with alternative 2 is that I
fear that it may not result in the same authentication method being used
by all RTSP implementations. Thus, interoperability within this feature
may be a function of the authentication method(s) eventually being
identified within an official version of RTSP anyway. This may mean that
alternative 1 is what needs to happen regardless.

> -----Original Message-----
> From:	Anup Rao [SMTP:[email-masked]]
> Sent:	Wednesday, April 23, 1997 10:06 AM
> To:	Sampo Syreeni
> Cc:	Henning Schulzrinne; [email-masked]
> Subject:	Re: RTSP denial-of-service attacks: never mind
> 
> Sampo Syreeni wrote:
> 
> > ...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]>
> 
> 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.
> 
> -- 
> -----------------------------------------------------------------
>   Anup Rao                                                      
>   Netscape Communications Corp.                   
>   email : [email-masked]         Phone : (415) 937 3129       
> -----------------------------------------------------------------

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 23 Apr 1997 20:29:31 -0400

> authentication mechanism is defined for it.

Certainly, in some environments (intranets), this seems overly
conservative. Plus, it's needed (or at least very useful) for multicast
destinations and all it takes is one marketing guy saying that a
customer wants it for unicast and some server will implement it...

> authentication mechanism is defined.

RTSP inherits two authentication mechanisms from HTTP: Basic and Digest.
It may also use SSL for client and server authentication; just added the
URL type rtsps:// for RTSP over SSL to the draft (before I forget...).
Servers SHOULD support Basic and Digest authentication (i.e., they are
only conditionally compliant if they do not).

---

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

>authentication mechanism is defined for it.

So do you suggest a dedicated authentication mechanism for RTSP? It might
be that a general purpose authentication protocol could be a better
candidate. For the sake of modularity and orthogonality in the overall
protocol suite, maybe the authentication part should be left for the
server and the potential receiver to do, out of band. (I'm not an expert
on the current state of authentication protocols but they're bound to be
out there. I also remember that this has been suggested already. So I
support it.)

>by all RTSP implementations.

Yep. It's bargaining with the devil...