Security continues to be the biggest concern for IT managers and, in turn, design engineers developing firewall systems. With more viruses popping up and hackers attacking more often, corporations are looking for any approach possible to plug holes in their firewall architectures.
Traditionally, designers have turned to packet classification, also called stateless classification, as a means for providing higher levels of performance in a firewall architecture. While doing a nice job on analyzing an individual packet, the packet classification approach falls short. Specifically, by not relating individual packet information to an overall flow, these classification engines can leave big holes in the firewall architecture, requiring application-level proxying, which adds cost and degrades firewall performance.
What's needed is a more stateful approach to classification. Rather than simply looking at a packet, designers need to implement stateful classification techniques that allow designers to classify the properties of a packet as well as understand how that packet fits into an overall communication flow. Here's why.
Stateful vs. Stateless
Classification capabilities can be described as stateful and stateless. Stateful classification parses packets and decodes the underlying protocols and their states throughout their evolution. Some protocols connect on pre-defined port numbers, also known as "well-known" ports. Other protocols connect on dynamically negotiated port numbers based on resource availability, also known as "ephemeral" port numbers.
Stateful classifiers, also called flow processors, track the dynamic negotiations, analyze the data streams, and have the ability to predict and decode related traffic connecting on ephemeral ports. Tracking, decoding, and analyzing protocols make stateful classifiers application-aware.
Stateless classification of network traffic, on the other hand, is based on pattern-matching and four-tuple look-up. Stateless classifiers, often called packet classifiers, parse individual packets without any context preservation to a flow (related stream of packets in a protocol connection). Furthermore, stateless classification does not have the capability to "anticipate" or track flow relationships of flows on dynamically negotiated (ephemeral) ports.
Stateless classification is connection based, thus requiring the classification engine to run a four-tuple look-up for source/destination IP addresses and TCP port numbers. Today, there are numerous IC based packet classification solutions available, and are widely deployed in core routing applications, such as congestion management and next-hop IP address look-up.
Why Stateful Wins Out
So why is stateful processing more effective? Analyzing network traffic at layer 3 with embedded protocol decoding intelligence enables "true" layer-7 application-aware policies. This flow processor feature is best demonstrated using an example of a complex, multi-media protocol H.323 (an application with many dynamic protocol connections).
Figure 1 depicts the relationships of the protocol connections in a typical H.323 application. Furthermore, this figure also illustrates a stateful flow processor's analysis capability over stateless packet classifiers in an H.323 application.
Figure 1: Relationships between protocol connections in a typical H.323 application.
H.323 spawns two TCP connections--one for call setup (Q.931) and another for call configuration (H.245). Then H.323-H.245 spawns at least eight user datagram protocol (UDP) streams for audio and video transmission, transported utilizing the real-time transport protocol (RTP) and the RTP control protocol (RTCP)
Although the RTP streams are spawned by a "parent" protocol (such as H.323-H.245) they do not contain any information that relates them to the applications that spawned them. Unless the H.323 application is tracked, decoded, and analyzed from the beginning, there is no way to know that the H.323-Q.931 connection dynamically negotiated the H.323-H.245 connection, and that the H.323-H.245 connection dynamically negotiated the RTCP/RTP connectionless (UDP) data streams.
Stateless classifiers identify protocols connected on "well-known" ports like H.323-Q.931 on TCP port 1720. Although all the RTCP and RTP streams are negotiated by H.245, packet classifiers are unable to relate them to the parent protocols because they don't decode the protocols and recognize the ephemeral port negotiations. Hence, all the subsequent audio and video streams are classified as general UDP traffic, and unrelated to the H.323 application.
On the contrary, stateful flow classifiers start analyzing packets at the beginning of the application, and maintain flow entries in a flow database to track and analyze the relationships of the evolving dynamic flows, which empowers the policy engine to correctly process every packet in every related flow to the end-application. All relationships are preserved as hierarchical (parent-child) relationships.
In Figure 1, every audio and video packet would be related to H.323-H.245, which is related to H.323-Q.931, which is related to a streaming media application, like NetMeeting, MSMedia, Real Player, or other web-based multi-media applications. Using this information, the firewall can make more intelligent policy, routing, queuing, firewall, and security service decisions on the traffic flow at hand.
A Firewall Implementation
To further illustrate the benefits of a stateful flow classifiers over a stateless packet classifiers, let's look at it running in a firewall implementation. Figure 2 illustrates firewall access control list (ACL) for controlling H.323 connections. The ACL rules allow a user system to initiate H.323 calls to the outside network, prevent outsiders from initiating H.323 calls into the protected network, and deny the user system from initiating any other types of traffic to outside the protected network.
Figure 2: Firewall ACL (H.323 snapshot) based on a stateless/packet classifier
With packet classifiers the scope of ACL rules is limited to IP (source and destination) addresses and TCP (source and destination) port numbers. Figure 2 illustrates a connection-based ACL developed around a packet classification technology. All stateful protocols that are not supported by the connection-based rules must be proxied, which involves additional cost and performance degradation.
In the upper half of Figure 2, outbound ACL rule #1 allows a user system to send packets anywhere on the outside network to TCP port 1720, which is the well-known port to initiate H.323 using Q.931 protocol. Outbound ACL rule #2 allows the user system to send packets anywhere on outside network to UDP or TCP ports above 1024, which are generally ephemeral ports negotiated during protocol establishment. Outbound ACL rule #3 denies any packets that do not meet the first two outbound ACL rules.
In the lower half of Figure 2, inbound ACL rule #1 allows inbound TCP packets destined to the internal user host whose synchronize (SYN) bit is not set (or packets with both SYN and acknowledge (ACK) bits set), that is any TCP packet that is not trying to establish a new TCP connection. Thus, any malicious inbound TCP packets passed by the firewall would be dropped by the internal user host's TCP stack because the firewall has blocked all inbound TCP packets trying to initiate a TCP connection.
Inbound ACL rule #2 allows responses from UDP or TCP ports above 1024, which are generally ephemeral (dynamic) ports negotiated during protocol establishment. As with outbound ACL rule #2, the inbound ACL rule #2 must be flexible enough to allow various values of ephemeral ports used by H.323 on the internal user system to be passed inbound.
This opens a rather large range of port values that may traverse the firewall in an inbound direction. The hole created by this rule is even more severe since it permits a lot of unchecked traffic to reach internal user host on protected network.
While stateless ACLs offer higher throughput, they are also susceptible to holes in order to support stateful protocols. Holes open conduits for hackers to steal information from, inject viruses into, or deny service with the host behind the firewall by misusing permitted protocols to this host, or possibly establishing illegitimate protocols undetected by the stateless firewall. In this example, the hole is static and rather large, and poses a security risk.
There are two alternatives for stateless firewalls to avoid opening holes and to ensure that protected network is secure. One is to forbid the internal user from accessing H.323 applications, which is not useful. The other is to proxy the entire application. This means the firewall performs the H.323 application for both the internal user and external server, which is an extremely inefficient process. Thus, robustness, flexibility, and efficiency are severely lacking in a stateless firewall.
Flow Classification to the Rescue
Above we looked at a stateless firewall design. Now let's turn to a firewall employing stateful analysis techniques.
A flow processor-based firewall ACL comprises rules that would track protocols and applications. Protocols that connect on "well-known" ports are easily identified. Protocols that dynamically connect on negotiated ephemeral ports would be tracked by their hierarchical flow relationships. Figure 3 provides a snapshot of the same H.323 protocol rule set used in Figure 2.
Figure 3: Firewall ACL (H.323 snapshot) based on a flow processor.
One can immediately note the difference from the prior example. The ACL no longer needs to rely on uncertain conditions based on TCP/UDP ports and TCP flags. Instead, the ACL takes advantage of several key stateful result fields of the secure flow processor.
Inbound and outbound rules #1 accomplish the same task as in the prior example. They permit internal user to initiate and carry on Q.931 calls while denying him/her from receiving any Q.931 calls from outside. Note that New_Flow_Flag is used here on inbound instead of the more complicated TCP SYN or (SYN and ACK). This flag reflects the ability of the secure flow processor to statefully track TCP connection establishment.
The greatest advantage of secure flow processing can be seen in inbound and outbound rules #2. These rules exist to selectively allow traffic for inbound and outbound TCP connections and UDP streams dynamically created during the course of each H.323 call. Recall that without secure flow processing we were forced to open up inbound and outbound firewall holes for TCP and UDP traffic on all ports above 1024. With flow processing the ACL can rely on Parent_Flow_ID flag instead, and thus avoid opening any holes.
When the flow processor specifies non-zero Parent_Flow_ID in its result, it indicates that the packet belongs to a TCP connection or UDP stream which is related to a prior connection or stream. Recall that inbound and outbound rules #1 permitted the internal user to make and to carry on Q.931 calls. The flow processor analyzes Q.931 messages, which negotiate ports for the H.245 dynamic connection. This allows the flow processor to recognize the packets belonging to this specific H.245 connection and to produce results with non-zero Parent_Flow_ID, which contain the Flow_ID of the prior related Q.931 connection. Therefore, ACL inbound and outbound rule #2 permits H.245 traffic specifically related to internal user-initiated H.323 calls.
Similarly, the flow processor analyzes H.245 messages, which negotiated UDP ports for dynamic media streams, which use RTP and RTCP protocols transported over UDP. This allows the flow processor to recognize the packets belonging these specific streams and to produce results with non-zero Parent_Flow_ID, which contain the Flow_ID of the prior related H.245 connection. Therefore, ACL rule #2 also permits media streams related to 'Internal User' H.323 calls.
Finally, the flow processor recognizes when the H.323 control connections (Q.931 and H.245) close via TCP handshakes, TCP resets, or TCP timeouts and removes any state related to these connections and all related connections and streams. Thus, any replayed packets will now produce results with Parent Flow ID set to zero which can be denied by ACL inbound and outbound rules #3.
The audio and video streams of RTP/RTCP are particularly noteworthy, since they do not explicitly close, because UDP is connectionless. The RTP and RTCP packets are implicitly denied after their parent flows (Q.931 and H.245) are closed.
Based on this example, designers can see that the stateful firewall ACL achieved transparent passage of all valid H.323 traffic through the firewall without sacrificing security or performance, nor increasing costs. There are no static port ranges in the firewall ACL that open up holes through which potentially dangerous traffic may pass.
Some Added Pluses
One of the added benefits of stateful analysis is that all packets are processed in the dataplane. Since packets do not have to be passed to a control processor for proxying, a separate control processor is not needed to perform the application proxy function and two passes through the TCP stack. Additionally, designers eliminate the need to pass information over slow bus architectures, such as PCI.
Elimination of policy-rule lookups on every packet is another potential benefit of the stateful approach. Since the flow processor can associate every packet with a flow, and hence a policy, it can provide the policy engine with the policy's "action handle". Thus, once the policy engine determines the policy action for an application that starts up, the policy engine can program the flow processor with its policy handle for future processing of packets. This capability enhances overall system performance.
About the Authors
Robert Friend is a senior staff systems technologist at Hifn. He is an
active member of the IETF, co-authoring RFC1967, RFC1974, and RFC2395. Robert earned a BSEE from UCLA and can be reached at rfriend@hifn.com.
Rahul Patel is a business line manager for Hifn's application
classification line of products. He holds a BSEE from Warangal, India, an MSCS from Arizona State University, and an MBA from Santa Clara
University. Rahul can be reached at rpatel@hifn.com.
