Taking a Peek at Bandwidth Usage on Encrypted Links

Transcription

1 Taking a Peek at Bandwidth Usage on Encrypted Links Maurizio Dusi, Alice Este, Francesco Gringoli, Luca Salgarelli Università degli Studi di Brescia, via Branze, 38, Brescia, Italy <firstname.lastname>@ing.unibs.it Abstract In this paper we describe a practical yet effective technique to monitor the amount of bytes that several classes of protocols, such as peer-to-peer, , etc., transmit over encrypted virtual links, such as IPSec tunnels. The experiments described in this paper demonstrate that our regression-treebased bandwidth estimator is effective enough to create usage models inherently robust to changes in path, number of users and type of protocols multiplexed over the encrypted link. In other words, our experimental results indicate that training data obtained from a test IPSec tunnel can be successfully used to monitor bandwidth usage on other encrypted tunnels where only the ciphertext is available. I. INTRODUCTION The knowledge of the bandwidth that each protocol class, such as peer-to-peer, , file transfer, voice over IP, etc., occupies on a given Internet link is critical for diagnosing problems, provisioning capacity and detecting breaches in service level agreements. Current traffic monitoring mechanisms that work on port numbers [1], deep packet inspection (DPI) or statistical analysis [2] build such per-class link usage knowledge by keeping track of each traffic flow at the transport layer, calculating per-flow usages, and finally deriving perclass global information by computing the total byte figures. These approaches suffer from two main problems. First, they do not scale well with high-capacity links, because of their computational and memory requirements due to the need of reconstructing each transport layer flow. Second, they cannot be applied to monitoring encrypted (virtual) links, such as IPSec tunnels, where the features required for these approaches to work, such as port numbers, flow identifiers or payload patterns, are not accessible. In a previous work [3], we introduced a coarse statistical classification mechanism, based on regression trees, that can overcome the scalability issues mentioned above. In this work we extend our technique to the case of encrypted traffic aggregates, aiming at a solution to the second issue. The proposed methodology allows regression trees to be trained on a given IPSec tunnel, where monitors can be placed on the point before the aggregate enters the tunnel, and on the tunnel itself, to gather statistical models of the way each traffic class uses that specific encrypted link. We then show experimentally that such models are indeed effective This work was supported in part by a grant from the Italian MIUR, under the PRIN project IMPRESA. for estimating the bandwidth occupied by each traffic class on other encrypted links, for which only the ciphertext is available, with different characteristics from the one used in the training phase. Our experimental results show that the technique works with reasonable accuracy: in case the number of hosts considered during the training and the evaluation phases is comparable, and the traffic classes are similar, the per-class average estimation error is never higher than 19%. Our results support the idea that the model is also robust with respect to the number of hosts who exchange traffic over the encrypted link: the models gathered from the traffic generated by a single user can be used to monitor another tunnel used by multiple hosts. Finally, even when the traffic classes transmitted over the training link are different from the ones supported by the evaluation one, the technique performs with acceptable accuracy. The rest of this paper is organized as follows. In Section II we describe the details of the problem we are trying to solve. We explain the regression tree-based technique at the base of our experiments in Section III. The testbed setup and the traces we captured are described in Section IV. We discuss the experiments and the results in Section V, then in Section VI we validate the results showing the accuracy on a larger dataset. Section VII compares this paper to other related works, while Section VIII concludes the paper. II. PROBLEM STATEMENT In real life, especially when dealing with wide-area networks, one rarely finds themselves in the position to observe both the encrypted traffic being transmitted over a link and the corresponding clear-text portion. More often than not, monitoring equipment can access only the encrypted traffic, in a scenario similar to the BLIND case of Figure 1. In this case, the application of supervised classification techniques to monitor link usage is problematic, since it is not possible to train the system on the clear-text corresponding to the encrypted traffic. In this paper we aim at exploiting the classification technique described in Section III to prove experimentally that a statistical model, gathered on a particular IPSec tunnel, is good enough to evaluate the per-class bandwidth usage of encrypted traffic of other tunnels that connect different networks. On the training tunnel we assume to have full access to the aggregate of the packets before and after the tunnel (in clear

2 1. Set up your own IPsec tunnel access to clear-text and encrypted traces tunnel LAB To the Internet 2. Gather the regression trees of the traffic classes tunnel BLIND access to encrypted traces only 3. Apply the models to the monitoring of another IPsec tunnel Fig. 1. Monitoring encrypted links: a practical scenario. text), as well as the encrypted ones as they are carried by the tunnel. On the contrary, the tunnels we apply the technique to are blind by assumption, i.e., access is granted only to the encrypted packets (Figure 1). An ad-hoc IPSec tunnel named LAB is instantiated between two subnets, connected by the Internet. We collected clear-text and encrypted traffic of a variable number of hosts (from one to a few) that direct their traffic to and from the Internet through the tunnel. Statistical models of the traffic classes are then computed, and they are applied to estimate the link usage by various traffic classes on another tunnel named BLIND, where only encrypted packets are visible. In order to prove that the technique we propose is effective, we have to demonstrate that the models gathered on the LAB tunnel are robust to the following changes: 1) When the characteristics of the networks supporting the two tunnels is different, in terms of path length, type of links, etc. 2) When the number of hosts insisting on the BLIND tunnel differs from the LAB case. 3) When the traffic classes and the amount of traffic each class generates are different in the two cases. III. A REGRESSION-TREE BANDWIDTH ESTIMATOR Here we briefly describe the bandwidth-estimation technique we derived based on regression tree [3], before describing the experiments we performed to validate its use on encrypted links. A. The technique The purpose of our technique is to estimate the percentage of bytes that several application classes (e.g., Web, P2P, Mail, etc.) generate in an observation time interval that we named epoch. By analyzing a vector x of statistical features extracted from each time epoch, our system derives an estimate of the fraction of bytes generated by each class. We apply a regression procedure [4], that requires a training set with associated ground truth, i.e., a set of labeled samples with the fraction of bytes y i of each class i (Web, P2P, etc.), obtained on a given (training) link. The regression procedure adopts a decision tree [5] for each traffic class; decision trees are proven to perform well and with low computation time in regression problems [6]. Another advantage of the decision tree approach is that it automatically discards the less informative features during the training phase (if any). During the training phase, we consider the relationship between each feature vector x and the corresponding groundtruth value y i to train the regression tree of the class i. In this phase we estimate the coefficient of the tree corresponding to each class i: this implies selecting the feature x z and determining the threshold value T z for each node z of the tree. During the evaluation, we measure the feature vector x associated to an epoch and we move from the root to the leaves of the tree we built for the class under consideration. Figure 2 shows an example for the Web class. At each step, the comparison between the value of x z of the evaluated epoch with the corresponding T z states the path to follow to reach the leaf. Once the leaf is reached, the algorithm returns the regression value of x, that is the estimation ŷ i of the portion of traffic of the target class in that epoch. B. Feature extraction From each epoch we measure the following two sets of features: 1) probability mass function (PMF) of the packet size, considering separately the packets transmitted in the two directions. We perform a quantization step on each packet size to the nearest multiple of 8-bytes, thus obtaining a PMF composed of 186 values for each transmission direction 1. 2) statistics (min, max, mean, stddev) related to the number of consecutive packets (and the corresponding amount of bytes), sent in one direction before seeing a packet going in the opposite direction. We collect those statistics for both directions of each traffic aggregate, obtaining 8 features for each direction. 1 In our experiments, the MTU is 1500 bytes while the minimum IP header size is 20 bytes.

