Application Assurance — Application Identification and User-Defined Applications

In order to classify traffic properly, it is recommended to follow the guidelines and best practices defined in this section before creating a new application:

• Analyze the application traffic

  • Identify what type traffic is used (Wireshark®).

  • Use the application the same way the end user would use it, the same application can create various flows.

• Configure the appropriate App-Filters

  • Following the analysis of the application done above, create the application.

  • Follow the App-filter best practices chapter to understand in which range to add the filters.

  • More than one App-filter can be required to identify a single application.

The default AA policy called AppDB (Application Database) is provided by Nokia and should be used on most deployments. Contact your regional support organization for more details on how to obtain it.

This configuration includes applications and application-groups most providers can use by default and is designed to allow the addition of any custom entries required by service providers to identify additional services/applications.

The following customization options exist:

• Generating a configuration for a particular region (such as APAC)

• Generating a new configuration (or updating a configuration) containing specific applications

Before adding new entries to the template and customizing the configuration, it is recommended to follow the next guidelines on app-filters and ranges. These guidelines are key to allow an easy upgrade path from the policy configuration provided by Nokia.

HTTP is a client/server protocol using TCP/IP at the transport layer to deliver resources such as HTML files, images, videos and more.

HTTP 1.1 enables HTTP clients to use a persistent connection to a server allowing them to reuse the same TCP session for multiple HTTP transactions. Text, images, video, scripts and other objects can be downloaded individually in different transactions through the same TCP session.

HTTP persistent connection describes a typical persistent HTTP connection between a web client and a server with multiple HTTP transactions within the same TCP session:

User-defined expression-based HTTP applications will use the first HTTP transaction to classify the flow (optionally this behavior can be modified).

The following example shows the content of a typical HTTP request to wikipedia.org which includes the following header fields: HTTP Host, HTTP URI, HTTP User Agent and HTTP referer fields:

