Overview of Stateful and Stateless Data Processing

Traffic that enters and exits a services gateway running JUNOS software is processed according to features you configure, such as packet filters, security policies, and screens. For example, the software can determine:

• Whether the packet is allowed into the device
• Which firewall screens to apply to the packet
• The route the packet takes to reach its destination
• Which class of service (CoS) to apply to the packet, if any
• Whether to apply Network Address Translation (NAT) to translate the packet’s IP address
• Whether the packet requires an Application Layer Gateway (ALG)

Packets that enter and exit a services gateway undergo both packet-based and flow-based processing.

• Flow-based packet processing treats related packets, or a stream of packets, in the same way. Packet treatment depends on characteristics that were established for the first packet of the packet stream, which is referred to as a flow.

  For the distributed processing architecture of the SRX-series services gateway, all flow-based processing occurs on the SPU.

• Packet-based, or stateless, packet processing treats packets discretely. Each packet is assessed individually for treatment.

  For the distributed processing architecture of the SRX-series services gateway, some packet-based processing, such as traffic shaping, occurs on the NPU. Some packet-based processing, such as application of classifiers to a packet, occurs on the SPU.

Understanding Flow-Based Processing

A packet undergoes flow-based processing after packet-based filters and some screens have been applied to it. All flow-based processing for a single flow occurs on a single SPU. An SPU processes the packets of a flow according to the security features and other services configured for the session.

Figure 6 shows a conceptual view of how flow-based traffic processing occurs on an SPU of an SRX 5600 or SRX 5800 services gateway.

Figure 6: Traffic Flow for Flow-Based Processing

A flow is a stream of related packets that meet the same matching criteria and share the same characteristics. JUNOS software treats packets belonging to the same flow in the same manner.

Configuration settings that determine the fate of a packet—such as the security policy that applies to it, if it requires an Application Layer Gateway (ALG), if Network Address Translation (NAT) is applied to translate the packet’s source and/or destination IP address—are assessed for the first packet of a flow.

To determine if a flow exists for a packet, the NPU attempts to match the packet’s information to that of an existing session based on the following match criteria:

• Source address
• Destination address
• Source port
• Destination port
• Protocol
• Unique session token number for a given zone and virtual router

Zones and Policies

The security policy to be used for the first packet of a flow is cached in a flow table for use with the same flow and closely related flows. Security policies are associated with zones. A zone is a collection of interfaces that define a security boundary. A packet’s incoming zone, as determined by the interface through which it arrived, and its outgoing zone, as determined by the forwarding lookup, together determine which policy is used for packets of the flow.

Flows and Sessions

Flow-based packet processing, which is stateful, requires the creation of sessions. A session is created for the first packet of a flow for the following purposes:

• To store most of the security measures to be applied to the packets of the flow
• To cache information about the state of the flow

  For example, logging and counting information for a flow is cached in its session. (Some stateful firewall screens rely on threshold values that pertain to individual sessions or across all sessions.)

• To allocate required resources for the flow for features such as Network Address Translation (NAT)
• To provide a framework for features such as Application Layer Gateways (ALGs) and firewall features

Most packet processing occurs in the context of a flow, including:

• Management of policies, NAT, zones, and most screens
• Management of ALGs and authentication

Understanding Packet-Based Processing

A packet undergoes packet-based processing when it is removed from the queue from its input interface and before it is added to the queue on its output interface.

Packet-based processing applies stateless firewall filters, class-of-service (CoS) features, and some screens to discrete packets.

• When a packet arrives at an interface on the services gateway, sanity checks, packet-based filters, some CoS features, and some screens are applied to it.
• Before a packet leaves the device, any packet-based filters, some CoS features, and some screens associated with the interface are applied to the packet.

Filters and CoS features are typically associated with one or more interfaces to influence which packets are allowed to transit the system and to apply special actions to packets as necessary.

Here are the kinds of packet-based features that you can configure and apply to transit traffic.

• Stateless firewall filters—Also referred to as access control lists (ACLs), stateless firewall filters control access and limit traffic rates. They statically evaluate the contents of packets transiting the device from a source to a destination, or packets originating from or destined for the Routing Engine. A stateless firewall filter evaluates every packet, including fragmented packets.

  You can apply a stateless firewall filter to an input or output interface, or to both. A filter contains one or more terms, and each term consists of two components—match conditions and actions. By default, a packet that does not match a firewall filter is discarded.

  You can plan and design stateless firewall filters to be used for various purposes—for example, to limit traffic to certain protocols, IP source or destination addresses, or data rates. Stateless firewall filters are executed on the SPU.

