Subject: [AVT] RTP in HTTP

From: [email-masked]
Date: Fri, 13 Jul 2001 11:30:44 +0200

Hi all

Following a discussion in the Internet Streaming Media Alliance Forum
I have submitted to the IETF a Internet Draft:
"draft-gentric-avt-RTP-HTTP-00.txt"
which text is copied directly below (it is quite short.)

Since the issues are transport of audio and video,
the AVT group seems to be the best fit, however
this subject is also firewall related so maybe some other
group(s) of experts could be involved ?

Colin, Stephen would there be a slot in London for raising
this issue ?

Regards,

*********************************

Internet Engineering Task Force                         Gentric-Philips
Internet Draft                                              Jones-Apple
                                                              July 2001
                                                      Expires Jan. 2002
Document: draft-gentric-avt-RTSP-HTTP-00.txt

                         Tunneling RTSP in HTTP

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document discusses tunneling RTSP in HTTP and more specifically
   RTSP with interleaved RTP data.

  1. Introduction

   There is a need for tunneling RTP streams inside RTSP in HTTP
   because in some cases users are located behind a firewall that is
   configured to only let HTTP through.

   After discussing the context of the problem we will give the
   requirements for a solution and outline what a solution could be.

  2. Motivation

   RTSP [1, 10.12] clearly defines how RTP stream data can be embedded
   with RTSP methods. It also recommends that RTSP should be
   transported using TCP.

   Note that tunneling RTSP (only) in HTTP would not be useful since
   the RTP data transported using UDP would be blocked.

Gentric, Jones           Expires January 2002                        1

                        Tunneling RTSP in HTTP               July 2001

   With this TCP based transport of RTP-inside-RTSP, firewalls
   configured to exclude UDP traffic can be traversed, which is already
   very useful.

   However for many end users the situation is even worse; indeed some
   ISPs and many corporate Internet access are protected by strict
   firewalls. Typically these firewalls are configured to exclude all
   traffic except HTTP. Thus there is need to transport media through
   HTTP.

   Although it is recognized that doing so is not optimal (see [1] and
   [2] for a discussion on why RTP/UDP is a better idea) it should be
   obvious that the core reason why tunneling streaming in HTTP in not
   a good idea is due to the use of TCP for transport, which is not an
   issue we need to discuss here since transporting RTP inside RTSP on
   TCP (as described in [1]) suffers from the same problem.

   In fact the need for such a solution is so strong that most media
   streaming products implement (pseudo) streaming through HTTP in one
   way or another.

   It is also obvious that although in many cases the reason why a
   corporate or ISP firewall is configured for HTTP only is pure
   paranoia, there are cases when suppressing media streaming is a
   genuine concern for an IT administrator. In this last case providing
   a standard technology that makes it possible to filter RTSP in HTTP
   would be a very good idea.

   It is however of fundamental importance to stress that one of the
   contexts where such tunneling is needed is in environments where IT
   management is not leading edge. Indeed paranoia very often goes
   together with ignorance and/or lack of capability to trustfully
   communicate between decision makers and knowledgeable technical
   people. In such environments firewalls are set for maximum security
   i.e. HTTP-only and solutions that are known to work will be kept as
   long as possible. Therefore the solution we seek MUST work with all
   deployed firewalls otherwise it will be a very little value since we
   cannot expect this key target population to upgrade their firewalls
   if this is what is required to enable RTSP tunneling in HTTP.

   On the other hand the situation is very different for more forward-
   looking organizations. We have two cases then. In places where IT
   administrators opened the required UDP ports in their firewalls so
   as to enable streaming, new solutions i.e. upgrading the firewall-
   will be easily adopted. There are also places where IT administrator
   did not open UDP ports for streaming upon explicit instructions from
   their management to stop media streaming. In such places surely the
   emergence of a standard technology enabling to deploy firewalls that
   can also block tunneling of media in HTTP will be well received.
   Therefore the solution we seek should also provide the ability to
   configure filtering mechanisms so as to give full control on what
   can and what cannot traverse the firewall.

Gentric, Jones           Expires January 2002                        2

                        Tunneling RTSP in HTTP               July 2001

  3. Requirements

   The requirements for tunneling RTSP in HTTP are therefore the
   following:
   Requirement 1: to traverse existing (deployed) HTTP-only firewalls
   Requirement 2: to allow the development of new HTTP-level firewalls
   where RTSP tunneling can be detected and eventually filtered.

  4. Solutions

   One solution is described in [3]. We will not discuss this solution
   in full detail but instead we will focus on what seems to be the
   most controversial issue.

  5. Discussion

   As described in [3] there is a need to prevent deployed HTTP proxy
   agents from trying to parse the RTSP syntax that lies after the HTTP
   header. Indeed HTTP-level firewalls are there to do exactly that:
   check that TCP connections carry HTTP data and nothing else.
   Unfortunately it seems that some deployed implementations will try
   to check the correctness of the HTTP syntax and in doing so stumble
   upon the RTSP syntax, causing the service to be denied. The solution
   proposed in [3] is therefore to hide RTSP syntax by trans-coding it
   in base64.

   One obvious problem with this solution is that it may be seen as
   some kind of a cheat. We pretend as discussed in section 2 that this
   is not a true concern. Actually, as mentioned above, tunneling
   streaming media in HTTP is already performed on very large scales by
   a number of proprietary solutions and firewall administrators are
   actually lacking standard-based solutions to recover control upon
   such bandwidth-intensive traffic.

   On the other hand, if a solution such as the one described in [3]
   was to become an IETF standard, proxy agents could detect this
   scenario by looking for an Accept or Content-Type header containing
   "application/x-rtsp-tunnelled". Classical filtering techniques could
   then be applied.

   Alternatively other marking schemes could be designed to allow
   detection of RTSP tunneling into HTTP.

   6. Security Considerations

   Tunneling RTSP in HTTP does not have different security
   considerations than RTSP on TCP (covered by [1]) nor HTTP.

   7. Acknowledgements

Gentric, Jones           Expires January 2002                        3

                        Tunneling RTSP in HTTP               July 2001

   This work has been started after a discussion in the Internet
   Streaming Media Alliance forum; authors wish to thank the people of
   this forum for raising interesting points.

   8. References

   [1] Schulzrinne, Rao, Lanphier, RTSP: Real Time Streaming Protocol
   RFC 2326, Internet Engineering Task Force, April 1998.
   [2] Schulzrinne, Casner, Frederick, Jacobson RTP: A Transport
   Protocol for Real Time Applications RFC 1889, Internet Engineering
   Task Force, January 1996.
   [3] http://index.apple.com/~singer/qt/rtspthroughhttp.html

   9. Authors' Addresses

   Philippe Gentric
   Philips
   51 rue Carnot
   92156 Suresnes
   France
   e-mail: [email-masked]

   anne jones
   Apple
   1 Infinite Loop
   Cupertino, CA 95014
   e-mail: [email-masked]

Philippe Gentric
Software architect
Philips Digital Networks - MP4Net
51 rue Carnot B.P. 301
92156 Suresnes FRANCE
tel: +33(0)147283740
fax: +33(0)147283725
[email-masked]
http://www.mpeg-4player.com

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www.ietf.org/mailman/listinfo/avt