This document describes a specific scenario in which the subscriber uses free-rate applications such as Whatsapp, Snapchat etc. with Secure Sockets Layer (SSL) flows while blocking other user traffic. This particular application runs on Cisco Aggregated Service Routers (ASR) 5x00 series. SSL is a computer networking protocol that manages server authentication, client authentication and encrypted communication between servers and clients.
To detect any app, you need some initial packets for the analysis. These two contradictory requirements are fulfilled to the maximum extent possible.
a) Detection must happen in the first packet itself
b) Detection accuracy must be 100%
If you try to fullfill requirement (a) & mark all the apps in the first packet (that is not practically possible), the requirement (b) on detection accuracy suffers.In order to make the detection accuracy good, you need more packets to analyze lot of apps ( there are apps & flows where the app is detected in the first packet itself). In case of the same app, it can happen that you are able to mark some flows in the first packet itself while other flows of the same app need more packets for analysis.
So if any of app is free-rated while blocking any other traffic, it can happen that the initial packet of the app does not get detected as it does not carry sufficient information. In particular case of apps based on SSL flows, the protocol is marked using either the server-name-indication field present in the client-hello packet or the common-name present in the SSL certificate. As the server-name is optional field, it is not always present. As shown in this image, in a Whatsapp SSL flow, after Three-Way-Handshake (TWH) the client hello packet is sent by the app. APCAP trace showing no Server Name Indication (SNI) field. Also seen are multiple retransmissions of client hello packets that eventually get dropped.
Also, as shown in this image, their are the hex-bytes for the client-hello packet in which the SNI field, used for marking Whatsapp, is not present. Hence, the client-hello packet cannot be marked as Whatsapp and goes undetected. As this packet falls into different rating-group, it gets dropped and hence multiple retransmissions of client-hello packet are seen (see frame no 5449, 5453, 5469). Finally, the connection gets terminated. Several such flows are seen in the pcap. This is the reason that no useful activity, for example the image upload for Whatsapp, can be done.
1. capture monitor subscriber imsi XXXX with following options
19 - User L3
X - PDU Hexdump Verbosity level 5
These commands give the analyser stats for the applications.
# show act analyzer statistics name p2p application snapchat
# show act analyzer statistics name p2p application whatsapp
Any packet, matching the above ruledef, must not be dropped. The priority of this ruledef must be just above the default ruledef (ip-any ruledef) that was matching this packet & causing it to get dropped.
By using this configuration, only the packets matching the above three rule-lines are free-rated. These include only the initial handshake packets in SSL flow (such as client-hello, server-hello) that are allowed using this ruledef, while all other packets in SSL flow do not match this ruledef. Thus, if there is a SSLflow that belongs to some other app (other than whatsapp that you want to free-rate), there cannot be any useful transaction, since only the initial two to three packets of an SSL flow are allowed to use this ruledef.
The suggested ruledef needs to have a higher priority than all-ip_004_012_00016 ruledef (ip any-match = TRUE) and
charging action that allows the traffic similar to whatsapp ruledef.(sid_040_rg_400_rate_99999/sid_040_rg_400_rate_00032/ sid_040_rg_400_rate_00064 with rating-group 400 and any rate).
With this config, the client hello packet hits the proposed ruledef and is allowed rather than being redirected. These are the two rulebases where whatsapp rules are seen: