Application-Level Traffic Monitoring and an Analysis on IP Networks

Transcription

1 Appliction-Level Trffic Monitoring nd n Anlysis on IP Networks Myung-Sup Kim, Young J. Won, nd Jmes Won-Ki Hong Trditionl trffic identifiction methods bsed on wellknown port numbers re not pproprite for the identifiction of new types of Internet pplictions. This pper proposes new method to identify current Internet trffic, which is preliminry but essentil step towrd trffic chrcteriztion. We ctegorized most current network-bsed pplictions into severl clsses ccording to their trffic ptterns. Then, using this ctegoriztion, we developed flow grouping method tht determines the ppliction nme of trffic flows. We hve incorported our method into NG-MON, trffic nlysis system, to nlyze Internet trffic between our enterprise network nd the Internet, nd chrcterized ll the trffic ccording to their ppliction types. Keywords: Pssive trffic monitoring nd nlysis, ppliction-level trffic identifiction, ppliction-level trffic chrcteriztion, Internet trffic, streming trffic, -to- trffic. Mnuscript received Apr. 8, 2004; revised Aug. 10, This work ws in prt supported by the Electricl nd Computer Engineering Division t POSTECH under the BK21 progrm of Ministry of Eduction, nd the Progrm for the Trining of Grdute Students in Regionl Innovtion of Ministry of Commerce, Industry nd Energy of the Koren Government. Myung-Sup Kim (phone: , emil: mount@postech.c.kr), Young J. Won (emil: yjwon@postech.c.kr) nd Jmes Won-Ki Hong (emil: jwkhong@postech.c.kr) re with the DPNM Lbortory, POSTECH, Pohng, Kore. I. Introduction In ddition to the fundmentl nd trditionl purposes of trffic nlysis such s network plnning, network problem detection, nd network usge reporting, trffic monitoring nd nlysis is required in mny res to improve network service qulity such s in bnorml trffic detection nd usge-bsed ccounting. However, to come up with n evolution of the Internet in terms of underlying technologies nd user services, network trffic monitoring nd nlysis techniques should be improved in terms of system rchitecture nd nlysis methodology. Two criticl problems exist in tody s Internet trffic monitoring nd nlysis. The first problem is how to hndle n incresed nd mssive mount of trffic dt generted from high-speed network links, such s 2.5 Gbps nd higher, in rel-time mnner [1]-[5]. The other problem is how to nlyze sophisticted trffic dt generted from vrious newly emerging network-bsed pplictions such s streming medi, -to (P2P), nd gme pplictions [6]-[8]. Regrding the second problem, the types nd ptterns of current network trffic re more complex thn they were in the pst. In the pst network environment, most Internet trffic ws occupied by HTTP, FTP, TELNET, SMTP, nd NNTP. Tody, the proportion of these well-known port-bsed trffic types is decresing. Insted, P2P, streming medi, nd gme trffic re incresing. Internet2 dministrtors report tht bout 4% of the trffic crried by their network is P2P trffic, while further 54% of unidentified trffic most likely belongs to P2P pplictions [9]. The mount of P2P ppliction trffic in mny ISPs is reported to be greter thn 50% of totl trffic [10]-[12]. The difficulty with current trffic nlysis is tht the trditionl method is indequte to nlyze this newly emerging trffic. We need new method to nlyze ppliction trffic. The 22 Myung-Sup Kim et l. ETRI Journl, Volume 27, Number 1, Februry 2005

2 fetures of the newly emerging network-bsed pplictions re s follows: A lrge number of different Internet-bsed pplictions hve been developed nd widely used. The number of these pplictions will increse continuously in the future. Mny new pplictions use proprietry ppliction-lyer protocols. These proprietry protocols re complex nd difficult to understnd in terms of formt nd opertion. Some pplictions such s KZA [13], [14] encrypt the dt flowing into the network to hide their behvior nd protect their systems from potentil security ttcks. The port numbers used by these pplictions re irregulr. Most internet pplictions use ephemerl port numbers greter thn 1024 s defult ppliction port. As of Jnury 2003, the proportion of TCP trffic using ephemerl ports is more thn 40% of the totl TCP trffic t lrge ISP bckbone network [11]. In our investigtion, the number of TCP sessions using ephemerl ports s server port is more thn 50% of the totl TCP sessions in the POSTECH cmpus network. The defult port numbers for mny pplictions re not registered on the IANA port list [15]. However, the developers of pplictions for regionl users usully do not register their port numbers to IANA. The topologicl ppliction rchitecture is shifting from the trditionl client/server model to P2P communiction model. Most P2P pplictions cn directly trnsfer dt to other s. The overly networks constructed by these pplictions re complex. Most newly emerging pplictions use multiple sessions to communicte with ech other. For exmple, streming medi pplictions estblish two or more sessions to trnsfer control dt nd multimedi dt. Sometimes they use both the trnsmission control protocol (TCP) nd user dtgrm protocol (UDP) simultneously. Mny P2P nd streming medi pplictions use dynmiclly determined ports to communicte between s. In the cse of streming medi trffic, the port number nd protocol for the delivery of multimedi dt re decided by the negotition between the client nd server. The port number for file trnsfer in the MSN instnt messging ppliction is lso determined dynmiclly. Some of them use dynmic port numbers to evde detection nd control [7], [8]. All of the bove fetures of the current pplictions mke it difficult to nlyze Internet trffic t the ppliction level. The ppliction-level trffic identifiction is fundmentl nd significnt step towrds the proper nlysis of ppliction-lyer trffic. The ppliction-level trffic chrcteriztion is nother chllenging re of trffic nlysis. Thus, this pper focuses on ppliction-level trffic identifiction nd chrcteriztion. We concentrted on the following two crucil questions. How cn we identify individul pplictions from IP trffic? And, wht re the chrcteristics of the current IP trffic t the ppliction level? Trditionl trffic identifiction methods, bsed on wellknown port numbers nd the IANA port list, re not suitble for determining the trffic from P2P, streming, nd other new pplictions. This pper proposes noble method to identify the recent Internet trffic. First, we ctegorize most of the current network-bsed pplictions into severl clsses ccording to their trffic ptterns. Using this ctegoriztion, we developed new method clled flow-grouping, which determines the ppliction nme of individul pckets. The flow-grouping method consists of three steps. The first step is to build the ppliction port tble (APT) by n exhustive off-line serch of pplictions. The second step is the importnt port selection (IPS) from ech flow record. It determines the importnt port number between source nd destintion port numbers in ech flow record. The third step is the flow reltionship mp (FRM), which ggregtes flows ccording to their inter-dependency nd decides corresponding ppliction nme to ech flow. To vlidte the proposed lgorithm, we hve designed nd implemented trffic nlysis system, clled NG-MON [1]. NG-MON is currently deployed t the Internet junction of POSTECH nd provides us with importnt chrcteristics of Internet trffic cptured between our cmpus nd the Internet. The orgniztion of this pper is s follows. Section II describes previous pproches on the identifiction nd chrcteriztion of Internet trffic nd explins their dvntges nd disdvntges. In section III, we present our trffic identifiction method. Section IV ddresses the design nd implementtion issues of our prototype system. In section V, we describe the deployment of the proposed method nd summrize the Internet trffic chrcteristics s n nlysis result. Finlly, section VI concludes the pper with possible future work. II. Relted Work In this section, we describe relted reserch work on ppliction-level trffic identifiction. We lso introduce some reserch results bout recent Internet trffic chrcteristics. 1. Appliction-Level Trffic Identifiction We consider two steps to determine the originl ppliction nme of individul pckets. The first step is to decide the importnt port number between source port nd destintion port. Most trditionl Internet-bsed pplictions such s WWW, FTP, nd Telnet use well-known port tht is below This simplifies determining the importnt port for pckets with port number below However, most newly ETRI Journl, Volume 27, Number 1, Februry 2005 Myung-Sup Kim et l. 23

