Streaming Media Supplement sa2150 and sa2250

Chapter 2 Media-IXT Deployment Scenarios

• Application-level firewalls (such as proxies)

• Network-level firewalls (such as packet filters)

• SOCKS firewalls (considered an alternative network-level firewall)

To allow any version of RealAudio

Player, RealPlayer, QuickTime player, or Windows Media Player to play

correctly, the firewall must allow packets that are bound for certain ports to pass to the inner network.

This section provides general comments about firewalls and goes on to explain how Media-IXT works with

them.

Application-level firewalls (proxy firewalls)

Application-level firewalls are named for the application layer (Layer 7) of the OSI model. Any application at

that level

• can look at the object data (payload) within packets passing through its host, and

• must understand the protocol which is characteristic of that data.

So, an application-level firewall that deals with streaming media traffic must “talk” HTTP , RTSP, MMS, or all

three.

An application-level firewall acts as a proxy between the client and the origin server. Since they are both

proxies, Media-IXT and the application-level firewall can (and should) be configured as a hierarchy, where

Media-IXT is the child and the firewall is the parent.

The application-level firewall can tunnel data or modify it. The details are beyond the scope of this manual; we

can say, though, that some firewalls set up a generic tunnel between Media-IXT and an origin server, and, that

this is not true for RealNetworks streaming. For Media-IXT, RealNetworks streaming through a firewall

requires the firewall to run some extra software from HP, and is not a matter of generic tunneling. This is

explained in “Understanding firewalls and RealNetworks” on page 30, and “Configuring firewalls for

RealNetworks” on page 75.

Network-level firewalls (packet-filtering firewalls)

Network-level firewalls, despite the name, inspect packets at the transport layer (layer 4) of the OSI model.

What network-level firewalls look for is the destination port to which TCP packets are addressed. Using access

control lists (ACLs), network-level firewalls allow traffic destined for some ports to pass from the Internet to

an organization's internal network, and block packets aimed at other ports. That is, each packet is either

forwarded or filtered. For this reason, network-level firewalls are also known as packet-filtering firewalls.

Routers, layer 4 switches with Network Address Translation (NAT), and Media-IXT’s Adaptive Redirection

Module all have capabilities similar to the network-level firewall.

For clients to receive streaming media content, the firewall must allow packets that are bound for the ports

associated with the relevant protocols to pass to the inner network. (The main streaming media protocol/port

associations are port 554 with RTSP, and port 1755 with MMS.)

SOCKS and Media-IXT

SOCKS is a networking proxy protocol that tunnels connection requests from hosts on opposite sides of a

SOCKS server. The SOCKS server authenticates and authorizes the requests, establishes a proxy connection,

and relays data.

SOCKS is commonly used to enable hosts behind a SOCKS server to gain full access to the Internet, while

preventing unauthorized access from the Internet to the internal hosts. In this way, a SOCKS firewall can be

implemented.

You can enable SOCKS when you configure Traffic Server. Traffic Server with SOCKS enabled accepts client

requests in the usual way. A SOCKS client built into Traffic Server then uses the designated SOCKS server in

much the same way as it would use a parent proxy. The difference is that Traffic Server communicates with the