Application Assurance — DNS IP Cache

This chapter describes the Application Assurance - DNS IP Cache.

Topics in this chapter include:

Applicability

The information and configuration in this chapter are based on SR OS Release 15.0 R5.

Overview

This chapter is intended for network architects and engineers working with Application Assurance (AA). It provides an example to configure the DNS IP Cache, which can be used by operators to ensure that traffic will be correctly classified to prevent charging fraud.

This chapter assumes that the reader has a basic understanding of AA policy (application-filters, applications, application-qos-policies). Additionally, the reader is expected to know the basics of HTTP and DNS.

Nokia recommends using the AA policy configuration templates provided by the Nokia Application Database (AppDB). The AppDB contains an optimized configuration to classify all supported applications and includes all relevant application groups, applications, and app-filters. It can be obtained through Technical Support.

AA uses various methods to classify traffic. Criteria include L3/4 information (IP addresses and ports), or L7 information (HTTP hostnames or other HTTP headers). Classification of Internet services using L3/4 information alone is not very common because IP addresses may change (service providers may add or remove IP addresses), or IP addresses may be region-specific. A more reliable method is to use L7 information, usually the HTTP hostname.

To access a website, after receiving the URL, a browser will perform two basic tasks:

Generate a DNS request to resolve the hostname to an IP address
Send an HTTP request to the web server, using the IP address from the preceding step, and display the web server response to the user browser

Basic Message Flow When Accessing Website shows the basic message flow.

Figure 1. Basic Message Flow When Accessing Website

HTTP is not a strict protocol. Several web server implementations have not implemented the standard completely and may allow requests that appear invalid. The most common case is an HTTP request in which the destination IP address of the packet does not correspond to the hostname.

For example, consider that:

The IP address of www.domain1.com is a.b.c.d (IP1).
The IP address of www.domain2.com is e.f.g.h (IP2).

If the web server running at IP1 receives an HTTP request containing the hostname www.domain2.com , it will reply and provide the content of www.domain1.com . This may happen because several web server implementations (for example, HTTP1.0) ignore the hostname requested.

This may lead to misclassification and incorrect handling of the flow. More specifically, some users may take advantage of this, as follows:

Assume that www.domain2.com is a free-of-charge (zero rated) site and www.domain1.com is a chargeable site. Any classification and charging function (including AA) that uses only the hostname will classify the traffic as traffic toward www.domain2.com .
As a result, the user will receive the content of www.domain1.com for free.

There are Internet applications that use this technique to bypass the operator charging policies. For malicious purposes, some applications manipulate (forge) the HTTP headers. Subscribers appear to be browsing a zero-rated site, while traffic is directed to a chargeable site. The applications tunnel traffic to a proxy server. The HTTP host header is a zero-rated site and the host that the subscriber wants to visit is inserted in another header (usually the x-online-host header).

To protect against such host header attacks, AA has implemented the DNS IP Cache feature.

AA will populate a cache with the DNS responses generated when the user requests to access a website, by inspecting DNS traffic. During traffic classification, apart from checking the hostname included in the HTTP request, AA will ensure that the destination IP of the packet matches an entry contained in the cache table.

For example, consider that the cache currently contains the following:


Domain	IP address
www.domain1.com	172.20.1.135 172.20.1.136

The operator can configure an app-filter with match criteria, as follows:

Hostname equal to www.domain1.com
Server address contained in the cache

The system will then verify that the packet contains the hostname configured and the packet destination is an IP address contained in the cache. Only if both criteria are true, the app-filter will match.

Regardless of how access to www.domain1.com is charged, the operator will be certain that this traffic will be correctly classified and charged and no other traffic will be charged at this rate (which may be zero-rated).

For additional protection, the operator can also configure a list of trusted DNS servers. The cache will be populated only with the responses from those DNS servers. This ensures that the cache will not be corrupted with responses from malicious DNS servers.

Operators are advised to use the DNS IP Cache feature for any web traffic that the operator charges at a lower rate or for web traffic that is free. This includes operator websites or partner sites.

