Chapter 10. NBAR

The following principles apply for NBAR:

• Network-based application recognition classifies traffic by protocol (Layers 4 through 7). Here are some examples:

  - NBAR extended inspection for HTTP traffic identifies traffic on ports beyond "well known" TCP ports.

  - NBAR Real-time Transport Protocol (RTP) payload classification allows for stateful identification of real-time audio and video bearer traffic. It can also differentiate based on audio and video codecs.

  - Real-Time Streaming Protocol (RTSP)-based applications can work in NAT's PAT configuration mode.

• User-defined custom application classification lets you identify TCP- or UDP-based applications using a string or value to match the type of application within the packet payload.

• Accounting functionality is enabled via the NBAR feature Protocol Discovery. It analyzes application traffic patterns in real time and discovers which traffic is running on the network. Furthermore, it provides bidirectional (input and output) traffic statistics per interface and per application: bit rate (bps), packet counts, and byte counts.

• A maximum of 24 concurrent URLs, hosts, or MIME type matches are supported.

Distributed NBAR

Originally, NBAR was not supported on distributed platforms, such as the VIP-enabled Cisco 7500 series routers and the Catalyst 6000 family of switches with a FlexWAN module. The Distributed Network-Based Application Recognition (DNBAR) feature was introduced in IOS releases 12.1(6)E, 12.2(4)T3, and 12.2(14)S. On these distributed platforms, DNBAR implements NBAR functionality on a VIP or FlexWAN module. Packets entering an interface on the VIP or FlexWAN are classified by NBAR, and separate reports are available on these modules. It is important to note that the DNBAR feature is identical to NBAR. Therefore, the term NBAR is used to describe both the NBAR and DNBAR features.

NBAR Classification Details

NBAR can classify applications based on the following characteristics:

• Statically assigned TCP and UDP port numbers.

• TCP and UDP protocols that assign port numbers dynamically and therefore require stateful inspection. This includes packets that require subport classification and classification based on deep packet inspection. This is further explained later in this chapter.

• Non-UDP and non-TCP IP protocols (EGP, EIGRP, GRE, ICMP, IPINIP, IPsec).

• HTTP traffic classified by URL, host, or Multipurpose Internet Mail Extension (MIME) type. NBAR also classifies application traffic using subport information, which combines matching of HTTP traffic and the hostname in addition to classification by MIME type or URL.

• Identifying worms in the packet payload, which is very useful for security mitigation. After you have identified unique match values signatures for a specific attack, use NBAR to block this traffic immediately while establishing a defense plan against the attack. For example, Code Red was identified by an "*.ida" URL in the HTTP GET request.

• Peer-to-peer traffic, such as Napster, Kazaa, Morpheus, Gnutella, Grokster, WinMX, eDonkey, eMule, BitTorrent, and so on.

• Heuristic and holistic classification. NBAR classifies an application based on the information of the whole packet and makes a determination based on the behavior of the whole packet. The RTP Payload Classification feature is based on this algorithm; the packet is classified as RTP based on multiple attributes in the UDP and RTP headers. Note that heuristic and holistic classification functions are limited to the PDLMs and cannot be used to customize applications!

• Citrix Independent Computing Architecture (ICA) traffic classification by application name.

NBAR offers additional capabilities that help classify applications:

• User-defined protocols. Operators can define names for their custom protocol applications. The user-named protocol can then be used by the Protocol Discovery CLI and MIB, and CLI commands such as match protocol or ip nbar port-map as an NBAR-supported protocol.

• Ten custom applications can be assigned using NBAR. Each customer application can have up to 16 TCP and 16 UDP ports, each mapped to the individual custom protocol. The real-time statistics per custom protocol can be monitored using the Protocol Discovery function.

• Matching the use of multiple ports to one application is a unique benefit of NBAR. A simple example demonstrates this: FTP uses TCP ports 20 and 21. NBAR consolidates traffic from both ports into one record. In comparison with NetFlow, FTP creates two separate flows, which need to be aggregated at a NetFlow collector afterward.