3 emerging Internet-bsed pplictions use ports greter thn 1024 s defult port for communiction. It is not esy to decide n importnt port for pckets tht hve both ports over 1024 nd belong to these new pplictions. The second step is the ctul decision of the ppliction nme from the pool of selected importnt port numbers. In this step, the dynmiclly negotited port number of newly emerging pplictions nd the lrge number of Internet-bsed pplictions re two criticl problems. The following is some relted work on the identifiction of ppliction level trffic. A. Trditionl Appliction-Level Trffic Identifiction Method The trditionl method is bsed on the well-known ports registered to the IANA port list [15]. For exmple, the web trffic cused by web client/server pplictions uses port numbers 80, 8080, or 443. In the trditionl method, the importnt port is the port less thn 1024 or the port tht ppers in the IANA port list. By this well-known port, we cn esily determine the corresponding ppliction nme. Just few yers go, this technique ws sufficient enough to identify most Internet trffic. However, we cnnot rely on this method ny more becuse of the mny new fetures in recent Internet trffic. For exmple, this method cnnot detect the dynmic port numbers generted by streming medi pplictions such s Microsoft Windows Medi Server/Plyer [16]. The trditionl method lso cnnot distinguish the trffic between two different pplictions using the sme port numbers simultneously. If the trget port number is not present in the IANA port number list, then this method is simply not pplicble. B. Pylod-Exmintion-Bsed Method To detect the dynmiclly determined ports of streming medi pplictions nd P2P pplictions, the pylod exmintion method is one possibility. The tools mmdump [17] nd SM-MON [7], [8] used this method to differentite streming medi trffic from other Internet trffic. In streming medi service, two types of sessions re estblished between the client nd server: control session nd dt session. The port number of the dt session is determined dynmiclly by the negotition between the client nd server using the pre-estblished control session. In ddition, it is lso useful to detect dt session of pssive FTP trffic tht shres similr fshion with streming medi. This method provides high ccurcy for the identifiction of streming trffic. However, it cuses dditionl system overhed for the inspection of pylod dt becuse the lod of cpture system is proportionl to the number of cptured pckets nd the snpshot size copied into the user-level. When the port number of the control session is chnged, this method is no longer effective. When the control session dt is encrypted, s with the KZA P2P ppliction, pylod inspection is lso not possible. To identity ll Internet trffic using this method, we should know every single detil of ll ppliction-lyer protocols; nevertheless, we believe this is impossible. C. Signture-Mpping-Bsed Method To increse identifiction ccurcy, the signture-mppingbsed method [18], [19] ws introduced. In this method, portion of pylod dt tht is sttic, unique, nd distinguishble from other pckets is exmined for ll pplictions regrdless of the protocol they re using. This portion of pylod dt is decided s signtures of those pplictions. By compring every pcket pylod with predetermined signtures, this method cn identify ppliction trffic more ccurtely thn the trditionl method. However, it requires lrge mount of offline work to discover the signtures of individul pplictions. It my be esy to determine the signture of the pplictions using stndrd nd open protocols such s HTTP nd FTP. Tody, the number of network-bsed pplictions is lrge nd incresing rpidly, nd mny use their own proprietry protocols. It is more difficult to exmine the signture of these proprietry pplictions. This method might lso cuse greter system overhed in the process of pcket cpture nd pylod comprison. However, some reserches [18] hve high hope to overcome such limittions, nd they re ctively exploring more dvnced techniques in signture mpping. D. Methods Used for P2P Trffic Identifiction The recent tendency in Internet trffic is shift from web trffic to P2P trffic. Mny studies focus on the chrcteriztion of P2P trffic [10]-[14]. The first step of ll these studies is to determine the P2P ppliction trffic from the entire rnge of network trffic. The technique used in this first step ws the trditionl method using corresponding defult port numbers for P2P pplictions, such s TCP port 6346/6347 (Gnutell), 1214 (FstTrck), nd 411/412 (DirectConnect) [10]. A reserch on Internet content delivery systems lso distinguished trffic type by the defult port numbers of ech ppliction nd the server IPs providing the corresponding services [19]. However, new versions of the KZA system do not use defult port number (1214) ny longer. They use dynmiclly ssigned port numbers to trnsfer dt between s. Furthermore, the port number used for file trnsfer between s in the MSN messenger ppliction chnged from fixed port (6981) to dynmic port. Recent reserch [11] finlly gve up identifying the trffic ccording to ppliction. Insted, 24 Myung-Sup Kim et l. ETRI Journl, Volume 27, Number 1, Februry 2005

4 they proposed new trffic type, clled TCP-Big, which is the ggregtion of unknown flows tht trnsmit more thn 100 KB in less thn 30 minutes. They showed tht the TCP-Big trffic hd lmost the sme properties s P2P trffic. 2. Trffic Chrcteriztion of Recent Internet Trffic In this section, we present some relted studies on trffic chrcteriztion. Mny recent studies ddressed the IP trffic chrcteriztion. They collected nd nlyzed the IP trffic from n enterprise network [20] or lrge ISP bckbone network [21]. They focused on trffic chrcteristics from vrious perspectives, such s user perspective chrcteristics, pcket-level nd flow-level fetures [21], [22], routing protocol-level behviors [23], nd so on. Concerning ppliction-lyer trffic chrcteriztion, sizble mount of recent studies concentrtes on P2P trffic. A number of recent studies [10], [24]-[30] contributed to scertin the nture of P2P trffic, prticulrly the trffic generted by FstTrck (KZA, KZA Lite), Gnutell (Morpheus, LimeWire, etc), nd Overnet (edonkey) tht genertes significnt shre of Internet trffic. Other reserch [11], [12] focused on the comprison of P2P trffic with other trditionl Internet trffic, such s WWW nd FTP. A study [10] used TCP flow-level dt gthered from multiple routers cross lrge Tier-1 ISP to nlyze three P2P pplictions: KZA, Gnutell nd DirectConnect. While this dt does not revel ppliction level detils nd insights explining the observed behvior, it is n importnt step in chrcterizing these pplictions from network engineering perspective. For exmple, the study found tht lthough the distribution of generted P2P trffic volume is highly skewed t the individul host level, the frction of the trffic contributed by ech network prefix remins reltively unchnged over long time intervls. Two recent studies [12], [13] considered tht, lthough KZA s protocol (FstTrck) is proprietry, KZA uses HTTP to trnsfer dt files, enbling this trffic to be logged nd cched. Both these studies monitor HTTP trffic on costly links: trffic from lrge Isreli ISP to the US nd Europe [13], or from the University of Wshington cmpus to its ISP [12]. They reported tht KZA trffic constitutes the most Internet trffic nd tiny number of files generte most of the downlod ctivities. They lso suggested the fesibility of trffic cching, nd empiriclly demonstrted its benefits. Furthermore, they compred KZA trffic with trffic generted by trditionl content distribution systems, such s Akmi nd web trffic [13]. They quntified the rpidly incresing importnce of P2P trffic, chrcterized the behvior of these systems from the perspectives of clients, objects, nd servers, nd derived implictions for cching. The chrcteriztion of current Internet trffic in this pper is n expnsion of the results of the recent studies. While the bsic chrcteristics of these previous studies remin vlid for our study, we investigte new spects of the current trffic in the ppliction lyer. III. Appliction-Level Trffic Identifiction In this section, we propose new method to identify Internet trffic type in the ppliction level, which suits current sophisticted Internet trffic. First, we investigte the communiction behvior of current Internet pplictions nd then clssify them ccordingly. Second, we present the proposed method for identifiction of Internet trffic bsed on this clssifiction. 1. Communiction Behvior of Internet Applictions The communiction behvior of current Internet-bsed pplictions is very complex. Trditionl client/server-bsed pplictions, such s web, telnet, nntp, nd smtp pplictions, usully use single TCP or UDP session with fixed port number to communicte with ech other. However, newly emerging Internet-bsed pplictions use multiple sessions with dynmic ports, which mkes trffic identifiction more difficult. In this section, we exmine the communiction behvior of recent Internet-bsed pplictions nd ctegorize them from this perspective. Tble 1 shows list of current Internet-bsed pplictions tht generte the most Internet trffic. We ctegorized these pplictions ccording to their service type nd protocol. The trditionl pplictions use stndrd nd open protocols tht simplify identifiction of their trffic. The others re newly emerging pplictions tht begn few yers go. The ppliction lyer protocols RTSP, SIP, Q.931, nd H.245 re Type Trditionl Streming medi P2P Gme Internet disk Tble 1. Current Internet-bsed pplictions. Applictions / Appliction lyer protocol http, https, ftp, telnet, ssh, nntp, dns, smtp, pop3, timed, etc. rtsp, sip, mms, rtp/rtcp, rdt, mmsu/mmst, q.931, h.245, etc. Gnutell, FstTrck, Overnet, Directconnect, MSN Messenger, etc. Strcrft, Wrcrft, Diblo, Counter Strike, etc. popdesk, internetdisk, webhrd, woorihrd, coolhrd, etc. ETRI Journl, Volume 27, Number 1, Februry 2005 Myung-Sup Kim et l. 25

5 Tble 2. Clssifiction of communiction behviors. Type Session Port Hosts Exmple Type S-F-2 Single Fixed Between two Web, telnet, ssh, smtp, snmp, nntp Type M-F-2 Multiple Fixed Between two Active mode FTP Type M-D-2 Multiple Dynmic Between two Pssive mode FTP Streming pplictions (Quicktime) Type M-F-3 Multiple Fixed Three or more Instnt messging P2P ppliction (Soribd) File shring P2P (Gnutell, DirectConnect) Gme ppliction (Strcrft, Diblo) Type M-D-3 Multiple Dynmic Three or more Instnt messging P2P (MSN messenger) File shring P2P (Kz, Kz Lite) Gme ppliction (Counter-Strike) Internet disk (popdisk, webhrd) used to deliver control dt between streming server nd client. Protocols RTP/RTCP nd MMSU/MMST re used to trnsfer multimedi dt from server to client. The Quicktime nd Rel Networks streming services use open protocols clled RTSP nd RTP/RTCP. However, the Microsoft windows medi service [16] uses proprietry protocol, MMS. The most populr -to- pplictions re file shring pplictions, such s Fsttrck (KZA, KZA Lite) [13], Gnutell (BerShre, Bnucleus, Morpheus, LimeWire) [28], nd instnt messging pplictions (MSN messenger, etc.). Mny gme pplictions use network to mke multi-user gmes interctive. In ddition, Internet disk service provides nother type of file shring method. The service provider constructs lrge file server t Internet dt centers (IDC). A user cn use portion of the disk spce nd shre it with other users by pying fee. We investigted the communiction behvior nd port numbers used by these widely deployed pplictions from the trffic monitoring nd nlysis perspective. We selected more thn 100 populr pplictions on our cmpus network nd instlled them in severl systems. We cptured ll the pckets generted by these pplictions in ech end system using etherel nd tcpdump nd exmined their behviors, especilly the source nd destintion port numbers, IP ddresses, the direction of trnsferred dt, nd the number of estblished sessions. From the investigtion of ech ppliction, we ctegorized the communiction behvior into five types s shown in Tble 2. We used three types of informtion to ctegorize the communiction behviors: the number of sessions mong the involved systems, the wy of selecting port number, nd the number of involved systems to provide service. We describe the detils of ech type below. A. Type S-F-2 Type S-F-2 is the communiction behvior of most trditionl Internet-bsed pplictions, such s web, telnet, ssh, smtp, etc. The communiction structure is client/server rchitecture nd uses well-known single fixed port number. In Type S-F-2, server cn simultneously communicte to multiple clients. However, these communictions re independent of ech other from the client s perspective. No communiction occurs between clients; insted, dt re trnsferred only between client nd server. Trffic of this type is esily determined. The port number used by ech ppliction is clue for ppliction identifiction: 80 for http, 23 for telnet, 22 for ssh, 25 for smtp, nd so forth. B. Type M-F-2 The FTP communiction in ctive mode is good exmple of type M-F-2. The FTP service use two different sessions: control session nd dt session. In ctive mode FTP, the fixed well-known port number 21 is used for the control session. The FTP service uses port number 20 to trnsfer dt. The identifiction of this type is the sme s the previous type S-F-2. Pckets with port number 21 re FTP control pckets. Pckets with port number 20 re FTP dt pckets if nd only if TCP session with port number 21 simultneously ppers between the sme two hosts. We cn use the IANA port list to determine this type of trffic. For exmple, the RelVNC ppliction uses port numbers 5800 nd 5900, while MS-SQL pplictions use port numbers 1433 nd C. Type M-D-2 This type of communiction behvior uses multiple sessions between two hosts like type M-F-2. However, the port numbers for one or more sessions re dynmiclly determined by the negotition between two involved hosts. The best exmples of this type of communiction re FTP trffic in pssive mode nd streming medi trffic. The dynmiclly generted session cn use TCP or UDP ccording to the 26 Myung-Sup Kim et l. ETRI Journl, Volume 27, Number 1, Februry 2005

