III.3 (DPI) Policy Enforcement

III.3 (DPI) Policy Enforcement

III.3.1 Staged Process Model

III.3.1.1 Overview

Figure III.2 – Policy Enforcement Function – Example of a 2-stage Rule Enforcement Process

The rule processing stages may be refined, e.g., by the introduction of hierarchical stages for the evaluation of different set of policy conditions, see Figure III.3. The (technical) motivation for such staged structures is related to goals, e.g., the improvement of rule processing efficiency or maximization of DPI packet processing rates.

Figure III.3 – Policy Enforcement Function – Hierarchical Evaluation Stages for Policy Conditions

NOTE 3 –Generic example to Figure III.3: the first set of policy conditions (related to rule set R_I from DPI-PIB_I) may represent just a few, L_3,4HI only related conditions with the goal in a coarse granular classification of packet flows. The next stage (related to rule set R_II) is optional, dependent of further, more detailed classification objectives. And so on. The final stage may contain just the most complex DPI rules, e.g., a condition for a specific application-level security threat.
Such a hierarchical structure allows to reduce the number of policy rules (and thus also conditions) to be performed down to the absolute minimum per packet.

III.3.1.2 Motivation and some examples

Some examples (by referring to the generic model by Figure III.3):

Example 1 - DPI for TCP-based IP applications:

Stage 1-I may focus on the separation in TCP and non-TCP traffic, and Stage 1-II may then just enforce the TCP-specific rule. Such an approach would address the two performance objective in a) minimizing the transfer delay for non-TCP packets (because the resources for TCP-specific rules are save) and b) the maximization of the overall packet rate for TCP and non-TCP traffic;

Example 2 - DPI for SIP traffic:

Stage 1-I may focus on SPI-dedicated policy rules like the policing for “flooding attacks”, any violating SIP message would be then just forwarded to (and discarded by) Stage 2, and Stage 1-II may continue with SIP DPI rules on SIP header elements, and Stage 1-III could provide an inspection of the SIP message body. Again, it’s an hierarchical approach, driven by performance optimization.

Example 3 - DPI for QoS support:

Stage 1-I may provide a packet classification on a coarse granularity, - like specific QoS support on aggregate level, and Stage 1-II may continue with the classification on fine granularity level, e.g., identifying ‘flows’ (within an aggregate) on a very low level. The hierarchical approach is here also reflecting packet actions on aggregate and flow level.

Example 4 - DPI for measurement support:

A DPI entity may be used in the context of the generation of local measurements (see flow metering process in clause 6). Thus, such a “DPI-correlated statistic” is tight to a Flow Descriptor. E.g., a correspondent DPI policy rule “measure the traffic volume for RTP packets with video codec type ‘H.264’ and H.264 profile ‘x’” relates to policy conditions up to L7 and the action in “updating statistic xyz”. It would be questionable in locating such a rule already in Stage 1-I due to possible inefficient processing because of other possible “flow packets” like RTP audio packets, RTCP, or non-RTP traffic etc.

Example 5 - DPI for general IP security:

Stage 1-I may focus on’ legacy’ policy rules, related to well-known security attacks and subsequent Stages may address more complex policy rules, just related to a specific traffic portion (which was identified by the previous Stage).

Example 6 - DPI for MPLS traffic:

A similar hierarchical rule partitioning as in previous examples, always dependent on the concrete applied DPI policy rules, may allow processing performance improvements.

A similar hierarchical rule partitioning as in previous examples, always dependent on the concrete applied DPI policy rules, may allow processing performance improvements.

Staged DPI processing models are thus justified in many scenarios.

III.3.2 Processing Stage 1: Packet Classification

III.3.3 Processing Stage 2: Action Execution

Action(s) are executed if identified by the set of policy conditions. There are three basic behaviour cases from packet path perspective:

• packet unmodified forwarded;

• packet modified forwarded (e.g., by “QoS tagging” packet header elements, by translated network address information); or

• packet not forwarded (e.g., by discard).

The overall (DPI) PEF provides consequently a filtering behaviour for traffic flows (out of an overall traffic aggregate) and for individual packets (out of a specific flow). Such policy rules are thus also termed as filter rules. The terms policy rule and filter rule are synonym in this Recommendation.

Directory: wp-content -> uploads -> 2012
2012 -> The Case Against the nypd’s Quota-Driven ‘Broken Windows’ Policing What Is It?
2012 -> Aa and na members Dying from Tobacco
2012 -> [Baby Crying] 01: 04 [Ching
2012 -> Unit Name / Nom de l’unité uic / ciu dates
2012 -> What We Owe Jehovah’s Witnesses
2012 -> Oceans Challenge Badge
2012 -> Canadian cycling olympians
2012 -> Greg landry, june olkowski and tom lysiak
2012 -> William goldman
2012 -> Does translocation and restocking confer any benefit to the European eel population? A review

Download 1.36 Mb.

Share with your friends: