Stateful vs. stateless traffic analysis

Transcription

1 Stateful vs. stateless traffic analysis Rahul Patel Business Line Manager, Advanced Products Group Hifn, Inc. Introduction Over the past few years, the Internet has become a conduit of diverse and complex forms of communication, a new way to do business, and to an extent, a medium for socialization; ultimately taking productivity to a level that has never been experienced before for the benefit of the environment, economy, and life in general. The challenges for most of the providers and users of services (ISPs, networking OEM manufacturers, enterprises, end-users and others) that enable the use and benefit of the Internet is to create a business model that will help them, not only sustain, but also profit from their participation in the new Internet economy. Recently, many of the providers of the Internet have failed to keep up with the challenge to maintain a sustainable business model, and hence succumbed to failure in what is widely termed as Internet bust. Hence, going forward, the mantra for the Internet provider is simple: create a sustainable business model. Internet is a service. Like in any service oriented business, accountability, reliability and robustness are key elements of making the business, not only sustainable, but also profitable. ISPs are actively looking up to equipment deployed in their networks to be intelligent enough to account for a service, and to make it more reliable in executing the customer agreed upon service level agreements (SLA). This effectively transfers some or most of the responsibility for intelligence in the network on OEM equipment manufacturers. Intelligent equipment may be defined as equipment that can do one or more of the following type services in a very reliable and robust form: QoS, firewall, security, NAT/ PAT (L3/L4) transforms, bandwidth/traffic management, monitoring, metering etc. This means that any and every data gram (packet) that gets serviced by the networking equipment would need to be parsed for its whereabouts, and analyzed in context of the application it is associated with - i.e. perform a thorough deep, granular, applicationaware classification. Stateful & Stateless Classification of Network Traffic Network traffic classification is a process in which network traffic is parsed and analyzed based on certain pattern matching and/or underlying protocol decoding schemes. This processing function gives the policy engines information that makes the policy engine implementation more robust and reliable. The finer and precise the classification is, the better the policy based decision-making process. Figure 1. Classification of Network Traffic (Packets) Today, there are two prominent types of classification capability available in the networks: stateful and stateless. Stateful classification depends predominantly on packet pattern matching and decoding of the underlying protocols and their states throughout their evolution. Some protocols are spawned on pre-defined port numbers, also known as well-know ports numbers. Some other protocols 86 IIC-China/ESC-China 2002 Conference Proceedings

2 are spawned on dynamically negotiated port numbers based on resource availability. These dynamically negotiated protocols are spawned on dynamically assigned port numbers, also known as ephemeral port numbers. Stateful classifiers track the dynamic negotiations and hence have the ability to predict and decode traffic spawned on ephemeral ports. Today, most of the classification of network traffic is based on packet pattern-matching and 4-tuple look-up. This kind of analysis does not classify traffic based on underlying protocols and its states, and hence, it is referred to as stateless classification. Stateless classification is parsing of individual packets without any context preservation to any related stream of packets/flows/sessions/protocols/applications. Further, this kind of classification does not have the capability to anticipate or track flow relationships on flow/sessions spawned on dynamically assigned (ephemeral) ports, ultimately making stateless classification not an applicationaware or true (OSI) layer-7 classification solution. This form of classification is based on individual packet inspection only i.e. 4/5-tuple look for source/destination IP addresses and TCP port numbers (first two fields of the packet as show in Figure 1). Stateless classification solutions are also referred to as packet classifiers. Today, there are numerous IC based packet classification solutions available, and are widely deployed in core routing based policy applications. Stateful classification is not only a parsing function but also a detailed analysis of complete data streams (or related packets), or flows, or sessions, breaking them into their constituent components with full association to end-applications, which may consist of one or more inter-related protocols. Some of these inter-related protocols can also be spawned on ephemeral ports. A stateful classifier preserves context of the relationships and has the ability to anticipate dynamically assigned port numbers. This capability coupled with the ability to decode protocols makes this kind of solution application-aware. Stateful classification, on some packets, may require a thorough and detailed analysis of the entire packet (packet header and payload as show in Figure 1). Stateful classification solutions are also referred to as flow classifiers. Ideal flow classification based policy engine applications include firewalls (including intrusion detection, denial of service attacks and other attacks), security, NAT/PAT transforms, QoS (access edge of the internet for Class of Service), bandwidth management, load balancing, billing, metering and monitoring. Benefits of stateful classification over stateless classification Analyzing network traffic at layer-3 (of the OSI model) with embedded protocol decoding intelligence enables true layer-7/end-application aware policies. This feature is the single largest benefit of stateful classification. This benefit is best demonstrated using an example of a complex, multimedia protocol H.323 (a relational protocol with sub-protocols). Figure 2 depicts a tree of network protocols that are spawned as sub-protocols in a typical H.323 protocol session. Further, this figure also illustrates stateless/packet classifier s and stateful/flow classifier s analysis capability over a H.323 protocol session. H.323 spawns two TCP (Transmission Control Protocol) connections, one for call setup (Q.931) and other for call configuration (H.245). Then at least eight UDP (User Datagram Protocol) streams are spawned for audio and video transmission. H.323-H.245 (call control protocol) sets up various audio and video related RTP (Real-time Transport Protocol) and RTCP (RTP Control Protocol) streams. Although the RTP streams are spawned by a parent protocol (like H.323-H.245) they do not contain any information that Figure 2. Benefits of Stateful Classification over Stateless Classification IIC-China/ESC-China 2002 Conference Proceedings 87