6 pplictions. Typiclly, streming medi pplictions use UDP sessions to deliver multimedi dt from medi server to client. The identifiction of the dynmic session of this type is complex. We cn use the pylod exmintion method used in mmdump [17] nd SM-MON [7], [8]. Otherwise, we cn consider heuristic method such s Flowscn [31], flowbsed trffic nlysis system. D. Type M-F-3 Mny new pplictions use multiple sessions nd communicte with multiple s simultneously. P2P file shring pplictions, P2P instnt messging pplictions, nd gme pplictions re the best exmples. Figure 1 illustrtes two prevlent types of P2P communiction rchitectures used by these pplictions: the centrl rbiter type nd the pure distributed type. As illustrted in Figure 1, communictes with other s or centrl servers simultneously, which estblishes multiple sessions. Some P2P pplictions nd gme pplictions use fixed port numbers for these multiple sessions nd both TCP nd UDP. This type of communiction is derived from the behvior of these pplictions. The multiple sessions with fixed port numbers mong mny s re fetures of this type of communiction. Although multiple sessions re involved, the use of fixed port numbers mkes the determintion of this type M-F-3 trffic strightforwrd. E. Type M-D-3 The erly versions of the MSN messenger ppliction used server ) Centrl rbiter type b) Pure distributed type Fig. 1. Peer-to- communiction rchitecture. fixed port number to trnsfer files between s, TCP port number However, the ltest version of MSN messenger (version 6.1) uses dynmiclly ssigned port number for file trnsfers. In ddition, the erlier version of KZA [13] used port number 1214 for dt trnsfers, but the ltest version of KZA cn llocte the server port number dynmiclly s needed. In this type of communiction behvior, single host estblishes multiple sessions with more thn three s. Some of those sessions re estblished using dynmiclly determined port numbers. Mny P2P pplictions nd gme pplictions re developed using this communiction type. The trffic type M-D-3 is the most difficult to identify. Therefore, we need n intelligent nd efficient method to identify Internet trffic t the ppliction level. The communiction behvior of mny Internet-bsed pplictions is shifting from type M-F-3 to type M-D-3. One min reson for this migrtion is to evde detection nd control. 2. Trffic Identifiction Method Using Flow Grouping In this section, we present our proposed method for Internet trffic identifiction. The min ide of the proposed method is s follows. We determine dependencies mong flows tht re generted by the sme pplictions, nd group the flows ccording to their corresponding pplictions. For exmple, web trffic (type S-F-2) typiclly uses port number 80 or 8080 for HTTP nd 443 for HTTPS s the defult port number. Type M- F-2 trffic cn be esily grouped ccording to their defult port numbers. However, in the cse of type M-D-3 trffic (ex., P2P trffic), flow grouping is not s simple s web trffic becuse they use port numbers greter thn 1024 nd mny port numbers re dynmiclly ssigned. If ll Internet trffic cn be grouped ccording to their pplictions, then Internet trffic nlysis nd chrcteriztion cn be performed with high ccurcy. Our proposed method consists of three steps, s illustrted in Fig. 2. These three steps implement the ppliction port tble (APT), importnt port selection (IPS), nd flow reltionship mp (FRM), respectively In our proposed method, we do not exmine the pylod of ech pcket. Insted, we use only the pcket heder informtion fter ggregting them into flows, s described in section II. The first step of the proposed method is to construct n APT. The APT is constructed by n exhustive off-line serch of ech ppliction using pcket nlysis tools. The APT contins the ppliction nme, its frequently used port numbers excluding the dynmiclly ssigned port numbers, nd trnsport-lyer protocol numbers. This informtion is used to decide the ppliction nme of ech flow in the FRM step. The second step is IPS. The input of IPS my either be rw pcket or flow dt. The outputs of IPS re flow dt nd ETRI Journl, Volume 27, Number 1, Februry 2005 Myung-Sup Kim et l. 27

7 3. Appliction Port Tble Unidentified trffic (rw pckets, flows) IPS Importnt port selection APT Appliction port tble Flow info. Importnt port info. FRM Flow reltionship mp Appliction-port info. Communiction type info. Identified trffic (flows) Fig. 2. Overll process of the trffic identifiction method. importnt port informtion. In this step, the flow informtion is generted from the cptured pckets ccording to their 5-tuple informtion: source IP ddress, destintion IP ddress, source port, destintion port, nd protocol. Then, we select the importnt port number from the flow informtion for TCP flows. Becuse both source nd destintion port numbers of most flows exceed 1024, it is necessry to distinguish the importnt port to decide the corresponding ppliction nme correctly. The third step is to construct the FRM. The flow dt, the output from the IPS, is the input into the FRM. The FRM groups flows ccording to their reltionships nd mrks flows with the corresponding ppliction nme. Most of the newly emerging pplictions use multiple connections with single or multiple (s) to perform vrious functions; therefore, it is possible to discover the reltionship mong flows tht belong to the sme ppliction. Using this dependency informtion, we clssify flows into number of groups. For exmple, the flows cused by MSN messenger pplictions re destined to belong to single group by the FRM. After this grouping process, the FRM determines the ppliction nme of ech flow group using APT informtion. The first step of the proposed method is to construct n APT. To decide the ppliction nme from cptured flow informtion, we perform the preliminry exmintion of the communiction behviors for widely used pplictions. We determine the nme, defult port number, trnsport protocol, nd communiction type of these pplictions. For n exhustive serch of pplictions, we used pcket nlysis tools such s tcpdump nd etherel. Using this investigtion, we construct n APT tht contins the informtion bout ech ppliction. The APT contins the ppliction nme, frequently used TCP/UDP port numbers, one representtive port number, nd its communiction type. The APT is n extension of the IANA port list contining dditionl informtion. We exmined more thn 100 populr pplictions nd constructed n APT, smll portion of which is shown in Tble 3. We lso record the communiction type of ech ppliction ccording to the clssifiction in Tble 2. We use this communiction-type informtion in the FRM process to finlize the grouping of flows. We select one port number s the representtive port of ech ppliction mong the frequently used port numbers. Even though n ppliction my use both TCP nd UDP long with mny different port numbers, only one representtive port number is ssigned to one ppliction. This representtive port number is used to indicte the group of flows. 4. Importnt Port Selection In this section, we describe the proposed lgorithm to select the importnt port number mong source nd destintion port numbers in ech flow dt. The importnt port number is the Tble 3. An exmple of n ppliction port tble. Appliction nme Representtive port TCP well-known ports UDP well-known ports Communiction type WWW 80 80, 8080, 443 Type S-F-2 FTP 21 20, 21 Type M-D-2 MSN Messenger , , Type M-D-3 Windows Medi Type M-D-2 KZA Type M-D-3 Soribd* , 7675, 7676, , 7674 Type M-F-3 edonkey , 4662, 6667 Type M-D-3 V-shre* , 8404 Type M-D-3 Shreshre* , 6733, 6777 Type M-D-3 *Applictions trgeting regionl users (e.g., users in Kore) 28 Myung-Sup Kim et l. ETRI Journl, Volume 27, Number 1, Februry 2005

