Dubai, 20 November 29 November 2012
II.5 Example policy rules for mixed (“stateful”) Application-dependent, Flow-independent/Flow-dependent DPI
Download 1.36 Mb.
|
- Navigate this page:
- II.6 Examples of multiple, different DPI policy rules for the same DPI application
- II.7 Further examples
- III.1 Introduction
- III.2.1 Concept
- III.2.2 (DPI) Policy condition
- III.2.3 Hierarchical (DPI) policy conditions or/and (DPI) policy rules
II.5 Example policy rules for mixed (“stateful”) Application-dependent, Flow-independent/Flow-dependent DPIII.5.1 Example “Detecting a specific Peer-to-Peer VoIP telephony with proprietary end-to-end application control protocols”Example for a bidirectional, stateful DPI policy rule. Note: the rule itself illustrates just the principal proceeding, but is not necessarily sufficient for a real deployment. Table II.5.1 – Example
II.6 Examples of multiple, different DPI policy rules for the same DPI applicationII.6.1 Example “Detection of Remote Telnet”The DPI policy rule may request to inspect for the (IP) application Remote Telnet. There are then two options: 1) the application identification may be solely based on a rule with just the flow level conditions if a well-known port is used (see Table II.6.1); or 2) another rule: an additional application level conditions would be required if application may not be derived from flow level condition (see Table II.6.2). Table II.6.1 – Example
Table II.6.2 – Example
This example illustrates application identification with and without “application payload” inspection”. II.7 Further examplesII.7.1 Example for application detection without independent of flow descriptor usage or notThe purpose could be the detection of application “image objects encoded in JPEG File Interchange Format (JFIF)” (NOTE 1). This DPI application could be detected by monitoring traffic with or without a particular rule for flow identification because just an application-level condition would be sufficient.. NOTE 1 – Such a data object is typically carried within the payload of an application layer protocol. The DPI policy rule could contain the condition for searching the so-called JFIF-Tag equal to “FF E0 00 10 4A 46 49 46 00 01”. Appendix III
(This appendix does not form an integral part of this Recommendation) III.1 IntroductionThis appendix provides complementary information concerning the used concepts, terminology and example functional models in this Recommendation. This appendix is orthogonal to the requirements, as specified in the main body of this Recommendation. III.2 (DPI) Policy ruleIII.2.1 ConceptIt may be noted that the used concept of a policy rule (see clause 3) is generic and thus applicable for DPI-specific policy rules, but also non-DPI related policing like for medium depth packet inspection (MPI) or shallow-depth packet inspection (SPI). Figure III.1 summarizes the used policy rule concept by this Recommendation. There are one or multiple (DPI) policy rules RDPI in place, called DPI policy rule set RDPI. The rules are stored in the DPI-PIB, which determines consequently the behaviour of the DPI-FE. Any individual rule RDPI,i may contain one or multiple policy conditions Ck and one or multiple policy actions Am. It may be noted that every DPI policy requirement (as specified by this Recommendation) may be satisfied by this policy rule concept. III.2.2 (DPI) Policy conditionThe policy condition represents a logical function (which may lead typically to a compare operation or search operation on elements of the evaluated packet). Such a logical function may contain itself one or multiple literals (also known as simple versus compound policy conditions). Compound policy conditions are typically specified as Boolean normal form (like disjunctive normal form (DNF) or conjunctive normal form (CNF)), which may imply a correspondent conversion between the high level policy management and decision process towards the execution in the packet path by the DPI-FE (e.g., a compound policy condition in format “(C1 C2) C3 ) “ must be converted). NOTE 1 –The applied structure (simple vs. compound) of policy conditions, and whether a policy rule provides only a single condition or multiple conditions per rule, is not relevant for this Recommendation. Because each specification structure for policy conditions (and rules) may be converted to each other. They are adequate from functional perspective. 
Figure III.1 – Policy Enforcement Process – Example Structure of a (DPI) Policy Rule It may be reminded again that the specification of explicit bindings between actions and conditions, and also the specification of entire DPI policy rules as such is out of scope of this Recommendation (see clause 1.1).
The example model with two functional stages of “packet scanning” and subsequent “packet analysing” represent a hierarchical concept in terms of distributed processing of policy conditions. 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:
| ||||||||||||||||||||||||