It is much more sophisticated than what I was thinking.
Thanks for the great article from Petr.
http://blog.ine.com/2009/04/19/understanding-modular-policy-framework/
Action are applied in the following sequence within MPF.
- QoS input policing. Applies to traffic entering the firewall, enforces traffic rate. Configured using the command police input| under the policy-map.
- TCP normalization. TCP and UDP connection limits and timeouts, and TCP sequence number randomization. Performs TCP connection modification and monitoring to enforce security settings. Confiugured using the command set connection and a pre-configured tcp-map with the advanced TCP parameters.
- CSC (if installed). Content security.
- 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.
- IPS (if installed). Intrusion prevention – allows the firewall to work as an inline IPS.
- QoS output policing. Applies to traffic leaving the firewall, enforces specified rate. The command is police output
- 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.
- QoS traffic shaping, hierarchical priority queue. Mutually exclusive with any other interface-level QoS features. Traffic shaping could be only applied under class-default
Feature | Interface-Level Direction | Global Policy Direction | Flow-aware feature |
QoS Input Policing | Ingress | Ingress | |
TCP Normalization, Connection Limits, ISN randomization | Bidirectional | Ingress | Yes |
CSC | Bidirectional | Ingress | Yes |
Application Inspection | Bidirectional | Ingress | Yes |
IPS | Bidirectional | Ingress | Yes |
QoS Output Policing | Egress | Egress | |
QoS Interface-Level PQ | Egress | Egress | |
QoS Shaping, Hierarchical PQ | Egress | N/A |
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.
Application priorities:
- CTIQBE
- DNS
- FTP
- GTP
- H323
- HTTP
- ICMP
- ICMP error
- ILS
- MGCP
- NetBIOS
- PPTP
- Sun RPC
- RSH
- RTSP
- SIP
- Skinny
- SMTP
- SNMP
- SQL*Net
- TFTP
- XDMCP
- DCERPC
- Instant Messaging
Here is the list of basic points about MPF:
1) Service policies could be applied globally or per-interface.
2) A packet flow can match multiple classes.
2.1) In case if two ore more classes specify the same feature, firewall applies the deterministic procedure to resolve the conflict.
2.3) In the classes specify different features, they are combined, provided that the features could be used together.
3) Many firewall features are aware of stateful traffic flows.
4) The order that the features are applied is fixed and does not depend on the order of classes in the policy-maps.