Identifying Applications by Name
The Session Smart Routing platform has several techniques by which it can associate inbound traffic to named applications. This is sometimes referred to as "Application Identification" (or "appID"), and the feature that allows administrators to define network policies using Fully Qualified Domain Names (FQDNs) instead of IP addresses.
The SSR has three built-in techniques for affiliating named applications to services, all of which will be described in this document. (A fourth technique, involving service function chaining third party software is not covered here.) The three techniques are:
- Using DNS to resolve FQDNs to IP addresses
- Using the
- Using the
Generally, when configuring a
service on a SSR, administrators use the
address field to identify the IP address(es)/CIDR block(s) that the SSR should use to match to inbound traffic. However, the
address field will also accept hostnames, such as
www.128technology.com. When a service uses a hostname in the
address field, it is referred to as a DNS-based service.
For every DNS-based service, the SSR will use its local DNS to resolve the hostnames; for every IP address that is returned the SSR will treat that as though it were configured in the
address field, and install FIB entries accordingly. It will also refresh these FIB entries based on the time-to-live (TTL) returned by the DNS server. Here is a sample configuration for reference:
firstname.lastname@example.org# show config running authority service interchange
In this configuration, the
address is configured as
community.128technology.com. This will be resolved once the configuration is committed, and the SSR will resolve that hostname and install FIB entries. The SSR will periodically re-resolve those hostnames to ensure that the FIB entries are kept up-to-date.
The names used in the
address field must be DNS-resolvable names. You cannot use wildcards such as
- This is a very easy and intuitive way to associate traffic to services, without having to define a long list of IP addresses. When upstream devices change their IP address, there's no need to reconfigure the SSR to keep it up-to-date, as this is handled by DNS.
- Unlike AppID based on TLS, there is no "chicken and egg issue;" i.e., no prerequisite to have the destination be reachable in order to learn the destination's name.
This technique relies on your SSR getting the same answers from DNS that your clients get. Take for example a massive SaaS provider such as
www.salesforce.com. Their web site resolves to hundreds or thousands of IP addresses distributed across the globe. When the SSR resolves that hostname, it will get a handful of answers; if a client does the same DNS query and gets a different set of answers, then the traffic the client sends will not match the FIB entries that the SSR has created.
Use DNS-based services when your destination uses a small set of nonvolatile IP addresses. This technique is perfect for small, hosted services. The effectiveness of using DNS-based services diminishes rapidly when referencing names that resolve to dozens of address or more.
AppID based on TLS
The SSR can also learn about named destinations by inspecting the traffic that traverses it. This is done by inspecting the X.509 certificate sent by a server during the TLS handshake process. Importantly: this presupposes that the SSR can route packets to that destination for the purposes of retrieving the server's certificate. Thus, when using AppID based on TLS, it is important to ensure that there is a
service-route capable of reaching that server in addition to the one you'll configure for the named application.
Normally this is done by having a "catch-all" service for
0.0.0.0/0 to route traffic out to the internet, but it does not need to be.
Server Hello message sent by a server will include its X.509 certificate, which is decipherable by the client to include information about the server. One such example is here:
[ptimmons@labsystem1 ~]$ openssl x509 -in /tmp/512b-rsa-example-cert.pem -text -noout
Version: 1 (0x0)
Serial Number: 3578 (0xdfa)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=JP, ST=Tokyo, L=Chuo-ku, O=Frank4DD, OU=WebCert Support, CN=Frank4DD Web CA/emailAddressemail@example.com
Not Before: Aug 22 05:26:54 2012 GMT
Not After : Aug 21 05:26:54 2017 GMT
Subject: C=JP, ST=Tokyo, O=Frank4DD, CN=www.example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (512 bit)
Exponent: 65537 (0x10001)
Signature Algorithm: sha1WithRSAEncryption
This sample certificate was supplied by FM4DD.
About a third of the way through the output you can see that the Common Name (listed as
CN in the
Subject line) is
www.example.com. This is what SSR will parse and subsequently retain as the "application name" for this destination. Assuming this matches a configured
application-name within a
service, a FIB entry is installed with this server's IP address and associated with the
To enable application identification based on TLS, configure the
application-identification element within the
router context as seen here:
firstname.lastname@example.org# show config running authority router burlington application-identification
For reference, here's a
service that would leverage the X.509 certificate shown above:
email@example.com# show config running authority service example
description "www.example.com website"
Here we can see the
application-name set to
www.example.com, which matches the Common Name from the X.509 certificate in our example. Assuming we had a
service-route capable of reaching
www.example.com to begin with, the TLS handshake would see the server's X.509 certificate returned back to the client through the SSR. The SSR parses the certificate, recognizes
www.example.com as belonging to the service named
example and installs a FIB entry for it with the server's IP address.
example service needs to have its own
service-route in order for traffic to be forwarded.
With the TLS-based application identification technique, the
application-name can include a wildcard such as
*.example.com, which is not possible with the DNS-based approach. This gives administrators a bit more flexibility in defining which traffic to match to services when parsing the X.509 certificates.
Update for SSR version 5.0
Starting with SSR version 5.0, a FIB entry is no longer installed as part of DPI. Instead, domain-names and IP addresses are learned from TLS and mapped to hierarchical services using the
description "all internet traffic"
description "www.example.com website"
AppID using Modules
The last, and arguably most powerful built-in technique for performing application identification is to use a module – effectively, a script that is resident on the SSR's host operating system that will generate a JSON file that contains dynamic, ingestible routes. This is extremely flexible, but requires some programming expertise.
It is also possible to simply place a static JSON document on the SSR's filesystem (i.e., one that is not generated by a local script) as a means of feeding an application identification module into the SSR).
Configuring application identification based on modules first requires that a router have the feature enabled:
firstname.lastname@example.org# show config running authority router becket application-identification
Script-Based Module Setup
Scripts are placed on the router's filesystem at
/etc/128technology/application-modules/. These scripts produce a JSON output stored at
/var/run/128technology/application-modules/, which in turn is processed by the SSR and installed as FIB entries.
Systemd-Based Module Setup
Beginning with the 5.2 release,
systemd may be used to manage the execution of application identification modules. JSON output produced by the module is passed directly to the highway REST API instead of being written to disk.
Using this approach, modules are registered by creating a file at
/etc/128technology/application-modules/services/<module-name>. This file lists the systemd units of the module and specifies if and how SSR should interact with them.
reload-service: When the highway process starts, reload the systemd unit. This is a signal to POST the JSON to highway again as module data is not saved through process restarts.
stop-on-shutdown: Stop the systemd unit when SSR is shutting down.
Modules must be registered in order for SSR to accept the POST of JSON module data.
In the following example, a systemd timer unit is used to periodically invoke the main service/script, which does the work of gathering module data. Both are stopped on shutdown, but only the timer unit needs to fire again on restart of SSR.
For more information about using timers with the systemd service, refer to ArchLinux systemd/Timers.
Beginning with the 5.2 release, module registration and detailed module status (including a full list of ip-prefix/ports/protocol) can be accessed via a REST API or from the CLI. Please refer to the API documentation available from the GUI, and the
show application modules status and
show application modules registration for full details.
Referencing Modules in Configuration
Each module produces a list of service names that are used to reference it in the configuration through the
application-name list. For example, an application identification module named
zoom will retrieve and process all of the IP addresses used for the
ZOOM videoconferencing service. The corresponding service looks like this:
email@example.com# show config running authority service ZOOM
description "Zoom meetings"
application-name is configured as it is with the
tls variant of
application-identification. In this case, however, it will read the contents of a JSON file to produce the FIB entries. Below is an excerpt from the
zoom module's output:
In the case of this module, the script that generates the JSON is
/etc/128technology/application-modules/zoom.py, the output is stored as
/var/run/128technology/application-modules/zoom.json. A copy of the
zoom.py script is available on our user community, AI-Driven SD-WAN powered by Session Smart community.
services tag of
ZOOM is what associates these IP prefixes to the service we've shown above. Each of these IP prefixes (which could have also included port ranges, but don't in this example) will create a FIB entry for the
ZOOM service, and be given access and policy determinations based on the configuration we've set in our SSR.
The SSR ships with an Office365 module, and other modules can be found on AI-Driven SD-WAN powered by Session Smart community, our user community, as well as on Github. For more information on writing your own application identification module, refer to our developer documentation or our sample code.