Apr
19

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.
About Petr Lapukhov, 4xCCIE/CCDE:

Petr Lapukhov's career in IT begain in 1988 with a focus on computer programming, and progressed into networking with his first exposure to Novell NetWare in 1991. Initially involved with Kazan State University's campus network support and UNIX system administration, he went through the path of becoming a networking consultant, taking part in many network deployment projects. Petr currently has over 12 years of experience working in the Cisco networking field, and is the only person in the world to have obtained four CCIEs in under two years, passing each on his first attempt. Petr is an exceptional case in that he has been working with all of the technologies covered in his four CCIE tracks (R&S, Security, SP, and Voice) on a daily basis for many years. When not actively teaching classes, developing self-paced products, studying for the CCDE Practical & the CCIE Storage Lab Exam, and completing his PhD in Applied Mathematics.

Find all posts by Petr Lapukhov, 4xCCIE/CCDE | Visit Website


You can leave a response, or trackback from your own site.

17 Responses to “Understanding Modular Policy Framework”

 
  1. Mz says:

    Thanks Petr,

    i dont know that the statefull doesn’t match twice for “flow-aware” feature. does it mean if we inspect http than the one that actually inspected was the initiator packet not the responder packet? if we use it on IPS does the return http traffic is not inspected or it inspected using the previous initiator state?

    Mz

    • When you inspect a traffic flow, the inspection engine applies to the whole traffic stream, starting with the initial packet and full subsequent exchange. As for the IPS feature example, for the flow-based traffic, the IPS inspection will be associated with the flow. All returning packets will use the same virtual sensor as the original flow.

  2. Lex says:

    This is awesome. I like to see self contained info. the new step with the vol5 workbooks really sets you apart from the competition with Narbik being the exception. I think every ccie candidate is fortunate of having guys like you, young Brian and Narbik around.

  3. Paul Stewart says:

    This is the best read anywhere on how MPF works. It seems like every where else you read about it, you are left asking “But what about…?” This article addresses everything.

  4. Zeus says:

    Hi Petr,

    Will you include it in your v3.0 Sec Workbook?

    thanks

  5. Robert says:

    “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).”

    Which list above ? I´ve seen a list in a CBT Nugget fpr SNAF:

    1.TCP Processing (but not exactly described if policing or connection settings have a “higher” priority,when would the sequence number randomization take place ?)
    2.CSC
    3.Application Inspection
    4.IPS
    5.QoS input policing
    6.QoS output policing
    7.QoS priority queuing

    OK, lets see if i get the right order:

    we have 2 statements fpr connection limits, but for FTP packets the statement “set connection conn-max 100″ works, because the class FTP is “above” (in menaing ogf lines in the config) the TCP class ?
    So if i clear the policy-map and then make something like:

    policy-map
    class default-inspection-traffic
    inspect ftp
    class TCP
    set connection conn-max 200
    police input 150000
    class FTP
    set connection conn-max 100

    the class FTP will never take action ? A FTP Packet would get policed to 150000 and could make 200 instead of 100 connections ?

    Conclusion:
    If i´ve to check a MPF, i first have that “Featurelist” in mind and THEN check what type of packets (in which order the classes are configured) are matched.

    Plz also name the policy-maps and write out the service-policy statements, they are crucial for examples in the topic “Levels and Directions”

  6. Paul Stewart says:

    Wow. I just stumbled on this. I too believe this is the best information anywhere describing how MPF classifies a flow and applies the features.

  7. Tacack says:

    Great job Petr! :) Paul stewart recommended this to me, and it’s a great read. Thanks for putting up such articles! Looking forward to seeing more from INE!

  8. Adrian says:

    Many thanks for such amazing explanation! You must have a V12 twin-turbo as a brain, do you eat a lot? :)

  9. Moe says:

    This is the best tutorial for cisco MPF in my opinion, even cisco documentation doesn’t include such explanation
    thank you.
    Mohammad Tayseer

  10. Ian says:

    Great post, thank-you.

  11. Mad says:

    Awesome… I’ve never found an explanation like this one!!!
    Very good and usefull article and the most important thing… It’s for human beings XD…
    Thank you man!!!!!!

  12. Aref says:

    Hi Petr,

    What if in the plicy-map test “in the Feature Incompatibilities section”, what if you do this:

    class-map FTP
    match port tcp eq 222
    class-map HTTP
    match port tcp eq 222
    policy-map TEST
    class FTP
    inspect ftp
    class HTTP
    inspect http

    How ASA would deal with it?
    Thanks
    Aref

  13. Aref says:

    Hi guys, in the meanwhile I’m waiting for an answer from Petr, I went looking further on Cisco documentation about http and ftp inspection in the same policy-map.

    I’ve got some confusion, if you go to see the Cisco’s documentation in this link: “http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/asa_84_cli_cfg.pdf” to these pages:
    641 (chapter 32-3)
    642 (chapter 32-4)
    643 (chapter 32-5)

    On page 641 (chapter 32-3) they say:
    2. When the packet matches a class map for a feature type, the ASA does not attempt to match it to any subsequent class maps for that feature type.
    3. If the packet matches a subsequent class map for a different feature type, however, then the ASA also applies the actions for the subsequent class map, if supported. See the “Incompatibility of Certain Feature Actions” section on page 32-5 for more information about unsupported combinations.

    On page 642 (chapter 32-4) they say:
    If a packet matches a class map for HTTP inspection, but also matches another class map that includes FTP inspection, then the second class map actions are not applied because HTTP and FTP inspections cannot be combined.

    Instead on page 643 (chapter 32-5) they say:
    An example of a misconfiguration is if you configure multiple inspections in the same policy map and do not use the default-inspection-traffic shortcut. In Example 32-1, traffic destined to port 21 is mistakenly configured for both FTP and HTTP inspection. In Example 32-2, traffic destined to port 80 is mistakenly configured for both FTP and HTTP inspection. In both cases of misconfiguration examples, only the FTP inspection is applied, because FTP comes before HTTP in the order of inspections applied.

    See example 32-1 and example 32-2 on the same page.

    I’m confused, can any one explain it please?

    Thanks
    Aref

  14. Blanche says:

    I love what you guys are usually up too. This sort of clever work and exposure! Keep up the awesome works guys I’ve added you guys to blogroll.

  15. Micah says:

    Hey! This post could not be written any better! Reading through this post reminds me of my old room mate! He always kept chatting about this. I will forward this article to him. Fairly certain he will have a good read. Thanks for sharing!

 

Leave a Reply

Categories

CCIE Bloggers