4Deep Packet Inspection (DPI) It fails more and more:P2PEncryptionProprietary solutionsMany different flavoursTypical approach:Deep Packet Inspection (DPI)PPLiveBittorrentInternetServiceProvider??Port:Port:?Payload:Payload: “bittorrent”GtalkeMule??Port:Port: 4662/4672Payload:RTP protocolPayload: E4/E5
5Possible Solution: Behavioral Classifier Phase 1Phase 2Phase 3VerifyTraffic(Known)(Training)(Operation)FeatureDecisionStatistical characterization of traffic (given source)Look for the behaviour of unknown traffic and assign the class that better fits itCheck for possible classification mistakes
6Phase 1 : Statistical characterization VerifyTraffic(Known)FeatureDecisionStatistical characterization of bits in a flowc2TestDo NOT look at the SEMANTIC and TIMING… but rather look at the protocol FORMAT
7Chunking and [ ] c c c Expected distribution Observed (uniform) 2Expecteddistribution(uniform)ObserveddistributionUDP headerFirst N payload bytesC chunkseach ofb bitsc21C, … ,Vector of StatisticsThe provides an implicit measure ofentropy or randomness of the payloadc2
14Phase 3 : Performance c Phase 1 Phase 2 Phase 3 VerifyTraffic(Known)FeatureDecisionStatistical characterization of bits in a flowc2TestDecision processMinimum distance / maximum likelihoodPerformance evaluationHow accurate is all this?
15Real traffic traces Internet Training False Negatives False Positives FastwebTraceotherComplementof known traffic1 day long traceRTPeMuleDNS> 90% of tot. volumeOracle(Manual DPI)20 GByte ofUDP trafficKnown + OtherTrainingqKnown TrafficFalse NegativesUnknown trafficFalse Positives
17Results (local) Case A Case B Rtp 0.08 0.23 Edk 13.03 7.97 Dns 6.57 Euclidean DistanceSVMCase ACase BRtp0.080.23Edk13.037.97Dns6.5719.19Case ACase B-0.050.980.540.122.14Known traffic(False Neg.)[%]Case ACase Bother13.617.01Case ACase B-0.18Other(False Pos.)[%]
18Real traffic trace FN are always below 3%!!! RTP errors are oracle mistakes(do not identify RTP v1)DNS errors are due to impure training set(for the oracle all port 53 is DNS traffic)EDK errors are (maybe) Xbox Live(proper training for “other”)FN are alwaysbelow 3%!!!
19P2P-TV applications P2P-TV applications are becoming popular They heavily rely on UDP at the transport protocolThey are based on proprietary protocolsThey are evolving over time very quicklyTot. Vectors% FNJoost335141.9PPLive84452-SopCast844730.1Tvants27184Tot. Vectors% FPOther1.2M0.3
20Pros and Cons KISS is good because… but… Blind approach Completely automatedWorks with many protocolsWorks even with small trainingStatistics can start at any pointRobust w.r.t. packet dropsBypasses some DPI problemsbut…Learn (other) properlyNeeds volumes of trafficMay require memory (for now)Only UDP (for now)Only offline (for now)
21PapersD. Bonfiglio, M. Mellia, M. Meo, D. Rossi, P. Tofanelli “Revealing skype traffic: when randomness plays with you”, ACM SIGCOMM Computer Communication Review "4", Vol. 37, pp , ISSN: , October 2007D. Rossi, M. Mellia, M. Meo, “Following Skype Signaling Footsteps”, IT-NEWS QoS-IP The Fourth International Workshop on QoS in Multiservice IP Networks, Venice, FebbruaryD. Rossi, M. Mellia, M. Meo, “A Detailed Measurement of Skype Network Traffic”, 7th International Workshop on Peer-to-Peer Systems (IPTPS '08), Tampa Bay, Florida, 25-26/2/2008D. Bonfiglio, M. Mellia, M. Meo, N. Ritacca, D. Rossi, “Tracking Down Skype Traffic”, IEEE Infocom, Phoenix, AZ, 15,17 April 2008D.Bonfiglio, A. Finamore, M. Mellia, M. Meo, D. Rossi, “KISS: Stochastic Packet Inspection for UDP Traffic Classification”, submitted to InfoCom09