3 Fig. 2. x=(x 1,,x i,,x N ) x ρ Regression Tree for the WEB traffic class x ξ <T ξ x ω x v ξ x ε y WEB x ξ T ξ Per-class decision tree algorithm: the example of the Web class. We gather features of type (1) by taking the size and the transmission direction of each packet, independently of the order the packets appeared within the epoch. Intuitively, those features should shed some light on the kind of activities in the epoch: for instance, large packets in both directions may suggest the presence of bulk transmissions. Feature set (2) takes into account the order of the packets and it should help in detecting protocols that generate packets of similar size but transmit them in different time periods of the communication. For each epoch, we extract the feature vector x and the target value y i from the aggregate. The number of elements composing the feature vector is 388, i.e., 372 for feature set (1) and 16 for set (2); y i contains the actual percentage of bytes of the target class i, i.e., the ground-truth of our experiments. Since our regression target is the percentage of traffic, we do not include in the feature set quantities that depend on the number of traffic sources, such as the amount of packets or bytes in the epoch, in order to mitigate the effect of the presence of different number of hosts in each epoch. C. Accuracy measure In regression problems a commonly used accuracy metric is the Mean Absolute Error (MAE) [7], that points out the average distance between the actual and the estimated values for the class i: MAE i = 1 S y ij ŷ ij, (1) S j=1 where S is the number of samples, i.e. the number of epochs, composing the evaluation set. The value of y ij is the actual percentage of bytes of the class i in the epoch j and ŷ ij is the estimated percentage returned by the decision tree trained on the samples of the i-th class. The MAE is expressed in the same units of the measured quantity, that is the percentage of bytes in the epoch. IV. EXPERIMENTS: TESTBED SETUP AND TRAFFIC TRACES A. LAB IPSec tunnel We created the LAB tunnel of Figure 1 between a Dual 2GHz Mac OS X machine in our Faculty s network at Brescia (UniBS) and a 2GHz Linux machine located at the University of Torino (PoliTO), Italy. We setup IPSec with Encapsulating Security Payload (ESP) in tunnel mode, using the KAME [8] x δ x φ implementation. The cipher we used was 3DES in CBC-mode, which means a block size of 8 bytes. We configured a set of five hosts at UniBS, running a mix of operating systems to use that tunnel entry point as default gateway, so that all of their Internet bound traffic, and the return one, would go through the tunnel. The only traffic we excluded from going through the tunnel is the one related to DNS, because making DNS queries go through the long distance link would affect the performance of the local resolvers, thereby introducing delays in how the applications operate. With this single exception, using tcpdump [9] we collected all the TCP and UDP traffic generated by such hosts during a work week on both the inside and outside interfaces of the gateway, obtaining two packet traces: one in clear-text and one encrypted (by IPSec). B. BLIND IPsec tunnel We created the BLIND tunnel of Figure 1 between a different machine inside UniBS (a Dual 2GHz Mac OS X) and an exit point (a 2.4GHz virtual Linux-box machine) located at the University of Rome Tor Vergata (UniROMA), Italy. Except for the different destination, the IPSec configuration was similar to the LAB case. In this case, at UniBS we configured seven hosts of an internal subnet to use the tunnel entry point as default gateway (to the Internet), except for DNS traffic. During the same time period, we collected all packets generated by such hosts on the encrypted link. In order to test the effectiveness of our approach, we also collected the clear-text traffic before it entered the tunnel, but used this information only to verify the accuracy of the estimation process. C. Traffic traces and ground-truth In our experiments, we derived the ground-truth information using gt [10], a publicly available tool that we developed for associating traffic flows with the application that generated them. We installed this software on all the hosts involved in the experiments, and we could therefore assign a reliable class tag to each packet before it entered the tunnel or after it left it. With the gt tag associated to each packet, we were able to calculate the percentage of bytes y i generated by each application class i, before the traffic enters the tunnel, for both the LAB and the BLIND cases. We assume that in each time epoch the aggregate composed of encrypted packets is characterized by the same values y i, i.e., we assume that the delay introduced by the IPSec encryption+encapsulation process is negligible compared to the duration of the epoch 2. We trained the system, building the regression trees describing the traffic classes, using the LAB traces. During the evaluation phase, we then estimated the per-class bandwidth usage of the BLIND IPSec tunnel by observing the properties of the encrypted traffic, i.e., by measuring the feature vectors x on the encrypted packets. 2 We estimated the delay introduced by IPSec in the order of 10ms, while we considered time epochs in the order of seconds.

