Traffic that enters and exits an SRX Series 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:
Packets that enter and exit an SRX Series device undergo both packet-based and flow-based processing.
For the distributed processing architecture of the SRX Series Services Gateway, all flow-based processing occurs on the SPU and sampling is multi-thread aware. Packet sequencing is maintained for the sampled packets.
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.
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 1 shows a conceptual view of how flow-based traffic processing occurs on an SRX Series Services Gateway.
Figure 1: 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:
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.
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:
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.)
Most packet processing occurs in the context of a flow, including:
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.
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.
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.
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.
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:
The following sections show you how to modify a session’s characteristics. For details, see the JUNOS Software CLI Reference.
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 SRX Series device 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.
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.
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.