• Payload inspection matching string patterns at a specific offset.

• Inspection for custom protocols by traffic direction, such as traffic heading toward a source or destination instead of collection traffic in both directions.

The following sections explain some of the features in this list in more detail. They describe features that are advanced or not intuitive, compared to evident features such as identifying applications by port number.

Classification of HTTP by URL, Host, or MIME

NBAR can classify application traffic by looking beyond a packet's TCP/UDP port numbers. This ability is called subport classification. NBAR looks at the TCP/UDP payload and classifies packets based on content within the payload, such as transaction identifier, message type, or other similar data. Classification of HTTP by URL, host, or MIME type is an example of subport classification. NBAR classifies HTTP traffic by text within the URL or Host fields of a GET request using regular expression matching. NBAR uses the UNIX filename specification as the basis for the URL or host specification format. The NBAR engine then converts the specified match string into a regular expression. NBAR does not classify packets that are part of a pipelined request. With pipelined requests, multiple requests are pipelined at the server before previous requests are serviced. For HTTP requests, in-depth analysis can be performed.

For request messages (client to server), the following HTTP header fields can be identified:

• User-Agent— A value in the HTTP header field, also known as "Browser ID," such as "Mozilla/4.0"

• Referrer— The reference to the previous visited website

• From— Indicates the initiator of the request, such as the e-mail address

For response messages (server to client), the following header fields can be identified:

• Server contains information about the software used by the origin server that handled the request, such as "Server: CERN/3.0 libwww/2.17."

• Location is used to redirect the recipient to another location.

• Content-Encoding is used as a modifier to the media type, such as "gzip."

Classification of Citrix ICA Traffic by Application Name

NBAR can classify Citrix Independent Computing Architecture (ICA) traffic and perform subport classification of Citrix traffic based on Citrix published applications. NBAR can monitor Citrix ICA client requests for a published application destined for a Citrix ICA Master browser. After the client makes a request to the published application, the Citrix ICA Master browser directs the client to the server with the most available memory. The Citrix ICA client then connects to this Citrix ICA server for the application. NBAR statefully tracks Citrix ICA client/server messages and classifies requests for given Citrix application names and traffic. NBAR performs a regular expression match using a user-specified application name string on the contents of the Citrix ICA control packets carrying the published application name.

NBAR Packet Description Language Module (PDLM)

Even though NBAR supports a long list of static and stateful protocols, new transport protocols will always be developed, and they will require extensions to the existing definitions. Recent examples are new peer-to-peer applications as well as new voice applications and others. NBAR PDLMs, which can be downloaded from the Cisco website, let you add support for new protocols without requiring an IOS release upgrade or a router reload. A PDLM can be loaded at runtime.

NBAR Scope

NBAR does not support certain scenarios:

• MPLS-labeled packets, because NBAR classifies only IP packets. As a workaround, you can use NBAR to classify IP traffic before the traffic is handed over to MPLS. Use the Modular QoS CLI (MQC) to set the IP DSCP field on the NBAR-classified packets and map the IP DSCP settings to the MPLS EXP settings.

• IP Multicast.

• Pipelined persistent HTTP requests.

• URL/host/MIME classification with secure HTTP.

• Asymmetric flows with stateful protocols.

• Packets originating from or destined for the network element running NBAR.

• Custom protocol traffic can be inspected for only the first 255 bytes of the payload.

• IPv6.

• Egress WAN links where tunneling or encryption is configured. As a workaround, NBAR should be configured on ingress interfaces to perform input classification before the traffic is switched to the WAN link for output. Even though NBAR is not supported in these environments, the NBAR Protocol Discovery function is supported on interfaces where tunneling or encryption is used. You can enable Protocol Discovery directly on the tunnel or on the interface where encryption is performed to gather key statistics on the various applications that are traversing the interface. The input statistics also show the total number of encrypted/tunneled packets received in addition to the per-protocol breakdowns.