Blog

Junos security – Global session parameters

February 23, 2014 12:33 pm

This security related blog post discusses aggressive aging, initial timeout, SYN and sequence checking in TCP connections – few of the session global parameters on SRXs.

The SRX device stores information and details about the ongoing sessions in its session table. The bigger the device the bigger the table. Product datasheets list the exact values (http://www.juniper.net/us/en/products-services/security/srx-series/?c_title=Datasheets#literature). However in none of the boxes is the session table unlimited and when it gets full, no new sessions are allowed. The aggressive sesson aging is used to minimize this impact. The device enters aggressive mode when the defined threshold of the session table utilization is reached. While in this mode the device enforces shorter idle timers as the ones defined in the applications. The sessions are removed sooner from the session table, which in turn frees resources for new ones.

The aggressive session aging configuration [edit security flow aging] takes the following 3 parameters:

  • early-ageout – the inactivity (idle) timeout (in seconds) that will be enforced to all sessions (the device disregards the inactivity timeout from the application) while the device is in aggressive aging mode
  • high-watermark – the point (percentage of the session table size utilization) when the device enters the aggressive mode
  • low-watermark – the point (percentage of the session table size utilization) when the device leaves the aggressive mode

Please see below an example configuration. The device enter the aggressive mode when the session table utilization reaches 95 percent and leaves it when the utilization drops below 80 percent. In aggressive mode the device removes all inactive sessions for more than 25 seconds from the session table.

inetzero-blog-Session-global-parameters-cli-1

The session global parameters are configured under the [edit security flow] hierarchy stanza. They modify or adjust the SRX default parameters and behavior. In this post we will focus on the initial TCP timeout, SYN flag and sequence number checking.

Keep in mind these are global parameters and affect the behavior of the whole device.

The SRX device has a default of 20 seconds timeout to complete the TCP 3-way handshake. During this time the session is sometimes referred as embryonic. Once the 3-way handshake completes the device uses the inactive timeout from the application (unless the device is in aggressive aging mode). The timeout for the 3-way handshake can be modified with the “tcp-initial-timeout” parameter.

The SRX checks the SYN-flag (each TCP session must start with TCP SYN packet) and sequence numbers by default. The “no-syn-check” and “no-sequence-check” parameters disables these checks.

Once globally disabled the SRX allows to enable these checks on a per security policy basis (have a look at the configuration below). Only traffic handled by these policies will be subjected to these checks.

inetzero-blog-Session-global-parameters-cli-2

If the SYN-flag and sequence numbers checks are not disabled globally and you define them in the security policy the commit operation will fail.

inetzero-blog-Session-global-parameters-cli-3

The „show security policies detail“ command is useful for troubleshooting, because it displays whether the policy has the checks enabled or not. Look for the “Per policy TCP Options:” line. In the example below the checks are enabled in the policy TEST and disabled in the policy DENY-log.

inetzero-blog-Session-global-parameters-cli-4

This post presented the aggressive aging and few of the global session parameters (initial TCP timeout, SYN flag and sequence numbers checking).  They are useful in situations where the default SRX behavior is not suitable and needs to be adjusted or changed.

Richard Pracko

Richard Pracko

Richard Pracko lives in Slovakia. Right after finishing his studies at the university with telecommunications as a major, he joined the Siemens Networking department, and focused on the integration of Juniper Networks and Siemens products. In the beginning of 2009, he left Siemens on his own initiative, and became a full time instructor for and technical consultant, over a vast geographic area (EMEA and more).

More Posts

Categorised in:

Leave a Reply

Your email address will not be published. Required fields are marked *