11/22/2015 Understanding Modular Policy Framework

http://blog.ine.com/2009/04/19/understanding­modular­policy­framework/ 1/13

Blog Home | INE Home | Members | Contact Us | Subscribe 

Free Resources

View Archives

All Access Pass

CCIE BloggersApr19

Understanding Modular Policy Framework17 CommentsPosted by Petr Lapukhov, 4xCCIE/CCDE in PIX/ASA Firewall

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 similaritiesto MQC (Modular QoS CLI) syntax found in Cisco IOS, but there are some major differences inthe flow of operations, even though many commands look the same. The following post assumesbasic understanding of ASA firewall and its configuration. It covers the basic logic of the MPF, butdoes 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, forthe purpose of understanding the MPF it is enough to use the following simplified packet flowchecklist:

1.  See if packet matches a flow in the connection table if so, skip to (4). This means packetsmatching 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 theNAT entry.

2.  Perform route lookup on the destination IP address to find egress interface3.  Match input access­list on the ingress interface. Use the ORIGINAL destination IP address,

not the untranslated IP for matching4.  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­list2.  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

11/22/2015 Understanding Modular Policy Framework

http://blog.ine.com/2009/04/19/understanding­modular­policy­framework/ 2/13

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 information8.  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 wasused at step (2). This route should not necessarily be the LONGEST match, just anymatching 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 seesthem. Secondly, pay attention to the concept of XLATE­based routing that ASA uses. Thisconcept requires special attention.What is the point of pinning an egress interface to a NAT entry? The reason being the fact that ifthere exists an XLATE entry, then more likely there are traffic flows using it. Therefore it isdesirable pinning traffic to the same interface that was used for XLATE creation – otherwisetraffic may match different NAT rule and the connection will be broken. This is why the firewallattempts finding the egress interface using the XLATE first. However, what happens if the routehas flapped and the untranslated address is now reachable via a different interface? The firewallwill still perform a route lookup using all routes that are bound to the original interface and tryfinding 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 1route 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 destinationuntranslated to the IP address 180.9.1.1. This IP is statically routed over the DMZ interface, butthe firewall will only check the routes bound to the “outside” interface and use the default route toroute 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 aset of features triggered by this rule. In ASA firewall, L3/L4 class­maps are used to specify thetraffic for a rule. The following is the list of the mot common classification criteria:

Access­List. Most typical and very flexible criterion, allows matching basedsource/destination IP addresses, port numbers, protocols and so on – everything you canput in an ACL. Example:

access‐list BGP permit tcp host 150.1.1.1 any eq bgpaccess‐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 portnumbers 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 trafficaccordingly.

11/22/2015 Understanding Modular Policy Framework

http://blog.ine.com/2009/04/19/understanding­modular­policy­framework/ 3/13

class‐map TUNNEL_GROUP match tunnel‐group TEST

In addition to specifying the match tunnel­group criterion, you can also configure oneadditional match statement. You are allowed any additional criterion with except to matchany or match access­list or match default­inspection­traffic. For example the followingconfiguration is supposed to matchVoIP traffic within the VPN tunnel, provided that VoIPpackets 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. Whenconfigured, 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­AccessVPN connections, where multiple users connection to the firewall unit. Notice that you canapply 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 classificationused exclusively with inspect action. It matches traffic on the default port numbers for ALLavailable inspection engines. For example it will match FTP traffic on port 21, HTTP on port80, DNS on port 53 and so on. As mentioned, the only supported feature with thisclassification type is traffic inspection.Other classification criteria such as match dscp and match rtp. Those allow matchingbased 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 onlyexception is the use of match tunnel­group along with some other match commands.

Applying Features in Policy MapsAfter you defined traffic classes, you may configure MPF rules using regular policy­map. We callthem regular, as there are special inspection policy maps, used to define inspection settings andparameers. 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. Configuredusing the command police input| under the policy­map.

2.  TCP normalization. TCP and UDP connection limits and timeouts, and TCP sequencenumber randomization. Performs TCP connection modification and monitoring to enforcesecurity 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}.

11/22/2015 Understanding Modular Policy Framework

http://blog.ine.com/2009/04/19/understanding­modular­policy­framework/ 4/13

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 output7.  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 shouldthe firewall apply to this flow? The rule of thumb to resolve conflicts in situations like that is asfollows:

1.  For a given feature type, the flow can match only one class, based on the order the classesare configure in the policy map. In our example, the TCP connection limits are set forclasses “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 andinspection), then feature actions from all classes are combined provided that they are notconflicting. In our example, FTP flow will be inspected, limited to 100 connections andpoliced ingress to 150Kbps.

The next question is: if the multiple features are combined together, what is the order they areapplied to the flow? It does not depend on the order of the class­map within the policy­map. Theactions are applied in sequence, in the same order they are presented in the list above. In ourexample, the flow is first policed, then normalized and then inspected. Notice that some featuresmay drop packets (such as policing) or modify the traffic contents (e.g. TCP normalization orinspection).

Levels and Directions

