Instructor: Prof. Richard Sinn

CMPE 209, Spring ’08

CMPE 209, SECTION 01

Network Security

Team Research Paper On:

RTSP

(Real Time Streaming Protocol)

March 10, 2008

Submitted By:HACKERS

BhupinderSingh Narang

Shubha Gururaja Rao

Farhad Doneshwar

Ishita V James

ManjotKaur

Jasleen Pandher

TABLE OF CONTENTS

Introduction………....…………………………………….……………….……3

1.1What is streaming? ………………………………………………………………….3

1.2 In which layer it works? …………………………………………………………...3

1.3 Purpose of RTSP ……………………………………………………………………4

1.4 RTSP Operation…………………………………………………………...... 4

1.5 RTSP Message Exchange………………………………………………………….5

Comparisons between RTSP and HTTP….………………………………...... 5

Security Consideration ….…………..………………….……………………...5

References ……………………………..………………….…….………………8

1. Introduction:

1.1 What is streaming:

Streaming compresses the digital audio file. It breaks all the data into small packets and sends it to the server over internet. At destination each packet are decompressed and reassembled in such a way that it can be played on a client’s machine. Packets are buffered in such a manner to play it continuously. Therefore many of the packets can be downloaded on the client’s machine before actual playback. The process of downloading remaining packets and put them in a queue while others are playing, remains in progress.

Streaming Protocol:

Protocols can be classified into three groups to implement multimedia streaming:

Network Layer Protocol: basically IP protocol is used at network layer for streaming.
Transport Protocols: UDP, TCP, RTP and RTCP provide end to end transport for streaming.
Session Control Protocols: messages and procedures are defined to control the delivery of data. RTSP and SIP are the examples of it.

1.2 In which layer it works?

RTSP is an application level protocol for the control of real-time streaming data. The major role if RTSP is that it allows two way communication with the unicast server, that by providing the viewers to perform interactive control functions such as pause, resume, fast forward, rewind. From the server’s perspective, RTSP works as a network remote control.

1.3 Purpose

RTSP breaks the continuous streams into small packets. The packet size will be decided as per the bandwidth available between client and the server. The user does not need to wait for the whole data to be received to listen to the music. Because as and when the user gets enough data it starts playing queued up and decompresses the other packet and downloads the remaining packets. The source of data can be live data feed and stored clips. RTP is used by the RTSP to deliver and control real time data.

RTSP is a two way communication protocol whereas RTP is one way communication protocol.

1.4 RTSP Connection Setup:

The working of RTSP is explained below:

Working of RTSP

The session description response is obtained from the web server, once it has got the http get request from the client.

Once the file is being described, the client sends a RTSP SETUP request to the streaming server.

Then the server response the client with an OK thereby indicating that the stream has been prepared successfully.

Always the client starts the streaming with a RTSP play request and ends the streaming session with a RTSP teardownrequest.

1.5 RTSP Message Exchange:

2>Comparisons between RTSP & HTTP:

RTSP overlaps the functionality of HTTP.

RTSP has different methods as well as protocol identifier.

In all cases, RTSP server has to maintain the state.

In RTSP both client and server can communicate by sending request and reply.

Different protocol is used when data delivery takes place out-of-band.

In HTTP (asymmetric protocol) in which client sends a request and the sever responds to it. Whereas in RTSP both can send request and reply.

3Security Considerations

3.1Authentication mechanism:

The basic authentication scheme of RTSP and HTTP are similar. It is not a secure method of authentication and it also does not in any way protect the entity. The data such as user’s password is transferred in clear text across the physical network used as the carrier. Thus basic authentication should never be used for sensitive or valuable information. Digest authentication can be used to address this problem. Basic Authentication is commonly used for User Identification by requiring the user to provide his user name and password. Some of the security breaches which may occur are illicit access to the server documents. Issue of user name and password by the server and One Time password scheme are some of the solutions for basic authentication. This type of authentication is also vulnerable to spoofing by other servers. Server implementers can use gateways or CGI Scripts to solve this. Thus additional enhancements can be implemented on basic authentication for authentication purpose.

3.2Abuse of server log information:

The logging information is sensitive and is private to the user. Thus the server should have proper mechanisms to protect the privacy and security of the user’s log information. The log information stored by the server usually contains the user’s request which can be used to identify the user’s subject of interest and his/her reading pattern. This is a confidential data and should not be distributed.

3.3Transfer of sensitive information:

