Understanding Modular Policy Framework

Modular Policy Framework (MPF) configuration defines set of rules for applying firewall features, such as traffic inspection, QoS etc. to the traffic transiting the firewall. MPF has many similarities to MQC (Modular QoS CLI) syntax found in Cisco IOS, but there are some major differences in the flow of operations, even though many commands look the same. The following post assumes basic understanding of ASA firewall and its configuration. It covers the basic logic of the MPF, but does go over all firewall features in depth.

Traffic Classification
Every MPF rule has a scope – subset of traffic that the rule applies to – and action – feature or a set of features triggered by this rule. In ASA firewall, L3/L4 class-maps are used to specify the traffic for a rule. The following is the list of the mot common classification criteria:
1) Access-List. Most typical and very flexible criterion, allows matching based source/destination IP addresses, port numbers, protocols and so on – everything you can put in an ACL. Example:
access-list BGP permit tcp host 150.1.1.1 any eq bgp
access-list BGP permit tcp any eq bgp host 150.1.1.1
!
class-map BGP
match access-group BGP
2) Port numbers/range. Without configuring an access-list, you can specify TCP/UDP port numbers to be matched by the class map, such as follows:
class-map PORTS
match port tcp range 100 200
3) Tunnel Group name. Allows matching the traffic for a particular tunnel group in the firewall. The firewall will dynamically track VPN tunnels created for this group and classify traffic accordingly.
class-map TUNNEL_GROUP
match tunnel-group TEST
In addition to specifying the match tunnel-group criterion, you can also configure one additional match statement. You are allowed any additional criterion with except to match any or match access-list or match default-inspection-traffic. For example the following configuration is supposed to matchVoIP traffic within the VPN tunnel, provided that VoIP packets are marked with DSCP value of EF.
class-map VPN_VOICE
match tunnel-group TEST
match dscp ef
4) Per-flow classification criterion configured using the match flow ip destination-address. This one could be used only along with the match tunnel-group command. When configured, it tracks every VPN connection separately and applies the configured action per-flow, not to all VPN traffic at the same time. This is particularly useful for Remote-Access VPN connections, where multiple users connection to the firewall unit. Notice that you can apply the QoS policing feature only per-flow, when classifying based on tunnel group names. Example:
class-map VPN_FLOWS
match tunnel-group TEST
match flow ip destination-address
5) Matching the default classification traffic. This is special “intelligent” type of classification used exclusively with inspect action. It matches traffic on the default port numbers for ALL available inspection engines. For example it will match FTP traffic on port 21, HTTP on port 80, DNS on port 53 and so on. As mentioned, the only supported feature with this classification type is traffic inspection.
6) Other classification criteria such as match dscp and match rtp. Those allow matching based on the DSCP value in IP packet headers and matching based on RTP port range.
As you noticed, a typical class map will only support ONE match command. The only exception is the use of match tunnel-group along with some other match commands.
Applying Features in Policy Maps
After you defined traffic classes, you may configure MPF rules using regular policy-map. We call them regular, as there are special inspection policy maps, used to define inspection settings and parameers. Regular policy maps attach actions to L3/L4 classes using the following syntax:
policy-map <NAME>
class <CLASS1>
<feature1>
class <CLASS2>
<feature2>
…
The list of the applicable firewall features follows:

1. QoS input policing. Applies to traffic entering the firewall, enforces traffic rate. Configured using the command police input| under the policy-map.
2. TCP normalization. TCP and UDP connection limits and timeouts, and TCP sequence number randomization. Performs TCP connection modification and monitoring to enforce security settings. Confiugured using the command set connection and a pre-configured tcp-map with the advanced TCP parameters.
3. CSC (if installed). Content security.
4. Application inspection (multiple types). The core of the stateful firewall. Parses traffic streams and detects application protocols and their commands. Allows enforcing per-application security policies. The command to apply inspection is inspect {protocol-name}. Could be fine-tuned using inspection policy-maps.
5. IPS (if installed). Intrusion prevention – allows the firewall to work as an inline IPS.
6. QoS output policing. Applies to traffic leaving the firewall, enforces specified rate. The command is police output
7. QoS interface priority queue. Services traffic using the interface-level low-latency queue. Configured using the command priority. Could not be applied along with policing feature.
8. QoS traffic shaping, hierarchical priority queue. Mutually exclusive with any other interface-level QoS features. Traffic shaping could be only applied under class-default

There could be a situation when a packet/flow matches multiple classes within the same policy-map. For example, with the following configuration
class-map FTP
match port tcp eq 21
!
access-list TCP permit tcp any any
!
class TCP
match access-list TCP
!
policy-map
class default-inspection-traffic
inspect ftp
class FTP
set connection conn-max 100
class TCP
set connection conn-max 200
police input 150000
FTP packets would match all three classes at the same time. The question is: what action should the firewall apply to this flow? The rule of thumb to resolve conflicts in situations like that is as follows:
a) For a given feature type, the flow can match only one class, based on the order the classes are configure in the policy map. In our example, the TCP connection limits are set for classes “FTP” and “TCP”, both matched by the flow in question. Since “FTP” precedes “TCP” the TCP connection limit is set based on “FTP” class.
b) If the packet flow matches multiple classes with different feature types (e.g. QoS and inspection), then feature actions from all classes are combined provided that they are not conflicting. In our example, FTP flow will be inspected, limited to 100 connections and policed ingress to 150Kbps.
The next question is: if the multiple features are combined together, what is the order they are applied to the flow? It does not depend on the order of the class-map within the policy-map. The actions are applied in sequence, in the same order they are presented in the list above. In our example, the flow is first policed, then normalized and then inspected. Notice that some features may drop packets (such as policing) or modify the traffic contents (e.g. TCP normalization or inspection).
Levels and Directions
Policy map could be applied globally or per interface. There could be only one global policy map and one policy-map applied per interface. The question is: how those maps are combined to build the resulting set of MPF rules? When traffic goes across the firewall, the system determines the ingress and egress interfaces for the flow based on the routing table and xlate entries. The system builds the list of classes matched by the flow based on the feature direction for every class configured under the policy-maps. Here is the table from the Doc CD:

Feature	Interface-Level Direction	Global Policy Direction
Inspection	Bidirectional	Ingress
CSC	Bidirectional	Ingress
IPS	Bidirectional	Ingress
QoS Input Policing	Ingress	Ingress
QoS Output Policing	Egress	Egress
QoS Interface-Level PQ	Egress	Egress
QoS Shaping, Hierarchical PQ	Egress	N/A
TCP Normalization, Connection Limits, ISN randomization	Bidirectional	Ingress

How to read this table? Let’s take the TCP Normalization feature for example. Suppose it is configured at the interface level. Then, based on its bi-directional behavior, packets entering and leaving the interface will be subject to normalization process, provided that they match the respective class-map. Take another example. If you have configured FTP traffic inspection at the interface level like this:
access-list FTP_FROM_INSIDE
permit tcp 10.0.0.0 255.255.255.0 any eq 21
!
class-map FTP_FROM_INSIDE
match access-list FTP
!
policy-map INSPECTION
class FTP_FROM_INSIDE
set connection max-conn 100
inspect ftp
Then both features apply only to FTP traffic going from the inside network 10.0.0.0/24 to the outside on port 21. The traffic to the inside network on port 21 is not inspected nor limited, even though features are bi-directional, as it does not match the access-list. To inspect traffic bi-directionally you need the access-list
access-list FTP_FROM_INSIDE
permit tcp 10.0.0.0 255.255.255.0 any eq 21
permit tcp any 10.0.0.0 255.255.255 eq 21
OK, that looks reasonable enough. Now what should the firewall do if a packet/flow matches multiple classes in level policy maps applied at different levels (i.e. interface and global)? Here is how the conflicts are resolved:
1) If there is a feature defined in the interface-level policy map and global policy map, and the flow matches both classes, the interface-level settings take precedence. For example, if the interface-level class-map FTP sets connection-limit to 100 and the global policy set the limit to 200, the resulting limit for FTP traffic is 100.
2) If the flow matches classes at the interface-level and global policy-maps and the classes have different features configured (e.g. inspect and policing) then actions are combined. The order that the features are applied is per the list provided above.
3) If the flow matches classes both at ingress and egress interfaces, the resulting effect depends on the type of traffic. Traffic classified “statefully”, such as TCP and UDP flows and ICMP, when ICMP inspection is enabled, triggers the same feature in different policy-maps only once. For example, if the flow enters the firewall and triggers the inspection feature in the ingress interface-level policy-map, the firewall will store this event in the state table. No further attempts to perform traffic inspection or normalization are made for this flow, even if it matches the egress interface policy. Moreover, the returning packets for the flow are not matched against the “flow-aware” features ingress on the returning interface. This is the direct consequence of the firewall stateful behavior. The list of “flow-aware” features includes: application inspection, CSC/IPS, TCP normalization and connection limiting.
What if the packet stream is not treated by the firewall as a single flow? For example, imagine a stream of ICMP packets when ICMP inspection is disabled. In this case, bidirectional features on ingress and egress interfaces will apply twice. Moreover, the returning packets will also be subject to feature actions, such as IPS checks. This behavior is also true with any flow unaware feature, such as QoS policing.
Feature Incompatibilities
As you remember, you can apply multiple actions under the same class. Some actions just can’t go together. Here is the list of the limitations:
1) You can’t combine policing and interface-level priority queuing for the same class.
2) You can’t configure shaping in global policy map.
3) You can only shape ALL traffic leaving the interface, i.e. you can only shape under class-default.
4) You cannot configure two inspect actions under the same class with except to default-inspection-traffic class.
What if traffic flow matches multiple classes and those classes define different protocol inspection actions? For example, what if the interface policy has two classes configured like the following:
class-map FTP
match port tcp eq 21
class-map HTTP
match port tcp eq 21
policy-map TEST
class FTP
inspect ftp
class HTTP
inspect http
Then the FTP flow will match both classes. However, one applies FTP inspection and another HTTP inspection. To resolve such conflicts, the firewall uses the list of application priorities (from the DocCD):

1. CTIQBE
2. DNS
3. FTP
4. GTP
5. H323
6. HTTP
7. ICMP
8. ICMP error
9. ILS
10. MGCP
11. NetBIOS
12. PPTP
13. Sun RPC
14. RSH
15. RTSP
16. SIP
17. Skinny
18. SMTP
19. SNMP
20. SQL*Net
21. TFTP
22. XDMCP
23. DCERPC
24. Instant Messaging

Application priority decreases in descending order, with CTIQBE inspection having highest priority. The inspection action with higher priority will be preferred in case of conflict. In the example described above, FTP is more preferred than HTTP, and thus traffic is inspected for FTP protocol.
Summary
As you can see, ASA firewall system implements sophisticated logic for traffic matching and feature application. This is the direct result of combining multiple features for the same set of traffic using the class->action based syntax. Right now the semantic is not very transparent, and it might take time to understand a particular configuration. Here is the list of basic points about MPF:
1) Service policies could be applied globally or per-interface.
2) A packet flow can match multiple classes.
2.1) In case if two ore more classes specify the same feature, firewall applies the deterministic procedure to resolve the conflict.
2.3) In the classes specify different features, they are combined, provided that the features could be used together.
3) Many firewall features are aware of stateful traffic flows.
4) The order that the features are applied is fixed and does not depend on the order of classes in the policy-maps.