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 not go over all firewall features in depth.

Traffic Flow through the Firewall

ASA is a complicated piece of hardware and software, just like any stateful firewall. However, for the purpose of understanding the MPF it is enough to use the following simplified packet flow checklist:

1. See if packet matches a flow in the connection table if so, skip to (4). This means packets matching existing states bypass the ACL checks
2. Find egress interface, drop packet if egress interface cannot be found. Two options:
   1. Packet’s destination address matches existing XLATE state or STATIC NAT statement. This is common when you use outside NAT. Egress interface is determined from the NAT entry.
   2. Perform route lookup on the destination IP address to find egress interface
3. Match input access-list on the ingress interface. Use the ORIGINAL destination IP address, not the untranslated IP for matching
4. Match flow against input QoS policy (interface or global policy, where interface policy takes precedence)
5. Apply source NAT if XLATE state does not exist and there is matching NAT rule. Use the following order of operations:
   1. NAT exemption, configuration using the command nat (interface) 0 access-list
   2. First matching STATIC NAT or PAT, with NAT taking precedence. If multiple entries match the packet, select the first one.
   3. Dynamic NAT entries configured using the command nat (interface) [ID] access-list
   4. Dynamic NAT entries configured using the command nat (interface) [ID] [network] [mask]. If [ID]=0 then identity XLATEs are created
6. Apply egress QoS policy (output policing, interface or global)
7. Create or update flow information
8. Lookup output egress interface in routing table based on destination IP. Find out the next-hop, which should be on the SAME interface as XLATE points to, if XLATE/STATIC was used at step (2). This route should not necessarily be the LONGEST match, just any matching route out of selected interface.

It is important to notice two important things: firstly, the addresses you should use in the access-lists are supposed to be pre-NAT addresses or in other words just as the packet originator sees them. Secondly, pay attention to the concept of XLATE-based routing that ASA uses. This concept requires special attention.
What is the point of pinning an egress interface to a NAT entry? The reason being the fact that if there exists an XLATE entry, then more likely there are traffic flows using it. Therefore it is desirable pinning traffic to the same interface that was used for XLATE creation – otherwise traffic may match different NAT rule and the connection will be broken. This is why the firewall attempts finding the egress interface using the XLATE first. However, what happens if the route has flapped and the untranslated address is now reachable via a different interface? The firewall will still perform a route lookup using all routes that are bound to the original interface and try finding a match. If a match is found, it is used to find out the next-hop and route packet out. If not, the packet is dropped. Look at the following configuration sample:

static (outside,inside) 180.9.59.1 180.9.1.1

!

route outside 0.0.0.0 0.0.0.0 180.9.29.2 1

route DMZ 180.9.1.1 255.255.255.255 192.10.9.254

Here packets going from “inside” to “outside” toward the IP address 180.9.59.1 are destination untranslated to the IP address 180.9.1.1. This IP is statically routed over the DMZ interface, but the firewall will only check the routes bound to the “outside” interface and use the default route to route the packet to 180.9.1.1. In this situation, even though the specific static route is not correct, the NAT-bound egress interface decision allows traffic to flow correctly.

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:

• 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
  

• 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
  

• 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
  

• 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
  

• 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.
• 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. Configured 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:

1. 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.
2. 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.
3. In case if two ore more classes specify the same feature, firewall applies the deterministic procedure to resolve the conflict.
4. In the classes specify different features, they are combined, provided that the features could be used together.
5. Many firewall features are aware of stateful traffic flows.
6. The order that the features are applied is fixed and does not depend on the order of classes in the policy-maps.