4 LAB BLIND Class Protocol list Examples of applications 5 hosts 7 hosts 18.2GB 18.0GB Web http, https firefox, iexplorer, safari 16.18% 32.18% P2P edonkey emule, amule, utorrent, bittorrent ktorrent, transmission 1.69% 1.43% pop3, pop3s, thunderbird, evolution, Mail imap, imaps, outlook express, 4.37% 4.89% smtp, smtps mail Remote shell ssh ssh, putty 1.64% 3.38% Chat/ skype skype, msn Call msn pidgin, kopete 5.27% 1.67% sopcast, sopcast, pplive, vlc, Streaming pplive, mediaplayer, realplayer, 68.36% 55.67% rtp, rtps winamp, quicktime Other others ntpd, rdesktop, svn 2.49% 0.78% TABLE I Mean Absolute Error Epoch length 5sec 10 sec 30sec 12.1% 17.0% 13.8% 7.1% 7.9% 5.9% 4.8% 5.3% 7.1% 1.0% 1.1% 1.0% 19.0% 17.4% 15.8% 1.7% 1.5% 1.2% TRAFFIC COMPOSITION AND EXAMPLES OF APPLICATION LABELS OBTAINED BY USING THE gt SOFTWARE (ON THE LEFT). DATASET COMPOSITION OF TRAFFIC COLLECTED ON THE LAB AND BLIND TUNNELS (IN THE MIDDLE). MEAN ABSOLUTE ERROR (MAE) IN ESTIMATING THE AMOUNT OF BYTES COMPOSING THE TARGET CLASS, OBSERVING THE ENCRYPTED AGGREGATES WITH TIME EPOCHS OF 5, 10 AND 30 SEC (ON THE RIGHT). The traces we obtained for both the LAB and the BLIND scenarios contained traffic belonging to the classes outlined in Table I and were collected at the end of October/beginning of November We grouped the protocols in traffic classes according to their purpose: for example, the P2P class includes the file-sharing protocols that hosts on our network used during the experiments (see Table I). In the Other class we inserted all the protocols corresponding to a negligible percentage of bytes and the packets without ground-truth label. Percentage of traffic Web Web estim. Streaming Streaming estim. V. RESULTS Using different numbers of involved hosts and different traffic classes, we developed the following three experiments, designed to mimic the three challenge points we described at the end of Section II. A. Robustness to changes in path In this case the number of hosts sending traffic through the LAB (where training was performed) and BLIND (where we evaluate the technique) tunnels is similar (5 vs. 7). The major difference is represented by the change in path, and therefore characteristics of wide-area links of the two IPSec tunnels. The MAE of the characterization process, i.e., the mean error in identifying the percentage of bytes that a given target class exchanged over the BLIND tunnel is shown in the right part of Table I. We considered different epoch length values when evaluating the technique, ranging from 5 to 30 seconds: given the small subset of involved hosts five and seven hosts, respectively, we opted for epoch length of at least 5 seconds, to make sure that a significant number of packets was present in each epoch. We verified that the estimation performed by the technique was pretty effective when training and evaluation sets came from two separate tunnels: in the worst case, the technique achieved an error of 19% in estimating the Chat/Call class byte portion with an epoch length of 5 seconds. Figure 3 shows how the decision tree approach effectively estimates the behavior in terms of percentage of bytes of the aggregate over time, tracking pretty well what actually happens on the link time [sec] Fig. 3. Representation along a time interval of 5 minutes of the actual percentages of traffic of the classes Web and Streaming and their estimations with an epoch length of 5 seconds. The accuracy of the technique is relatively stable when considering longer time epochs: the mean absolute error in the above worst case improves few percentage points, becoming 15.8% with epochs of 30 seconds. In the case of P2P and Streaming, results also tend to improve moving to longer epochs. We believe that this is related to the statistical behavior of these classes: they are generally responsible for generating long lasting sessions, therefore the technique can better estimate their behavior over longer observation periods. B. Robustness to the number of hosts We further investigated how the technique fares when the number of hosts insisting on the BLIND and LAB tunnels are different. To this end, we captured an additional LAB trace in January 2010, configuring a single host to forward all its traffic towards the LAB tunnel for about two weeks. We ended up with 13.2GB of data, mainly composed of P2P (42%), Streaming (30%) and Web (15%), while Mail, Remote Shell and Chat counted for around 4% each. We then used this single-host trace to gather the regression trees of each traffic class, and then applied such models to estimate the per-class usage of the BLIND trace described earlier (seven hosts). The results of this experiments are shown in Table II and support the idea that, at least for the considered classes of