Policy map could be applied globally or per interface. There could be only one global policy mapand one policy­map applied per interface. The question is: how those maps are combined to buildthe resulting set of MPF rules? When traffic goes across the firewall, the system determines theingress and egress interfaces for the flow based on the routing table and xlate entries. Thesystem builds the list of classes matched by the flow based on the feature direction for everyclass configured under the policy­maps. Here is the table from the Doc CD:

11/22/2015 Understanding Modular Policy Framework

http://blog.ine.com/2009/04/19/understanding­modular­policy­framework/ 5/13

Feature Interface­LevelDirection

Global PolicyDirection

Inspection Bidirectional IngressCSC Bidirectional IngressIPS Bidirectional IngressQoS Input Policing Ingress IngressQoS Output Policing Egress EgressQoS Interface­Level PQ Egress EgressQoS Shaping, Hierarchical PQ Egress N/ATCP Normalization, Connection Limits, ISNrandomization Bidirectional Ingress

How to read this table? Let’s take the TCP Normalization feature for example. Suppose it isconfigured at the interface level. Then, based on its bi­directional behavior, packets entering andleaving the interface will be subject to normalization process, provided that they match therespective class­map. Take another example. If you have configured FTP traffic inspection at theinterface 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 theoutside on port 21. The traffic to the inside network on port 21 is not inspected nor limited, eventhough 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 matchesmultiple classes in level policy maps applied at different levels (i.e. interface and global)? Here ishow the conflicts are resolved:

1.  If there is a feature defined in the interface­level policy map and global policy map, and theflow matches both classes, the interface­level settings take precedence. For example, if theinterface­level class­map FTP sets connection­limit to 100 and the global policy set the limitto 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 classeshave different features configured (e.g. inspect and policing) then actions are combined. Theorder 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 effectdepends on the type of traffic. Traffic classified “statefully”, such as TCP and UDP flows andICMP, when ICMP inspection is enabled, triggers the same feature in different policy­mapsonly once. For example, if the flow enters the firewall and triggers the inspection feature inthe ingress interface­level policy­map, the firewall will store this event in the state table. Nofurther attempts to perform traffic inspection or normalization are made for this flow, even if itmatches the egress interface policy. Moreover, the returning packets for the flow are not

11/22/2015 Understanding Modular Policy Framework

http://blog.ine.com/2009/04/19/understanding­modular­policy­framework/ 6/13

matched against the “flow­aware” features ingress on the returning interface. This is thedirect consequence of the firewall stateful behavior. The list of “flow­aware” featuresincludes: 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 astream of ICMP packets when ICMP inspection is disabled. In this case, bidirectional features oningress and egress interfaces will apply twice. Moreover, the returning packets will also besubject to feature actions, such as IPS checks. This behavior is also true with any flow unawarefeature, such as QoS policing.

Feature Incompatibilities

As you remember, you can apply multiple actions under the same class. Some actions just can’tgo 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 inspectionactions? For example, what if the interface policy has two classes configured like the following:

class‐map FTP   match port tcp eq 21class‐map HTTP   match port tcp eq 21policy‐map TEST   class FTP     inspect ftp   class HTTP     inspect http

Then the FTP flow will match both classes. However, one applies FTP inspection and anotherHTTP inspection. To resolve such conflicts, the firewall uses the list of application priorities (fromthe DocCD):

1.  CTIQBE2.  DNS3.  FTP4.  GTP5.  H3236.  HTTP7.  ICMP8.  ICMP error9.  ILS10.  MGCP11.  NetBIOS12.  PPTP13.  Sun RPC14.  RSH15.  RTSP16.  SIP17.  Skinny18.  SMTP

11/22/2015 Understanding Modular Policy Framework

http://blog.ine.com/2009/04/19/understanding­modular­policy­framework/ 7/13

19.  SNMP20.  SQL*Net21.  TFTP22.  XDMCP23.  DCERPC24.  Instant Messaging

Application priority decreases in descending order, with CTIQBE inspection having highestpriority. The inspection action with higher priority will be preferred in case of conflict. In theexample described above, FTP is more preferred than HTTP, and thus traffic is inspected forFTP protocol.

Summary

As you can see, ASA firewall system implements sophisticated logic for traffic matching andfeature application. This is the direct result of combining multiple features for the same set oftraffic using the class­>action based syntax. Right now the semantic is not very transparent, andit might take time to understand a particular configuration. Here is the list of basic points aboutMPF:

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.

Tags: asa, firewall, mpf, overview

Download this page as a PDF

About Petr Lapukhov, 4xCCIE/CCDE:

Petr Lapukhov's career in IT begain in 1988 with a focus on computer programming, andprogressed into networking with his first exposure to Novell NetWare in 1991. Initially involvedwith Kazan State University's campus network support and UNIX system administration, he wentthrough the path of becoming a networking consultant, taking part in many network deploymentprojects. 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 eachon his first attempt. Petr is an exceptional case in that he has been working with all of thetechnologies covered in his four CCIE tracks (R&S, Security, SP, and Voice) on a daily basis formany years. When not actively teaching classes, developing self­paced products, studying for theCCDE 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.