It should not be considered that no sensitive data transfer takes place over RTSP. And it is difficult to recognize which information is sensitive. Thus care should be taken to secure the information. As stated in RFC 2068, and knowing RTSP is similar to HTTP in many views, consider the header information: server, via, referrer and from. This information reveals the user’s information. So we should have proxy servers acting as a portal through a network firewall. These should identify the hosts and take precautions when transferring the information. And options can be provided to the user to disable some information from being sent.

3.4Attacks based on file and path names:

The servers must make sure that the files sent on the requests of clients should be only those that are intended by the administrator of the network. When a server translates its URI’s directly into a file system call, it should be careful so as not to send files that were not intended to that client.

For Example, in UNIX Operating System, the pathname of a file can be “..”. Thus, “..” should not be allowed in the request URI as this may allow some other file to be accessed which may not be intended to the requested user. And some of the files which are just for the reference of the server should not be allowed to be accessed by any RTSP client. This may lead to a serious security concern and thus must be avoided.

3.5Personal Information:

RTSP users have private data such as user name, mail address, encryption keys passwords etc. This information should not be leaked through any protocol RTSP, HTTP, etc. Thus the implementers should provide a mechanism which helps the users protect the personal information. This area of security is prone to security problems and care should be taken during implementation.

3.6Privacy Issues Connected to Accept Headers:

Information about the users can be revealed due to access headers, to all the servers which have been accessed. Accept header fields which are present in every request, particularly if they contain quality values, are used by servers as reliable user identifiers. But, these identifiers will let the content providers to forming submissions of users or matching cross-server click trails. And the network address of a host which is running a user agent can also be a long lived user identifier, if they are not behind a proxy. Thus when proxies are used for maintaining privacy, user agents should be careful while offering accept header configuration options to end users. An option of proxies filtering the accept headers can be provided in relayed requests for more privacy.

3.7DNS Spoofing:

As the RTSP sessions have a longer connection time compared to HTTP sessions, the dominance of the RTSP client DNS optimizations must be less.

The RTSP clients heavily rely on DNS, and thus the probability of security attacks which basically involve mis-association of DNS names and IP addresses. Thus instead of caching a previous host name lookups, the clients should depend on the name resolver for IP number/DNS name association. Some servers do cache the host name look ups, but they should have a TTL (Time To Live).

If they fail to look up at the TTL, the servers can be prone to spoofing.

This method also helps the user in reducing his/her experience of failure in accessing the sites which use replicated servers for improving load balancing property of clients.

3.8Location Headers and Spoofing:

There maybe multiple organizations which are supported by a single server. And these organizations need not trust each other. Thus, the server will check the Content Location and Location headers in the responses which are generated under the mentioned organizations to confirm that an organization has not attempted to invalidate the resources on which it does not have any authority

3.9Concentrated denial-of-service attack:

One of the advantages of RTSP protocol is that it allows a remote controlled denial-of-service. An attacker can initiate a flow of traffic to many IP Addresses by specifying them as destinations of a SETUP message. Though we can get to know the ipaddress of the attacker when this type of security attack occurs, it doesn’t help us in stopping further such attacks. This can be controlled by configuring the server to allow only the clients it recognizes to initiate an RTSP message. This process can be carried out either by using a database of known clients by authentication mechanisms in RTSP or by any other secure means.

3.10 Session Hijacking:

In RTSP, there is no relation between the session and the transport layer connection, an attacker can add his/her own session identifier and send some requests which may harm the destination. Thus care should be taken while implementing the protocol and large and random and non sequential session identifiers to minimize the possibilities of such attacks.

3.11 Authentication:

The RTSP servers should have both basic and digest authentication mechanisms. If the servers need more privacy and security, it may extend the security mechanism by encrypting all the data it is sending over the network.

3.12 Stream Issues:

The RTSP protocol mainly deals with the stream control. But the stream delivery is handled by other protocols such as IGMP, RTP and IP multicast etc. Thus, while implementing RTSP protocol, the security considerations of the related protocols must also be addressed.

3.13 Persistently suspicious behavior:

Whenever a RTSP server encounters a suspicious behavior from a client, it should stop the session and return an error code 403(forbidden). The RTSP server should be capable of detecting the weak points of a server and also the probable entry points of malicious connections. The server should also be able to stop processing requests from a client which doesn’t follow the basic local security policies.

References
IETF Standard – RFC 2326 Real Time Streaming Protocol, April 1998
IETF Standard – RFC 2068 Hypertext Transfer Protocol - HTTP/1.1, January 1997
IETF Standard – RFC 2069 An Extension to HTTP : Digest Access Authentication, January 1997