Some users will attempt to exploit the operator configuration, trying to obtain content at reduced rates or free of charge. Enabling the feature in the configuration will validate the hostname included in the HTTP request, preventing charging fraud.

Configuration

The example configuration comprises a 7750 SR configured with ISA-AA. The configuration requires a web client and Internet access through SR. The same general DNS IP cache configuration also applies to AA deployed in VSR, MG, and CMG systems.

To pass traffic between two endpoints and verify the configuration, an Epipe service can be created.

The following example assumes:

The user has the IP address 192.168.2.11.
The zero-rated website is "www.nokia.com".
The IP address of the trusted DNS server is 192.0.2.1.

The following sections show how to configure a DNS IP cache to contain the IP addresses of the website www.nokia.com . Only the IP addresses provided by the trusted DNS server will be added in the cache. Finally, an app-filter will be configured whose match criteria will be both the domain and the IP addresses contained in the cache.

To verify the configuration, the operator needs to generate DNS traffic and HTTP traffic to www.nokia.com (as shown in Basic Message Flow When Accessing Website ).

Creating a DNS IP Cache

Create a dns-ip-cache entry and populate it with DNS responses for "*.nokia.com$", only from the DNS server 192.0.2.1:

*A:Dut-C>config>app-assure>group# info
----------------------------------------------
dns-ip-cache "nokia-cache" create
    description "dns cache for nokia"
    dns-match
        domain "domain1" expression "*.nokia.com$"
        server-address 192.0.2.1
    exit
no shutdown 
----------------------------------------------

Create an app-filter

Nokia recommends using the AA AppDB for a complete library of application and app-filter definitions. The AppDB contains verified configurations for all common applications. Operators are advised to consult the AppDB, then edit one of the predefined app-filters for the application to be verified.

It is common for operators to define app-filters for domains that are not included in the AppDB, such as on-net websites:

app-filter
        entry 100 create
            expression 1 http-host eq "*.sponsor1-operator.com$"
            server-address eq dns-ip-cache "dns-ip-cache1"
            application "Sponsor Content #1"
            no shutdown

Create the Application for the Nokia Website

The configuration is as follows:

*A:Dut-C>config>app-assure>group# info
----------------------------------------------
policy
    begin
    application "Nokia NET" create
        description "Nokia website"
        app-group "Web"
    exit
    commit
exit
----------------------------------------------

Create an App-filter for Nokia Traffic, Which Uses the DNS IP Cache

In the example, it is assumed that Nokia content is fetched from the host www.nokia.com .

*A:Dut-C>config>app-assure>group# info
---------------------------------------------
policy
   begin
    app-filter
        entry 61000 create
            description "Nokia Web Access"
            expression 1 http-host eq "*.nokia.com$"
            server-address eq dns-ip-cache "nokia-cache"
            application "Nokia NET"
            no shutdown
        exit
    exit
    commit
exit
----------------------------------------------

The preceding app-filter will match traffic if the hostname matches *.nokia.com$ and if the destination IP address of the packet matches an entry in the cache.

Create application-qos-policy entries

Create a default subscriber policy to inspect DNS responses. This application QoS policy (AQP) is used to populate the cache. No match criteria are needed. AA will only analyze DNS traffic to populate the cache.

*A:Dut-C>config>app-assure>group# info
---------------------------------------------
policy
    begin
    app-qos-policy
        entry 50 create
            action
                dns-ip-cache "nokia-cache"
             exit
             no shutdown
        exit
    exit
    commit
exit
----------------------------------------------

Operational Considerations