5 Mean Absolute Error Class Epoch length 5sec 10 sec 30sec Web 17.6% 13.7% 11.8% P2P 15.0% 11.9% 7.1% Mail 5.8% 9.4% 6.7% Remote shell 1.5% 1.6% 1.1% Chat/Call 16.2% 18.5% 15.5% Streaming 3.0% 2.5% 1.7% TABLE II ROBUSTNESS TO THE NUMBER OF HOSTS: MAE. THE TRAINING TRACE (LAB) IS GENERATED BY A SINGLE HOST. BLIND TRACE IS COMPOSED OF THE TRAFFIC OF SEVEN USERS AND IS USED FOR EVALUATION. LAB w/o Streaming, BLIND w/o Web LAB BLIND Mean Absolute Error Class 5 hosts 7 hosts Epoch length 4.6GB 3.1GB 5sec 10 sec 30sec Web 52.91% 3.6% 7.3% 2.9% P2P 4.83% 2.79% 8.1% 6.3% 4.6% Mail 13.01% 9.00% 5.3% 5.1% 4.9% Remote shell 3.35% 2.65% 0.6% 0.6% 0.4% Chat/Call 19.61% 2.02% 35.3% 35.1% 24.2% Streaming 82.76% Other 6.29% 0.78% TABLE III ROBUSTNESS TO CHANGES IN TRAFFIC CLASSES: MAE. DATASET COMPOSITION (LAB DOES NOT INCLUDE STREAMING AND BLIND DOES NOT INCLUDE WEB) AND MAE OF THE REGRESSION-TREE APPROACH. traffic, the technique can perform reasonably well even if the training is carried out on a number of hosts which is different from the number of hosts that insists on the actual encrypted tunnel to monitor: in the worst case, the accuracy lowered by 7.9 point percentages with respect to the case outlined in the previous section. In any case, this is definitely one of the areas where there is ample room for improvement. C. Robustness to changes in traffic classes The third challenge we raised in Section II has to do with the fact that when monitoring a link in the BLIND scenario, one can reasonably assume to know most of the traffic classes that compose it, but not all. In other words, we want to evaluate how the technique is robust to the case when training in the LAB scenario is performed over traffic classes that are (relatively) different from the BLIND one. To this end, we extracted from the LAB dataset of Table I all the epochs that did not include Streaming traffic, and created our models as if during the training we did not configure any host to generate Streaming traffic. In the same way, we extracted from the BLIND dataset all the epochs during which no Web traffic was exchanged. We ended up with a training set different from the evaluation set in terms of classes of traffic. Note that the differences in paths, link types, etc. between the LAB and BLIND tunnel still persist. Table III reports the details of these crippled sets, together with the results we achieved by training and evaluating the technique on them. At a high level, there is a relatively negligible decrease in overall accuracy, with one exception: the majority of the Streaming traffic is labeled as Chat/Call, introducing false positives up to the 35.3% for this class with epochs of 5sec. However, the technique is effective in detecting the absence of the Web traffic: in the worst case, it erroneously detects 7.3% of usage by the Web class. We repeated this type of experiment by selectively removing other traffic classes from the LAB and BLIND traces, obtaining comparable results. Even reducing the training (LAB trace) to the traffic produced by one single host, mimicking what done in Section V-B, does not cause a significant reduction of accuracy in this scenario. VI. DISCUSSION: USING A LARGE DATASET To validate the results we showed in the previous Section we performed further tests on additional larger datasets we collected in June The number of hosts involved in the experiment was 87 for the training set (LAB) and 103 for the testing (BLIND) set. They were users of two disjoint subnetwork of our University transmitting traffic to the Internet through the gateway. Due to the large set of involved users we could not install the gt software on all the hosts. So, differently from the previous traces we derived ground-truth information applying a pattern matching technique [11] on clear-text traces we collected outside the IPSec tunnel. The composition of the datasets we show on the left part of Table IV has relevant differences: the LAB traffic is mostly P2P, while BLIND users were generating large web browsing traffic. In the Table appears also the Network Services class manly composed of DNS packets that in previous experiments did not pass through the tunnel. In this dataset we did not find a significant number of packets carrying Streaming traffic. We redirected the traffic reaching the border gateway sent by two subnetworks of our University to the entry point of an IPSec tunnel. Also the tunnel exit point was located inside our network, so, to collect traces with different tunnel characteristics, we inserted a machine running Dummynet [12] between the tunnel entry and exit points. Dummynet was configured so as to create a 50Mbps link between the entry and exit points for the LAB trace, with a delay of 100ms. For the BLIND trace the bandwidth was set to 90Mbps, with a delay of 50ms. This configuration allowed us to evaluate all three aspects of our technique: robustness to changes in path, number of hosts and traffic composition, obtaining the MAE measurements listed on the right of Table IV. We considered different epoch size values ranging from 0.5 to 5 seconds: considering the large number of involved hosts we opted this time for smaller epoch sizes because even the epochs of 0.5 seconds contains a significant number of packets. We verified that the accuracy of the traffic composition the technique estimates in this case is comparable to the results we discussed in previous Section. In the worst case, the recognition procedure achieved a MAE of 20.3% in estimating the byte portion of P2P class and a MAE of 19.9% evaluating Web class using an epoch of 5 seconds. These two classes represented the predominant traffic but with different percentages in training and testing sets, so they are the most difficult to recognize correctly.