8 Client (rndom port) (ctive open) SYN_SENT ESTABLISHED CLOSED SYN SYN-ACK ACK FIN FIN Server (listening port) listening (pssive open) SYN_RCVD ESTABLISHED CLOSED Fig. 3. TCP communiction sequence. connection estblishment 3-wy hndshking dt trnsfer connection termintion port number tht is necessry for trffic identifiction. The proposed IPS lgorithm considers only TCP flows. Figure 3 demonstrtes norml TCP communiction sequence. To estblish connection between client nd server, 3-wy hndshking mechnism is pplied. To terminte the connection, FIN pckets re sent to ech other. In TCP communiction, the server opens port nd wits for client connection request. The server listening port is the importnt port for identifying TCP trffic. How cn we select the server listening port from the cptured flow informtion? First, we utilize SYN nd SYN-ACK pckets tken from the 3-wy hndshking opertion. The destintion port in SYN pcket nd the source port in SYN-ACK pcket re the server listening port. Using this, we cn determine the importnt port number from ll TCP flows. It is importnt to check both the SYN pcket nd SYN-ACK pcket becuse in rel Internet environment the SYN pckets without SYN-ACK pckets re cptured frequently. Therefore, the preliminry step of IPS is to determine whether flow hs corresponding reverse flow. In deciding the importnt port number, we exclude flows tht do not hve corresponding reverse flows. To improve the performnce of the IPS lgorithm, we use the fct tht no system uses port numbers below 1024 s rndom client port numbers; the rndomly system-generted port numbers re lwys greter thn We decide the importnt port by checking port numbers of less thn 1024 before we pply the proposed SYN/SYN-ACK pcket-bsed method. We should consider vrious cses tht cn rise in relworld environment. First, we might not cpture entire pckets (SYN nd SYN-ACK pckets) needed for the IPS lgorithm in high-speed network link. Sometimes, intentionl pcket drops occur, especilly when smpling is required. Sometimes, unintentionl pcket drops my occur due to symmetric routing nd the performnce limittions of cpturing system. Further, we should consider tht long lsting TCP sessions, streming medi service, VoIP service, or network gme connections my continue for long period (e.g., more thn 30 minutes). The SYN nd SYN-ACK pckets pper only t the beginning of TCP connection. In cse the IPS module strts to cpture pckets from the middle of these connections, we cnnot determine the importnt port for these flows. For the third cse, we should consider the flow dt, such s Cisco NetFlow dt, s n input to our IPS module in order to extend our method to vrious environments. In this cse, the flow informtion might not hve TCP flg informtion s clue to identify the importnt port; for exmple, Cisco NetFlow V5 dt does not hve this informtion. To solve these problems in our IPS, we use the following five points of Assumption 1. Assumption 1.. If the importnt port of TCP flow f is determined, then the importnt port of its reverse flow r f is lso determined. b. If the importnt port of TCP flow f is the source port, then the importnt port of TCP flow f b with the sme source port nd sme source IP ddress s flow f is the source port. c. If the importnt port of TCP flow f is the destintion port, then the importnt port of TCP flow f b with the sme destintion port nd sme destintion IP ddress s flow f is the destintion port. d. If TCP flow f nd TCP flow f b re different nd both hve the sme source port nd source IP ddress, then the importnt ports of flows f nd f b re the source port. e. If TCP flow f nd TCP flow f b re different nd both hve the sme destintion port nd destintion IP ddress, then the importnt ports of flows f nd f b re the destintion port. The first three ssumptions re obvious. The lst two lso hold in generl networks becuse they re typicl outcomes from TCP connections. Using the combintion of the IPS lgorithm nd Assumption 1, we could determine the importnt port of 99.99% of the totl TCP flows t the POSTECH Internet Junction. The remining 0.01% of TCP flows is considered bnorml trffic cused by DoS/DDoS ttcks or Internet worms. In the cse of UDP flows, we cnnot pply this type of method becuse it does not use 3-wy hndshking mechnism like TCP. Insted, we use the FRM lgorithm directly to group UDP flows, s described next. 5. Flow Reltionship Mp Using the FRM, we cn group the TCP nd UDP flows ccording to the corresponding pplictions, nd we cn ETRI Journl, Volume 27, Number 1, Februry 2005 Myung-Sup Kim et l. 29

9 Nottion f(sip, dip, dip, dport, proto) f f (sip), f (sport), f (dip), f (dport), f (proto) rf f = f b Tble 4. Nottion for FRM. Description A flow with sip, sport, dip, dport, proto; long form of flow nottion A short form of flow nottion The sip, sport, dip, dport, proto of flow f The reverse flow of flow f : f (sip)= rf (dip), f (sport)= rf (dport), f (dip)= rf (sip), f (dport)= rf (sport), f (proto)= rf (proto) The complete equlity: f (sip)= f b (sip), f (sport)= f b (sport), f (dip)= f b (dip), f (dport)= f b (dport), f (proto)= f b (proto) f = f b (x,y,..) The conditionl equlity: f (x)= f b (x), f (y)= f b (y),.. A An ppliction G(A ) An ppliction group, the elements of G(A ) re the flows generted by the ppliction A. discover unidentified port numbers used by pplictions. In ddition, the FRM cn esily discover newly emerging pplictions in the future. Finlly, we cn increse the ccurcy of ppliction-lyer trffic identifiction. The min ide of the FRM reflects the fct tht there exist dependencies mong flows belonging to the sme ppliction. According to the dependencies, the FRM groups the individul flows into number of sets. The flows belonging to set re the flows generted from the sme ppliction. The FRM lgorithm consists of two consecutive processes: property dependency grouping (PDG) nd loction dependency grouping (LDG). We define some bsic nottions to describe PDG nd LDG, which re illustrted in Tble 4. We use two nottions to describe single flow: long form nd short form. The long form of flow nottion is expressed by the flow definition. The short form of flow nottion mkes it esy to red equtions tht include mny flows. The reverse flow of flow f is denoted s rf. We denote the complete equlity of the two flows f nd f b with f = f b. The two flows f nd f b hve conditionl equlity, if nd only if some of the 5-tuple vlues of f re equl to those of f b. Generlly, we use the following nottion to describe the conditionl equlity: f = f b (x, y, ). The vlues of x nd y cn be ny of the 5-tuple nottions (sip, dip, sport, dport, proto). A. Property Dependency Grouping The property dependency grouping (PDG) clssifies individul flows ccording to the flow property dependencies. We define the property dependencies s the reltionship between two individul flows belonging to the sme pplictions in terms of protocols, port numbers, nd IP ddresses, which is described in Assumption 2. The three points in Assumption 2 re the generl property dependencies tht re commonly pplied to UDP nd TCP flows. We use them to ssign the flows to groups in PDG. Assumption 2.. If flow f belongs to ppliction group G(A ), then the reverse flow r f of flow f lso belongs to the sme ppliction group G(A ): If nd only if f G( A ), then f G( A ). b. If flow f belongs to ppliction group G(A ) nd flow f b hs conditionl equlity to flow f with sport, sip, nd proto, then flow f b lso belongs to the sme ppliction group G(A ): If f G( A ) nd f b r = f ( sip, sport, proto), then f G( A ). c. If flow f belongs to ppliction group G(A ) nd flow f b hs conditionl equlity to flow f with dport, dip, nd proto, then flow f b lso belongs to the sme ppliction group G(A ): If f G( A ) nd f = f ( dip, dport, proto), then f G ( A ). b Figure 4 illustrtes Assumption 2 s digrm of flows. Assumption 2() is obvious, s shown in Fig. 4(). Becuse flow is unidirectionl, the reverse flow of the originl flow lwys exists nd belongs to the sme ppliction. If two flows hve the sme source port number, the sme source IP ddress, nd the sme protocol number, then the two flows belong to the sme ppliction by Assumption 2(b), s illustrted in Fig. 4(b). In ddition, flows with the sme destintion port number, the sme destintion IP ddress, nd the sme protocol number belong to the sme ppliction by Assumption 1(c), s illustrted in Fig. 4(c). b b 30 Myung-Sup Kim et l. ETRI Journl, Volume 27, Number 1, Februry 2005

10 b c d e originl flow () Assumption 1 (b) Assumption 2 (c) Assumption 3 Filg. 4. Flow digrm for Assumption 2. PDG LDG Originl flows PDG groups LDG groups Fig. 5. Flow grouping with PDG nd LDG. Assumption 2 is pprent nd provides n ccurte grouping of flows. The flows grouped by the PDG lgorithm re from the sme pplictions. The process of flow grouping by PDG is s follows. First, we select one flow mong the cptured flows. Second, we choose the reverse flow of the selected flow. Third, we select the flows with conditionl equlity to the selected flow in sip, sport, nd proto. Fourth, we select the flows with conditionl equlity to the selected flow in dip, dport, nd proto. Fifth, we repet the process from the second step to the fourth step for the flows selected in the third nd fourth steps. This recursive flow selecting process continues until no flow is selected ny further. After finishing the grouping of flows from the first selected flow, we select nother flow from the remining flows nd continue the sme steps until no flow remins. We cn pply this generl PDG lgorithm without modifiction to the UDP flows. However, considering the TCP flows, we need little modifiction to the originl PDG lgorithm becuse the client side progrm in TCP connection cnnot estblish multiple connections using single client port, while the server progrm cn estblish multiple connections using server port. To improve the cpcity of the originl PDG lgorithm, we pplied it to the result of the IPS lgorithm tht is equl to the flows whose importnt port numbers re determined. Therefore, we modified the originl PDG lgorithm. When we pplied our proposed PDG lgorithm to IP trffic in POSTECH Internet junction, we were ble to reduce bout 100,000 of the concurrent flows into 500 PDG groups. B. Loction Dependency Grouping With the PDG lgorithm, we cn clssify ll TCP nd UDP flows into number of PDG groups. The flows belonging to the sme group hve high probbility tht they originted from the sme ppliction. However, we cnnot gurntee tht the flows generted by single ppliction re grouped into single group by the PDG lgorithm. Mny pplictions, such s P2P pplictions, use multiple port numbers, nd sometimes TCP nd UDP protocols together. The problem occurs when the PDG lgorithm is unble to group TCP flows nd UDP flows into single group. In ddition, the PDG lgorithm cnnot group two TCP flows with different port numbers into single group even though the sme ppliction generted them. This sitution frequently occurs becuse mny pplictions currently use multiple TCP port numbers or dynmiclly ssigned TCP port numbers. To solve this incomplete solution of the PDG lgorithm, we ETRI Journl, Volume 27, Number 1, Februry 2005 Myung-Sup Kim et l. 31