11/22/2015 Understanding Modular Policy Framework

http://blog.ine.com/2009/04/19/understanding­modular­policy­framework/ 8/13

17 Responses to “Understanding Modular Policy Framework”

 

1.   Mz says:April 19, 2009 at 6:20 am

Thanks Petr,

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

Mz

Reply

 Petr Lapukhov, CCIE #16379 says:April 19, 2009 at 8:38 am

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

Reply

2.   Lex says:April 19, 2009 at 7:19 am

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

Reply

3.   Paul Stewart says:April 19, 2009 at 12:11 pm

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

Reply

4.   Zeus says:April 19, 2009 at 6:37 pm

Hi Petr,

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

thanks

Reply

11/22/2015 Understanding Modular Policy Framework

http://blog.ine.com/2009/04/19/understanding­modular­policy­framework/ 9/13

5.   Robert says:April 20, 2009 at 4:38 am

“The next question is: if the multiple features are combined together, what is the order theyare 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 listabove. In our example, the flow is first policed, then normalized and then inspected. Noticethat 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.CSC3.Application Inspection4.IPS5.QoS input policing6.QoS output policing7.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 “setconnection conn­max 100″ works, because the class FTP is “above” (in menaing ogf lines inthe config) the TCP class ?So if i clear the policy­map and then make something like:

policy­mapclass default­inspection­trafficinspect ftpclass TCPset connection conn­max 200police input 150000class FTPset connection conn­max 100

the class FTP will never take action ? A FTP Packet would get policed to 150000 and couldmake 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 ofpackets (in which order the classes are configured) are matched.

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

Reply

6.   Paul Stewart says:May 21, 2009 at 5:27 pm

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

Reply

11/22/2015 Understanding Modular Policy Framework

http://blog.ine.com/2009/04/19/understanding­modular­policy­framework/ 10/13

7.   Tacack says:November 29, 2009 at 7:37 pm

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

Reply

8.   Adrian says:March 5, 2010 at 11:23 am

Many thanks for such amazing explanation! You must have a V12 twin­turbo as a brain, doyou eat a lot? 

Reply

9.   Moe says:May 6, 2010 at 6:17 am

This is the best tutorial for cisco MPF in my opinion, even cisco documentation doesn’tinclude such explanationthank you.Mohammad Tayseer

Reply

10.   Ian says:June 7, 2010 at 3:55 am

Great post, thank­you.

Reply11.  Recurso de INE en "CCIE en castellano" says:

December 8, 2010 at 3:38 pm

[...] Understanding ASA MPF [...]

Reply

12.   Mad says:January 24, 2011 at 12:36 pm

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!!!!!!

Reply

13.   Aref says:May 5, 2013 at 1:26 pm

Hi Petr,

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

class­map FTP

11/22/2015 Understanding Modular Policy Framework

http://blog.ine.com/2009/04/19/understanding­modular­policy­framework/ 11/13

match port tcp eq 222class­map HTTPmatch port tcp eq 222policy­map TESTclass FTPinspect ftpclass HTTPinspect http

How ASA would deal with it?ThanksAref

Reply

14.   Aref says:May 7, 2013 at 7:04 am

Hi guys, in the meanwhile I’m waiting for an answer from Petr, I went looking further onCisco 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 tomatch 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, thenthe 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 aboutunsupported combinations.

On page 642 (chapter 32­4) they say:If a packet matches a class map for HTTP inspection, but also matches another class mapthat includes FTP inspection, then the second class map actions are not applied becauseHTTP 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 policymap and do not use the default­inspection­traffic shortcut. In Example 32­1, traffic destinedto 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 bothcases of misconfiguration examples, only the FTP inspection is applied, because FTPcomes 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?

ThanksAref

Reply

11/22/2015 Understanding Modular Policy Framework

http://blog.ine.com/2009/04/19/understanding­modular­policy­framework/ 12/13

15.   Blanche says:May 16, 2013 at 9:08 pm

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

Reply

16.   Micah says:June 21, 2013 at 4:25 pm

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

Reply

 

Leave a Reply

 Name (required)

 Mail (will not be published) (required)

Submit Comment

Search

Search   Submit

Categories

Select Category

CCIE Bloggers

Brian Dennis, CCIEx5 #2210Routing & SwitchingVoiceSecurityService ProviderISP Dial

Brian McGahan, CCIEx4 #8593, CCDE #2013::13DesignData CenterRouting & Switching

11/22/2015 Understanding Modular Policy Framework

http://blog.ine.com/2009/04/19/understanding­modular­policy­framework/ 13/13

SecurityService Provider

Mark Snow, CCIEx4 #14073Data CenterCollaborationSecurityVoice

Petr Lapukhov, CCIEx4 #16379, CCDE #2010::7DesignRouting & SwitchingSecurityService ProviderVoice

Popular Posts

CCIE Data Center v2.0 Blueprint Announced

twitter.com/ineFollowIcon Icon Icon Icon Icon

© 2011 INE, Inc., All Rights Reserved