6 LAB BLIND Mean Absolute Error Class 87 hosts 103 hosts Epoch length 2.9GB (1h) 6.7GB (3h) 0.5sec 1sec 5sec Web 31.83% 78.41% 14.6% 15.6% 19.9% P2P 64.70% 18.34% 15.9% 15.5% 20.3% Mail 2.35% 2.30% 6.4% 5.4% 4.5% Remote shell 0.41% 0.00% 0.7% 0.6% 0.8% Chat 0.01% 0.01% 0.1% 0.06% 0.05% Network serv. 0.11% 0.08% 0.3% 0.2% 0.2% Other 0.59% 0.85% TABLE IV ROBUSTNESS TO CHANGES IN PATH, NUMBER OF HOSTS AND TRAFFIC COMPOSITION: MAE. LAB AND BLIND TRACES INCLUDES THE INTERNET TRAFFIC GENERATED BY TWO DISJOINT LARGE SETS OF USERS. VII. RELATED WORK Several works have shown IP-level features to be effective when classifying clear-text flows [13] or encrypted connections that carry a single TCP flow on top of it [14], [15], [16], [17], [18]. However, the informativeness of such features is not clear when considering protocols such as IPSec that multiplex the flows into the same encrypted connection, given that there is no way to reassembly the flows being routed through the IPSec channel without knowing the encryption keys. In [19], Wright et al. considered epochs of artificiallyencrypted traffic composed of TCP packets carrying the same clear-text application protocol and showed that traffic which carries only a single application protocol leaks enough information about the flows to allow them to precisely assess their number, without the need of reassembling the multiplexed flows. We presented a statistical technique, based on regression trees, for coarse identification of traffic aggregates in [3]. There we focused on clear-text aggregates, although we also discussed its potential on encrypted tunnels, showing a preliminary test under the hypothetical assumption of being able to train the system on clear-text traffic before it enters the tunnel. In this paper we get away from that restrictive assumption, and demonstrate experimentally that statistical models (regression trees) built on a given IPSec tunnel can be successfully applied to other tunnels. VIII. CONCLUSIONS AND FUTURE WORK In this paper we described a statistical technique for the coarse estimation of the amount of bytes generated by different traffic classes on an IPSec-encrypted communication link. The approach is based on regression trees, and uses only features derived from the observation of IP packets, without the need to reconstruct each transport-layer connection, making it applicable to monitoring bandwidth usage on encrypted links. To the best of our knowledge, this is the first work that provides results on the effective identification of applications on encrypted channels, using real IPsec traffic traces captured between two live networks for experimental purposes. Our results have several practical implications. They show that it is possible to train a regression-tree based system on a given IPSec tunnel (LAB), where one has full knowledge on the applications that use the channel, and then apply the obtained models to estimate how another tunnel (BLIND) is being used, in terms of application classes, with relatively low error rates. Furthermore, the technique is robust not only to changes in network path, but also to changes to the number of hosts and to the traffic classes insisting on the LAB and BLIND tunnels. ACKNOWLEDGMENTS We thank the group of G. Bianchi, especially F. S. Proto, at the Univ. of Rome Tor Vergata and the group of M. Mellia at the Polytechnic Univ. of Torino for their help in setting up and maintaining the IPSec tunnels used for the experiments described in this paper. REFERENCES [1] D. Moore, K. Keys, R. Koga, E. Lagache, and K. C. Claffy. The Coral- Reef Software Suite as a Tool for System and Network Administrators. In USENIX LISA 01, San Diego, CA, USA, Dec [2] M. Mellia, R. Lo Cigno, and F. Neri. Measuring IP and TCP behavior on edge nodes with Tstat. Elsevier Computer Networks, 47(1):1 21, Jan [3] M. Dusi, A. Este, F. Gringoli, and L. Salgarelli. Coarse Classification of Internet Traffic Aggregates. In Proceedings of the 45th IEEE International Conference on Communications (ICC 2010), Cape Town, South Africa, May [4] I. Witten and E. Frank. Data Mining: Practical Machine Learning Tools and Techniques. Morgan Kaufmann Publishers Inc., San Francisco, USA, [5] L. Breiman, J. Friedman, R. Olshen, and C. Stone. Classification and Regression Trees. Chapman & Hall, New York, [6] C. M. Bishop. Pattern Recognition and Machine Learning (Information Science and Statistics). Springer, 1 edition, Oct [7] M. Kukar I. Kononenko. Machine Learning and Data Mining: Introduction to Principles and Algorithms. Horwood Publishing Limited, [8] The KAME projecy. [9] Tcpdump/Libpcap. [10] F. Gringoli, L. Salgarelli, M. Dusi, N. Cascarano, F. Risso, and K. Claffy. GT: picking up the truth from the ground for Internet traffic. ACM SIGCOMM Computer Communication Review, 39(5):13 18, Oct [11] L7 Filter. [12] M. Carbone and L. Rizzo. Dummynet Revisited. ACM SIGCOMM Computer Communication Review, 40(2):12 20, Apr [13] T. Karagiannis, K. Papagiannaki, and M. Faloutsos. BLINC: multilevel traffic classification in the dark. In ACM SIGCOMM 05, Philadelphia, PA, USA, Aug [14] R. Alshammari and A.N. Zincir-Heywood. Investigating two different approaches for encrypted traffic classification. In Proc. of Privacy, Security and Trust 08, Fredericton, Canada, Oct [15] G. Bissias, M. Liberatore, D. Jensen, and B. N. Levine. Privacy Vulnerabilities in Encrypted HTTP Streams. In Proc. Privacy Enhancing Technologies Workshop (PET 2005), Dubrovnik, Croatia, May [16] M. Dusi, M. Crotti, F. Gringoli, and L. Salgarelli. Tunnel hunter: Detecting application-layer tunnels with statistical fingerprinting. Elsevier Computer Networks, 53(1):81 97, Jan [17] M. Dusi, A. Este, F. Gringoli, and L. Salgarelli. Using GMM and SVM-based Techniques for the Classification of SSH-Encrypted Traffic. In Proceedings of the 44th IEEE International Conference on Communications (ICC 2009), Dresden, Germany, Jun [18] G. Maiolini, A. Baiocchi, A. Iacovazzi, and A. Rizzi. Real Time Identification of SSH Encrypted Application Flows by Using Cluster Analysis Techniques. volume 5550 of Lecture Notes in Computer Science, pages Springer, Jun [19] C. V. Wright, F. Monrose, and G. M. Masson. On Inferring Application Protocol Behaviors in Encrypted Network Traffic. Journal of Machine Learning Research, 7: , Dec