Dubai, 20 November 29 November 2012
Management of DPI signature library
Download 1.36 Mb.
|
- Navigate this page:
- 6.2.2.3 The rule format exchanged through external interface
- 6.2.4 Initiation of management actions
- 6.3 Traffic inspection aspects
- 6.3.2 Protocol-stack aware and protocol-stack agnostic DPI aspects
- 6.3.3 DPI policy rule actions aspects
6.2.2 Management of DPI signature libraryThis clause defines requirements for management of DPI signatures library. 6.2.2.1 Adding new signaturesR-6.2.2.1/1: It is required to be able to add new DPI signatures to the DPI signature library. 6.2.2.2 Operations on existing signaturesR-6.2.2.2/1: It is required to be able to modify (update) existing signatures in the DPI signature library. R-6.2.2.2/2: It is required to be able to enable and disable specific DPI signatures in the DPI signature library. R-6.2.2.2/3: It is required to be able to delete (remove) specific DPI signatures in the DPI signature library. 6.2.2.3 The rule format exchanged through external interfaceR-6.2.2.3/1: The DPI signature for application identification exchanged through external interfaces (i.e., e1 and e2 in Figure 8-1) can optionally follow any rule format (see also clause 1.2). 6.2.3 Location of management functionR-6.2.3/1: The DPI signature management actions specified in clause 6.2.2 are required to be performed locally from the DPI functional entity or remotely or both (see Figure 6-1). 6.2.4 Initiation of management actionsR-6.2.4/1: It is required to support the push mode regarding DPI signature operations, when the operations are remotely initiated (e.g., by the DPI-PDFE in Figure 6-1). R-6.2.4/2: It is required to support the pull mode regarding the DPI signature operations, when the operations are locally initiated by the DPI-FE. The notion of pull means that the DPI-FE local management function requests the DPI-PDFE to perform a management action on a new or existing signature. How a DPI-FE could initiate a request is out of scope of this Recommendation. 6.3 Traffic inspection aspectsThis clause addresses the aspects concerning the types of traffic subject to DPI. 6.3.1 Flow identification aspectsR-6.3.1/1: The DPI Functional Entity is recommended to support the identification of applications, without flow level inspection (see also Figure VII-7). R-6.3.1/2: Any DPI scenario can optionally be initially flow-independent, i.e. the provided DPI policy rule to the DPI-FE would not contain a flow descriptor. However, the rule could request to collect interested flow information. R-6.3.1/3: Such a request is required to provide an IPFIX flow key plus the optional completion of lacking flow information. R-6.3.1/4: DPI functional entity can optionally require a complete recognition of IPFIX flow identifier based on a given IPFIX flow key and the inspection of multiple subsequent packets. R-6.3.1/5: The reporting action of a complete or incomplete IPFIX flow identifier by the DPI-FE to a remote network entity can optionally be conditional (e.g., event-driven, timer-controlled, etc.). 6.3.2 Protocol-stack aware and protocol-stack agnostic DPI aspectsThe DPI identification function (within a DPI-FE) is responsible for application identification and concerns the compare and search operations, based on the DPI signature, against an incoming packet (PDU). There are two options: the DPI-FE is either aware of the internal PDU structure (i.e., “protocol stack aware DPI-FE”) or unaware of the structure (“protocol stack agnostic DPI-FE”). Both options may provide the same identification result and be functionally equivalent. The main difference is that the protocol stack aware identification logic may be more efficient. It is useful to distinguish the following two types of analysis regarding operational efficiency (i.e., application identification and optional flow identification): a) Predetermined Payload area Analysis (PPA): When packets (flow) correspond to a known application with a clearly defined payload structure, the DPI-FE may inspect the fixed predetermined location of the payload (i.e., the protocol-stack aware packet inspection mode). b) Full Payload area Analysis (FPA): When packets (flow) do not correspond to a known application or the structure of the application payload is not clearly defined or known, the DPI-FE inspects the “entire payload area” (i.e., the protocol-stack agnostic packet inspection mode). Both PPA and FPA can be applied to the same traffic flow. R-6.3.2/1: The DPI-FE is recommended to support protocol stack aware application identification. R-6.3.2/2: The DPI-FE is recommended to support protocol stack agnostic application identification. R-6.3.2/3: The DPI-FE is required to identify applications on top of IPv4 and IPv6 protocol stack and can optionally on top of other underlying protocol stack. R-6.3.2/4: The DPI-FE is recommended to identify applications in nested traffic, such as encapsulated or tunnelled traffic. 6.3.3 DPI policy rule actions aspects6.3.3.1 BackgroundDPI policy actions may be performed on different hierarchical levels, e.g., DPI-FE, local and remote PDFs, and may include for instance the following: 1) Packet path level actions (by the DPI-FE): a) Accept the packet and forward it to the packet forwarding function(PFF)(a conditional action for In-Path DPI mode only); b) Discard the packet (silently or otherwise); c) Redirect the packet to other output interfaces; d) Replicate/mirror the packet to other output interfaces; e) Traffic classification, local measurements, and reporting of measurement data; f) Prioritization, blocking, shaping and scheduling methods of individual packets. 2) Node level actions (by involvement of the local policy decision function (L-PDF)): a) Dynamic building of new DPI policy rules and/or modification of existing rules (stored in the DPI policy information base (DPI-PIB)); b) Generation of logging/tracing data and reporting to policy management (see clause 2.11.2 in [b-IETF RFC 3871]); c) Detecting and reporting of unidentifiable applications d) Notification of intrusion detection systems (e.g., by reporting traffic samples, suspicious packets); 3) Network level actions (via the remote policy decision function (R-PDF)): a) Resource management, admission control and high-level filtering (at the level of network subsystems (such as specified in ITU-T RACF [ITU-T Y.2111], ETSI TISPAN RACS [b-ETSI ES 282 003] and 3GPP PCC [b-ETSI TS 123 203]); b) Content charging based on subscribers’ application types (e.g., IETF RADIUS or Diameter). Figure 6.2 further explains the above structuring principle through a detailed generic policy rule format (versus the one introduced in clause 1.2): 
Figure 6-2 – An example of detailed Policy Rule format (in comparison to Figure 1-2/clause 1.2)) The mapping of specific actions to conditions is out of scope of this Recommendation. 6.3.3.2 RequirementsR-6.3.3.2/1: Once an application has been identified by the DPI-FE, it can optionally be possible to extract application specific information. For example, a URL in HTTP, a media format (“codec type”) in real-time transport protocol (RTP), or a RTP session identifier (e.g., SSRC for the RTP source endpoint). R-6.3.3.2/2: The DPI-FE can optionally be able to work in conjunction with a flow metering function, such as the IPFIX metering process [IETF RFC 5101] and some filtering capabilities, such as [b-IETF RFC 5476]. NOTE – This metering process typically populates the following IPFIX Information Elements (used as flow keys): sourceIPv6Address and destinationIPv6Address, sourceIPv4Address and destinationIPv4Address, protocolIdentifier, sourceTransportPort, destinationTransportPort, etc. However, it is the DPI-FE’s role to populate the application tag and the completion of the IPFIX flow identifier (based on the given IPFIX flow key, see also Figure A.1). 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:
|