understanding modular policy framework-packetflow
DESCRIPTION
Understanding Modular Policy Framework-packetflowTRANSCRIPT
11/22/2015 Understanding Modular Policy Framework
http://blog.ine.com/2009/04/19/understandingmodularpolicyframework/ 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 accesslist 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 accesslist2. 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] accesslist
11/22/2015 Understanding Modular Policy Framework
http://blog.ine.com/2009/04/19/understandingmodularpolicyframework/ 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 accesslists are supposed to be preNAT addresses or in other words just as the packet originator seesthem. Secondly, pay attention to the concept of XLATEbased 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 nexthop 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 NATbound 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 classmaps are used to specify thetraffic for a rule. The following is the list of the mot common classification criteria:
AccessList. 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 accesslist, 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/understandingmodularpolicyframework/ 3/13
class‐map TUNNEL_GROUP match tunnel‐group TEST
In addition to specifying the match tunnelgroup criterion, you can also configure oneadditional match statement. You are allowed any additional criterion with except to matchany or match accesslist or match defaultinspectiontraffic. 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
Perflow classification criterion configured using the match flow ip destinationaddress.This one could be used only along with the match tunnelgroup command. Whenconfigured, it tracks every VPN connection separately and applies the configured action perflow, not to all VPN traffic at the same time. This is particularly useful for RemoteAccessVPN connections, where multiple users connection to the firewall unit. Notice that you canapply the QoS policing feature only perflow, 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 tunnelgroup along with some other match commands.
Applying Features in Policy MapsAfter you defined traffic classes, you may configure MPF rules using regular policymap. 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 policymap.
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 preconfigured tcpmap 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 perapplication security policies. The command to apply inspection is inspect {protocolname}.
11/22/2015 Understanding Modular Policy Framework
http://blog.ine.com/2009/04/19/understandingmodularpolicyframework/ 4/13
Could be finetuned using inspection policymaps.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 interfacelevel lowlatency 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 classdefault
There could be a situation when a packet/flow matches multiple classes within the same policymap. 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 classmap within the policymap. 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 policymap 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 policymaps. Here is the table from the Doc CD:
11/22/2015 Understanding Modular Policy Framework
http://blog.ine.com/2009/04/19/understandingmodularpolicyframework/ 5/13
Feature InterfaceLevelDirection
Global PolicyDirection
Inspection Bidirectional IngressCSC Bidirectional IngressIPS Bidirectional IngressQoS Input Policing Ingress IngressQoS Output Policing Egress EgressQoS InterfaceLevel 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 bidirectional behavior, packets entering andleaving the interface will be subject to normalization process, provided that they match therespective classmap. 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 bidirectional, as it does not match the accesslist. To inspect traffic bidirectionally you need the accesslist
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 interfacelevel policy map and global policy map, and theflow matches both classes, the interfacelevel settings take precedence. For example, if theinterfacelevel classmap FTP sets connectionlimit 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 interfacelevel and global policymaps 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 policymapsonly once. For example, if the flow enters the firewall and triggers the inspection feature inthe ingress interfacelevel policymap, 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/understandingmodularpolicyframework/ 6/13
matched against the “flowaware” features ingress on the returning interface. This is thedirect consequence of the firewall stateful behavior. The list of “flowaware” 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 interfacelevel 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
inspectiontraffic 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/understandingmodularpolicyframework/ 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 perinterface.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 policymaps.
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 selfpaced 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/understandingmodularpolicyframework/ 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 “flowaware” 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 flowbased 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/understandingmodularpolicyframework/ 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 classmap within the policymap. 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 connmax 100″ works, because the class FTP is “above” (in menaing ogf lines inthe config) the TCP class ?So if i clear the policymap and then make something like:
policymapclass defaultinspectiontrafficinspect ftpclass TCPset connection connmax 200police input 150000class FTPset connection connmax 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 policymaps and write out the servicepolicy 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/understandingmodularpolicyframework/ 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 twinturbo 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, thankyou.
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 plicymap test “in the Feature Incompatibilities section”, what if you do this:
classmap FTP
11/22/2015 Understanding Modular Policy Framework
http://blog.ine.com/2009/04/19/understandingmodularpolicyframework/ 11/13
match port tcp eq 222classmap HTTPmatch port tcp eq 222policymap 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 policymap.
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 323)642 (chapter 324)643 (chapter 325)
On page 641 (chapter 323) 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 325 for more information aboutunsupported combinations.
On page 642 (chapter 324) 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 325) they say:An example of a misconfiguration is if you configure multiple inspections in the same policymap and do not use the defaultinspectiontraffic shortcut. In Example 321, traffic destinedto port 21 is mistakenly configured for both FTP and HTTP inspection. In Example 322,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 321 and example 322 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/understandingmodularpolicyframework/ 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/understandingmodularpolicyframework/ 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