When configuring the DNS IP cache (chapter 3.1), configuration of the following parameters was omitted:
- size (10)
- high-wmark (90)
- low-wmark (90)
The default values—shown in parentheses—were used.
- size refers to the maximum number of entries in the cache (it can be between 10 and 32000). The cache size is set to values above 1000 in live deployments, depending on the operator use cases. If the cache becomes full, new IP addresses will be ignored.
- high-wmark defines the high watermark value for the DNS IP cache (percentage). When the number of IP addresses stored in the cache exceeds the threshold defined, the system will generate a trap.
- low-wmark defines the low watermark value for the DNS IP cache (percentage). Assuming the high watermark value was reached and a trap was generated, the system will clear the trap if the number of IP addresses stored in the cache drops below the low watermark value.
Apart from the number of IP addresses that can be stored in the cache (10 in our example), there are also a maximum number of domains that can be stored. These maximum values are indicated in the show command outputs described later.
The AQP configured to populate the cache uses a default subscriber policy. A default subscriber policy does not contain any match criteria against application (application, app-group, charging-group) or L3/4 information (IP address or prefix, TCP/UDP port, IP protocol, DSCP). The AQP will be applied to all matching flows starting with the first packet of a flow. Match criteria can only be by application service options, traffic direction, and optional AA subscriber name.
The app-filter was created by consulting app-filters defined in the AppDB. The entry ranges have been defined in the AppDB. The ranges defined ensure that after Nokia upgrades the AppDB, the custom protocols (defined by the operator) will not be affected. Therefore, the operator should use an entry in the correct range, so that the configuration is not removed after a policy upgrade done with the policy sync tool. User-defined application groups must prefix their description with the text "Custom", thus facilitating future policy upgrades.
If the cache becomes full, new DNS responses will still increase the "Cache full count" and will still get a hit on "DNS Total responses", "Domain name matched", and "Domain & server matched", assuming that they match (see the next section for the show command output). An IP address will expire and be removed from the cache if it is not included in any DNS response for a specified period of time.

Troubleshooting and Debugging

Using the tools and show commands, the operator can verify whether DNS responses are present in the cache and that the configuration is valid.

Show Commands

The following show commands can be used to evaluate the configuration created and verify whether traffic has matched.

The following command shows the DNS IP cache:

*A:Dut-C# show application-assurance group 1 dns-ip-cache "nokia-cache"

===============================================================================
Application Assurance Group 1 dns-ip-cache "nokia-cache"
===============================================================================
Admin Status                : Up
AQP Ref                     : Yes
Domain expressions          : 1 (out of 32)
Server addresses            : 1 (out of 64)
High watermark              : 90%
Low watermark               : 80%
Cache size                  : 10

-------------------------------------------------------------------------------
ISA                        Usage         (%)        Alarm             Hit Count
                                                    State
-------------------------------------------------------------------------------
1/2                            0        0.00        clear                     8
3/1                            0        0.00        clear                     8
===============================================================================

The preceding output provides the following information:

The administrative status of the DNS IP cache "nokia-cache" is "Up". An administrative status of "Down" indicates that the DNS IP cache is not in use.
The DNS IP cache "nokia-cache" is referenced by an AQP.
The number of configured domain expressions (in our example, "*.nokia.com$") equals 1 and the maximum value (shown in brackets) is 32.
The number of server addresses is 1 and the maximum value (shown in brackets) is 64.
The number of times a cache lookup was successful (hit count) is 8. A hit count of 0 indicates a possible configuration error.

The following command displays the content of each ISA card:

*A:Dut-C# show application-assurance group 1 dns-ip-cache "nokia-cache" isa 1/2

===============================================================================
Application Assurance Group 1 dns-ip-cache "nokia-cache" ISA 1/2
===============================================================================
Admin Status                : Up
AQP Ref                     : Yes
Domain expressions          : 1 (out of 32)
Server addresses            : 1 (out of 64)
High watermark              : 90%
Low watermark               : 80%
Cache size                  : 10

-------------------------------------------------------------------------------
ISA 1/2 DNS Stats
-------------------------------------------------------------------------------
DNS
    Total responses         : 5
    Domain name matched     : 5
    Domain & server matched : 5
Cache
    Total entries added     : 2
    Total entries removed   : 1
Usage                       : 1 (10.00%) threshold alarm clear
    Full count              : 0
    Hit count               : 8
    Miss count              : 0