11 developed method clled loction dependency grouping (LDG). The min role of LDG is to connect the preliminry PDG groups ccording to their inter-dependencies, s illustrted in Fig. 5. The PDG lgorithm clssifies flows into number of groups. Then, using the LDG lgorithm, the PDG groups generted by the sme ppliction re grouped into one single group. To combine inter-relted PDG groups, we use the weight concept between them. We clculte the weight vlues of every PDG group pir. After we obtin the vlues, we merge the PDG groups by their inter-reltionship. If the weight vlue of two PDG groups is greter thn specified threshold vlue, then the two PDG groups re joined into single group. As illustrted in Fig. 5, the eight different PDG groups re merged into the finl three LDG groups by the LDG lgorithm. To obtin the weight vlue W(G,G b ) between every two PDG groups G nd G b, we define weight vlue w(f, f b ) between two flows f nd f b for preliminry step. We do not consider the weight vlue between the two flows tht belong to the sme PDG group. The weight vlue w(f, f b ) of f nd f b is clculted by the following eqution: 100 if f ( sip) = f ( sip)nd f ( dip) = f ( dip), b b 100 if f ( sip) = f ( dip) nd f ( dip) = f ( sip b b ), w( f, f ) = 10 if ( ) ( )or ( ) ( ), b f sip = f sip f dip = f dip b b 10 if f( sip) = fb( dip)or f( dip) = fb( sip), 0 otherwise, where f G nd f G b b nd G G. The weight vlue is 100 when the two flows re locted between two different hosts becuse the two different flows between two hosts hve high possibility to be the sme ppliction trffic. The conditions when the vlue is 100 cover the type M-F-2 nd type M-D-2 cses of the APT. The weight vlue is 10 when two flows re locted mong three different hosts. In this cse, two flows hve slight possibility to be generted by single ppliction. The cses when the vlue is 10 cover the type M-F-3 nd type M-D-3 of APT. Otherwise, the weight vlue between ny two flows is 0. Using the weight vlue between two flows, we clculte the weight vlue between two different PDG groups s follows: W ( G, Gb ) = w( f, fb ), where f G nd fb Gb nd G Gb. The weight vlue W(G,G b ) of two PDG groups G nd G b is the sum of the weight vlues of ech pir of flows tht belong to two different PDG groups G nd G b. After clculting the weight vlue mong the PDG groups, we merge them by the b following rule: W ( G, Gb ) W ( G, Gb ) If mx(, ) threshold, n( G ) n( G ) where n(g ) is the number of flows in G, then G nd G b cn be merged into single group. Currently we re using 50 s threshold, which ws determined from mny experiments with IP trffic from the POSTECH Internet junction. We my hve to use different threshold vlue to pply the LDG lgorithm to other network environments. However, this eqution works efficiently in the current POSTECH network environment. By the LDG lgorithm, we cn merge ll PDG groups into LDG groups, s in Fig. 5. When we pplied our proposed lgorithm to POSTECH Internet trffic, we could clssify bout 100,000 concurrent flows into 150 concurrent LDG groups on verge. The detils of our nlysis results re described in section V. During the LDG process, we use the informtion of the APT to decide the ppliction nme of ech flow. Before the bove LDG lgorithm is pplied to PDG groups, we select PDG groups of type S-F-2, type M-F-2, nd type M-F-3 using APT informtion. The PDG groups of these types cn be esily picked up becuse they use fixed port numbers. For the remining PDG groups, we pply our LDG lgorithm. The flows in the remining LDG groups re the flows of type M-D- 2 nd type M-D-3. The flows in the selected PDG nd LDG groups re tgged with the corresponding representtive port numbers. We cn use the tgged port number to recognize the corresponding ppliction nme in the subsequent phses of trffic nlysis. The ppliction nme of ll LDG groups my not be determined if the APT does not hve corresponding ppliction nme in the list. In this cse, the flows in the undetermined LDG groups re mrked with minus vlues. This mkes it esy to investigte the new ppliction becuse we hve mny clues in the undetermined LDG groups. The newly investigted ppliction informtion is dded to the APT, nd from tht time on, the undetermined LDG group cn be determined nd tgged with its corresponding representtive port number. By the proposed flow-grouping lgorithms, we cn ccurtely identify Internet trffic t the ppliction level nd esily find new populr pplictions. IV. Design nd Implementtion of the Appliction- Level Trffic Anlysis System In this section, we describe the design nd implementtion of the ppliction-level trffic nlysis system using the proposed method. b 32 Myung-Sup Kim et l. ETRI Journl, Volume 27, Number 1, Februry 2005

12 Appliction-level trffic identifiction system Appliction port tble Network link rw pckets Importnt port number selector Pcket cpturer SYN pcket SYN-ACK pcket Pcket heder info. Flow genertor TCP server port tble Flow info. APT DB APT mnger APT info. PDG group Info. PDG LDG Flow reltionship mpper determined flow info. [Remote host], [DB], [File system] Fig. 6. Overll rchitecture of the ppliction-level trffic nlysis system. 1. Design of the Appliction-Level Trffic Anlysis System Figure 6 illustrtes the overll design of the ppliction-level trffic nlysis system, which consists of three min modules. They re the APT module, the IPS module, nd the FRM module. The IPS module consists of pcket cpturer, flow genertor, nd TCP server port tble. The pcket cpturer receives rw pckets from network link nd extrcts pcket heder informtion from ech rw pcket. The pcket heder informtion is sent to the flow genertor. If pcket is SYN or SYN-ACK pcket, it is stored in the TCP server port tble. The SYN pcket tble keeps the TCP listening port informtion. To select the importnt port number from ech flow, the flow genertor looks up the TCP server port tble. We used hsh tbles to store flow informtion nd server listening port informtion in the flow genertor nd the TCP server port tble to improve the serch opertion. The IPS module cn be implemented in single system or multiple systems depending on the network links we monitor. When the cpcity of single system is sufficient to hndle ll of the rw pckets, the IPS module cn be implemented in single system. However, multiple cpture systems re necessry occsionlly, such s when the trget link speed is high or when we hve number of trget links to be cptured. In tht cse, the IPS module should be seprted into two levels: the first-level IPS nd second-level IPS. While the first-level IPSs re only responsible for their ssigned links, the second-level IPSs collect the results of first-level IPSs nd merge them. The importnt port-determined flows re sent from the IPS module to the FRM module. The PDG module of the FRM first receives the flows nd clssifies them into number of PDG groups using the proposed PDG lgorithm. The next LDG module merges the incoming PDG groups using APT informtion nd the proposed LDG lgorithm. The result of the LDG module cn be stored in file system or DB, or be sent to the other nlysis system for subsequent nlysis. Through the off-line serch of ech ppliction, we built n ppliction port configurtion file using XML. We used XML becuse it is esy to use nd mny XML-relted librries re provided in vrious lnguges, such s C/C++ nd Jv. Figure 7 shows n exmple of n ppliction port configurtion file. The APT mnger reds this configurtion file nd retins port group informtion. When the LDG module receives PDG groups from the PDG module, it looks up the APT to decide the corresponding ppliction nme of ech LDG group. Finlly, the LDG module determines the ppliction nme of flows by tgging the flows with the corresponding representtive port number. <?xml version="1.0" encoding="iso "?> <pt-config> <pp ppnme="msn Messenger" repport="1863" type="m-d-3" clss="p2p"> <session protocol="tcp" port="1863" /> </pp> <!-- MSN Messenger --> <pp ppnme="www" repport="80" type="s-f-2" clss="trditionl"> <session protocol="tcp" port="80" /> <session protocol="tcp" port="8080" /> <session protocol="tcp" port="443" /> </pp> <!-- WWW --> <pp ppnme="wmedi" repport="1755" type="m-d-2" clss="streming"> <session protocol="tcp" port="1755" /> </pp> <!-- Windows Medi Streming --> </pt-config> Fig. 7. An exmple of n ppliction port configurtion file. 2. NG-MON NG-MON [1] is rel-time Internet trffic monitoring nd nlysis system for high-speed networks developed t POSTECH. We hve implemented our ppliction-level trffic nlysis system s n essentil prt of NG-MON. Figure 8 illustrtes ETRI Journl, Volume 27, Number 1, Februry 2005 Myung-Sup Kim et l. 33