3 relates them to the applications that spawned them. The ephemeral TCP and UDP ports are negotiated by parent flows: H.323-Q.931 is the parent of H.323-H.245, and H.323-H.245 is the parent of RTCP/RTP ( connectionless ) streams. Stateless (or Packet) classifiers can relate to protocols spawned on well-known ports only like H.323-Q.931 (on port#1720). Although all the RTCP and RTP streams are negotiated by Q.931, packet classifiers are unable to relate them the parent protocol. Hence, all the subsequent audio and video streams are unaccounted for in light of the endapplication. On the other hand, stateful (or flow) classifiers start analyzing packets at the beginning of the flow (H.323-Q.931). Further, flow classifiers maintain flow entries in a flow database to track and analyze the relationships of the evolving dynamic flow (spawned on ephemeral ports) empowering the policy engine to relate every packet (even on an associated connectionless RTP streams like audio and video) to the end-application. All relationships are preserved as hierarchical/parent-child relationships. In this example, every audio and video packet would be related to H.323-Q.931, which may be spawned by streaming media applications like NetMeeting, MSMedia, Real Player, and other Web multi-media applications. This ability of flow classifiers aids network infrastructure in providing intelligent policy, routing, queuing, firewall and security services related decisions based on deeper understanding of network traffic applications. An Example of a Flow Classifier Figure 3 indicates a high-level block diagram of Hifn s MeterFlow Accelerator (MFA) - a flow classifier. A flow classifier like MFA would identify/parse, and then analyze, all packets on the network connection. Packets are queued on a packet input queue. MFA first identifies the flow associated with each packet, and then builds a flow entry in the flow database for every new flow that is analyzed. MFA dynamically updates the flow entries upon performing stateful classification on packets in the associated flows as more packets are received and the protocol on the connection evolves. Flow entries also reflect hierarchical relationships between one or more related flows, flows and related protocols, one or more protocols, and protocols related to (layer-7 OSI model) applications. MFA then stores it in local SDRAM memory. Protocol/application specific decoding micro-code is embedded in the MFA. This enables MFA to decode and track the state of the protocol or the application as it evolves. Hifn s Protocol Definition Language (PDL) not only provides most of the widely deployed protocols and applications decoding engines, but also provides the flexibility to extend the protocol/application coverage to incorporate proprietary and newer protocols/applications. For every packet received, MFA outputs a packet result on the packet result queue, which identifies the flow entry ID, application protocol, and state of the protocol. This packet result is used for applications that need to make a policy decision (or packet modification, marking, deny/permit decision) on every packet in policy applications such as Figure 3. MeterFlow Accelerator (MFA) Device firewalls, DiffServ and MPLS edge routers, load balancers, etc. The policy-engine application will utilize MFA s application-aware results to perform a look-up in its database in order to arrive at a policy for the packet under scrutiny. Periodically, MFA outputs a flow report on the flow report bus, identifying the state of the flow and all child flows associated with the parent flow. The flow report is used for metering applications, such as bandwidth management, billing applications, SLA (service level agreement) validation/ verification etc. The metering applications may use the flow reports to measure usage and/or time, as well as bandwidth, jitter, and latency QoS characteristics of the connection, and may send notices based on the state of the flow. Additionally, the host sub-system may asynchronously request the current state of a flow entry in the flow database. These requests are made on the run-time control queue, and the response is output on the flow report queue. The run-time control queue is also used for MFA system configuration. Application Example: Stateful & Stateless Classification based Firewall To further illustrate the benefits of a stateful/flow classifier over a stateless/packet classifier, lets look at it running in a firewall implementation, (Below is a snapshot of H.323 rules in a firewall Access Control List). Assume this ACL snapshot is for an internal system InternalSystem#1, H.323 related traffic is bi-directional (i.e. InternalSystem#1 can communicate with any system outside the protected network, while any protected outside system can only respond to call initiated by InternalSystem#1). Stateless/Packet Classification based Firewall Since packet classifiers classify packets predominantly based on IP and TCP headers, the scope of ACL rules is limited to IP (source and destination) addresses and TCP (source and destination) port numbers. Table 1 illustrates a packet classifier (IP and TCP headers) based ACL. Rules can be compartmentalized into two major sections, i.e. one for outbound traffic and other for inbound traffic. Associated InternalSystem#1 IP address and destination port number tracks outbound H.323-Q.931 protocol packets. Q.931 spawns on a well-known port number (1720). Subsequent child flows (or sub-protocols) are spawned on 88 IIC-China/ESC-China 2002 Conference Proceedings

4 Table 1. Firewall ACL (H.323 snapshot) based on a Stateless/Packet Classifier dynamically allocated (ephemeral) ports. Usually, ephemeral port numbers are 1024 and higher. Hence, any and every UDP or RTP or TCP related packets that have a destination port number of 1024 and higher would also suffice rule#2. This creates a hole in the firewall as non-h.323 related audio or video stream would also be permitted by the firewall. Similarly, on the inbound section of the ACL, any UDP, RTP, or TCP related traffic would require permission by the firewall to enable response traffic to an outbound call set up. This in turn leaves an open hole for any audio or video stream, enabling not only various attacks like DoS (Denial of Service), Syn-flooding etc. but also unwarranted inbound UDP or RTP or TCP packets. Hence, Table 1 clearly demonstrates some of the shortcomings of a packet classifier based firewall. Stateful/Flow Classification based Firewall A flow classifier based firewall ACL would comprise of rules that would track protocols and applications. Protocols/applications that get spawned on well-known ports are easily identified. Protocols/applications that get spawned on IIC-China/ESC-China 2002 Conference Proceedings 89

5 dynamically assigned (ephemeral) ports would be tracked by their hierarchical/parent-child relationships. Table 2 illustrates a snapshot of an H.323 protocol based rule set for the same example as in the prior section. Outbound H.323-Q.931 protocol related packets are easy to identify as Q.931 spawns on a well-known port number (1720). Any and every dynamically assigned (ephemeral) port number based protocols that get spawned by Q.931 (e.g. H.323- RTCP and H.323-RTP) would bear a parent-child relationship. Hence, RTP traffic that is not related to Q.931 would not have a parent-child identifier linking it to the parent protocol Q.931. Further, protocol based condition-checking fills the holes that would be otherwise un-filled by a packet classifier. Similarly, for the inbound traffic rules, clear relationships to the outbound traffic will be preserved via tracking of states of the protocol. Hence, no new inbound flows or packets without any relationship (ultimately) with outbound H.323-Q.931 set up will be permitted through the firewall. Again, this level of condition checking fills the holes that would be otherwise not filled by a packet classifier. This implementation is simpler compared to in-line mode implementation of the flow classifier. Also, this implementation relies on a sophisticated policy engine like an NP, and such flow classification implementations are not deemed as high-performance as what an in-line mode implementation would be. Flow Classifier in In-line Mode When stateful classification is required to perform on every packet that arrives into the network, and the performance of classification is significant to the overall system performance, then a flow classifier should be implemented in in-line mode. Figure 5 illustrates an in-line mode of a flow classifier. Hardware implementation examples of a policy system A stateful classification based policy system consists of a policy decision engine, typically a Network Processor (NP) or a custom implementation of a similar function (in an ASIC), policy rules database (SRAM), a command CPU (a general purpose processor), and a flow classification engine (that analyzes the traffic to empower the policy decision engine with reliable intelligence). These individual functions can be assembled in different flow classifier based configurations, two of which are more prominent i.e. Coprocessor mode, or In-line mode. Flow classifier in co-processor model In this configuration, as shown in Figure 4, a flow classifier is not in the fast (data) path. The flow classifier depends on the policy engine (NP or ASIC) to route packets to it. Upon receiving packets from the NP or ASIC, the flow classifier presents the NP or ASIC with appropriate classification results. The NP or ASIC makes the decision based on the policy rules associated with underlying protocol/application, and ultimately performs an action. The NP or ASIC accordingly marks (for QoS, traffic shaping like applications), modifies (security, NAT/PAT like applications), routes (for load balancing, switching like applications), or denies/permits (for firewall like applications) packets. Figure 5. Flow Classifier in In-line mode Packets from the back plane (MAC- Media Access Control interface) would be sent directly to the flow classifier and the NP (or a FIFO, if NP does not have the capacity to buffer packets while packets are classified). The flow classifier performs at line-rate and presents results to the NP to make the policy related decision. Policy rules may be stored in the system memory. NP also interfaces to the back plane for redirecting policy-enforced packets. In-line mode implementations are significantly complex compared to a co-processor mode implementation. A significant advantage of a flow classification based implementation is that a policy engine may not have to hash the policy rule database on all packets if a classifier (through its packet-flow association) can present the policy engine with action handles based on prior packets in the same flow. This capability enhances overall system performance. Conclusion Stateful/flow classification is quickly becoming a necessity for IP service providers to implement intelligent network service platforms comprising of services like QoS, security, firewalls, bandwidth management, monitoring, metering, billing etc. It is becoming more apparent that stateful classification is more complex than stateless classification. Implementing a flow classification solution otherwise (i.e. with a stateless/packet classifier IC and/or combination of other processing ICs and software) has significant drawbacks on power consumption, system costs and form factor fronts. The need for a line rate performance implementation of services translates into an absolute necessity to implement flow classification in a single-chip. Figure 4. Flow Classifier in a Co-processor mode 90 IIC-China/ESC-China 2002 Conference Proceedings

6 About the author Rahul Patel Hifn, Inc. 750 University Avenue, Los Gatos, CA USA Phone: (+1-408) Fax: (+1-408) Rahul Patel, Business Line Manager, is responsible for Hifn s application-classification line of products. Previously, he was the Senior Marketing Manager for Samsung Semiconductor. Prior to Samsung, Mr. Patel was a Strategic Marketing Engineer for Epson Electronics America. Starting as a Senior ASIC-CAD Engineer for Epson, he was awarded numerous Outstanding Achievements awards. Mr. Patel holds a BS in Electronics & Communication Engineering from Regional Engineering College, Warangal, India, a MS in Computer Science from Arizona State University, and a MBA from Santa Clara University. Mr. Patel has written numerous articles in various industry publications and has also spoken at industry conferences in the past. IIC-China/ESC-China 2002 Conference Proceedings 91