15.7. RealAudio and RealVideo
RealAudio
and RealVideo are proprietary protocols developed by RealNetworks to
provide real-time streaming of audio and video data across the
Internet. Although the players for these protocols can run as
independent applications, they are most frequently used as plug-ins
to web browsers. At this writing, these are the most popular
protocols for distributing relatively large amounts of audio or
video.
The advantage of using them instead of simply distributing audio or
video files is twofold. First, if a web browser encounters an audio
or video file, it needs to download the entire file before playing
it. This can mean a long and extremely boring wait if the file is
eventually going to play for more than a few seconds. Few people are
willing to hang around watching a transfer progress meter move for 20
minutes in order to watch a 10-second movie. Second, because the
files are downloaded, users are not only able to make their own
copies, they're encouraged to do so; once they've waited
the 20 minutes, they're certainly not going to delete the local
copy of the file! If you want to keep track of who's watching
the file when, and you don't want copies of it floating around,
this is extremely undesirable.
Protocols for distributing audio and video tend to based on UDP
because people are more tolerant of having small amounts of data lost
than of having pauses. With TCP, if a packet is lost, there will be a
wait for retransmission, which is much more annoying than just going
on to the next packet. Audio and video protocols also tend to use
multiple ports in order to maximize efficiency. Because of these
characteristics, these protocols tend to be difficult to support
through firewalls.
15.7.1. Risks of RealServer
Running a server
for RealAudio or RealVideo is not inherently dangerous; the protocol
is a relatively safe one for the server. On the other hand,
RealNetworks has had some problems with security, and both the
Windows NT and the Unix server have been distributed with extremely
risky installations. Be sure that configuration files are not
world-writable, that created accounts have appropriate privileges and
passwords, and that programs are not running with more privileges
than they need. Since the servers represent a considerable load in
any case, you may want to dedicate a bastion host to them; that will
also help to contain any security problems.
15.7.2. Risks of RealAudio and RealVideo Clients
The RealAudio and RealVideo clients have relatively limited
capabilities and have not had any known security problems. Because of
the way the protocols work, it can be difficult to allow the clients
to run effectively without opening large holes in your firewall,
which is of course risky. However, the clients themselves are
relatively low risk if you are able to safely get the data to them.
15.7.3. Packet Filtering Characteristics of RealAudio and RealVideo
RealAudio and RealVideo by default use a system where a TCP
connection, initiated by the client, is used for session control,
while the actual data is transferred using UDP. Multiple UDP ports
may be used for the same session. Because this system is extremely
difficult to permit through packet filters without creating
significant extra vulnerabilities, it is possible to configure
RealVideo and RealAudio clients to use TCP only (on port 7070) or to
use TCP accompanied by UDP packets from a single port in the range
6970-7170, specified by the client.
Direction |
Source Addr. |
Dest. Addr. |
Protocol |
Source Port |
Dest. Port |
ACK Set |
Notes |
In |
Ext |
Int |
TCP |
>1023 |
7070 |
[50]
|
Request, external client to internal server |
Out |
Int |
Ext |
TCP |
7070 |
>1023 |
Yes |
Response session control, internal server to external client |
Out |
Int |
Ext |
UDP |
6970-7170[51]
|
>1023 |
[52]
|
Response data, internal server to external client |
Out |
Int |
Ext |
TCP |
>1023 |
7070 |
[50] |
Request, internal client to external server |
In |
Ext |
Int |
TCP |
7070 |
>1023 |
Yes |
Response session control, external server to internal client |
In |
Ext |
Int |
UDP |
6970-7170[51] |
>1023 |
[52] |
Response data, external server to internal client |
[50]ACK is not set on the first packet of this type
(establishing connection) but will be set on the rest.
15.7.4. Proxying Characteristics of RealAudio and RealVideo
RealNetworks provides sample code for RealAudio and RealVideo proxies
for use if you would like to have your own. They also have worked
with a number of firewall vendors to incorporate the proxy code into
products. Using a proxy is the best solution to get reasonable
performance of RealAudio and RealVideo through a firewall, since the
tricks used to make it allowable through packet filters significantly
decrease performance. However, the RealAudio and RealVideo proxies
can put a fairly considerable load on a machine.
15.7.5. Network Address Translation Characteristics of RealAudio and RealVideo
RealAudio and RealVideo will work with network translation if they
are configured to use TCP only; the UDP-based modes use embedded IP
addresses. You will need a network address translation system that
understands RealAudio and RealVideo to use UDP, but an appropriate
module is available for Linux IP masquerading.
15.7.6. Summary Recommendations for RealAudio and RealVideo
- Unless you need high performance, run RealAudio and RealVideo clients
configured to use TCP only, and permit outbound TCP connections on
port 7070.
- If you need high performance on RealAudio and RealVideo clients, use
RealNetworks' proxies.
- Run RealServer on a dedicated bastion host and configure it
carefully.
![Previous](../gifs/txtpreva.gif) | ![Home](../gifs/txthome.gif) | ![Next](../gifs/txtnexta.gif) |
15.6. Push Technologies | ![Book Index](../gifs/index.gif) | 15.8. Gopher and WAIS |