Supported Protocols for CBAC
CBAC can perform inspection for many protocols and applications; however, the depth of its inspection is not necessarily the same for each protocol or application. Here is a list of supported protocols and applications:
All TCP and UDP sessions, including FTP, HTTP with Java, SMTP, TFTP, and the UNIX R commands, such as rexec, rlogin, and rsh
ICMP sessions, including echo request, echo reply, destination unreachable, time exceeded, timestamp request, and timestamp reply ICMP messages
Sun Remote Procedure Calls (RPCs)
Oracle SQL*Net
H.323 v1 and v2 applications, including White Pine CU-SeeMe, Netmeeting, and Proshare
Real-Time Streaming Protocol (RSTP), including applications such as RealNetworks RealAudio G2 player, Cisco IP/TV, and Apple QuickTime 4 software
Other multimedia applications, including StreamWorks, NetShow, and VDOLive
Voice over IP (VoIP) protocols, including the Skinny Client Control Protocol (SCCP) and the Session Initiation Protocol (SIP)
All TCP and UDP sessions are supported for inspection, which includes putting a connection's information in a state table and dynamically adding an ACL entry for it (before FAB). For certain applications, such as FTP and SMTP, CBAC can perform additional inspection by restricting the control commands that are executed, fix nontranslated embedded addressing information, and examine control connections to see if additional connections are being set up.
Multimedia applications represent the biggest problem with stateful firewalls because they open multiple connections and sometimes embed addressing information in messages on the control connection. The Cisco IOS CBAC can inspect many of these applications and deal with their quirks, to allow secure connectivity.
RTSP Applications
The Real-Time Streaming Protocol (RTSP), defined in RFC 2326, defines how real-time data streams, such as voice and video, are delivered between devices. It typically is used in applications that need to deploy a large-scale broadcast solution, such as audio and video streaming. Applications that use RTSP include the RealNetwork RealAudio G2 Player, Cisco IP/TV, and Apple QuickTime 4 software.
RTSP uses three types of connections:
Control? Used as the main messaging connection between the client and server. It supports both TCP and UDP; however, CBAC performs inspection only for TCP.
Multimedia? Used to deliver audio, video, or data. These are UDP connections. Either the Real-Time Transport Protocol (RTP) or the Real Data Transport Protocol (RDT) is used to set up and maintain these connections. The Cisco IP/TV and Apple QuickTime 4 products use RTP. RDT was developed by RealNetworks and is used to manage the data connections and retransmission of missing packets. The RealNetwork RealServer G2 product uses RDT.
Error? Can be either a unidirectional or bidirectional UDP connection that the client uses to request missing information or to synchronize audio and/or video streams, to prevent jitter problems.
RTSP clients typically use TCP ports 554 or 8554 to connect to the multimedia server. The client and server then dynamically negotiate the UDP port numbers (1024 to 65,535) for the multimedia streams. Figure 9-4 shows an example of the different types of methods to establish RTSP connections. The top part of this figure shows a connection between a client and server using RTP, the middle part with a client and server using RDT, and the bottom part with a client and server using only a TCP connection for all functions (this typically is used only for small-bandwidth applications).
Figure 9-4. RTSP Connections
CBAC monitors the control connection to determine when it should add additional connections to its state table, as well as its inbound external ACL (before FAB), and remove the connections.
H.323 Applications
CBAC supports inspection for H.323 version 1 and 2 applications. H.323 defines how to deliver voice, video, and/or data between devices. Unlike RTSP, H.323 is much more complicated. First, either a terminal device can use a server, called a gateway, to find other terminal devices that have content, or it directly can access another terminal device. Second, many more connections are set up between the two terminals when sharing multimedia information.
If a terminal is connecting to a gateway, it opens a TCP connection to port 1720. The gateway then opens a connection back to the terminal, using a dynamically negotiated ports for this second connection that is used to pass control information. The terminal uses this connection to discover the location of other terminals. Based on where the terminal wants to connect, the gateway negotiates the UDP port numbers between the two terminals. The source terminal then initiates the UDP connections to the destination terminal. These UDP connections are used to transport voice, video, and other data payloads. For each of these feeds, there is a separate UDP connection.
Instead of using a gateway, a terminal can connect directly to another terminal, assuming that the destination terminal is configured for this. In this instance, the source terminal opens a TCP connection to port 1720 on the destination terminal, and the remaining UDP multimedia connections that need to be set up are negotiated dynamically, including the port numbers used for these connections. Figure 9-5 illustrates the connections set up directly between two terminals.
Figure 9-5. H.323 Terminal Connections
With CBAC, the Cisco IOS inspects the TCP 1720 command connection to determine what additional connections are being established between terminals or gateways. Then it adds the appropriate entry or entries in its state table and dynamically adds the necessary ACL statement(s), before FAB, to allow these additional connections. CBAC also monitors the command connection to determine when the primary or secondary connections no longer are needed, and removes them from the state table and the corresponding dynamic ACL (before FAB) from the inbound external ACL.
Skinny Support
Skinny is a Cisco-proprietary protocol that was developed to support Cisco VoIP phones and their connectivity. With Cisco IP phones, a server runs the CallManager (CM) software. CM has all the phone configurations, as well as their location information. Using DHCP, when a Cisco IP phone boots up, it acquires its IP addressing information as well as the IP address of the CM server.
Figure 9-6 illustrates the connections set up with Skinny. First, the IP phone registers itself with CM (by its IP address) and its identification information. It does this by setting up a TCP connection (port 2000) to CM. This connection remains up until the IP phone is rebooted. If the phone needs additional configuration, CM can function as a TFTP server, holding the phone's configuration on its disk drive. The IP phone then can use TFTP to download its configuration file.
Figure 9-6. Skinny Connections
After it has registered with CM, an IP phone can make phone calls to other IP phones. When making a call, the IP phone contacts the CM and tells it the destination phone that it wants to connect to, as well as the source UDP port number that the phone will use. The CM contacts the destination IP phone and informs it of the new connection request. Assuming that the phone is in an on-hook state, the destination IP phone passes back the UDP port number that the source phone should use, which, in turn, the CM passes to the source phone. The source phone then establishes the connection to the destination.
CBAC supports inspection of Skinny connections as of Cisco IOS 12.3(1). With inspection, CBAC inspects the control packets exchanged between the client IP phone and CM. Based on this inspection, CBAC adds (and removes) the necessary entries in the state table and dynamic ACL entries (before FAB) to allow the voice connection to be set up (and torn down) directly between the two IP phones. Some restrictions with Skinny include the following:
A music-on-hold server, if used, must be installed on the CM: it cannot reside on another device.
The firewall router with CBAC cannot be the CM because CBAC inspection can inspect only connections going through the router, not connections that terminate on the router.
The CM and the two IP phones making the connection cannot be on three different networks that are separated by the router/firewall with CBAC. Inspection works only if the three devices are connected to no more than two interfaces on the CBAC router.
SIP Support
SIP is a standards-based protocol that defines the interaction between a VoIP phone, VoIP gateway, and other VoIP phones; it is specified in RFC 2327. SIP defines how to establish, maintain, and tear down phone calls using VoIP.
Figure 9-7 illustrates the connections set up with SIP. First, the client sets up either a TCP or UDP connection to the VoIP gateway (destination port 5060). This is the signaling connection and is used to send call setup and teardown messages to the gateway. After establishing the signaling connection, the VoIP phone can make phone calls. It does this by using the signaling channel to initiate the connection through the gateway. The IP phone sends an unused UDP port greater than 1023 to the gateway, along with the identification of the device that it wants the call. The gateway then contacts the destination IP phone and requests the UDP port number on the destination that the source should use. The gateway passes both the destination IP address and the port number back to the source on the signaling channel. The source IP phone then establishes the phone connection directly to the destination phone. As you can see from this process, the call setup is very similar to that of Skinny.
Figure 9-7. SIP Connections
CBAC supports the inspection of SIP connections as of Cisco IOS 12.2(11)YU and 12.2(15)T. CBAC inspects the control packets exchanged between the VoIP phone and VoIP gateway. Based on this inspection, CBAC adds (and removes) the necessary entries in the state table and dynamic ACL entries (before FAB), to allow the voice connection to be set up directly between the two IP phones. Some restrictions with SIP include the following:
Although SIP supports connections based on DNS names and IP addresses, CBAC supports only connections that specify IP addresses for phone connections. Therefore, the gateway must pass back an IP address of the destination phone.
SIP supports both TCP and UDP for the signaling connection. However, CBAC supports only UDP (port 5060, by default).
