Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Unified Policies Support for Flow

Starting in Junos OS Release 18.2R1, unified policies are supported on SRX Series devices, allowing granular control and enforcement of dynamic Layer 7 applications within the security policy. Unified policies are the security policies that enable you to use dynamic applications as match conditions as part of the existing 5-tuple or 6-tuple (5-tuple with user firewall) match conditions to detect application changes over time.

Unified policies allow you to use dynamic application as a policy match criteria in the application. On applying Application Identification (AppID) to the traffic, the AppID checks several packets and identifies the application. After the application is identified, the final policy is applied to the session. The policy actions such as permit, deny, reject, or redirect are applied to the traffic as per the policy.

During the initial policy lookup phase, which occurs prior to a dynamic application being identified, if there are multiple policies n the potential policy list, the SRX Series device applies the default security policy until a more explicit match has occurred. The policy that best matches the application is the final policy.

For more information on unified policies, See [Unified Security Policies, Application Identification Support for Unified Policies, and Understanding IDP Policy Support for Unified Policies.]

Flow First Path for Unified Policies

When the device examines the first packet of a flow, it determines the corresponding security policy, and performs a security policy lookup. During this process following cases are observed:

  • If the traffic matches a legacy security policy or the final policy, the session is created.

  • If there are multiple policies in the potential policy list and there is a security policy conflict, then the default security policy is applied.

  • If there are multiple policies in the potential policy list, and the policy action does not permit the traffic, then the session is closed. A log message is generated to indicate the reason for the session closure. The default security policy is required during policy conflict stage, because each policy in the potential policy list has different configuration values for MSS, TCP SYN check, session timeout interval, and so on. In this case, when the default security policy is applied, all the values configured in that policy are applied. When a default security policy is matched, the policy actions are applied for the session.

    Note:
    • The default security policy is system-defined policy. This policy cannot be deleted.

    • The default policy is created on every logical system level, similar to the global default policy.

    • The session timeout interval and session log values are leveraged from the default security policy and default values such as TCP-MSS and TCP SYN are leveraged from the flow configuration.

  • When a default policy is applied, a potential metadata for the policy action is allocated. The potential metadata is updated according to the potential policy list.

    Note:
    • Having a default security policy helps in resolving in the potential policy list.

    • There can be many sessions matching the default security policy; however, the application services defined in the policy for the permitted traffic can be different. The security flow information for each session is saved.

    • When an SRX Series device is operating in chassis cluster mode, the information is synchronized from the primary node to the secondary node along with the flow session and the chassis cluster real time objects (RTO).

  • When the final application is identified, the security policy matching with the final application is applied. The subsequent packets are processed according to the final policy.

Understanding Flow Fast Path

After the first packet in a flow has traversed the device and a session has been established for it, it undergoes fast path processing. When the device examines a security flow session with default policy, it performs a security policy lookup and following cases are observed:

  • If the existing Application Identification requires an update, the policy lookup process in repeated. The process is repeated until an explicit policy is returned and replaced in the security flow session. If an implicit policy is returned, the traffic is denied and the session is closed.

  • When the final application is identified, the final policy matching the traffic is applied. If the policy actions in the default and the final policy are similar, the final policy replaces the default policy in the security flow session. If the policy actions in the default and the final policy are different, default policy is retained and the security flow session is closed.

    Note:

    When the final and the default policy with a deny action is matched, the security flow session is closed.

  • To update a session, the session timeout, log, or counter configuration in the final policy is used.

Configuring the Session Log for the Default Security Policy

The default security policy is required to manage policy conflicts in the potential policy list. You can set the session logs for the required sessions in default security policy configurations:

You can enable logging at the end of a session and at the beginning of the session with the following commands:

  1. Generate a Session_Create log for policies entering the global pre-id-default-policy.
    CAUTION:

    Configuring session-init logging for the pre-id-default-policy can generate a large amount of logs. Each session that enters the SRX that initially matches the pre-id-default-policy will generate an event. We recommend only using this option for troubleshooting purposes.

  2. Generate a Session_Close log for policies which close without exiting the global pre-id-default-policy.

We recommend enabling session-close logging within the pre-id-default-policy. This will ensures that security logs are generated by the SRX if a flow is unable to leave the pre-id-default-policy. These events are generally a result of Juniper Networks Deep Packet Inspection (JDPI) being unable to classify traffic properly. The events might also indicate potential attempts at evading the application identification (AppID) engine.

Configuring the Session Timeout for the Default Security Policy

You can set the session timeout for the required sessions in default security policy configurations. You can specify the timeout values for UDP, TCP, ICMP, and ICMP6 sessions using the set security policies pre-id-default-policy then session-timeout command:

  • Specify the timeout value in seconds for the TCP session:
  • Specify the timeout value in seconds for the UDP session:
  • Specify the timeout value in seconds for the ICMP session:
  • Specify the timeout value in seconds for the ICMP6 session:
Release History Table
Release
Description
18.2R1
Starting in Junos OS Release 18.2R1, unified policies are supported on SRX Series devices, allowing granular control and enforcement of dynamic Layer 7 applications within the security policy. Unified policies are the security policies that enable you to use dynamic applications as match conditions as part of the existing 5-tuple or 6-tuple (5-tuple with user firewall) match conditions to detect application changes over time.