II.1.1 Purpose
Accompanying material for discussion of DPI use cases and requirements.
II.1.2 Specification level of rules
Packet inspection may be considered as a packet policing function (see Appendix VII). The particular “inspection function” may be thus formulated as policy rule. The specification depth may differ in various respects:
• High-level
• Low-level rules (using informal specification language, like a prose language)
• Low-level rules (using formal specification grammar)
II.1.3 Generic rule format
In order to use a common description format, the examples here following below generic rule format, comprised of
• a rule header (name, identifier, precedence, etc.) and
• a rule body (for conditions, actions).
Figure II.1 – Generic rule format
It may be noted again that the specification of explicit bindings between actions and conditions is out of scope of this Recommendation.
II.2 Example policy rules for Application-dependent, Flow-dependent DPI – Identification order “1st Application, 2nd Flow” II.2.1 Example “Security check – Block SIP messages with specific content types and derive SIP device address”
Table II.2.1 – Example
DPI Policy Rule ("Security check – Block SIP messages with specific content types and derive SIP device address")
Rx: “…”, Id = …, precedence = …
|
Condition(s)
|
Action(s)
|
If:
C1: "L4+ PDU = SIP message?"
AND
C2: "SIP content-type values = {…}"
|
Then:
A1: “extract flow information (which contains the remote source IP transport address) and …”
A2: “… SIP message”
A3: “Update Statistic”
|
II.2.2 Example “Detection of Malware”
Here: network-based detection of malicious software (‘malware’), which is typically distributed via FTP and HTTP (or SMTP), in contrary to host-based malware detection.
Assumption: a pattern matching technique is sufficient for detecting particular malware. The characteristic patterns of malwares are registered beforehand as signatures, and it detects malwares by comparing these patterns with byte code of a malware. Pattern matching technique is effective for existing malwares whose signature has been created.
Table II.2.2 – Example
DPI Policy Rule ("Detection of Malware")
Rx: “…”, Id = …, precedence = …
|
Condition(s)
|
Action(s)
|
If:
C1: "L4+ PDU = FTP message?3"
OR
C2: "L4+ PDU = HTTP message?"
AND
C3: "L4+ PDU contains byte pattern “xyz4”"
|
Then:
A1: “extract flow information (which contains the remote source IP transport address) and …”
A2: “report detected Malware type”
|
II.2.3 Example “Detection of specific video format”
Here: H.264 as example. Rule may be further refined for checking specific subformats.
Table II.2.3 – Example
DPI Policy Rule ("Detection of specific video format")
Rx: “…”, Id = …, precedence = …
|
Condition(s)
|
Action(s)
|
If:
C1: "look for video format H.264 by checking for H.264 header information"
AND
C2: "packet matches Flow Descriptor = FD "
|
Then:
A1: “…”
|
II.2.4 Example “Detection of File Transfer in general”
Here: FTP/TCP-based file transfer, thus an example of an IP application with two (or >2) "flow components", one control flow and "0 to many (parallel)" data flows (separate TCP connections for individual file transfers).
The assumption here: the overall flow level conditions are given by just the 2-tuple of IP connection endpoint addresses (of FTP client and FTP server).
Table II.2.4 – Example
DPI Policy Rule ("Detection of File Transfer in general")
Rx: “…”, Id = …, precedence = …
|
Condition(s)
|
Action(s)
|
State S1 (“inspect for ftp control traffic”):
If:
C1: "IP protocol type = “TCP”"
AND
{
C2: "L4 port = «well-known port for ftp control»"
OR
C3: "L4+ PDU contains FTP Commands …"
}
|
Then:
A1: “extract flow information (the 2-tuple of f = {IP Source Address (SA), IP Destination Address (DA)})”
|
State S2 (“inspect for ftp data traffic”):
If:
C1: "Flow Descriptor = FD (or inverse due to both traffic directions)"
AND
C2: "IP protocol type = “TCP”"
AND
C3: "L4+ PDU contains FTP DATA header information elements (e.g., filename, file lists."
|
Then:
A1: “extract file name(s) information and report to …”
|
That’s an example of stateful DPI, abstracted here to just two states for control traffic detection and file traffic detection. The initial state (S1) belongs to the “flow independent” identification category (FI) and subsequent state S2 is then acting in “flow dependent” identification category (FD) mode.
Share with your friends: |