13 Network device Pcket cpturer Flow genertor Flow store Trffic nlyzer Presenter Web server User Interfce Web browser Rw pcket Pcket heder info. Flow info. Stored flow Anlyzed dt Fig. 8. Overll rchitecture of NG-MON. Rw pcket Pcket heder info. Flow info. Flow info. Network device/ Network link Pcket cpturer Flow genertor Flow store Appliction-level trffic nlyzer Flow genertor File system PDG LDG DB Pcket cpture First level IPS TCP server port tble Second level IPS Lod APT mnger Updte pp.xml Fig. 9. Integrtion of the ppliction-level trffic nlysis system with NG-MON. the clustering nd pipeline rchitecture of NG-MON. The nlysis tsk of NG-MON is divided into five phses: pcket cpture, flow genertion, flow store, trffic nlysis, nd presenter. The rw pckets re cptured in the pcket cpture phse. The pcket heder informtion extrcted from ech rw pcket is delivered to the second phse, the flow genertion phse. The flow informtion is generted in the flow genertion phse. The frgmented IP pckets re ressembled into single pcket in this phse before being dded to the corresponding flow record. The flow informtion is stored in the flow store phse. The trffic nlyzer queries the flow store, nlyzes the fetched flow dt for their nlysis purpose, nd stores nlyzed dt into DB or file system. The presenter provides the nlysis results to users using Web interfce. 3. Integrtion of Appliction-Level Trffic Anlysis System with NG-MON As mentioned previously, the ppliction-level trffic nlysis module is implemented s plug-in module to NG- MON. Figure 9 illustrtes the integrtion of the pplictionlevel trffic nlysis module with the current NG-MON system. The components of the IPS module re broken into the pcket cpturer, flow genertor, nd flow store phses. We use the pcket cpturer module nd flow genertor module of NG- MON without ny modifiction. The TCP server port tble nd first-level IPS module re dded to the flow genertor, nd the second-level IPS module is dded to the flow store, s described in Fig. 9. The importnt port-number-determined flows re stored s rw file formt in the flow store. For the trffic nlysis t the ppliction level, we developed specilized nlyzer where the APT mnger nd FRM module re running. The nlyzer receives the flow dt from the flow store using the sme pproch s the other nlyzers. The result of the ppliction-level trffic nlyzer, the tgged flow informtion with the representtive port number, is stored in the dtbse, which my be used by the presenter or other nlyzers. The presenter nd other nlyzers determine the 34 Myung-Sup Kim et l. ETRI Journl, Volume 27, Number 1, Februry 2005

14 corresponding ppliction nme of ech flow by the representtive port number. We integrted the dditionl IPS components to the existing NG-MON rchitecture without destroying the philosophy of NG-MON: sclbility nd extendibility. We implemented the ppliction-level trffic nlysis system using C lnguge, libpcp librry, nd xml librries in Linux environment. To store the nlysis results, we used MySQL Dtbse becuse it is the fstest in dt storing nd retrieving mong severl freely vilble dtbse systems. We designed the pcket cpture system with multi-threded rchitecture to hndle multiple network interfce crds in single cpture system. We used semphore for ech cpture thred to send the cptured dt to the exporting module without conflict. We designed the communiction protocols between ech phses over TCP. We used TCP rther thn UDP to eliminte the possibility of dt loss in the delivery of dt between phses nd mde use of number of hsh tbles to effectively perform the PDG nd LDG lgorithms nd reduce their processing time. Some common issues for trffic monitoring nd nlysis systems re lredy tken cre of by the NG-MON s existing modules. For exmple, one might be questioning how we del with frgmented pckets in the nlysis modules. Frgmented pckets re ressembled before being ggregted into flows, so they would not be pssed to the nlyzer module for simplicity resons. Another issue, which reltes to NG-MON s design, is how to del with the time dependency between flows. We hve tken cre of this issue in the ctul implementtion by hndling the flows with the grnulrity of minute. When identifying the current minute s flows, we serch for the identicl flows nd look up their ppliction nmes in the previous minute dt. According to few dditionl conditions we define, our lgorithm will decide whether the previous minute s decision on ppliction nmes is still vlid in the current minute. We refer to this procedure s history lookup mechnism. V. Experience nd Results In this section, we describe the deployment of the ppliction-level trffic nlysis system in POSTECH cmpus network. We lso present the nlysis results. 1. System Deployment We hve deployed the NG-MON with the ppliction-level trffic nlysis module in the Internet junction of our cmpus network. Our cmpus Internet link is composed of two 100 Mbps Metro Ethernet networks. There re two core-switches nd two Internet routers connected with four 1-Gbps Ethernet links in msh structure, s shown in Fig. 10. We used four opticl tps to cpture ll in/out Internet trffic from the four 1-Gbps Ethernet links between core-switches nd Internet routers. We cn see the results of the ppliction-level trffic nlysis in the protocol view pge of the NG-MON presenter. Figure 11 shows n exmple of the ppliction-level trffic nlysis results. NG-MON cptures ll the in/out Internet trffic nd nlyzes them from vrious points of view. The nlysis grnulrity of current NG-MON is one minute, though it is configurble. During ech minute, ech phse of NG-MON performs its ssigned tsk. The ppliction-level trffic nlyzer lso works with one-minute grnulrities; the nlysis result is stored in the DB every minute. Figure 11() is front pge of the ppliction-lyer trffic nlysis, where we cn see the proportion of determined trffic t specified minutes in terms of bytes, pckets, nd flows. We cn see the top 10 list of ppliction trffic nd the top 10 list of undetermined flow groups. The undetermined flow group informtion helps us to investigte unknown pplictions off-line. Figure 11(b) shows the sorted list of determined ppliction trffic with the proportion of them in flows, pckets, nd bytes. Figure 11(c) shows the flow-level detils of specific ppliction trffic. The Opticl tp 1 Gbps opticl link 100 Mbps metro Ethernet Cmpus bckbone network Core switch Router INTERNET Core switch Router NG-MON Appliction-level nlyzer Fig. 10. Internet connection structure of POSTECH. ETRI Journl, Volume 27, Number 1, Februry 2005 Myung-Sup Kim et l. 35

15 (b) Top 10 list of ppliction lyer trffic () Appliction protocol view of NG-MON presenter (c) Detil in flow level of edonkey trffic (d) The nlyzed trffic proportion during lst 1 hour in time-series grph Fig. 11. Appliction protocol view pge. Tble 5. Trffic trce summry. Collection period Feb. 1, 2004 to Feb. 7, 2004 Collection loction Internet junction of POSTECH cmpus network Flows Pckets Bytes ( 10 6 ) Rtio (%) (In:Out) ( 10 6 ) Rtio (%) (In:Out) GB Rtio (%) (In:Out) TCP % (47:52) 18,345 93% (49:50) 13,697 98% (40:59) UPD % (51:48) 1,089 5% (52:47) 190 1% (69:30) Totl ICMP 33 3% (46:53) 190 0% (78:21) 16 0% (76:23) Others 0.1 0% (28:71) 1 0% (37:62) 0.6 0% (85:14) Totl % (49:50) 19, % (50:49) 13, % (41:58) grphs in Fig. 11(d) re three time-series grphs showing the proportion of determined trffic in flows, pckets, nd bytes during specified one-hour period. 2. Appliction Lyer Trffic Chrcteristics We collected Internet trffic t the POSTECH cmpus network for one week in Feb The overll sttistics of the trffic trce re described in Tble 5. Among the cptured pckets, we excluded the non-ip pckets nd IP pckets with spoofed IP ddresses. We considered the spoofed pcket s pckets whose source nd destintion IP ddress does not belong to our cmpus network ddress rnge. The portion of the excluded dt ws 0.5% of the totl trffic in bytes. As Tble 5 illustrtes, the outbound trffic is 1.4 times lrger thn the inbound trffic in bytes. The 36 Myung-Sup Kim et l. ETRI Journl, Volume 27, Number 1, Februry 2005

16 10 4 totl 12 tcp udp icmp totl tcp udp icmp Number of flows Number of flows st 2nd 3rd 4th 5th 6th 7th dy 0 1st 2nd 3rd 4th 5th 6th 7th dy () Inbound flow distribution (b) Outbound flow distribution totl tcp udp icmp totl tcp udp icmp Number of pckets Number of pckets st 2nd 3rd 4th 5th 6th 7th dy (c) Inbound pckets distribution 10 8 totl tcp udp icmp 0 1st 2st 3rd 4th 5th 6th 7th dy (d) Outbound pckets distribution Number of bytes Number of bytes totl tcp udp icmp 0 1st 2nd 3rd 4th 5th 6th 7th dy (e) Inbound bytes distribution 0 1st 2nd 3rd 4th 5th 6th 7th dy (f) Outbound bytes distribution Fig. 12. Time-series grph in three nlysis metrics (flow, pcket, nd byte) for our trffic trce (mesured from Feb.1 to Feb 7, 2004). ETRI Journl, Volume 27, Number 1, Februry 2005 Myung-Sup Kim et l. 37

