MuTriCs: Survey of Traffic Classification Papers
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

 
View only
 
 
Still loading...
ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
AuthorsTitlePublication yearCitations (approx.)Subjective markDistinctive forAdvantagesDisadvantagesOutput level detailDetects unknown?Machine Learning algorithmReal-time classification?Encrypted?Automatic?Network areaTraffic scopeCan work on NetFlow?Required header fieldsTraffic featuresTraining essenceClassification essenceTesting dataset summaryEvaluated trafficPerformancePaper typeMulticlassifier / multilevel?
2
T. Karagiannis, et al.BLINC: Multilevel Traffic Classification in the Dark20057724+ *multilevel approachworks on netflow dataneeds manual and careful training / maintenanceapplication classNot ML
manually derived rules
moderateyesnoedgeall
moderate support for NAT
yesIP: pkt size
TP: ports
social level: remote IPs, IP communities
functional level: numer of source ports
application level: behavior of application
manually create graphlets representative for each traffic typeuse rules, thresholds and heuristics on graphletsabout 3.5TB self-collected; self-made DPIweb, p2p, data, net mgmt, mail, news, chat, streaming, gaming, malware, unknownrecall ~80-%
precision ~90+%
classification methodyes
3
D. Adami, et al.On the Use of Compression Algorithms for the Classification of IP Flows200913+compression used for entropy estimationunidirectional TCP flag sequencepoor performanceapplication protocolNot ML
automatic training of a compression algorithm
rather not, needs sequence of TCP flagsyesyesedgeTCPnoTCP: SYN, ACK, PSH, RST, URG, FINtime-ordered sequence of TCP flags encoded as integer numberautomatically tune compression algorithms with samples of each protocol trafficcompress sequence of TCP flags with compression algorithms tuned for different protocols; choose the one with best compression ratiolittle information; DARPA, Univ. of Pisa, RECIPE programFTP, SSH, SMTP, HTTP, HTTPS, othersunknown, moderate / not badclassification method
4
P. Bermolen, et al.Abacus: Accurate behavioral classification of P2P-TV traffic201075-very detailed performance, portability, and sensitivity analysis; outstanding review of related work; introduction of rejection criterion for detecting unknown trafficsimple, lightweight; works on netflow datalimited to P2P-TV UDPP2P-TV application nameyesSVMyes (under 60s)yesyesedge, adaptable to backboneP2P-TV UDPyesIP: (pkt size)
TP: ports
histogram of number of packets received from each peer in a time window (5s)automatically train SVM basing on traffic samplescreate signatures of incoming traffic and classify using SVM; verify if the distance of signature to the center of training vectors is below rejection threshold R30 testbed peers (26GB of data with ground truth)
<4GB of real traffic without P2P-TV (for False Pos. analysis)
SopCast, TVAnts, PPLive, Joost, others (Skype, eDonkey and DNS)FP 0.1%
TP 95%
classification method
5
G. Aceto, et al.PortLoad: taking the best of two worlds in traffic classification2010133+payload pattern matchingfast implementationneeds payload and manual trainingapplication nameNot ML
optimized pattern matching
yes (on first packet)nonoallallnoIP: direction
payload: 32 bytes
payload patternmanually create signaturesoptimized pattern matching on the beginning of first packet59 GB self-collected; DPI: l7-filter and coral-reef61 applications, 554 signaturesrecall unknown ?,
precision: sessions 75%, bytes 98%
(good for heavy-weight flows)
classification method
6
V. Carela-Espanol, et al.K-Dimensional Trees for Continuous Traffic Classification201045- *optimal k-NN implementationearly identificationrepeating work of Bernaille et al.
using accuracy as the only performance metrics
application nameno?Optimized k-NN
k-dimensional trees
(C++ ANN library)
yes (after a few packets)yesyesedgeallnoIP: direction, size
TP: ports
size of first few packets, relevant port numberstrain k-d treek-NN with O(log N) time complexity<1 TB CoMo-UPC
DPI: L7
12 types of traffic (from TIE)uses only accuracy, which depends on traffic type
avg from 97% down to <10%
classification method
7
A. Este, et al.On-line SVM traffic classification201114high-speed SVM classification through computational optimization and multi-threadsimpleshort, no accuracy evaluated - only speedapplication classSVMyesyesyesedgeallnoIP: packet sizesize of first 4 packetstrain SVM, precompute gaussian kernel valuesoptimized SVMdiverse8 typesnot evaluatedoptimization
8
M. Crotti, et al.Optimizing Statistical Classifiers of Network Traffic201024-research on automatic tuning of classification algorithm parameters (instead of manual tuning)distinctivevery short explanation of optimization procedure, no comment on the "non-linear" optimization of parametersapplication classBayes-likeyes (after a few packets)yesyesedgeallnoIP: packet sizesize of first few (2-3) packetsnon-parametric density estimation using the histogram method; for each class outputs a fingerprint matrix Mchoose the class with the least anomaly score, provided it is less than an acceptance thresholdGT through pattern matching: UNIBS,
GT through port number: LBNL and CAIDA
several traffic typesrecall about 90%
precision about 90%
optimization
9
D. Adami, et al.Skype-Hunter: A real-time system for the detection and classification of Skype traffic201204- *reverse-engineering of Skype protocol, detailedsimple rule-based Skype classifierrigid and limited only to Skype; poor evaluationSkype / not Skype
Signalling / Call
yesNot ML
strict rules
almost, often needs just a few secondsyesN/Aedgeonly Skype TCP/UDPnoIP: size, time
TP: payload
packet size, packet payload (signatures), inter-arrival timeno trainingrule-based decisionDARPA, Tstat Skype testbed, and own dataset (unknown GT tool)mostly Skype + some misleading traffic (P2P, FTP, etc)unknown, rather goodsingle protocol detection
10
M. Dusi, et al.Taking a Peek at Bandwidth Usage on Encrypted Links201104 *rough estimate on the contents of an IPSec tunnel, uniquesimple, regression-based approachshort paper, little information on implementation, quite simple verificationestimate on the amount of traffic for a few application classesRegression treemoderate (after 5/10/15 seconds)yes!yesall, depends on where you train itIPSec, VPN tunnels, probably all kinds of tunnelsnoIP: size, time0) divide transmission into time-windows (5/10/15 s)
1) discretized histogram of packet sizes (two directions)
2) sort of transaction analysis: counts of packets and data length until direction change
train regression tree given ground-truth datain each time-window, measure the features and ask the regression tree on predicted amounts of traffic for each traffic class iself-made with gt (36GB, 10/2009) + self-made with L7 (10GB, 7/2010)web, p2p, mail, remote shell, chat, streaming, otherMAE (mean absolute error) <= 19%, usually betterinferring encrypted tunnels
11
M. Dusi, et al.Tunnel Hunter: Detecting application-layer tunnels with statistical fingerprinting2009115- *detection of HTTP and SSH tunnels, good resultssimplequite verbose article, slow pace of the contentsis tunnel or notyesNot ML
Bayes-like
yes (after a few packets)yesyesedgeHTTP and SSH, can be adapted to DNS and generally TCP, maybe to other TPs as wellnoIP: size, timesize and log10(iat) of first L packets (quanitized values)non-parametric density estimation using the histogram method; for each class outputs a fingerprint matrix Mcompute anomaly score, compare to a thresholdself-made HTTP and SSH traffic (normal and tunnel)SSH, SCP, POP3, SMTP, CHAT, P2P, HTTPaccuracy 82-100%, completeness close to 100%
for multi-class the accuracy and completeness both close to 100%
inferring encrypted tunnels, anomaly detection
12
A. Dainotti, et al.Identification of traffic flows hiding behind TCP port 80201004 *application of a simple classifier ensemble to detecting non-HTTP traffic on TCP port 80simple, fast, interestingrelatively small testing dataset of non-HTTP traffic; not too generalis HTTP or notEnsemble of simple pattern matching + C4.5 decision treeyes (after 4 packets)yesyesedgeHTTP/non-HTTP traffic on TCP port 80, can be adapted to othersnoIP: size, direction
TP: port number
port number (sort of), directions and sizes of first 4 packetsfor each of 4 possible packet direction combinations train a separate C4.5 tree on packet sizesfilter by port + filter by directions + classify on sizesUNIBS, LBNL, CAIDA and UNINA with payload, GT through L7 and gt; small number of non-HTTP trafficHTTP and others on TCP port 80overall accuracy close to 99%simple classification / anomaly detectionyes
13
G. Szabo, et al.Accurate Traffic Classification2007352 *combining many approachesshort, combining mechanism takes votes from the strongest to the weakest elementvery little details on classification submodules (ie. information theoretic, statistics, connection pattern, signature, port); tuning of combining element based on "empirical accuracy" - overtrained?; many hardcoded, custom "heuristics" (explained, though), poor validation, little scientific valueapplication class (fixed)Unknownnoyes?noedgeallnoIP: size, time, ...
TP: port number, payload, ...
many features - connection pattern (BLINC-like), packet statistics, payload signatures, port number (with degree of belief), intra-flow features toounknown, probably hardcodedcustom combination of 6 views on traffic: information-theoretic, statistics, connection pattern, payload signature, port numbers, heuristics5 mobile operators (Europe + Asia), 50000 IPschat, email, filetransfer, p2p, streaming, system, web, tunnelperformance of the combined method not givenclassification methodyes
14
G. Maiolini, et al.Real Time Identification of SSH Encrypted Application Flows by Using Cluster Analysis Techniques200923-application of K-means to inferring SSH tunnelsclassification through clusteringpoor testing dataset (generated artificially), wrong order of sections?, poor description of classification method; the value of K (k-means) searched using brute-force method and fixed for all considered applications; poor English; no CPU performance evaluation; no completeness metricapplication class, in case of SSH also the included applicationk-means clusteringyes (after a few packets)yesyesedgeTCP applications over SSHnoIP: direction, size, timepacket direction, size, and timeself-generated HTTP, FTP-Control, POP3, and SSH tunnels (SCP, SFTP and HTTP)as on the leftavg accuracy without tunnel 94.53%, avg accuracy with SSH tunnel close to 99%; no completeness analysis, which seems to be poorinferring encrypted tunnels
15
A. Dainotti, et al.Early Classification of Network Traffic through Multi-classification201134+ *comparison of 6 combination techniques (on 8 classifiers) to early classification (after few packets)innovative, interestingnot sure about represenativeness of dataset, very short analysis of the impact of selection of classifiers on the performance of an ensemble; sparse performance metrics; the paper is a bit sketchyapplication name / classnoMany ML and non-ML methods combined using 8 differents algorithmsyes (1 pkt=97% accuracy, 2 pkt=98.3%, ...)yesyesedgeallnovariousvariousvariousvariousselfcollected 59 GB (1 day in Oct 2009), 1M flows, gt by L7bittorrent, smtp, skype, pop, http, soulseek, nbns, qq, dns, ssl, rtp, edonkeyvery high accuracy, usually over 98%; recall not givenclassification methodyes
16
G. Munz, et al.TCP Traffic Classification Using Markov Models201095 *successful application of observable Markov model to traffic classificationcomparison to work of Bernaille et al., separate analysis of HTTP Flash video, computationally lightpoor evaluation datasetapplication nameyesObservable, left-right Markov modelyes (after min. 4 packets)yesyesedgeTCP, probably applicable to othersnoIP: direction, position
TCP: length
size of first (3...7) TCP payloads, packet direction and position in streamfor each application, calculate vector of initial probabilities and a transition matrixchoose application with the highest a-posteriori log-likelihood, ie. goodness-of-fit measure of observation to Markov chainself-made, a bit synthetic traces; 300 connections for training, 500 for testingHTTP, IMAP, SMTP, SSH, eDonkey, BitTorrent, Gnutellaaverage (for 7 packets) recall 97.66%, precision 98.03%classification method
17
A. Dainotti, et al.Classification of Network Traffic via Packet-Level Hidden Markov Models2008414+ *application of packet-level HMMnice and cleanlittle too short, no detection of "unknown" traffic, very small dataset of some of the evaluated traffic types, poor validationapplication namenoHidden-Markov Modelmoderate (10+ packets)yesyesedgeallnoIP: time, sizeinter-packet gap (log), packet sizeBaum-Welch training of HMMchoose maximum likelihood (Forward-Backward algo of Rabiner) - no threshold, no "unknown" detectioncampus network, verified with DPI and hand; about 5GB of dataAge of M, CounterStrike, Edonkey, HTTP, MSN, PPlive, SMTPcorrect classification 90% - 100%, poor validationclassification method
18
H. Dahmouni, et al.A Markovian Signature-Based Approach to IP Traffic Classification2007263 *classification by TCP flags; presents a measure of traffic model similarity; mentions weakness of class. basing on statistical traffic propertiesquite simple, details on underlying math. methodsvery weak performance evaluation - just 3 simple protocols, with little practical dataapplication nameyes1st order Markov chainmoderate (tens of packets?)yesyesedgeTCPnoIP: time, direction
TCP: flags
sequence of TCP flags translated into a state of a Markov chainestimate transition probabilities given samples of trafficMaximum-Likelihood and Neyman-Pearson test9256 sessions of HTTP, Telnet and HTTPSHTTP, HTTPS, telnetnot evaluated, at least partially highclassification method
19
I. Bermudez, et al.DNS to the Rescue: Discerning Content and Services in a Tangled Web201205- *usage of passive DNS response sniffing to tagging IP flows and analysis of web traffic belonging to chosen FQDN; interesting analysis of the appspot.com platform; interesting section on dimensioning the DNS resolverinnovative, fresh, interesting, accurately detailed, inspiringpoor coverage on application of DN-Hunter to IP traffic classification, poor analysis of correlation of the durinal patterns in CDNs to simply the effect of greater number of users during evenings; non-comprehensive analysis of alternative usage of TLS handshake phasedomain name related to given traffic flow (eg. facebook.com)N/ANot ML
copy text directly
yes! (before flow starts)yesyesedgeall with a preceding DNS querynoDNS query before packetsDNS query made in a temporal time-window preceding the flowN/A, no trainingquery the DNS resolver using a tuple of {clientIP, serverIP} -> returns the last matching domain name5 diverse, very nice sets from EU and US; total of almost 2 days of traffic, 64M of TCP flowsN/Anot evaluatedaugmenting flow information with domain name / classification feature
20
T. Nguyen, et al.Timely and Continuous Machine-Learning-Based Classification for Interactive IP Traffic201204uses statistics of any N most recent packets in a flow (subflows) - doesn't need full flow stats or the first few packetsreal-time, any-time classification; directional neutralitylittle number of evaluated protocols, poor testing data set; applicability to simultaneous classification of e.g. 8 protocols not evaluatedapplication nameyesNaive Bayes, C4.5yesyesyesbackboneallnoIP: time, direction, sizeinterpacket arrival time, interpacket length variation, IP packet length (min, max, mean, stddev in 2 directions)automatically train the ML algorithm basing on labelled samples; synthetically generate mirror-image replicas for the opposite flow direction and use them to augment the training samples for the same protocolBayes or C4.5 on N packets in a flowtwo month-long traces of ET (2005)
3.4GB of VoIP (mainly G.711, 2007)
background traffic - two days in 2004
online game (FPS, Wolfenstein ET), VoIP (G.711 and GSM codecs)for N=25, 99% precision, 95% recall, under 1sclassification method
21
A. Finamore, et al.KISS: Stochastic Packet Inspection Classifier for UDP Traffic2010225- *cryptanalysis of L7 protocol headerclear, robust, supports packet samplinglimited to UDP, slow, requires packet payload, requires "background" class in order to detect unknown protocolsapplication nameyesSVMmoderate (needs 80 packets)yesyesbackboneUDP, adaptable to TCPnoFirst 12 bytes of the payloadfor 80-packet window - header randomness in first 12 payload bytes (chi-square distance of observed distribution to the uniform distribution for 24 offsets)train SVM, needs "background" traffic for trainingrun SVM (once for each flow)100 GB of real traffic and testbed traffic (P2P-TV, Skype)BitTorrent, eMule, RTCP, RTP, DNS, Skype, Sopcast, TVAnts, PPLive, backgroundaverage TP 99.6%, avg FP <1%classification method
22
S. H. Yeganeh et al.CUTE: Traffic Classification Using TErms201205- *1) automatic DPI term extraction;
2) proof that term order can be neglected if using term weights
nice, simple, and fast; supports packet sampling1) requires access to packet payload (can work without full payload)
2) poor presentation of the experimental results: no table, no confusion matrix, etc.
application nameyes?Not MLyesnoyesbackboneallnoPacket payloadexistence of pre-computed terms in packet payload1) For each protocol, extract all common substrings in packet payloads
2) Compute the frequency of the terms found in payloads
3) Assign a weight to each term so that unique terms get high score, and terms common in all protocols get low score
Search the payload for terms and compute the average weight for each protocol. Choose the class with maximum average weight.Two 30-minute traces from tier-1 ISPs on different continents; each having about 40 million flows. No encrypted flows.AIM, FTP, HTTP, BitTorrent, IMAP, GNUTELLA, RTSP, IRC, SMTP, POP3Both precision and recall >90% for almost all protocolsclassification
Loading...
 
 
 
survey