Feb 5, 2003 - D.J. Parish, K. Bharadia, A. Larkum, I.W. Phillips and M.A. Oliver. Abstract: Communication networks, including the Internet, support a wide ...
Using packet size distributions to identify real-time netvvorked appIications D.J. Parish, K. Bharadia, A. Larkum, I.W. Phillips and M.A. Oliver
Abstract: Communication networks, including the Internet, support a wide range of packet-based applications. It is often necessary to know what applications are in use. Traditionally, applications were readily identified by inspection of data held in the packet header such as the destination port number. However, newer and real-time applications cannot always be detected by such a simple investigation and hence other techniques such as packet classification or deep packet analysis have been developed. Deep packet analysis however has sigmficant problems such as its inability to operate on encrypted data packets, and its need to capture specific packets from the traffic stream. The paper considers an alternative approach to the detection of real-time applications. A search was made for a statistical fingerprint derivable from the observable traffic streams generated by such applications. This has been found to be the packet size distribution of the application, and the paper considers ths statistic for a range of such applications and network conditions. A detector, based on the described approach, is presented and evaluated using real network traffic.
1
Introduction
It is often necessary to know what actual applications are currently in operation across modern packet based communication networks such as the Internet. Traditional uses for this information include activities such as network management and optimisation. However, new networking paradigms and emerging problems create a further drive for the availability of this information [ 11. Future networks will attempt to support each data stream in an appropriate manner for the application that generates it [2, 31. Active and programmable networks attempt to support application initiated functionality [4] and in certain cases may need to identify a specific application. A further need for this information is in the area of security and fraudulent use detection, where a network operator may wish to be made aware if certain applications are invoked, or even to stop them from operating. In all such cases, an efficient mechanism for the identification of the application generating a traffic stream is required. This problem is further compounded by the fact that a network node may have many independent traffic streams of differing activity rates passing through it at any given time. Each application is represented by a stream of packets which is identifiable at the network and transport layers respectively, by an IP address and a port number. (A unique combination of source and destination IP address and port number will exist for each application connection enabling each independent stream to be separately identified.)
0IEE, 2003 IEE Proceedings online no. 20030411 doi:10.1049/ip-com:20030411
Paper first received 12th October 2002 and in revised form 5th February 2003 D.J. Parish, K. Bharadia, A. Larkum and M.A. Oliver are with the Department of Electronic and Electrical Engineering, Loughborough University, Ashby Road, Loughborough LEI 1 3TU, UK I.W. Phillips is with the Department of Computer Science, Loughborough University, Ashby Road, Loughborough LE11 3TU, UK IEE Proc.-Commun., Vol. 150, No. 4, August 2003
Traditionally, Internet applications have been identifiable by their port number [5], and therefore intercepting the port number held in a packet generated by the application uniquely identified that application. Many such applications use the TCP protocol for their transport layer such as the Web protocol HTTP, which is uniquely identified by the port number 80. Recently, however, there has been a great increase in Internet applications that do not use registered port numbers. In some cases the port number may appear to follow an ad hoc allocation, but this cannot be relied upon to remain static. Many of these applications represent realtime activities such as network games and audiolvideo transfer tools including conferencing. These applications usually use the UDP rather than the TCP protocol in their transport layer, and a means of detecting such applications that is not dependent on unique port numbers is therefore required. This paper will concentrate on UDP-based applications as they tend to be the most damaging to other network users. Non-registered TCP-based applications also exist, but are not considered here. Recent techniques to solve this problem utilise some form of packet classification or ‘deep packet analysis’ [6, 71 as their detection mechanism. In essence, this process involves searching for uniquely identifying information held within the data portion of the packets (i.e. deeper than the headers where the port number and IP address are located). Such techniques require considerable processing and buffer memory [8] as multiple complete datagrams, including data, must be captured, stored and processed for each application stream. Depending upon the exact technique in use, it may also be necessary to capture specific packets generated by the application, for example the first packet in order to effect detection. T h ~ scan be very difficult in situations of high load where packets may be lost by the capturing system unless dedicated hardware is utilised. A further and fundamental problem with deep packet analysis is its inability to operate on encrypted datagrams. Encryption will render the data content unintelligible, although some of the header information may remain in plain text. 221
This paper presents a different approach to the problem of detecting non-registered UDP based applications and is based on packet statistics. The authors have found experimentally that the packet size distribution for many UDP-based applications follows an application specific profile and t h s statistic is now considered as a detection metric. As such, detection is performed on a sample of packets representing a portion of the stream generated by an application, rather than on one, or a small, number of packets as would be the case for packet classification. The technique is therefore directed towards application stream classification, rather than individual packet classification. This means that a delay must be tolerated while the initial sample set is collected, but as real-time applications tend to operate for extended periods of time, this is not seen as a significant drawback.
applications may use registered port numbers and if SO, are better detected by t h s mechanism. The UDP protocol, however, is a true datagram protocol and will simply generate datagrams from the data passed to it. It will not attempt to build up maximally sized packets. As such, a greater variety of packet sizes would be expected. In practice, packets also tend to be relatively small, due to the real-time nature of the applications. Each application may naturally generate different sizes of data due to its specific operation and this characteristic gives rise to the sigmficant variation seen between applications. Also, unlike TCP [9], UDP will not adapt to network state (although the application itself may do so), hence the insensitivity to this characteristic. Some published literature in the area of network measurement suggests that certain packet sizes dominate communication network traffic, e.g. [lo]. Superficially, this would appear to invalidate the work of this paper. However, this not the case as the work of other researchers is based on aggregate traffic flows generated by multiple applications, many of which will use TCP, rather than UDP as their transport protocol. In our work, we are analysing individual UDP-based flows.
2
Packet size distribution for networked applications
It was found by the authors that, for many UDP-based applications, the packet size distribution appears to be fairly insensitive to network state and user setting, yet is very application-dependent.By contrast, the statistic for different TCP-based applications is very similar. The sigmficant difference between UDP- and TCP-based application behaviour is a result of the different transport protocol operations. TCP acts as a streaming protocol when large volumes of data are being transferred. In an ideal situation, the datagrams so generated will be as large as possible, which is typically limited to the mss (maximum segment size) for the subnet. As such, all servers will tend to generate equal-sized packets, regardless of application. In the return direction, minimum-sized acknowledgement packets will be received. It is therefore impossible to determine the application in use by an analysis of the packet size distribution for TCP-based applications such as FTP and HITTP. However, as previously explained, such
Variation of packet size distribution
3
A detailed set of measurements was collected from a representative selection of UDP-based Internet applications including networked games, video streaming tools and audio/video conferencing tools. Traffic samples were captured over a sufficient duration to ensure stable distributions: typically 30 seconds of real-time operation.
3.1
Typical packet size distributions
Fig. 1 shows the packet sue distribution profiles for 4 UDP applications (specifically a network game and three video applications) when operating under ideal network conditions. The dlfference in profile is immediately obvious.
600 E 500
E 1000
3
8x
800
3
400
600
300
400
sE 200
-
b
200 0 1
8
100
15 22 29 36 43 50 57 bin no.
1
8
15 22 29 36 43 50 57 bin no. b
1
8
15 22 29 36 43 50 57 bin no.
a
~~~~~
6 g
9
300
200 100
0
0 1
8
15 22 29 36 43 50 57 bin no. C
d
Fig. 1 Packet size distributions Resolution is 10 bytestbin a Quake2 b iVisit c Realplayer d CuSeeMe 222
IEE Proc,-Commun., Vol. 150, No. 4, August 2003
Similar differences were seen for other applications and it is important to note that some of the video conferencing applications utilise standards-based compression algorithms, yet still yield different packet size distributions.
specific application, whch does not influence the packet size distribution of the main stream.
3.3 Effect of application user settings on the packet size distribution Figs. 3 and 4, respectively, show the effect of user controlled settings on the application packet sue distribution for a network game and a video conferencing tool. In Fig. 3 it is seen that the distribution profile is largely independent of the user-selected connection performance, but the actual number of packets generated in a 30 second capture period is different in each case. (The multiple streams shown in the graphs represent the multiple two-way connections established by the application.) Fig. 4, however, shows that the user setting has an effect on the packet size distribution profile for ths particular application. Very few of the evaluated applications show this effect; however, it must be considered for any practical detector. The effect could be mitigated against by ensuring that multiple distributions for the application when operating under a range of different user settings are
3.2 Effect of network load and loss on the application packet size distribution Fig. 2 shows the effect of varying network state on the packet size distribution for a video streaming application. This was acheved by setting different values of delay and loss probability into a loaded network emulator, and also by adding additional network traffic from a traffic generator. The loading effects represented a range of conditions from a low delay, lightly loaded local network to a heavily loaded, high delay trans-atlantic Internet connection. The packet size is seen to retain a similar distribution regardless of the network state and this observation was similar for other applications. In Figs. 26 and 2c note that a return packet stream appears if the network loading reaches a moderate level. This is a control mechanism used by this
pzq
-
200-
C
$
150-
>,
c
J 100U ??
1
50-
0..
,
,
I
I
-
,
.-.
-
I
MSN-CII
180
oCli-Sw
160
e
140 120 $100 2 80 U E 60 40 20 0
5
-
1 3 5 7 9 1 1 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 bin no. b
. .-
o]il, 1
4
7
10 13 16
I1
,.,_ * y I l , ~ , , , , , , 19 22 25 28 31 34 37 40 43 46 49 bin no.
, , , , , , , , , , , , ,., , , ,
,_)_,
C
Fig. 2 Packet size distributions for Realplayer operating across a loaded network Resolution is 30 bytes/bin a No load b Moderate load c High load IEE Proc.-Commun. Vol. 150, No. 4, August 2003
223
considered. This is acceptable providing the distributions are still sigmficantly different from those of other applications.
5 120 80
5
40
U
s o
1
3
5
7
3.4 Effect of encryption on the packet size distribution Figs. 5 and 6, respectively, show the packet size profiles for a video and an audio conferencing tool when operating in plain and encrypted forms. No significant change has occurred to the distributions as a result of the encryption operation. Even if this were not the case, encrypted and plain profiles could be stored in a practical detector for relevant applications.
9 1 1 13 15 17 19 21 23 25 27 29 bin no. a
1
3
5
7
--" 250 ;200
9 1 1 13 15 17 19 21 23 25 27 29 bin no. b
~. c
5 100 8 5
5
-
5 150
5
100 50
80 60 40 20 0
.="o 1
3
5
7
bin no
9 1 1 13 15 17 19 21 23 25 27 29 bin no.
a
100 c 80 60 U 5 40 = g 20 c - 0
2
C
Fig. 3 Packet size distributionsfor Descent 3 with dgferent user settings Resolution is 10 bytesbin a 28.8 kbits/s
I..
1
b ISDN
I
10 19 28 37 46 55 64 73 82 91 100109118127136145 bin no.
c ADSL
b
Fig. 5 Packet size distribution for VIC application Resolution is 10 bytes/bin
a Unencrypted b Encrytped
~.
ImHstl-Hst2-
c
C
I
8
x
-
I
1
hHstP-Hstl
~
c
JU
E 700
40 20 01 4 i
-e '~~~
=. 10 13 16 19 22 25 28 31 34 37 40 43 46 49 bin no a &
600 500
400
-
g
300 200
100
O
c
1
6 1 1 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 bin no. a
1
6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 bin no. b
3
,o
x 800
C
JU
E 700
100 F 50
2
L
1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49
3
500
400
300
g 200
-
bin no.
b 50 c
$
600
I, ,111
*
100 O
f
3
40
5
20
Fig. 6 Packet size distribution for RAT application
10 0
Resolution is 10 bvtesibin a Unencrypted b ~~~~~~d
8
-
g
I
I
Yl161Z1136145 bin no. C
Fig. 4 Packet size distributions for NetMeeting with three dgferent user quality settings Resolution is 10 bytes/bin a Low quality b Average quality c High quality 224
3.5 Chi-squared ana,ysis of the packet size distribution The quantitative difference between the relevant distributions was investigated using a database of packet size distributions against which new traces of the applications IEE Proc.-Commun., Vol. 150, No. 4,August 2003
Table 1: Results of the chi-squared tests between different application traces App-test
Chi-value
Critical value 50%
Critical value 95%
Next closest
Chi-value
Critical value 50%
Age-o-King
0.002
1.4
0.1
Wolfenstein
30.1
1.4
Descent3
0
2.4
0.4
Wolfenstein
12.4
2.4
NetMeeting
109.8
112.3
89.5
VIC
283
107.3
Realplayer
21.1
23.3
13.9
MonsTMad
120
17.3 2.4
StarCraft
0.002
1.4
0.1
MonsTMad
46
WinMedPlyr
0
0.5
0.004
MonsTMad
70
1.4
Wolfenstein
0
0.5
0.004
Descent3
14
2.4
Cossacks
0.3
2.4
0.4
Age-o-King
94.6
2.4
Forsaken
6.2
6.3
2.2
MonsTMad
49
6.3
FreeTel
0
0.5
0.004
MonsTMad
53
1.4
IntelVP
0
0.5
0.004
MonsTMad
53
1.4
MechWarrior
0
2.4
0.4
MonsTMad
60
3.4
RAT
0
0.5
0.004
MonsTMad
73
1.4
MonsTMad
0
0.5
0.004
Starcraft
47
2.4
MonsTMad
91.2
VIC
51.9
54.3
39
32.3
could be compared. A chi-squared value and critical value for 95% and 50% confidence were calculated for another trace of each application against all the traces held in the database. The results are summarised in Table 1. For each application, the ch-squared value resulting from the computation with the pre-stored trace for that application is shown, along with the corresponding 95% and 50% confidence value. The lowest chi-squared value resulting from the computation with a different application trace is also given, again with the corresponding 50% confidence value. As the calculation ignores packet size probabilities of zero in both data sets, the confidence value varies from application to application. It is seen that, for all the applications shown, the lowest value of chi-squared always occurred when the computation was performed with a trace from the same application. In all but four cases, this value of chi-squared is below the critical value for 95% confidence and, in all cases, below the critical value for 50% confidence. In all cases, the next lowest ch-squared value from a different application is seen to be significantly greater than the first, and much greater than the associated 50% confidence value for ths second choice application. Hence the second choice application must be rejected in favour of the first. All the application traces are uniquely identifiable, and the majority can be considered to be statistically unique for the database. It is impossible to claim that no two applications could ever have identical packet size distributions. However, this has not been found to be the case with the common applications investigated so far. In practice, an operational detector would also have available some additional information such as the relative size of the incoming and outgoing packets streams which would help in identifying broad application classes. Using such additional information, further refinement of an application prediction could be made if required.
algorithm and operating on a processor in a communication network. The issues whch will influence this are:
4 Using the packet size distribution as an application detection metric
4.1 Distribution granularity The effect of varying distribution granularity was observed here. The variation of the SOD for three different granularities -50, 150 and 250 bins is shown in Fig. 7. These typical results are from a network game. It was found
It is now necessary to determine how usable such a statistic will be in practice, i.e. when implemented in a detection IEE Proc.-Commun., Vol. 150, No. 4, August 2003
Processing power and memory requirements; Resolution (distribution granularity) of the stored packet size profiles in the database; and Sampling time for detection traces. The first two are related in that a higher resolution of packet size profile will lead to greater processing and memory. requirements. These issues were investigated using a prototype detector that collected packets from a network connection. These were then separated into individual streams and used to build up a profile of each packet size distribution, which was then compared with stored profiles for a range of applications. Two basic detection mechanisms were used in order to investigate the potential for application detection; one based on the correlation coefficient [l 13, the other using a nearest neighbour analysis based on the Euclidean distance D between the two distributions k and I [12]. De[k 11 =
dn
(X,X,r)2
(1)
i= 1
where De = Euclidean distance between the kth and Ith objects in n-dimensional space, and X , = ith normalised bin value of the kth object. The detector was coded in C and run an a range of Pentium PCs using the Linux operating system with processor speeds from 200 MHz upwards. A success metric, SOD(success of detection) was defined as As SOD = Au where A, = number of successful detection attempts, and A , = total number of detection attempts
225
2 v,
06 04
Corr In1
-r\-
02
. . . . . . . . . . .
0Jd. 1 2 3 4
I
.
. .
x ,
CorrOull
,
5 6 7 8 9 10 11 12 13 14 15 16 17 18
detection attempt a
% v,
1
2
3 4
5 6 7 8 9 10 11 12 13 14 15 16 17 18
detection attempt a
10 08 +NN
06
04 02 0
Out1
I +NN In1
CorrInl
h
-8- NN Oull
1 2 3 4
5 6 7 8 9 10 11 12 13 14 15 16 17 18
detection attempt b
1
2
3 4
5 6
-f--
corr In1
--+-
car, out1
7 8 9 10 11 12 13 14 15 16 17 18
detection attempt b +NN
04
Oull
-CorrInl
02 1
3
5
7
9
11
13
15
17
detection attempt
v)
04
02
C
0
Fig. 7 Success of detection (SOD) plotted against detection attempt for dflerent dktribution granularities (Quake II game) a Distribution granularity= 50 b Distribution granularity= 150 c Distribution granularity= 250
that distributions with 150 bins provided optimum detection performance, although limited performance was found for much smaller bin sizes. The results were obtained using a standard Ethernet network, allowing a maximum packet size of approximately 1500 bytes; hence the profiles need a resolution of 10 bytes per bin. This will impact upon the memory and processing requirements for a practical detector.
4.2 . Effect of detection time on the success ratio The detection process using different capture times was attempted for a range of applications with a distribution granularity of 150 bins. Typical results for three different capture times obtained at each successive detection attempt up to the 18th, are shown in Fig. 8 for the Quake game. These show the detection performance for both the incoming and outgoing packet streams between a local client and an Intemet server with three to five other clients competing in the game. It was found that successful detection was always obtained if the sampling time was at least 30 seconds. In practice, many applications can be successfully detected with shorter sampling times. The requirement is simply for a statistically sigmficant packet size distribution to be captured for each application and t h s is determined by the application packet generation rate. A further implication of t h s is that successful detection does not require every packet in a given stream to be recorded. Successful detection has been achieved based on a random selection of 10% of the packets in a stream if the sampling time is suitably increased. 5
Using the statistical detector
The prototype PC-based detector described in Section 4 was configured to use a distribution bin size of 150, and to attempt application prediction based on successive 30 second traffic traces. It has been evaluated on a range of real networks supporting different mixes of application 226
1
2
3 4
5 6
7 8
9 10 1 1 12 13 14 15 16 17 18
detection attempt C
Fig. 8 Success of detection (SOD) plotted against detection attempt for dfferent sample tunes (distribution granularity= 1 SO, Quake game) a Sample time = 5 s b Sample time = 15s c Sample time = 30 s
traffic. In most cases, SODratios of 1 were obtained, with slightly poorer performance for nearest neighbour detection. Typical results are shown in Table 2. These show the SOD ratio for simultaneous sessions of a Quake game, a video-streaming tool (RealPlayer) and a multicast video application (VIC). Where appropriate, detection on both the incoming and outgoing streams is shown. Table2 SOD for simultaneous sessions of Quake2, R e alplayer and VIC Euclidean detection
Correlation detection
In1
Outl
In1
Outl
RealPlayer
1.00
-
1.oo
Quake II
0.67 1.oo
1.oo
1.oo 1.oo
1.oo -
Application
VIC
-
The detector has recently been deployed on a variety of operational networks in a small company and in educational establishments. A generalised installation is shown in Fig. 9. The detector PC is physically attached to the network at a location where external traffic is concentrated, typically close to the site gateway or router. The detector needs to receive a duplicate of the traffic entering and leaving the site; it does not alter this traffic in any way. This can simply be achieved by connecting a hub or similar device to the connection (as shown in Fig. 9), or by replicating the traffic on a switch (or router) port. The detector process can also be incorporated into the router itself. This has been acheved in practice by running the detector software on a PC-based Linux router. Such a configuration then allows offending connections to be IEE Proc.-Commwz, Vol. 150. No. 4, August 2003
Detector
Fig. 9
Generalised deployment of the detector in a site network
dropped automatically simply by writing rules into the IP routing table. Such a mechanism is an extension to the basic detector process. The detector can be controlled and managed remotely. In the installations studied so far, all management and inspection of detection results was undertaken remotely via a second PC elsewhere using the Internet for communication. 6
Conclusions
This paper has investigated how the packet size statistic can be used as an identification metric for real-time, UDP-based networked applications. These applications are difficult to detect by conventional means, and impossible to detect if the application is encrypted. A study of application packet size distributions has shown the merit of this approach, and a discussion regarding the operation of the UDP protocol has suggested why this should be so. A prototype detector has been evaluated using real network traffic allowing the sampling parameters to be optimised. The merit of the approach lies in its ability to operate on less than ideal traffic. There is no requirement to capture specific packets from a traffic stream, merely a statistically significant sample. Processing is not needed on a per packet basis, as would be the case for conventional packet classification approaches, but only on a sampled set of packets. Significantly, encryption of the stream has no effect on the detection operation, providing the port number is in plaintext. (Even encryption of the port number will not invalidate the basic approach; however, isolation of multiple traffic streams to and from a given IP address may h u t its potential if they are generated by multiple applications.) The main limitation of the approach lies in the possibility that multiple applications may share identical packet size distributions. This was not seen to be the case for the common applications used in the experimental study, but cannot be ignored. If this situation did arise, a number of enhancements may be considered. (i) A subset of the most commonly occurring applications only may be included in the database to h u t the range of
IEE Proc.-Commun.. Vol. 150, No. 4, August 2003
detectable applications if certain applications are known never to operate over a given network segment. (ii) Further information may be used to limit the potential set of applications in whch to search. Such information could include the ratio of the incoming and outgoing traffic rates. This statistic has been seen to be indicative of the general application type (i.e. game, video streaming tool, video conferencing application). (iii) A further analysis of the results of the different detection mechanisms (correlation and nearest neighbour) over multiple sampling periods may be used to increase the SODratio. It may also be argued that a determined user may obscure an application by shaping its traffic profile. However, such a user could also invalidate more traditional detectors by, for example, port spoofing or masquerading (modification of the application specfic data as used in packet classification). As such, the detector described in this paper is no less robust against such attack than other classification mechanisms. 7
Acknowledgment
The authors acknowledge the support of EPSRC for sections of this work. 8
References
1 McKeown, M., and Varghese, G.: ‘Fast IF’ packet forwarding and classification for next generation internet’, IEEE Netw., 2001, 15, (2), PP. 6-7 2 Nirkhe, V., and [Baugher, M.: ‘Quality of service support for networked media players’. Proceedings of COMPCON ’95, 1995, pp. 234248 3 Decasper, D., Dittia, Z., Parullcar, G., and Plattner, B.: ‘Router plugins: a software architecture for next-generation routers’, IEEEI ACM T r m . Netw., 2000, 8, (I), pp. 2-15 4 Legedza, U., Wetherall, D., and Guttag, J.: ‘Improving the performance of distributed applications using active networks’. Proceedings of IEEE INFOCOM, April 1998, pp. 590-599 Gupta, P., and McKeown, N.: ‘Algorithms for packet classification’, IEEE Netw., 2001, 15, (2), pp. 24-32 Gupta, P., and McKeown, N.: ‘Classifying packets using heirarchial intelligent cuttings’, IEEE Micro, 2000, 20, (I), pp. 34-41 Macian, C., and Finthammer, R.: ‘An evaluation of the key design criteria to achieve high update rates in packet classifiers’, IEEE Nefw., 2001, 15, (6), pp. 2429 8 Iyer S., Rao Kompella, R., and Shelat, A.: ‘ClassiPl: an architecture for kist and flexible packet classification’, IEEE Netw., 2001, 15, (2), pp. 33-41 9 Wang, Z . , and Crowcroft, J.: ‘A new congestion control scheme: slow start and search (Tri-S)’,Comput. Commun Rev., 1991,21, (l), pp. 3243 10 Epsilon, R., Ke, J., and Wdliamson, C.: ‘Analysis of ISP IF’/ATM network tr&c measurements’, Perform Evul. Ra?,1999, 27, (2), pp. 15-24 W.: ‘Statistics concepts and applications’ (BenjaminSchefler, 11 Cummings Publishing, Company, 1988) 12 Nadler, M., and Smith, E.: ‘Pattern recognition engineering’ (Wiley, 1993)
221