17 inbound trffic refers to the trffic trnsferred from the Internet to our cmpus network, nd the outbound trffic is vice vers. In ddition, the number of UDP flows is much greter thn the number of TCP flows, while the TCP trffic overwhelms the UDP trffic in the pcket count nd byte size. This fct infers tht the smll size UDP pckets re very widely used by networkbsed pplictions. This mkes the flow-bsed trffic nlysis systems overloded. Moreover, the inbound pcket count is 10% lrger thn the outbound pcket count, while the totl inbound byte count is bout 15% smller thn the totl outbound byte count. This mens tht the verge pcket size of inbound trffic is much smller thn the outbound trffic. We believe this is minly due to P2P trffic nd populr FTP servers operted by students. The totl number of internl nd externl IP ddresses ppered in the cptured flows ws bout 3,600,000. Figure 12 illustrtes six time-series grphs of the trffic trce. Ech grph shows vrince of three-trnsport lyer protocol (TCP, UDP, nd ICMP) trffic nd the sum of them in three nlysis metrics (flow, pcket, nd byte). We lso ctegorized the trffic into inbound nd outbound trffic to compre the directionl behvior of our cmpus trffic. The totl flow distribution is minly ffected by the UDP flows, s illustrted in Figs. 12() nd 12(b). The inbound nd outbound flow distribution hs similr shpe nd the verge number of outbound flows is slightly lrger thn tht of the inbound flow. The shpes of pcket distribution nd byte distribution grphs re primrily ffected by the mount of TCP trffic, which contrdicts the shpe of the flow distribution. The timeof-dy effect ppers in ll three kinds of grphs. The trffic increses from the fternoon nd peks between 10 p.m. nd 1.m. of the next dy, nd then goes down in the morning, which is typicl of our university Internet usge behvior since ll of our students live in the cmpus dormitories. The incoming ICMP pckets re much lrger thn the outgoing ICMP pckets, s illustrted in Figs. 12(c) nd 12(d). This implies tht the outside IP ddresses more frequently join nd leve the network thn the inside IP ddresses, nd the number of outside IP ddresses is more thn tht of the inside. The fluctution of incoming bytes is higher thn the fluctution of outgoing bytes. This is becuse the number of outside users is much higher thn inside users. In other words, the more users ccess network, the less the fluctution of downlod trffic ppers. For ppliction-level trffic identifiction, we constructed the APT informtion by investigting bout 800 Internet-bsed pplictions. The determined proportion of the trffic trced by our proposed method is 99.5% of totl flows, 94% of totl pckets, nd 92% of totl bytes. Most determined trffic were generted from less thn 100 pplictions mong the pplictions listed in the APT. Tble 6 shows the ten heviest Tble 6. Top 10 most populr pplictions in flows, pckets, nd bytes. Flows Top 10 pps Rtio (%) In:Out (%) edonkey : 49.2 SORIBADA : 50.1 V_SHARE : 46.0 HTTP-WEB : 50.9 MSN : 49.8 BATTLE_NET : 89.5 AFS : 50.1 DNS : 50.5 SAYCLUB : 50.2 FREECHAL : 50.1 Totl : 50.3 Pckets Top 10 pps Rtio (%) In:Out (%) edonkey : 49.4 HTTP-WEB : 44.0 FREECHAL : 58.9 FTP : 56.0 V_SHARE : 51.1 SORIBADA : 50.6 AFS : 52.8 MSN : 49.6 mirc : 55.1 BITTORENT : 55.4 Totl : 50.4 Bytes Top 10 pps Rtio (%) In:Out (%) edonkey : 52.4 HTTP-WEB : 33.8 FREECHAL : 85.4 FTP : 78.8 V_SHARE : 55.2 MSN : 54.6 mirc : 94.5 SORIBADA : 65.4 BITTORENT : 74.2 WMedi : 8.7 Totl : Myung-Sup Kim et l. ETRI Journl, Volume 27, Number 1, Februry 2005

18 % Flows 60 % Pckets % Bytes Totl flows Inbound flows Outbound flows Applictions 20 Totl pckets Inbound pckets Outbound pckets Applictions () Flow distribution (b) Pcket distribution (c) Byte distribution 20 Applictions Totl bytes Inbound bytes Outbound bytes Fig. 13. Cumultive probbility distribution of flows, pckets, nd bytes of the top 150 trffic generting pplictions. pplictions in three perspectives of trffic metrics: the number of flows, the number of pckets, nd the totl byte size. As Tble 6 shows, the flow distribution does not follow the pcket nd byte distribution, while the pcket nd byte distribution is lmost in ccordnce with the other. The top 10 most populr pplictions occupy 95.6% of the totl flows, 76% of the totl pckets, nd 76.7% of the totl bytes. This indictes tht the flow distribution is more skewed thn the other two distributions. Six of the pplictions in the flow distribution nd seven of the pplictions in the pcket nd byte distributions in the bove tble re P2P pplictions, which belong to M-D-3. Our results re in ccordnce with the results of severl previous results in P2P trffic nlysis [10]- [14]. Web trffic is still one of the most trffic-consuming pplictions, while the FTP ppliction is less thn the web ppliction. World-wide P2P pplictions such s edonkey nd KZA occupy lrge prt of Internet trffic. In ddition, ntion-wide P2P pplictions such s V_SHARE, FREECHAL, SAYCLUB, nd SORIBADA re locted in the top 10 list of the three different distributions nd occupy lrge prt of Internet trffic. Figure 13 shows cumultive probbility distribution of flows, pckets, nd bytes from the determined trffic in our trffic trce of the top 150 trffic-generting pplictions. Figure 13 indictes tht the flow distribution is more skewed thn the other two distributions. Severl populr pplictions generte most of the IP trffic; the top six pplictions occupy bout 80% of the totl trffic. In ddition, the outbound trffic is more skewed thn the inbound trffic in flow distribution nd byte distribution. 3. Performnce nd Limittions The performnce of our FRM lgorithm solely depends on the flow counts rther thn the physicl link speed or rel bndwidth utiliztion. Although there is greter chnce to hve n increse in the number of flows in the multi-gigbit links, we believe tht the number of flows generted from those links is tolerble by the current version of our implementtion. From the recent deployment experiences t vrious sites (e.g. POSTECH, Kore Internet exchnge), we were ble to verify the sclbility of the system nd provide precise figures for system performnce mesurement. The current version of our system cn hndle bout 100,000 flows within or little over 5 seconds, nd 1,000,000 flows in round 30 seconds. The verge number of flows generted from the POSTECH Internet junctions during 1 minute ws 100,000 where the link utiliztion ws 250 to 300 Mbps. Using the FRM lgorithm, we could clssify the 100,000 flows into bout 500 LDG groups nd decide the corresponding ppliction nme of 99% of the flows, 95% of the pckets, nd 92% of the bytes. In ddition to tht, we hd ccess to the government-owned fcility clled Kore Internet exchnge (KIX), which ws the country s mjor PoP nd consisted of gigbit bckbone links with vrious utiliztion rtios. Our deployment took plce in four different one-gigbit links, simultneously, with the mximum of 2.4 Gbps nd 1,200,000 flows per minute in totl. For the record, these figures re obtined from both rel-world deployments nd testing environments using SmrtBits 600, pcket generting hrdwre tool. We define n ppliction (in the context of ppliction-level trffic nlysis) s collection of flows tht re directly or indirectly originted from the sme ppliction-lyer protocol, while rel-world pplictions imply ctul progrms tht mke use of the ppliction-lyer protocols. For exmple, there re hundreds of FTP pplictions in the Internet, such s CuteFtp, WsFtp, nd so on. Obviously, they ll shre one thing in ETRI Journl, Volume 27, Number 1, Februry 2005 Myung-Sup Kim et l. 39

19 common: they use the FTP protocol. In our system, the trffic generted from these pplictions is shown s FTP trffic s whole, not CuteFtp or WsFtp trffic. In this cse, we ctully grouped flows ccording to the type of service they provide (file trnsfer) s well s the protocol in use (FTP) for this service. Here is somewht confusing scenrio of using session initition protocol (SIP). SIP signling trffic should be grouped s SIP-bsed trffic regrdless of the origin rel-world pplictions. Wht is different from the previous exmple is tht the type of service is not one but mny (e.g., VoIP, video conferencing); but the ppliction protocol in use is the sme t the initil phse for ll these services. The objective of our lgorithm is to reduce the unknown trffic s much s possible; however, this does not necessrily imply the complete investigtion over ll existing vendor pplictions. Therefore, in this cse we simply nrrow the problem down to SIP-bsed trffic nd cler some of the mbiguity in trffic. For more detiled nlysis on specific services, we provide bsis (the smple dt contins the prticulr service trffic) for n offline nlysis. Throughout the recent experience of system deployments into vrious networks, we strongly believe tht our methods re generlly useful for the purposes of n in-depth monitoring of IP networks, ppliction usge, nd user behviors. However, there re few limittions. Even though we nlyze the ppliction-level informtion of the networks, it is not entirely correct to cll ours lyer 7 nlysis system becuse we only work with the pcket heder informtion. The good news is tht the pylod exmintion method becomes limited becuse of the privcy issue nd the encryption of contents. The second constrint is tht the APT is not universl. The slight modifiction to the APT might be necessry t the deployment site. For exmple, populr pplictions in Europe might not pper mong the user groups in Kore. We re considering these limittions in our future reserch. VI. Conclusion The lrge number of pplictions nd their use of dynmic sessions cuse one of the min problems with trffic nlysis in the recent high-speed nd high-volume Internet. The trffic types nd ptterns of the recent Internet re complex nd sophisticted compred to trditionl trffic, such s HTTP, FTP, nd TELNET. The trditionl well-known port numberbsed trffic nlysis mechnism is not suitble to nlyze newly emerging Internet trffic, such s P2P, streming medi, nd gme trffic. Therefore, we must develop new method ble to hndle the vrious trends of current trffic. In this pper, we hve presented method to identify Internet trffic t the ppliction lyer, which is the preliminry but criticl step for the chrcteriztion of Internet trffic s well s for other vriety of uses. First, we ctegorized Internet trffic from the trffic nlysis point of view. We ctegorized most current network-bsed pplictions into five clsses ccording to their trffic pttern. Using this ctegoriztion, we developed flow grouping method, which determines the ppliction nme of individul pckets. The proposed method consists of three components: n APT, n IPS, nd FRM. To vlidte our method, we designed nd implemented n ppliction-lyer trffic nlysis system s n essentil prt of the NG-MON system. We hve identified more thn 90% of Internet trffic from POSTECH using our proposed method. The nlysis results show tht more thn 50% of recent Internet trffic is cused by newly emerging pplictions, especilly P2P pplictions. Previous studies presented similr sttisticl results. In ddition, most Internet trffic is generted by bout ten of the most populr pplictions. In this pper, we lso chrcterized Internet trffic using short time period of trffic trce, which is insufficient to discern the overll trends of recent Internet trffic. We re in the process of constructing long-term trffic trce by collecting trffic for one week in ech month nd mking vrious trffic trces by collecting trffic in number of ISP nd enterprise networks. The exct trffic identifiction in n ppliction lyer leds to the ccurcy of high-level trffic nlysis, such s P2P nd streming trffic chrcteriztion. Therefore, we intend to pply the proposed method to vrious trffic trces to improve our proposed method, especilly the FRM lgorithm. Further, the detiled nd ccurte trffic nlysis cn provide useful informtion towrds the control of current Internet trffic. We re lso considering monitoring nd nlysis needs for the IPv6 environment nd the QoS trffic provisioning bsed on the nlysis results of Internet trffic s the next step of our reserch. References [1] Se-Hee Hn, Myung-Sup Kim, Hong-Tek Ju, nd Jmes W. Hong, The Architecture of NG-MON: A Pssive Network Monitoring System, LNCS 2506, DSOM 2002, Montrel, Cnd, Oct. 2002, pp [2] Se-Hee Hn, Hong-Tek Ju, Myung-Sup Kim, nd Jmes W. Hong, Design of Next Genertion High-Speed IP Network Trffic Monitoring nd Anlysis System, Proc. of 2002 Asi- Pcific Network Opertions nd Mngement Symp. (APNOMS 2002), Jeju, Kore, Sept , 2002, pp [3] E. Rosen, A. Viswnthn, nd R. Cllon, Multiprotocol Lbel Switching Architecture, RFC3031, IETF, Jn [4] 4 Deb Agrwl, Jose Mri Gonzlez, Goujun Jin, nd Brin Tierney, An Infrstructure for Pssive Network Monitoring of 40 Myung-Sup Kim et l. ETRI Journl, Volume 27, Number 1, Februry 2005

