AA traffic identification classifies per-flow traffic into applications and application groups, and assigns flow attributes to the traffic.
Application identification means there is sufficient flow information to provide the network operator with a view of the underlying nature and value of the content based on the end-user application related to each flow. The application ID does not include:
anti-virus signatures per IPS/UTM
content inspection (e-mail, text, picture, or video images). The payload data content of flows is not examined as part of the application identification.
AA can identify and measure non-encrypted IP traffic flows using any available information from Layer 2 to Layer 7, and encrypted IP traffic flows using heuristic and pattern-match techniques. Nokia maintains a global application database (App-DB) to keep application definitions (app filters and applications) up-to-date in customer deployments.
AA attempts to positively identify the protocols and applications for flows based on a pattern signature observation of the setup and initial packets in a flow. The system correlates control and data flows belonging to the same application. In parallel, statistical and behavioral techniques are also used to identify the application. Until identified, the flow does not have a known application and is treated according to the default policies (AQP policies defined using all or any ASO characteristics, subscriber ID and traffic direction as match criteria) for traffic for that AA subscriber, app-profile and direction (packets are forwarded unless an action is configured otherwise). If the identification beyond OSI Layer 2 is not successful, the flow is flagged as an unknown protocol type, (for example unknown_tcp or unknown_udp). The unknown traffic is handled as part of all application statistics and policy, including generation of stats on the volume of unknown traffic.
AA allows operators to optionally define port-based applications for trusted TCP or UDP ports. Operators must explicitly identify a TCP/UDP port or ports in an application filter used for trusted port application definition and specify if protocol signature-based application identification is to be performed on a flow. Two options are available:
If no protocol signature processing is required (expected to be used only when (A) AQP policy must be performed from the first packet seen, (B) the protocol signature processing requires more than one packet to positively identify a protocol or application, and (C) no other application traffic runs over a TCP/UDP port), the first packet seen by AA ISA for a flow on that TCP/UDP port allows application identification. The traffic for a flow is identified as ‟trusted tcp/trusted_udp” protocols.
If protocol signature verification of an application is required, that is, it is expected to be used only when:
AQP policy must be performed from the first packet seen.
The protocol signature processing requires more than one packet to positively identify a protocol or application.
Other application traffic may run over a TCP/UDP port, for example TCP port 80
The first packet seen identifies the application but protocol signature-based analysis continues. After the identification completes, the application is re-evaluated against the remaining application filters allowing detection and policy control of unexpected applications on a trusted port.
Flow attributes provide optional flow classification metadata extracted from traffic by AA stateful flow processing, which complements and is orthogonal to the AA application and app-group classification.
When a flow attribute is enabled, every flow is assigned a confidence level for each enabled attribute. Confidence levels are used to condition control actions and for analytics. AA cflowd record exports include the 0-100% confidence level for each attribute, and are null for attributes that are not enabled. This allows analytics of traffic by flow attribute, including confidence. As with AA protocol signatures, flow attribute signatures are provided as a set in the AA.tim file.
At AA system startup or after an AA ISA activity switch, traffic diverted to the ISA may contain flows that are already in progress. Typically, application identification relies on patterns in the initial set of packets exchanged. If these initial packets were not seen by the ISA, in progress TCP flows are marked with the existing protocol signature and have a policy applied according to an application based on the existing protocol until they end or the identification of an in-progress flow is possible. Statistics are generated.
From the first packet of a flow, a default per-AA subscriber AQP policy is applied to every packet. After an application is identified, subsequent packets for a flow apply AA subscriber and application-specific AQP. The AA-generated statistics for the flow with AA subscriber and application context are collected based on the final determination of the flow's application. A subset of the applications may be monitored on an ongoing basis to further refine the identification of applications carried with the traffic flow and to identify applications using an external application wrapper to evade detection.