===============================================================================

The preceding output provides additional information about the:

total number of DNS responses that were analyzed (Total responses)
number of times the domain name defined in the DNS match criteria matched a DNS response (Domain name matched)
number of times both the domain name and server address defined in the DNS match criteria matched a DNS response (Domain & server matched)
total number of entries added in the cache (2 in the preceding example)
total number of entries removed from the cache (1 in the preceding example). An entry will be removed from the cache if an internal timer expires. This ensures that the cache does not maintain very old IP addresses, which may no longer be valid. If the IP address is re-learned, the timer will be reset.
successful/unsuccessful IP address lookups in the cache (Hit/Miss count)

If one or more of the preceding values indicates an error, the configuration should be checked. The domain/server configured may not match the hostname requested (for example, the operator configured the domain "*.nokia.com" while the user requested the hostname "*.nokia.co.uk").

The following command shows the created app-filter:

*A:Dut-C# show application-assurance group 1 policy app-filter 61000
                app-filter
                    entry 61000 create (0 flows, 0 B)
                        description "Nokia Web Access "
                        expression 1 http-host eq "*.nokia.com$"
                        server-address eq dns-ip-cache "nokia-cache"
                        application "Nokia NET"
                        no shutdown
                    exit
                exit

The following command shows the AQP used to populate the cache and verifies that traffic is matched.

*A:Dut-C# show application-assurance group 1 policy app-qos-policy 50

===============================================================================
Application QOS Policy Entry 50 (Default Subscriber Policy)
===============================================================================
Description : (Not Specified)
Admin State : in-service
Hits        : 2 flows
Conflicts   : 0 flows

Match :

Action :
    DNS IP Cache                 : nokia-cache
===============================================================================

The Admin State "in-service" indicates that the AQP is in use. If no traffic has matched and the number of hits remains zero, the configuration should be checked.

Tools Commands

The following tools command dumps the initial status of the DNS IP cache (assuming that the server with IP address 192.168.1.100 can be accessed via FTP):

*A:Dut-C# tools dump application-assurance group 1 dns-ip-cache "nokia-cache" 
url ftp://username:password@192.168.1.100/tmp/mylog.log

This command dumps the contents of the cache in a file. Adding a URL is optional; however, for cache tables that contain a large number of entries, it is a better option. The command will generate a text file that contains the following:

=====================================================
Application-Assurance dns-ip-cache "nokia-cache"
Current Time:          "11/08/2017 12:45:32" (UTC)
  group:               1
  isa:                 3/2
  admin state:         no shutdown
  max-entries:         10
=====================================================
ip-address  creationTime(UTC)  lastUpdated(sec)  numDNSResponses   
lastMatchTime(UTC)  numTimesMatched   

Total entries in-use:   0

=====================================================

DNS traffic is generated to populate the cache and HTTP messages are sent to verify that the filter matched correctly. Afterward, the following command is launched to dump the cache.

*A:Dut-C# tools dump application-assurance group 1 dns-ip-cache "nokia-cache" 
url ftp://username:password@192.168.1.100/tmp/mylog.log

=====================================================
Application-Assurance dns-ip-cache "nokia-cache"
Current Time:          "11/13/2017 09:02:25" (UTC)
  group:               1
  isa:                 3/1
  admin state:         no shutdown
  max-entries:         10
=====================================================
ip-address  creationTime(UTC) lastUpdated(sec)  numDNSResponses  lastMatchTime(UTC) 
numTimesMatched     
8.1.17.21  "11/13/2017 08:31:35"  136              4        "11/13/2017 09:00:09"
    7

Total entries in-use:   1
=====================================================

The preceding log shows that the cache entry matched four times (numDNSResponses). Traffic was sent to this address seven times (numTimesMatched).

Conclusion

This chapter describes how an operator can ensure that traffic will match the correct filter and ensure that fraudulent traffic will not be misclassified. By using the DNS IP Cache feature, operators can ensure that traffic will be correctly charged.