\documentclass[11pt]{article}
\usepackage{times}
\usepackage{graphics}
%\usepackage{i-d}
\usepackage[dvips]{changebar}

\title{Real Time Streaming Protocol (RTSP)}
\author{H. Schulzrinne, A. Rao, R. Lanphier}

\newcommand{\motivation}[1]{\begin{quotation}\begin{footnotesize}#1\end{footnotesize}\end{quotation}}

\newcommand{\CS}{$C\rightarrow S$}
\newcommand{\SC}{$S\rightarrow C$}

\begin{document}
\begin{center}
\begin{tabular}{lcr}
Internet Engineering Task Force & \hspace{1in} & MMUSIC\\
Internet Draft                  && Schulzrinne/Rao/Lanphier\\
ietf-mmusic-rtsp-03             && Columbia U./Netscape/Progressive Networks\\
\today\\
Expires: January 1, 1998        && \\
\end{tabular}
\end{center}

\maketitle

\subsection*{Status of this Memo}

This document is an Internet-Draft.  Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups.  Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress''.

To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

Distribution of this document is unlimited.

\begin{abstract}
The Real Time Streaming Protocol, or RTSP, is an application-level
protocol for control over the delivery of data with real-time
properties.  RTSP provides an extensible framework to enable controlled,
on-demand delivery of real-time data, such as audio and video.  Sources
of data can include both live data feeds and stored clips.  This
protocol is intended to control multiple data delivery sessions, provide
a means for choosing delivery channels such as UDP, multicast UDP and
TCP, and delivery mechanisms based upon RTP (RFC 1889).
\end{abstract}

%{\bf This is a snapshot of the current draft which will become the next
%version of the ``official'' Internet Draft.}

\tableofcontents

\input{intro}
\input{notation}
\input{parameters}
\input{message}
\input{request}
\input{response}
\input{entity}
\input{connections}
\input{methods}
\input{status}
\input{headers}
\input{caching}
\input{examples}
\input{syntax}

\section{Security Considerations}
\label{sec:security}

\begin{changebar}
The protocol offers the opportunity for a remote-controlled
denial-of-service attack.  

The attacker, using a forged source IP address, can ask for a stream to
be played back to that forged IP address.  Thus, an RTSP server SHOULD
only allow client-specified destinations for RTSP-initiated traffic
flows if the server has verified the client's identity, e.g., using the
RTSP authentication mechanisms.

\end{changebar}

Since there is no relation between a transport layer connection and an
RTSP session, it is possible for a malicious client to issue requests
with random session identifiers which would affect unsuspecting clients. 
This does not require spoofing of network packet addresses.  The server
SHOULD use a large random session identifier to make this attack more
difficult.

Both problems can be be prevented by appropriate authentication.

\begin{changebar}
Servers SHOULD implement both basic and digest \cite{rfc2069}
authentication. 
\end{changebar}

In addition, the security considerations outlined in [H15] apply.

\appendix
\input{machine}
\input{rtp}
\input{open}
\input{changes}

\section{Author Addresses}

\begin{flushleft}
Henning Schulzrinne\\
Dept. of Computer Science\\
Columbia University\\
1214 Amsterdam Avenue\\
New York, NY 10027\\
USA\\
electronic mail: {\sf schulzrinne@cs.columbia.edu}
\end{flushleft}

\begin{flushleft}
Anup Rao\\
Netscape Communications Corp.\\
501 E. Middlefield Road\\
Mountain View, CA 94043\\
USA\\
electronic mail: {\sf anup@netscape.com}
\end{flushleft}

\begin{flushleft}
Robert Lanphier\\
Progressive Networks\\
1111 Third Avenue Suite 2900\\
Seattle, WA 98101\\
USA\\
electronic mail: {\sf robla@prognet.com}
\end{flushleft}

\section{Acknowledgements}

This draft is based on the functionality of the original RTSP draft submitted
in October 96.  It also borrows format and descriptions from HTTP/1.1.

This document has benefited greatly from the comments of all those
participating in the MMUSIC-WG. In addition to those already mentioned,
the following individuals have contributed to this specification:

\begin{flushleft}
\begin{tabular}{ll}
Rahul Agarwal      & Eduardo F. Llach\\
Bruce Butterfield  & Rob McCool\\ 
Steve Casner       & David Oran\\
Martin Dunsmuir    & Sujal Patel\\
Eric Fleischman    & \\
Mark Handley       & Igor Plotnikov\\
Peter Haight       & Pinaki Shah\\
Brad Hefta-Gaub    & Jeff Smith\\
John K. Ho         & Alexander Sokolsky\\
Philipp Hoschka    & \\
Ruth Lang          & Dale Stammen\\
Stephanie Leif     & John Francis Stracke\\
\end{tabular}
\end{flushleft}

\bibliographystyle{ieeetr}
\bibliography{string,i-d,rfc-short,net95,net96}

\end{document}
