Packets that traverse a network are never the same. New and updated applications operate with new IP addresses and IP ranges, use new protocols and carry new services. Even across organizations whose operations have been relying on the same ERP or CRM applications for decades, the lure of cloud and SaaS applications alongside the practice of shadow IT have resulted in a new mix of protocols and applications congesting the available network bandwidth.
When it comes to traffic analytics, deep packet inspection (DPI) stands out as a robust tool for inspecting voluminous IP traffic. It is integrated within the network to deliver real-time classification of protocols, applications and service types. DPI is specifically designed to tackle complicated protocols and applications, going beyond millions of easily detectable webservices, such as news websites, to niche applications that are often hard to discern – for example a proprietary enterprise chat app.
DPI technologies, such as the DPI engine R&S®PACE 2 by ipoque, encapsulate a rich set of application signatures in a frequently updated library, allowing common and popularly used applications to be monitored and classified in real-time. This spans thousands of applications, including Teams, Facebook, Salesforce, SAP and Gmail. However, while this ensures network administrators have a certain level of application insights at their fingertips, it leaves a huge visibility gap across niche applications, proprietary applications or updated applications that are most often relevant to only a handful of users. To ensure that existing DPI libraries meet the needs of these users, it is necessary that there is flexibility and freedom on the users’ end to define and add custom signatures to the existing repository, based on their current requirements.
The custom service classifier (CSC) plug-in by ipoque was introduced to address this need. The CSC is an extension of the DPI engine R&S®PACE 2 and is loaded as a separate binary. Deployed alongside the host application and with compatibility across any network environment, the CSC plug-in offers users the opportunity to build up their own set of custom signatures using flow-based service classification.
Keep it quick and simple with JSON
CSC by ipoque leverages JavaScript Object Notation (JSON) — an open-standard, text-based file format used to exchange data. JSON is used to represent JavaScript object literals, arrays and scalar data. It serializes structured data and transports it across the network. The use of JSON greatly simplifies the task of network administrators in charge of adding new signatures via the CSC, as it provides a friendly and an easily writable and readable format. The usage of JSON enables CSC users to easily add signatures, without requiring knowledge of C or C++ programming language. The maintenance of these files can be done manually or in an automated fashion by the maintainer of the custom signatures.
Defining custom signatures in the CSC requires users to specify a range of JSON attributes that are used to detect the underlying application or service. These comprise of general attributes such as the version of the CSC plug-in and its configuration parameters. The attributes also include the general configurations of the DNS cache and the maximum number of entries it can cache. The attributes then dive into the services, starting from the lists of custom service definitions and zooming into service-level specifics, such as each service’s unique number, short name, long name and description. Service-level specifics are used in corresponding classification events. These are then matched to a list of domains and one or more IPv4 / IPv6 addresses.
Automated event-based classification
The CSC is programmed to respond to triggers such as flow information, a DNS request and an HTTP request. For each specified trigger, the plug-in returns one classification result per flow. The classification result for each flow is derived by filtering the event through a hierarchy of matching criteria with the topmost criterion being the IP addresses or address ranges. In the absence of matching IP addresses, the CSC uses the DNS cache information, from which it extracts the available metadata, such as the HTTP host line, HTTP user agent, HTTP2 authority header field, HTTP2 User Agent, TLS SNI client, TLS SNI server, QUIC server name indication (SNI) and QUIC user agent ID (UAID).
To illustrate how this works, let us take a sample application ‘Local QA Service’ that is not included in the default library of R&S®PACE 2. The trigger event in this case will be a DNS or an HTTP request. Here, users can specify the DNS trigger as “request for dashboard.mycompany.com” or the HTTP trigger as “request to server 172.16.0.0/12”. This prompts the CSC to return the specified corresponding plug-in event, which in this case is the classification result. The DNS and HTTP inputs are run through the CSC’s hierarchy of matching criteria that are pre-specified for each custom app that is listed by the user in the CSC. In this instance, the IP address is sufficient to produce a classification result. The CSC thus returns the classification result with the application identified as ‘Local QA Service’, allowing R&S®PACE 2 to accurately detect and classify the application every time it is accessed.