• Class-of-service (CoS) features—CoS features allow you to classify and shape traffic. CoS features are executed on the SPU.
  • Behavior aggregate (BA) classifiers—These classifiers operate on packets as they enter the device. Using behavior aggregate classifiers, the device aggregates different types of traffic into a single forwarding class to receive the same forwarding treatment. BA classifiers allow you to set the forwarding class and loss priority of a packet based on the Differentiated Service (DiffServ) value.
  • Traffic shaping—You can shape traffic by assigning service levels with different delay, jitter, and packet loss characteristics to particular applications served by specific traffic flows. Traffic shaping is especially useful for real-time applications, such as voice and video transmission.

• Certain screens—Some screens, such as denial-of-service (DoS) screens, are applied to a packet outside the flow process. They are executed on the NPU.

For details on specific stateless firewall filters and CoS features, see the JUNOS Software Interfaces and Routing Configuration Guide and the JUNOS Software CLI Reference.

Changing Session Characteristics

Sessions are created, based on routing and other classification information, to store information and allocate resources for a flow. Sessions have characteristics, some of which you can change, such as when they are terminated. For example, you might want to ensure that a session table is never entirely full to protect against an attacker’s attempt to flood the table and thereby prevent legitimate users from starting sessions.

Depending on the protocol and service, a session is programmed with a timeout value. For example, the default timeout for TCP is 30 minutes. The default timeout for UDP is 1 minute. When a flow is terminated, it is marked as invalid, and its timeout is reduced to 10 seconds.

If no traffic uses the session before the service timeout, the session is aged out and freed to a common resource pool for reuse. You can affect the life of a session in the following ways:

• You can specify circumstances to terminate sessions by using any of the following methods:
  • Age out sessions based on how full the session table is.
  • Set an explicit timeout for aging out TCP sessions.
  • Configure a TCP session to be invalidated when it receives a TCP RST (reset) message.
• You can configure sessions to accommodate other systems as follows:
  • Disable TCP packet security checks.
  • Change the maximum segment size.

The following sections show you how to modify a session’s characteristics. For details, see the JUNOS Software CLI Reference.

Controlling Session Termination

JUNOS software terminates sessions normally in certain situations—for example, after receiving a TCP FINish Close or receiving a RST (reset) message, when encountering Internet Control Message Protocol (ICMP) errors for UDP, and when no matching traffic is received before the service timeout. When sessions are terminated, their resources are freed up for use for other sessions.

To control when sessions are terminated, you configure the services gateway to age out sessions after a certain period of time, when the number of sessions in the session table reaches a specified percentage, or both.

• To terminate sessions based on a timeout value or the number of sessions in the session table:
  • You can use the following set security flow command to specify the number of seconds in tens of seconds after which a session is invalidated. The following command ages out sessions after 20 seconds:

    set security flow aging early-ageout 2

• To configure an explicit timeout value, use the following command. This set security flow command removes a TCP session from the session table after 280 seconds.

  set security flow tcp-session tcp-initial-timeout 280

• To cause any session that receives a TCP RST message to be invalidated, use the following command:

  set security flow tcp-session rst-invalidate-session

Disabling TCP Packet Security Checks

The JUNOS software provides a mechanism to disable security checks on TCP packets to ensure interoperability with hosts and devices with faulty TCP implementations. The following set security flow command disables TCP SYN checks and TCP sequence checks on all TCP sessions.

Setting the Maximum Segment Size for All TCP Sessions

This command allows you to specify the maximum segment size in TCP SYN packets used during session establishment. Decreasing the maximum segment size helps to limit packet fragmentation and to protect against packet loss that can occur when a packet must be fragmented to meet the MTU size but the packet’s DF-bit (don’t fragment) is set.

• The following command configures the TCP maximum segment size to 1400 bytes for all TCP sessions:

  set security flow tcp-mss all-tcp 1400

Copyright © 2008, Juniper Networks, Inc. All rights reserved. Trademark Notice.