Understanding Stateful and Stateless Data Processing for J Series Services Routers

Junos OS for J Series Services Routers integrates the world-class network security and routing capabilities of Juniper Networks Operating System.

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

Whether the packet is allowed into the router
Which class of service (CoS) to apply to the packet, if any
Which firewall screens to apply to the packet
Whether to send the packet through an IPsec tunnel
Whether the packet requires an Application Layer Gateway (ALG)
Whether to apply Network Address Translation (NAT) to translate the packet's address
Which route the packet uses to reach its destination

Packets that enter and exit a services router running Junos OS undergo both packet-based and flow-based processing. A device always processes packets discretely. Packet treatment depends on characteristics that were established for the first packet of the packet stream.

Branch devices implement both packet-based and flow-based modes, concurrently. Flow-based and packet-based processing are described in the following sections:

Understanding Flow-Based Processing

A packet undergoes flow-based processing after any packet-based filters and policers have been applied to it.

Figure 6 shows an architectural overview of traffic flow in a Juniper Networks device running Junos OS. See Figure 8 to follow the path of the traffic as it traverses through the flow services module.

Figure 6: Traffic Flow for Flow-Based Processing

Image g030006.gif

A flow is defined as a set of packets coming from the same source/destination addresses, source/destination ports (when applicable), protocol, and ingress/egress zones. Flows are time bound so it is possible to have packets that, while fitting the previous definition, belong to different flows. For example, when an existing session is initiated and terminated, after which a new session is established using the exact same parameters as the previous session, the packets would belong to different flows.

Configuration settings that determine the fate of a packet—such as the security policy that applies to it, whether the packet is sent through an IPsec tunnel, if it requires an Application Layer Gateway (ALG), if Network Address Translation (NAT) is applied to translate the packet's address—are assessed for the first packet of a flow. The settings are then applied to the rest of the packets in the flow.

To determine if a packet belongs to an existing flow, the router attempts to match the packet's information to that of an existing flow based on the following six match criteria:

Source address
Destination address
Source port
Destination port
Protocol
Session token—An internal parameter not extracted from the packet's header

If the packet matches an existing flow, processing for the packet is determined by the flow state (maintained by the flow's session). If the packet does not match the session for an existing flow, the packet’s information is used to create a new flow state and a session is allocated for it (a session is allocated only if this is permitted by the security policy). Sessions used for the first packet of a flow is cached in a flow table for use with the same flow and closely related flows.

Note: A new session is allocated for the new flow state only if this is permitted by the security policy. For TCP, only SYN packets will trigger creating a new session (unless SYN checking is not enabled).

Zones and Policies

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, based on the characteristics assessed for the first packet of a flow, for the following purposes:

To store 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) and IPsec tunnels
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. The flow engine and session bring together the following features and events that affect a packet as it undergoes flow-based processing:

Flow-based forwarding
Session management, including session aging and changes in routes, policy, and interfaces
Management of virtual private networks (VPNs), ALGs, and authentication
Management of policies, NAT, zones, and screens

Policies can be configured to log session permit, close, and deny events.

Understanding Packet-Based Processing

A packet undergoes packet-based processing when it is dequeued from its input (ingress) interface and before it is enqueued on its output (egress) interface.

Packet-based processing applies stateless firewall filters and class-of-service (CoS) features to discrete packets. You can apply a firewall filter to an ingress or egress interface, or to both.

When a packet arrives at an interface on the device, any packet-based filters and policers associated with the interface are applied to the packet before any security policies are evaluated.
Before a packet leaves the device, any packet-based filters and traffic shapers associated with the output interface are applied to the packet after any security policies have been evaluated.

Figure 7 shows an architectural overview of traffic flow in a Juniper Networks device running Junos OS.

Figure 7: Traffic Flow for Packet-Based Processing

Image g030004.gif

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.

Note: Packet-based processing occurs only if you configure filters, CoS, IPv6, and MPLS features for an interface that handles the packet.

The following sections describe the kinds of packet-based features that you can configure and apply to transit traffic. For details on specific stateless firewall filters and CoS features, see the Junos OS Routing Protocols and Policies Configuration Guide for Security Devices, the Junos OS Class of Service Configuration Guide for Security Devices, and the Junos OS CLI Reference.

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 terms 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.

Class-of-Service Features

CoS features allow you to police and shape traffic.

Policing traffic—Policers allow you to limit traffic of a certain class to a specified bandwidth and burst size. Packets exceeding the policer limits can be discarded or assigned to a different forwarding class, a different loss priority, or both. You can use policers to limit the amount of traffic passing into or out of an interface.
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.