Stateful and Stateless Data Processing

Traffic that enters and exits a Services Router running JUNOS software 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
• The route the packet takes to reach its destination.

Packets that enter and exit a Services Router running JUNOS software undergo both packet-based and flow-based processing.

• Flow-based, or stateful, 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.
• Packet-based, or stateless, packet processing treats packets discretely. Each packet is assessed individually for treatment.

The software implements flow-based security and services, with packet-based application of filters, policers, traffic shapers, and other classification features.

Flow-Based Processing

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

Figure 1 shows an architectural overview of traffic flow in a Services Router running JUNOS software. See Figure 3 to follow the path of the traffic as it traverses through the Flow services module.

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, 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

If the packet matches an existing flow, processing for the packet is assessed in the context of its flow state, which is maintained by the flow's session. If it does not match the session for an existing flow, the packet is used to create a flow state and a session is allocated for it.

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, 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

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 router, 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 router, 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 2 shows architectural overview of traffic flow in a standard JUNOS router.

Figure 2: Traffic Flow for Packet-Based Processing

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.

Here are 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 Software Interfaces and Routing Configuration Guide and the JUNOS Software 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 router 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 (CoS) 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.

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 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 using any of the following methods:
  • Aggressively age out invalid sessions aggressively based on a timeout value.
  • 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.
  • Accommodate end-to-end communication.

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 router 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

  • You can use the following set security flow command to specify a percentage of sessions. When the number of sessions in the session table reaches this percentage, the router begins to age sessions aggressively. When the number of sessions in the session table reaches the low-water mark, the router stops aggressively aging sessions.

    set security flow aging high-watermark 90 low-watermark 50

  • 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 routers with faulty TCP implementations. The following set security flow command disable TCP SYN checks and TCP sequence checks on all TCP sessions.

Accommodating End-to-End TCP Communication

End-to-end TCP communication in a customer network might not work for large packets approaching 1500 bytes because of GRE or IPsec tunneling encapsulation. You can use the set security flow command to change the maximum segment size (MSS) for TCP packets to be sent or received over GRE and IPsec tunnels.

• The following set security flow commands set the TCP MSS to 1400 bytes for IPsec tunnel sessions and 1364 bytes for GRE tunnel sessions:

  set security flow tcp-mss ipsec-vpn mss 1400

  set security flow tcp-mss gre-in mss 1364

  set security flow tcp-mss gre-out mss 1364

  The following command configures the TCP MSS to 1400 bytes for all TCP sessions.

  set security flow tcp-mss all-tcp 1400

• The following command allows an unmatched incoming DNS reply packet:

  set security flow allow-dns-reply

• The following command sets the timeout value for route change to nonexistent route:

  set security flow route-change-timeout

• The following command enables TCP SYN flood protection mode:

  set security flow syn-flood-protection-mode

You can use other set security flow commands to accommodate other systems. For syntax information, see the JUNOS Software CLI Reference.

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