The below documentation serves to explain the behavior of Security Policy Rules in the context of Application match by defining a few common cases

For the sake of clarity the below references, in this documentation, are defined as below

Tuples = Source address, Source port, Destination address and Destination port. Any reference to “Tuples” match refers to a match against src address/port and/or destination address/port

Services = When match criteria is defined for Services (under the Service option available under rules, example Service defined as Destination-port 441)

Case 1: Rule defines match criteria for Zone and/or Source/Destination Tuples and/or Services, rule has an “Application” match (such as Youtube, Outlook etc), Action is set as “Deny”

Sub-case 1: If traffic matches this rule based on Zone/Tuple/Services match

·         If a traffic flow matches this rule, based on source-address/source-port/source-zone/services or destination-address/destination-port/destination-zone, and there is also an “Application” match, then irrespective of the action set (whether allow or deny), the packets of this traffic flow will be “allowed” until the Application is identified

·         Usually Application is identified during the start of L7 contents (for ex, https sni field, client-hello, server-hello etc). Until the application is identified, the state for this session would be “Evaluation in progress” and it would be stalled at this rule until the Application is identified

·         Post the application identification, if the application matches the one defined in this rule, it would be subject to the defined action (flow will be denied if the action is set to Deny).

·         Post the application identification if the application does not match the one defined in this rule, it will be punted to the next rule and so forth, until a match occurs – if there is no match it will be finally be dropped via “Implicit deny” (it’s the defacto action if there is no match)

Sub-case 2: If traffic does not match this rule based on Zone/Tuple/Services match

·         If a traffic flow “does not” match this rule based on source-address/source-port/source-zone/services or destination-address/destination-port/destination-zone, then it will be punted to the next rule (it will not enter into “Evaluation in progress”), until it find a rule which matches the Zone/Tuples/Service

·         If the traffic does not match any of the rules based on Zone/Tuple/Services, it would be subject to implicit deny from the first packet on

Case 2: Rule does not define any match criteria for Zone or Source/Destination Tuples or Services, it just defines a match criteria for an Application (say Youtube, Outlook etc)

If the traffic hits such a rules, it will enter into “Evaluation in progress” state, and packets for this flow will be allowed until application is identified – post which it will be subject to the action of this rule (if the application matches) or it will be punted to the next rule (if the application doesn’t match)

Case 3: Rule defines match criteria for Zone/Tuples/Services but there is no Application match criteria defined in the rule

If the traffic matches such a rule, based on Zone/Tuple/Service matching the flow, it will be evaluated on the “first packet” match against Zone/Tuples/Services, and would be subject to the specified action (if the action is set to “Deny”, traffic will be denied from the first packet on)

Case 4: Rules defines a Service match criteria and Application match criteria (for ex match Service Dst-port 441 and match Application Youtube)

If the traffic matches the “Service” defined, then it will enter into “Evaluation in progress” state as there is also an Application match defined, during this state the packets will be allowed irrespective of the action defined in the rule, the flow will be stalled at this rule until the application is identified. Once the application is identified it will be subject to the action of the rule if the application matches or it would be punted to the rule

Note 1: The above explanation holds true for a scenario where the action, in a security policy rule, is set to "Apply Security Profile" which invokes an URL-filter profile. Similar to the application identification, even in the case of URL filtering, we would need pass the packets to identify the url (present int the sni field of the https/http request) post which the urlf module will determine the category of the url (through spack or cloud lookup)

Note 2: The above behavior remains the same while matching the url category/reputation instead of "application" in the security rule

Summary: A flow first needs to match a  rule based on Zone/Tuples/Service definition, post that if there is an Application match defined it would enter into “Evaluation in progress” until application is identified and is subject to the defined action if the Application ends up matching.  If there is no Application match defined in the rule then it’s subject to the defined action immediately

Side note: This behavior is similar in other security vendors, a few packets would be passed until the application/url is identified, post the identification the configured action will be imposed