20 Appliction Dt Strems, Pssive nd Active Mesurement Workshop, L Joll, Cliforni, Apr [5] Luc Deri, Pssively Monitoring Networks t Gigbit Speeds Using Commodity Hrdwre nd Open Source Softwre, Pssive nd Active Mesurement Workshop, L Joll, Cliforni, Apr [6] Myung-Sup Kim, Hun-Jeong Kng, nd Jmes W. Hong, Towrds Peer-to-Peer Trffic Anlysis Using Flows, Lecture Notes in Computer Science 2867, Edited by Mrcus Brunner, Alexnder Keller, 14th IFIP/IEEE Int l Workshop on Distributed Systems: Opertions nd Mngement (DSOM 2003), Heidelberg, Germny, Oct. 2003, pp [7] Hun-Jeong Kng, Myung-Sup Kim, nd Jmes Won-Ki Hong, A Method on Multimedi Service Trffic Monitoring nd Anlysis, Lecture Notes in Computer Science 2867, Edited by Mrcus Brunner, Alexnder Keller, 14th IFIP/IEEE Int l Workshop on Distributed Systems: Opertions nd Mngement (DSOM 2003), Heidelberg, Germny, Oct. 2003, pp [8] Hun-Jeong Kng, Hong-Tek Ju, Myung-Sup Kim, nd Jmes W. Hong, Towrds Streming Medi Trffic Monitoring nd Anlysis, Proc. of 2002 Asi-Pcific Network Opertions nd Mngement Symp. (APNOMS 2002), Jeju, Kore, Sept , 2002, pp [9] Internet2, [10] Subhbrt Sen nd Ji Wng, Anlyzing Peer-to-Peer Trffic cross Lrge Networks, Proc. of the second ACM SIGCOMM Workshop on Internet Mesurement Workshop, Nov [11] Alexndre Gerber, Joseph Houle, Hn Nguyen, Mtthew Roughn, nd Subhbrt Sen, P2P The Gorill in the Cble, Ntionl Cble & Telecommunictions Assocition (NCTA) 2003 Ntionl Show, Chicgo, IL, June 8-11, [12] Stefn Sroiu, Krishn P. Gummdi, Richrd J. Dunn, Steven D. Gribble, nd Henry M. Levy, An Anlysis of Internet Content Delivery Systems, Proc. of the Fifth Symp. on Operting Systems Design nd Implementtion (OSDI 2002), Boston, MA, Dec [13] Nthniel Leibowitz, Mtei Ripenu, nd Adm Wierzbicki, Deconstructing the KZA Network, 3rd IEEE Workshop on Internet Applictions (WIAPP'03), June [14] Nthniel Leibowitz, Aviv Bergmn, Roy Ben-Shul, nd Aviv Shvit, Are File Swpping Networks Ccheble? 7th Int l Workshop on Web Content Cching nd Distribution (WCW), Boulder, Colordo, [15] IANA, [16] Microsoft, Windows Medi Technology, com/windows/windowsmedi/defult.sp. [17] Jcobus vn der Merwe, Rmon Cceres, Yng-hu Chu, nd Cormc Sreenn mmdump- A Tool for Monitoring Internet Multimedi Trffic, ACM Computer Communiction Review, vol. 30, no. 4, Oct [18] TS Choi, CH Kim, SH Yoon, JS Prk, HS Chung, BJ Lee, HH Kim, nd TS Jeong, Rte-Bsed Internet Accounting System Using Appliction-Awre Trffic Mesurement, Proc. of 2003 Asi-Pcific Network Opertions nd Mngement Symp. (APNOMS 2003), Fukuok, Jpn, Oct. 1-3, 2003, pp [19] Argus, [20] Remco Poorting, Remco vn de Meent, nd Aiko Prs, Anlysing Cmpus Trffic Using the meter-mib, Proc. of the Pssive nd Active Mesurement Workshop (PAM2002), Mr , [21] Chuck Frleigh, Sue Moon, Bryn Lyles, Chse Cotton, Mujhid Khn, Deb Moll, Rob Rockell, Ted Seely, nd Christophe Diot, Pcket-Level Trffic Mesurements from the Sprint IP Bckbone, IEEE Network, [22] Juergen Quittek, Mrcelo Pis, nd Mrcus Brunner, Integrting IP Trffic Flow Mesurement, Proc. of Workshop on Pssive nd Active Mesurements (PAM2001), Apr , [23] Shrd Agrwl, Chen-Nee Chuh, Suprtik Bhttchryy, nd Christophe Diot, The Impct of BGP Dynmics on Intr-Domin Trffic, Sprint ATL Reserch Report Nr. RR03-ATL , Sprint ATL, Nov [24] Rnjit Bhgwn, Stefn Svge, nd Geoffrey Voelker, Understnding Avilbility, Proc. of the 2nd Int l Workshop on Peer-to-Peer Systems (IPTPS '03), Berkeley, CA, Feb [25] B. Krishnmurthy, J. Wng, nd Y. Xie, Erly Mesurements of Cluster-Bsed Architecture for P2P Systems, ACM SIGCOMM Internet Mesurement Workshop, Sn Frncisco, CA, Nov [26] Krishn P. Gummdi, Richrd J. Dunn, Stefn Sroiu, Steven D. Gribble, Henry M. Levys, nd John Zhorjn, Mesurement, Modeling, nd Anlysis of Peer-to-Peer File-Shring Worklod, Proc. of the 19th ACM Symp. on Operting Systems Principles (SOSP-19), Oct [27] S. Sroiu, P. Gummdi, nd S.D. Gribble, A Mesurement Study of Peer-to-Peer File Shring Systems, Proc. of Int l Conf. on Distributed Computing Systems, [28] P. Krishn Gummdi, Stefn Sroiu, nd Steven Gribble, A Mesurement Study of Npster nd Gnutell s Exmples of Peer-to-Peer File Shring Systems. [29] J. Chu, K. Lbonte, nd B. Levine, Avilbility nd Loclity Mesurements of Peer-to-Peer File Systems, Proc. of ITCom: Sclbility nd Trffic Control in IP Networks, July [30] E.P. Mrktos, Trcing Lrge-Scle Peer-to-Peer System: n Hour in the Life of Gnutell, 2nd IEEE/ACM Int l Symp. on Cluster Computing nd the Grid, [31] Dve Plonk, FlowScn, FlowScn/. ETRI Journl, Volume 27, Number 1, Februry 2005 Myung-Sup Kim et l. 41

21 Myung-Sup Kim received the BS, MS nd PhD degrees in computer science nd engineering from Pohng University of Science nd Technology (POSTECH) in 1998, 2000 nd Currently, he is Post-Doctorl Fellow in the Dept. of Electricl nd Computer Engineering, University of Toronto, Cnd. His reserch interests include Internet trffic monitoring nd nlysis, ppliction-level trffic nlysis, nd network-security ttck detection nd prevention. He is member of IEEE nd KNOM. Young J. Won received his BMth degree in computer science from the University of Wterloo, Cnd in Currently, he is grdute student in the Dept. of Computer Science nd Engineering, Pohng University of Science nd Technology (POSTECH), Kore. His reserch interests include Internet trffic monitoring nd nlysis, ppliction-level trffic nlysis, nd networksecurity ttck detection nd prevention. Jmes Won-Ki Hong is n Associte Professor in the Dept. of Computer Science nd Engineering, POSTECH, Pohng, Kore. He hs been with POSTECH since My Prior to joining POSTECH, he ws Reserch Professor in the Dept. of Computer Science, University of Western Ontrio, London, Cnd. Dr. Hong received the BSc nd MSc degrees from the University of Western Ontrio in 1983 nd 1985 nd the PhD degree from the University of Wterloo, Cnd in He hs been very ctive s prticipnt, progrm committee member, nd orgnizing committee member for IEEE CNOM sponsored symposiums such s NOMS, IM, DSOM nd APNOMS. For the lst few yers, he hs been working on vrious reserch projects on network nd systems mngement, which utilize Web, Jv, CORBA nd XML technologies. He is IEEE Comsoc Director of On-Line Content, CNOM Vice-Chir nd KICS KNOM Chir. His reserch interests include network nd systems mngement, trffic monitoring nd nlysis, nd security mngement. He is member of IEEE, KICS, KNOM nd KISS. 42 Myung-Sup Kim et l. ETRI Journl, Volume 27, Number 1, Februry 2005