P2P Plugin Classification and Detection Failure for Application with SSL Flows in ASR5x00

Introduction

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.

Problem

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. A PCAP 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.

Troubleshoot

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

To check the plugin version:

#show plugin p2p
Wednesday July 29 22:12:07 SAST 2015
plugin p2p
  patch-directory /var/opt/lib
  base-directory /lib
  base-version 1.50.52055
  module priority 1 version 1.139.505

Solution

In order to avoid, you need to ensure that the packets before an app (say whatsapp) get marked and must go through. 

Use this ruledef :

ruledef ssl_clienthello
      tcp either-port = 443
      tcp payload-length >= 44
      tcp payload  starts-with hex-signature 16-03
#exit

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.

Sample Configuration

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:

rulebase mbc-internet-rs
action priority 1087 dynamic-only ruledef WhatsApp_P2P_040_400_99999_All_internet charging-action sid_040_rg_400_rate_99999
action priority 1088 dynamic-only ruledef WhatsApp_P2P_040_400_00064_All_internet charging-action sid_040_rg_400_rate_00064
action priority 1089 dynamic-only ruledef WhatsApp_P2P_040_400_00032_All_internet charging-action sid_040_rg_400_rate_00032
action priority [1090-9909] dynamic-only ruledef ssl_clienthello charging-action sid_040_rg_400_rate99999/00064/00032 --> Higher priority than all-ip ruledef and charging action with rating group 400
action priority 9910 dynamic-only ruledef all-ip_004_012_00016_MI_internet charging-action sid_004_rg_012_rate_00016
action priority 9920 dynamic-only ruledef all-ip_004_012_00032_MI_internet charging-action sid_004_rg_012_rate_00032
action priority 9930 dynamic-only ruledef all-ip_004_012_00064_MI_internet charging-action sid_004_rg_012_rate_00064


rulebase mbc-iphone-rs
action priority 1206 dynamic-only ruledef WhatsApp_P2P_040_400_99999_All_iphone charging-action sid_040_rg_400_rate_99999
action priority 1207 dynamic-only ruledef WhatsApp_P2P_040_400_00064_All_iphone charging-action sid_040_rg_400_rate_00064
action priority 1208 dynamic-only ruledef WhatsApp_P2P_040_400_00032_All_iphone charging-action sid_040_rg_400_rate_00032
action priority [1209-8999] dynamic-only ruledef ssl_clienthello charging-action sid_040_rg_400_rate99999/00064/00032 --> Higher priority than all-ip ruledef and charging action with rating group 400
action priority 9000 dynamic-only ruledef all-ip_015_150_00016_ALL_iphone charging-action sid_015_rg_150_rate_00016
action priority 9010 dynamic-only ruledef all-ip_015_150_00032_ALL_iphone charging-action sid_015_rg_150_rate_00032
action priority 9020 dynamic-only ruledef all-ip_015_150_00064_ALL_iphone charging-action sid_015_rg_150_rate_00064
action priority 9030 dynamic-only ruledef all-ip_015_150_99999_ALL_iphone charging-action sid_015_rg_150_rate_99999

charging-action sid_040_rg_400_rate_99999
content-id 400
service-identifier 40
billing-action egcdr
cca charging credit
exit

ruledef ssl_clienthello
tcp either-port = 443
tcp payload-length >= 44
tcp payload  starts-with hex-signature 16-03
exit