Multimedia Support
This section discusses multimedia: advantages and supported applications, H.323 support, and important multimedia configuration considerations.
Multimedia applications present a particularly daunting challenge to a firewall, as clients may transmit requests on TCP, get responses on UDP or TCP, use dynamic ports, may use the same port for source and destination, and so on. Every application behaves in a different way. Implementing support for all multimedia applications using a single secure method is very difficult.
Two examples of multimedia client applications are as follows:
RealAudio clients send the originating connection request to TCP port 7070. The RealAudio server replies with multiple UDP streams anywhere from UDP port 6970 through 7170 on the client machine.
The CUseeMe client sends the originating request from TCP port 7649 to TCP port 7648. The CUseeMe datagram is unique in that it includes the legitimate IP address in the header as well as in the payload and sends responses from UDP port 7648 to UDP port 7648.
The Cisco Secure PIX Firewall dynamically opens and closes UDP ports for secure multimedia connections. This significantly reduces the security risk posed by opening a large range of ports and mitigates the need to reconfigure application clients.
Also, the PIX Firewall supports multimedia with or without NAT. Firewalls that cannot support multimedia with NAT limit multimedia usage to registered users only or require exposing inside IP addresses to the Internet. Lack of NAT support for multimedia often forces multimedia vendors to join proprietary alliances with firewall vendors to accomplish compatibility for their applications.
Real Time Streaming Protocol (RTSP)
The Real Time Streaming Protocol (RTSP), described in RFC 2326, is a real-time audio and video delivery protocol used by many popular multimedia applications. It uses one TCP channel and sometimes two additional UDP channels. RTSP applications use the well-known port 554, usually TCP and rarely UDP. RFC 2326 requires only TCP so the PIX Firewall only supports TCP. This TCP channel is the control channel and is used to negotiate the other two UDP channels depending on the transport mode that is configured on the client.
The first UDP channel is the data connection and may use one of the following transport modes:
Real-Time Transport Protocol (RTP)
Real Data Transport Protocol (RDT) (developed by RealNetworks, Inc.)
The second UDP channel is another control channel, and it may use one of the following modes:
RTP Control Protocol (RTCP)
UDP Resend
RTSP also supports a TCP-only mode. This mode contains only one TCP connection, which is used as the control and data channels. Because this mode contains only one constant standard TCP connection, no special handling by the PIX Firewall is required.
The following RTSP applications are supported by the PIX Firewall:
- Cisco IP/TV
- Apple QuickTime 4
- RealNetworks
- RealAudio
- RealPlayer
- RealServer
Note that RDT Multicast mode is not supported.
RTP Mode
In standard RTP mode, the following three channels are used by RTSP:
TCP control channel—Standard TCP connection initiated from the client to the server.
RTP data channel—Simplex (unidirectional) UDP session used for media delivery using the RTP packet format from the server to the client. The client's port is always an even-numbered port.
RTCP reports—Duplex (bi-directional) UDP session used to provide synchronization information to the client and packet-loss information to the server. The RTCP port is always the next consecutive port from the RTP data port.
Figure 9-5 illustrates the communication between client and server in standard RTP mode for RTSP.
){kind=link}
Figure 9-5 Standard RTP Mode Client/Server Transactions
For standard RTP mode RTSP traffic, the PIX Firewall behaves in the following manner:
Outbound connections—After the client and the server negotiate the transport mode and the ports to use for the sessions, the PIX Firewall opens temporary inbound conduits for the RTP data channel and RTCP report channel from the server.
Inbound connections—If a conduit exists allowing inbound RTSP connections to an RTSP server, and if all outbound UDP traffic is implicitly allowed, no special handling is required, since the server initiates the data and report channel from the inside.
If a conduit exists allowing inbound RTSP connections to an RTSP server, and if all outbound TCP traffic is not implicitly allowed, the PIX Firewall opens temporary conduits for the data and report channels from the server.
RealNetworks' RDT Mode
In RealNetworks' RDT mode, the following three channels are used by RTSP:
A TCP control channel—Standard TCP connection initiated from the client to the server.
A UDP data channel—Simplex (unidirectional) UDP session used for media delivery using the standard UDP packet format from the server to the client.
A UDP resend—Simplex (unidirectional) UDP session used for the client to request that the server resend lost data packets.
Figure 9-6 illustrates the communication between client and server in RealNetworks' RDT mode for RTSP.
){kind=link}
For RealNetworks' RDT mode RTSP traffic, the PIX Firewall will behave in the following manner:
Outbound connections—If outbound UDP traffic is implicitly allowed, and after the client and the server negotiate the transport mode and the ports to use for the session, the PIX Firewall opens a temporary inbound conduit for the UDP data channel from the server.
If outbound UDP traffic is not implicitly allowed, and after the client and the server negotiate the transport mode and the ports to use for the session, the PIX Firewall opens a temporary inbound conduit for the UDP data channel from the server and a temporary outbound conduit for the UDP resend channel from the client.
Inbound connections—If a conduit exists allowing inbound RTSP connections to an RTSP server, and if all outbound UDP traffic is implicitly allowed, the PIX Firewall opens a temporary outbound conduit for the UDP data channel from the server.
If a conduit exists allowing inbound connections to an RTSP server, and if all outbound TCP traffic is not implicitly allowed, the PIX Firewall opens temporary conduits for the UDP data and UDP resend channels from the server and client, respectively.
Figure 9-6 RealNetworks' RDT Mode Client/Server Transactions
By default, the PIX Firewall does not inspect any ports for RTSP connections. To enable the PIX Firewall to inspect specific ports for RTSP traffic, such as the standard port 554, use the fixup protocol rtsp command.
The fixup protocol rtsp command enables the PIX Firewall to dynamically create conduits for RTSP UDP channels for RTSP traffic on the indicated port. The syntax of the fixup protocol rtsp command is as follows:
fixup protocol rtsp port [-port ] no fixup protocol rtsp port [-port ] clear fixup protocol rtsp
where port[-port] is the single port or port range that the PIX Firewall will inspect for RTSP connections.
Use the no form of the command as shown in Example 9-5 to disable inspection of traffic on the indicated port for RTSP connections. If the fixup protocol rtsp command is not enabled for a given port, then neither inbound nor outbound RTSP will work properly on that port.
Example 9-5 Adding and Deleting Standard and Non-standard Ports for RTSP
|
pixfirewall#(config) fixup protocol rtsp 554 |
|
pixfirewall#(config) fixup protocol rtsp 8554-8574 |
|
pixfirewall#(config) no fixup protocol rtsp 554 |
|
pixfirewall#(config) no fixup protocol rtsp 8554-8574 |
NOTE
To allow support for Cisco IP/TV the RTSP fixup protocol needs to be configured for TCP port 8554 as well as the default of TCP port 554 using fixup protocol rtsp 8554.
Using the clear fixup protocol rtsp command without any arguments causes the PIX Firewall to clear all previous fixup protocol rtsp assignments.
H.323
H.323 is more complicated than other protocols because it uses two TCP connections and several UDP sessions for a single "call." (Only one of the TCP connections goes to a well-known port; all the other ports are negotiated and thus temporary.) Furthermore, the content of the streams is far more difficult for firewalls to understand than existing protocols, because H.323 encodes packets using Abstract Syntax Notation (ASN.1).
Other protocols and standards supported within H.323 are
H.225-Registration, Admission, and Status (RAS)
H.225-Call Signaling
H.245-Control Signaling
TPKT Header
Q.931 Messages
Abstract Syntax Notation (ASN.1) (PIX Firewall 5.2)
Supported H.323 versions are as follows:
H.323 v1
H.323 v2 (PIX Firewall 5.2)
PIX Firewall supported H.323 applications include
Cisco Multimedia Conference Manager
Microsoft NetMeeting
Intel Video Phone
CUseeMe Networks
MeetingPoint
CUseeMe Pro
VocalTec
Internet Phone
Gatekeeper
fixup protocol h323 Command
By default, the PIX Firewall inspects port 1720 connections for H.323 traffic. If you have H.323 servers operating on ports other than port 1720, use the fixup protocol h323 command to have the PIX Firewall inspect those non-standard ports for H.323 traffic. The syntax of the fixup protocol h323 command is as follows:
fixup protocol h323 port [-port ] no fixup protocol h323 port [-port ] clear fixup protocol h323
where port[-port] is a single port or port range that the PIX Firewall will inspect for H.323 connections.
Example 9-6 demonstrates the typical use of the fixup protocol h323 command and its no form to add and delete standard and non-standard ports for H.323 traffic.
Example 9-6 Adding and Deleting Standard and Non-standard Ports for H.323
|
pixfirewall(config)# fixup protocol h323 1720 |
|
pixfirewall(config)# fixup protocol h323 7720-7740 |
|
pixfirewall(config)# no fixup protocol h323 1720 |
|
pixfirewall(config)# no fixup protocol h323 7720-7740 |
The fixup protocol h323 command causes the PIX Firewall to do the following for H.323 traffic on the indicated port:
Perform NAT in packet payload.
Dynamically create conduits for TCP or UDP channels.
Use the no form of the command to disable the inspection of traffic on the indicated port for H.323 connections. If the fixup protocol h323 command is not enabled for a given port, then neither outbound nor inbound H.323 will work properly on that port.
Using the clear fixup protocol h323 command without any arguments causes the PIX Firewall to clear all previous fixup protocol h323 assignments and set port 1720 back as the default.