• HTTP Host — Represents the domain name (does not include ‟http://”).

• HTTP URI — The URL trailer after the host domain name (begins with slash ‟/”).

• HTTP Referer — The address of the previous web page from which a link to the currently requested page was followed (in this example, the referer is www.google.com which means the user clicked on a link from a Google search pointing to wikipedia.org).

• HTTP User Agent — This identifies the web browser or application making the HTTP request.

Classifying HTTP traffic from this web site can be done using a single expression tail anchored on the HTTP host:

configure application-assurance group 1:1 policy app-filter
    entry <1..65535> create
        description "Wikipedia Web Access" expression 1 http-host eq "*.wikipedia.org$"
        application "Wikipedia"
        no shutdown 
    exit

This can be confirmed using Wireshark®.

HTTPS uses SSL/TLS to encrypt traffic between the client and the server. Because this communication is encrypted, it is not possible to identify the HTTP Host or URI. However, AA can still identify the service requested by the subscriber by looking at the TLS certificate information or Server Name Indication exchanged in the clear before the TLS session is established.

SSL/TLS traffic can optionally be identified using the Server Name Indication (SNI) which is an extension to the TLS protocol.

The SNI is found in the TLS Client Hello, the http-host expression in the app-filter is reused to classify this traffic:

configure application-assurance group 1:1 policy 
    app-filter
        entry <1..65535> create
            description "Yahoo HTTP or TLS SNI"
            expression 1 http-host eq "*.yahoo.com$"
            application "Yahoo"
            no shutdown
          exit

SIP is a signaling protocol used for controlling multimedia communication sessions such as voice and video over RTP. AA automatically monitors SIP control flows and associates RTP/RTCP media flows accordingly in the sip_rtp protocol signature.

The operator can use a SIP expression match criteria in app-filter to further refine traffic classification and identify any additional application on top of the default AA policy. This can be particularly useful in business VPNs to identify voice and telepresence applications.

AA supports SIP expression match criteria on SIP URI, SIP user agent and SIP media type. The following snapshot from Wireshark® shows a SIP control exchange using the voice-video application Vonage® followed by the RTP media audio flow; the expression fields that can be matched using AA app-filters are highlighted:

The following configuration example provides the configuration to classify Vonage® SIP/RTP desktop traffic using SIP URI expression:

configure application-assurance group 1:1 policy 
    app-filter
        entry <1..65535> create
            description "Vonage"
            expression 1 sip-uri eq "*voncp.com*"
            application "Vonage"
            no shutdown
        exit

Similar to SIP, H323 is a signaling protocol used for controlling multimedia communication sessions such as voice and video over RTP. AA automatically monitors H323 control flows and associates the RTP media flow accordingly in the h323_rtp protocol signature.

The operator can use an H323 expression match criteria app-filter to further refine traffic classification and identify any additional application on top of the default AA policy. This can be particularly useful in business VPNs to identify voice and telepresence applications.

AA supports H323 expression match criteria on the H323 product ID. The following snapshot from Wireshark shows an H323 control exchange using the Telepresence application LifeSize® followed by the RTP media audio flow; the expression field that can be matched using AA app-filters is highlighted:

The following configuration example provides the configuration to classify LifeSize® H323/RTP traffic using the H323 product ID expression:

configure application-assurance group 1:1 policy 
    app-filter
        entry <1..65535> create
            description "LifeSize H323 traffic"
            expression 1 h323-product-id eq "^LifeSize*"
            application "LifeSize"
            no shutdown
        exit

RTSP is a signaling protocol used for controlling media streaming content such as audio and video over RTP/RDT. AA automatically monitors the RTSP control flows and associates its RTP/RDT media flow with the rtp_rtsp protocol signature.

The operator can use an RTSP expression match criteria app-filter to further refine traffic classification and identify any additional application on top of the default AA policy. This can be particularly useful to identify specific streaming applications.

AA supports RTSP expression match criteria on the RTSP Host, URI, User Agent. The following snapshot from Wireshark® shows an RTSP setup request to YouTube® followed by the RTP media audio flow; the expression fields that can be matched in RTSP SETUP request using AA app- filters are highlighted:

The following configuration example provides the configuration to classify YouTube® RTSP/RTP traffic using RTSP Host expression:

configure application-assurance group 1:1 policy 
    app-filter
        entry <1..65535> create
            description "YouTube RTSP/RTP Video"
            expression 1 rtsp-host eq "*.youtube.com$"
            application "YouTube"
            no shutdown
        exit

Independent Computing Architecture (ICA) is a Citrix Systems® protocol used in Citrix’s WinFrame, Citrix XenApp (formerly called MetaFrame/Presentation Server), and Citrix XenDesktop products.

Citrix makes it possible to run applications remotely on large servers, thus making better use of server resources while at the same time allowing people using other platforms to use the applications, for example, run Microsoft® Word on a UNIX workstation.

Citrix_ica protocol signature will detect any remote application using Citrix (the protocol needs to be unencrypted and configured to non-seamless). The Citrix ICA session is started from a client and can be anything from Remote Desktop, SAP to Microsoft® Word.

The Citrix expression match app-filter is used to classify traffic based on the Citrix-published application. This published application is configured on the server and in the preceding example, it can be for instance RDP, SAP, Word, XLS or Microsoft® Word depending how the server is configured.

configure application-assurance group 1:1 policy 
    app-filter
        entry <1..65535> create
            description "Citrix SAP Application"
            expression 1 citrix-app eq "SAP"
            application "Citrix SAP"
            no shutdown
        exit

The following configuration example uses a server-address app-filter to classify traffic from server 10.1.1.1 in the application called Application-1:

configure application-assurance group 1:1 policy 
    app-filter
        entry <1..65535> create
            description "Server #1 10.0.0.1"
            server-address eq 10.0.0.1/32
            application "Application-1"
            no shutdown
        exit

The following configuration example uses server-address and server-port app-filters to classify traffic from server 10.0.0.2 on port 1234 in the application called Application-2. It is particularly useful when the same server is used to provide different services that need to be classified separately:

configure application-assurance group 1:1 policy 
        entry <1..65535> create
            description "Server #2 10.0.0.2 port 1234 Only"
            server-address eq 10.0.0.2/32
            server-port eq 1234
            application "Application-2"
            no shutdown
        exit

It is possible to combine a protocol signature with a port number in the same app-filter, this is typically done in business VPNs for specific internal applications not detected using existing AA protocol signatures.

The following configuration example classifies a business VPN application running on TCP port 4000 and not detected by any other signatures. It combines the protocol signature unknown_tcp with the desired port number. This allows keeping the classification untouched for the rest of the protocols/applications and is the recommended approach:

configure application-assurance group 1:1 policy 
    app-filter
        entry <1..65535> create
            description "Business VPN Application X Port 4000"
            server-port eq 4000
            protocol eq unknown_tcp
            application "Busines VPN Application X"
            no shutdown
        exit

Traffic can be classified based on flow-setup-direction app-filter. The flow setup direction can be either subscriber-to-network or network-to-subscriber.

Network side and subscriber side is AA terminology related to where AA is enabled:

• In broadband and mobile networks, AA is enabled per subscriber. This means the subscriber side represents the ESM/mobile/transit subscriber while the network side represents Internet or other subscribers.

• In business VPNs, AA is enabled on a VPN SAP/spoke SDP and the subscriber side represents the local VPN site (SAP/spoke/transit).

The following example shows the configuration to classify http traffic hosted by AA subscribers (for example, broadband subscribers running a web server):

configure application-assurance group 1:1 policy 
    app-filter
        entry <1..65535> create
            description "HTTP Server on the subscriber side"
            flow-setup-direction network-to-subscriber
            protocol eq http
            application "HTTP Server"
            no shutdown
        exit

Traffic can be classified using an IP protocol number for non TCP/UDP traffic.

The following example provides the configuration to classify ICMP IPv4/v6 traffic:

configure application-assurance group 1:1 policy 
    app-filter
        entry <1..65535> create
            description "ICMP v4"
            protocol eq "non_tcp_udp"
            ip-protocol-num eq icmp
            application "ICMP"
            no shutdown
        exit
        entry <1..65535> create
            description " ICMP v6"
            protocol eq "non_tcp_udp"
            ip-protocol-num eq ipv6-icmp
            application "ICMP"
            no shutdown
        exit

Custom protocols can be used to classify TCP/UDP applications using hexadecimal string matching (up to 16 hex octets) at a configurable payload offset in the data payload. The expression string length and offset must not exceed 128 bytes.

To illustrate this feature the Solaris® application GoGlobal is used. It provides remote access to a server (similar to VNC®). The following snapshot (SIP Wireshark® capture) from Wireshark® shows a TCP SYN/ACK session establishment followed by the first data exchange:

Wireshark® shows that each TCP session payload starts with 80DC0400 (no offset) after the three-way TCP handshake. As a result, the configuration required to classify this traffic is as follows:

configure application-assurance group 1:1 policy 
    custom-protocol 1 ip-protocol-num tcp create
        description "goglobal tcp"
        expression 1 eq "\x80\xdc\x04\x00" offset 0 direction client-to-server
        no shutdown       
    exit
    app-filter
        entry <1..65535> create
            description "GoGlobal "
            protocol eq "custom_01"
            application "GoGlobal"
            no shutdown
        exit

Subscriber-level statistics can be updated in real time. AA is usually configured by the operator to collect subscriber-level statistics for all application groups in residential and Wifi, while business VPNs typically collect Application group and all applications for each site with AA enabled.

The following commands can be used to view per subscriber statistics for all app-groups or applications configured in ISA group 1, partition 1 for the ESM subscriber "Bob" or business VPN SAP 1/1/1:10:

show application-assurance group 1:1 aa-sub esm "bob" app-group count
show application-assurance group 1:1 aa-sub sap 1/1/1:10 application count

In case only app-group statistics are collected per subscriber, the aa-sub-study feature can be used to collect per application-level statistics for selected subscribers, as follows:

A:PE# configure application-assurance group 1:1 statistics aa-sub-study application
A:PE>config>app-assure>group>statistics>aa-sub-study# aa-sub esm "bob"

Once done, the system will show all application level statistics for this subscriber:

show application-assurance group 1:1 aa-sub-study esm "bob" application count

Similar to partition-level statistics, aa-sub and aa-sub-study statistics can be sorted by octets, packets, flows:

show application-assurance group 1:1 aa-sub-study esm "bob" application count top [octets | packets | flows] [max-count <max-count>]

Traditional show commands may not provide enough information when troubleshooting flow identification and the operator can use the ISA flow-record-search tool to dump the ISA flow table for more information. This feature comes with a large number of filtering options documented in the user guide.

Each flow gives visibility into: Flow ID, Sub-Type, Sub-Name, Initiator, Direction, Source IP, Dest. IP, IP Protocol, Source Port, Dest. Port, FC, DSCP, Classified, Protocol, Application, App- Group, Charging Group, Packets tx, Bytes Tx, Packets-discarded, Bytes-discarded etc.

See below for the most commonly used commands.

The following command shows all the flows in an ISA card per ISA group:partition (can be a very long output, up to 3M entries):

application-assurance group 1:1 flow-record-search isa 1/2

The following command shows all the flows per AA subscriber in a given group:partition:

tools dump application-assurance group 1:1 flow-record-search aa-sub esm "bob"

The following command shows all the active flows per AA subscriber in a given group:partition:

tools dump application-assurance group 1:1 flow-record-search aa-sub esm "bob" flow- status active

The flow-record-search command is also available with additional details by adding search-type detail at the end of the command line. Note that due to the length of the output it is recommended to paste the CLI output content in a notepad file.

AA cflowd allows operators to export the HTTP domain extracted from HTTP flows to the NSP cflowd collector. This allows the operator to understand which HTTP hosts are visible in the network.

However, in case a cflowd collector is not deployed, AA provides the HTTP host recorder tool command to record HTTP hosts seen by AA. See the Multiservice ISA and ESA Guide for more details.

A:PE# show debug 
debug
    application-assurance
        group 1:1
            http-host-recorder
                filter
                    default-filter-action record
                    record http-host-app-filter-candidates
                exit
                rate 100
                no shutdown
            exit
        exit
    exit
exit

A:PE# tools dump application-assurance group 1:1 http-host-recorder top bytes

This function is particularly useful in business VPN (it can also be used in residential networks). The port-recorder AA tool function is similar to the http-recorder. It allows the operator to record which ports are used on selected applications.

It is most commonly used with the applications Unidentified TCP and Unidentified UDP but it can be configured to record any other applications:

A:PE# show debug 
debug
    application-assurance
        group 1:1
            port-recorder
                application "Unidentified TCP"
                application "Unidentified UDP"
                rate 100
                shutdown
            exit
        exit
    exit
exit

A:PE# tools dump application-assurance group 1:1 port-recorder top bytes