Abnormal Event Detection for Network Flooding ... - Semantic Scholar

JOURNAL OF INFORMATION SCIENCE AND ENGINEERING 20, 1079-1091 (2004)

Abnormal Event Detection for Network Flooding Attacks CHI-SHIH CHAO*, YU-XIN CHEN AND AN-CHI LIU *

Department of Communications Engineering Department of Information Engineering Feng Chia University Taichung, 407 Taiwan E-mail: [email protected]

Due to the high demand for network service availability and reliability, the IDS (Intrusion Detecting System) has become an essential element for IP networks. Currently, most IDSs use a pattern-matching mechanism to detect network flooding attacks. However, while running, such a mechanism needs to take into considerable the computing time/resource of an IDS or an IDS-embedded router. This can easily cause the IDS or router to become overloaded or to crash. In this paper, an abnormal event detection mechanism based on the abrupt variation analysis of network traffic is proposed. This detection mechanism works cooperatively with the pattern-matching mechanic to perform effective attack detection in a situation where overloading of an IDS or an IDS-embedded device should be avoided. In addition, a monitoring system using abnormal event detection is designed and implemented to demonstrate its detection performance. By using the developed system, network managers can not only determine the occurrence and the behavior of an attack, but also take some timely actions to present or stop the attack on crucial network resources. Keywords: abnormal traffic event detection, statistical reference window, network flooding attacks, event correlation, network security management

1. INTRODUCTION Due to the rapid growth of the use of the Internet and its related technologies, the demand for high quality and reliable Internet service has increased. However, the occurrences of malevolence network attacks and viruses seriously threaten the Internet [1, 2]. These disaster events, either network attacks or viruses, cause not only system crashes or performance degradation, but also damages IT enterprises. Therefore, an effective system for detecting network attacks is needed. Current methods used for intrusion detection are described in the following:
Pattern-Matching The pattern-matching method is widely used by most of the current IDSs. Normally, an IDS uses predefined pattern rules describing network attacks to check and analyze each incoming pattern of packets. The major problems with pattern-matching for network attack detection are the low processing capacity and the inability to detect novel attacks. To improve packet processing performance, Fisk [3] and Coit [4] proposed sevReceived March 30, 2004; accepted June 30, 2004. Communicated by Chu-Sing Yang.

1079

1080

CHI-SHIH CHAO, YU-XIN CHEN AND AN-CHI LIU

eral methods to speed up pattern comparing tasks. In addition, Snort 2.0 [5] also used a rule optimizer and rule classifier to quicken attack detection.
Abnormal Behavior Detection Abnormal behavior detection finds abnormal behavior in network traffic, which triggers more detailed checks of network attacks. This is because abnormal traffic behavior is normally treated as a symptom of an underlying problem in the managed network. This method is widely used in network management for fault detection or prediction. In 1990, Maxion et al. [6] monitored the campus network traffic of Carnegie Mellon University for about seven months and used the acquired data to construct a traffic model for predicting the traffic amount in the next time slot. Then they set an appropriate threshold for the next time slot to check if traffic changed abnormally. Hood and Ji [7] collected all the MIB logs from network backbone routers for network fault verification. Moreover, they used a Bayesian network to calculate the probability of fault occurrence in each time slot. Thotton et al. [8] used a first order auto-regressive model to calculate white noise series. The generalized likelihood ratio was used to determine the degree of the value change of a parameter. In their work, spatial correlation was also utilized to combine all measured parameters to reduce the number of fault occurrences. Nevertheless, abnormal behavior detection has difficulty verifying whether the detected “abnormal” behavior is a real problematic event or not; this means that network managers need to further check related network logs and data to make a more precise determination.
Visualization Hiraishi et al. [9] used a “Hyperbolic Tree” to visualize the system log data of users. Managers can understand all the actions and related information of each system user by observing the corresponding “Hyperbolic Tree” and can easily discover invalid user actions when the branches connected to the “Danger” group grow explosively. Erbacher et al. [10] used two basic components to construct a connection graph of a managed host. The first component is an arrow used to show the direction of a connection of the monitored host, while the second component is a circle with which arrows connect. Several different kinds of arrows are designated for different network services, such as telnet, FTP, NFS, port scanning, and so on. All the connections from and to a host can be observed by monitoring the connection graph of that host. If there is an attack on that host, it can be easily discovered by monitoring the width change of the attack connection arrow in the connection graph. In summary, current IDSs use pattern-matching as the major network attack detection mechanism. However, the pattern-matching mechanism may cause equipped routers or IDSs to become overloaded when flooding attacks occur; this will make the router or IDS the first victim in a network attack event. To solve this problem, we combine pattern-matching and traffic change detection to detect network flooding attacks based on the reduced average CPU computing load of the IDS. In addition, we also implement a visual monitoring system. After observing the behavior of network flooding attacks via the monitoring system, network managers can take actions to prevent, stop, or even control the expansion of the attacks in advance. The rest of this paper is organized as follows.

ABNORMAL EVENT DETECTION FOR NETWORK FLOODING ATTACKS

1081

Section 2 describes the behavior of network flooding attacks and our management architecture. The time series analyses used in our abnormal traffic change detection are also presented. Section 3 describes the major traffic change detection methods with different change detection mechanisms and time series analyses. In addition, the performance of these methods is evaluated and compared. Section 4 presents our system implementation, and section 5 concludes this paper.

2. ABNOMAL EVENT DETECTION A system for detecting network flooding attacks must be able to not only determine the occurrence of an attack in time, but also visualize the attack in order to alert or protect network users. This means that the management system should provide timely information about the occurrence of an attack as well as the overall attack behavior or its paths. To do this, the system must determine the behavior of network flooding attacks first. During an attack, abnormal events reflecting abrupt traffic changes occur in the network area affected by the attack [1]. The attack traffic floods the related network elements (devices) and causes some specific packet measures to grow explosively. On the basis of these observations, we can use some standard management protocols (e.g., SNMP) to easily obtain these measures from the managed network and then determine if there are abnormal traffic changes. Once an abnormal traffic change is found, the type of the attack can be determined by examining the type of the attack packets associated with the abrupt traffic change, and the IDS will trigger pattern-matching only using the matching rules of that attack from the entire attack-pattern knowledge base. To track attack paths, the management system should observe the incoming and outgoing traffic of each transmission interface of the managed network elements. Based on information regarding the attack traffic direction, the next victims of the attack can be estimated and warmed in advance. For example, as shown in Fig. 1, the attack traffic passes through link(1 → 3) and link(2 → 3) in time t1, and runs across element3 to element4 in time t2. Thus, we can deduce that the downstream of element4 – link(4 → 5) will be the next victim as the attack traffic floods the network.

t1

t2

t3

1 3 2

4

5

May be affected in next time slot t3

Fig. 1. Flooding by attack traffic.

Considering the system implementation, it is possible that the manager or the management system will be unable to correctly collect related management information from its managed network (or devices), due to the network congestion caused by the attack

1082

CHI-SHIH CHAO, YU-XIN CHEN AND AN-CHI LIU

traffic. To avoid this situation, an out-of-band management architecture, as shown in Fig. 2, can be used. Every managed element (router in Fig. 2) directly transmits needed management information to the corresponding manager via the out-of-band management information network (such as via a SMS network). This can assure that the management traffic will not be affected or infected by the attack traffic.

Manager Domain (LAN) Out-Of-Band Real-World Network

Fig. 2. Management architecture.

For traffic change detection, to accurately detect abrupt changes in flooding attacks, several change detection methods with two different time series analyses can be used (performance comparisons will be given in section 3). Here, we will first discuss two different kinds of time series analysis normally used in traffic change detection [11] as a basis for setting traffic thresholds, and we will later discuss the major methods used in our traffic change detection scheme. Time series analyses normally divides the data over time into two major portions, the “reference window” portion and the “test window” portion, before further engineering traffic. The traffic data in the reference window are used as thresholds to make a comparison with the (current) traffic in the test window. Two mechanisms are usually used to determine the size of the reference window for the time series data: the fixed and variance mechanisms. In the fixed reference window size mechanism, the size of the reference window is fixed in every comparison at each regular time interval, and the size of the reference window is the same as that of the test window. The window size can be determined and adjusted by users themselves. In our experiments, we examined the detection accuracy achieved with different fixed window sizes. In the variance reference window size mechanism, the size of the reference window varies. The time series data in the test window is compared with the traffic data in the reference window, which is the same size or two or more times the size of the test window. In our work, the variance reference window size is determined as follows (as shown in Fig. 3): 1. Initially, the sizes of the reference window and the test window are the same. As shown in Fig. 3 (a), we assume
that the starting point of the reference window is at time T,  that the ending point of the reference window and the starting point of the test window are time T + t and  that the ending point of the test window is time T +

ABNORMAL EVENT DETECTION FOR NETWORK FLOODING ATTACKS

1083

Initially, choose two windows of the same size In Time T

Partition point

If no change occurs, extend the reference window In Time T + t

In Time T + 3t

(a)

(b)

(b)

(c)

(c)

Partition point

If no change occurs, continue to extend the reference window Partition point

If a change occurs, choose a new reference window In Time T + 4t

(a)

Change point

Partition point

Fig. 3. Various window sizes.

2t. Then, T + t can be viewed as a partition point between the reference window and the test window. 2. When we compare the traffic data in the reference window with that in the test window, if the degree of variation does not exceed the threshold, then the partition point will shift to the end of the test window. The next time, the data in the text window will be compared with the traffic data within a reference window that is twice as large. This step will be repeated until the degree of variation of the traffic exceeds the specified threshold (as shown in Fig. 3 (b)). 3. When the degree of variation exceeds the threshold, a change point will be set at the partition point of the last traffic comparison (as shown in Fig. 3 (c)). This means that an abrupt change will be detected in the text window, and that the detection procedure will be restarted from the current change point. For abrupt traffic change detection based on a comparison of the two traffic windows, the log likelihood ratio test with first order Auto-Regressive model, which was proposed by Hood et al. [12], is used in our work. By modeling the two adjacent traffic windows of the time series data using AR(1), we can generate two white noise series. Then, the joint probability of a change between these two traffic windows can be esti2 2 mated as l = ( 1 ) N R ( 1 ) NT exp( − NRσ2 R )exp( − NTσ2 T ), and the joint probability 2σ R 2σ T 2πσ R2 2πσ T2 2 of no change happening can be calculated as l 0 = ( 1 ) N R + NT exp( −( NR + N2 T )σ P ), 2σ P 2πσ P2 where
NR and NT are the values of the white noise series random variables of the reference window and the test window, respectively;  σ P2 is the pooled variance. Next, the log likelihood ratio used to estimate the degree of change can be obtained by using η = (NR + NT)logσP − NRlogσR − NTlogσT.

CHI-SHIH CHAO, YU-XIN CHEN AND AN-CHI LIU

1084

In our study, two other traffic detection methods, the standard derivation comparison method and the average comparison method, were employed to make a performance comparison for traffic change detection, where the degree of change in the standard derivation comparison method and the average comparison method was defined as (σ )higher Average higher and η = η= , respectively. Averagelower (σ )lower

3. DETECTION PERFORMANCE EVALUATION To compare the performance of the traffic change detection methods mentioned in section 2, an experimental network was built, which included three PC-based routers, four PCs, two Ethernet switches, and one hub (as shown in Fig. 4). In addition, the whole experimental networking environment was equipped as shown in Table 1: Table 1. Experimental environment. PC Hardware OS Routing Daemon Routing Protocol Flow Calculator Background Traffic Attack Window Size Change Degree Threshold

Pentium 200MHz + 64MB Memory Redhat linux 7.3 Gated RIPv2 NeTraMet (with Flow Meter MIB) [13] Poisson 200, 400, 600, 800, 1000 pkts/sec WWW 40, 80, 120, 160, 200 users 1000, 2000 pkts/sec 5, 10, 15, 20, 30 samples 2, 3, 5, 10 (AR(1))

Background Traffic : simulate normal traffic Attack Traffic

Fig. 4. Experimental environment.

ABNORMAL EVENT DETECTION FOR NETWORK FLOODING ATTACKS

1085

In our experiments, in each trail, flooding attacks are started by two PCs running 1000 DDoS attacking processes simultaneously. Three traffic change detection methods mentioned in section 2 were used to detect abrupt traffic changes caused by these attacks. Bi-direction background traffic was generated separately by two different traffic models across the experimental network to simulate typical user network traffic. The first one was the Poisson traffic model, in which the inter-arrival time is defined as t = log(1 − p )

, where λ is the average arrival rate of the traffic packets. Fig. 5 shows the λ artificial Poisson traffic collected in our experimental network. As one can see, the traffic seems to be too stable and unlike real Internet traffic. Therefore, the second background traffic model used was the WWW model. In our work, we used freeware written by S. Deng [14], which uses the Weibull and Pareto distributions, to generate WWW traffic and inject it into our experimental network (as shown in Fig. 6). −

Fig. 5. Poisson traffic.

Fig. 6. WWW traffic.

For each detection method with different time series analyses, after performing about 1000 attack experiments, we selected the parameter combination that achieved the best degree of accuracy on average. Figs. 7 and 8 show the performance of each method. In Fig. 7, “m2-30-5” means that if a user uses method 2 to perform attack detection, the best parameter combination will be 30 samples per window, where the change degree threshold is 5. In other words, “a window size of 30 and a threshold degree of 5” will be the best settings for method 2 to detect abrupt traffic changes. Methods 1~6 are described as follows:
m1: the log likelihood ratio test with AR(1) and a fixed reference window size;
m2: the log likelihood ratio test with AR(1) and a variable reference window size;
m3: the average value (or mean) comparison with a fixed reference window size;
m4: the average value (or mean) comparison with a variable reference window size;
m5: the standard derivation comparison with a fixed reference window size;
m6: the standard derivation comparison with a variable reference window size.

CHI-SHIH CHAO, YU-XIN CHEN AND AN-CHI LIU

1086

1.2

Accuracy

1

m1-30-5 m2-30-5 m3-30-2 m4-30-2 m5-30-5 m6-20-5

0.8 0.6 0.4 0.2 0 200

400

600

800

1000 1000-2

Background Traffic

Fig. 7. Detection performance with Poisson traffic.

accuracy

1.2 1

m1-30-5

0.8

m2-30-2 m3-30-2

0.6

m4-30-3

0.4

m5-15-3

0.2

m6-20-2

0 40

80

120

160

200

users

Fig. 8. Detection performance with WWW traffic.

Fig. 7 shows the best parameter combination for each attack detection method with the background traffic of a Poisson distribution. As shown in Fig. 7, the attack traffic was set to 2000 pkts/sec, and we found that most of the detection methods had good performance. This is because there was quite a large difference between the amounts of attack traffic and background traffic. Hence, later, we reduced the amount of attack traffic to 1000 pkts/sec and again used background traffic of 1000 pkts/sec to evaluate performance. The corresponding evaluation results are shown in Fig. 7, which are depicted by “1000-2”. We can find that methods 2 and method 5 with a window size of 30 and a change degree threshold of 5 achieved better performance than the others. However, it should be pointed out that the performance evaluation is made in a stable intra-networking environment. Most networks with rising and falling traffic (for example, the out-bound trunk of a campus network), require many modifications.

ABNORMAL EVENT DETECTION FOR NETWORK FLOODING ATTACKS

1087

Fig. 8 shows the best parameter combination of each detection method in the WWW background traffic test. From Fig. 8, we find that methods using the log likelihood ratio test could not achieve good detection of abrupt traffic changes in this case. However, methods 3 and 4 with 30 samples per test window and method 5 with 15 samples per test window achieved extremely high accuracy in detection. In our system implementation, according to the results shown in Figs. 7 and 8, method 4 was employed as the major method for network flooding attack detection. With traditional IDSs, pattern-matching is widely used to perform attack detection, where the content of each incoming packet is examined in detail using each rule in the IDS’s knowledge base (Fig. 9 (a)). In the worst case, the total number of pattern-matches R

needed is T = N

∑ a , where N is total number of incoming packets during a detection i

i =1

time interval, R is the number of rules in the knowledge base, and ai is the number of comparison items in rule i, respectively. In order to reduce the total number of pattern-matches, an improved pattern-matching method was developed. It classifies all incoming packets before matching patterns; that is, each incoming packet needs to only be examined based on the corresponding portion of rules (as shown in Fig. 9 (b)). For example, incoming TCP packets only need to be compared (or examined) with the TCP-related rules in the knowledge base. In the worst case, the total number of patternx

matches can be reduced to T = N +

ni

Ri

∑∑∑ a , where N is the total number of incomk

i =1

j =1 k =1

ing packets during the detection time interval, ak is the comparison number of items in rule k, Ri is the number of rules in category i, ni is the number of incoming packets in category i, and x is the number of categories. It should be noted that no matter whether it is being attacked or not, the IDS would check all the incoming packets.

TCP

TCP

TCP

UDP

UDP

ICMP

UDP ICMP ICMP

(a)

TCP

packets

rules

TCP

TCP

UDP

UDP

ICMP

UDP ICMP ICMP

(b)

Fig. 9. (a) Traditional and (b) improved pattern-matching.

However, according our observations, it is not usual for a network service (or a network server) to be attacked all the time. Of course, if an attack occurs, a serious and costly damage to the enterprise will occur if there is no protection of the IDS. In our work, as mentioned in section 2, an IDS inside an edge router, along with the improved pattern-matching method combined with effective traffic change detection, was installed in our laboratory network. When no attack occurred, the average CPU computing load on the IDS could be reduced dramatically since pattern-matching would not be enabled. When attacks occurred, the CPU computing load on our IDS increased by only around 4-6% on average.

1088

CHI-SHIH CHAO, YU-XIN CHEN AND AN-CHI LIU

4. SYSTEM IMPLEMENTATION In our system implementation, the IDS has two subsystems: one is the centralized Visual Monitor built into the Manager host, and the other is the Detector embedded in our PC-based routers (Fig. 4). To observe the behavior of network flooding attacks, the topology of the managed network is that shown in the Visual Monitor (Fig. 10). A manager can use a simple specification language to describe the managed network for the purpose of later visualized translation of the corresponding topology [15]. Users can use the Visual Monitor to obtain more detailed information regarding each interface of the managed backbone devices (Fig. 11). In addition, they can determine the behavior of flooding attacks by observing the occurrence sequence of abnormal events (alarms) in the Visual Monitor, which collects detected abnormal traffic events in all of its managed IDC-embedded routers (Fig. 10 (b)). Please note that, in Fig. 10 (b), the symbols R and symbol S in a router’s interface stand for the in-bound and out-bound abnormal traffic events detected at that interface, respectively. As mentioned in section 2, an effective network flooding attack detection system can not only provide information about attacks but also support timely actions taken to reduce or prevent damage. To do this, in our system, the manager can utilize the graphic window of the Interface View (in Fig. 11) by clicking on the designated interface of the managed devices in the Visual Monitor. Each flow shown in this view is checked by our abnormal traffic detection system. If a flow is detected as an attack, the State column of that flow will be valued “Abnormal.” In this case, the network manager can click on the “Drop” button to trigger the corresponding IDS-embedded router, which has the interface control of the abnormal flow for dropping its incoming packets. With this function, a network manager can prevent, stop, or even control network flooding attacks through timely “dropping” of the attacking packets in the proper network elements’ interfaces.

(a)

(b) Fig. 10. Topology views.

ABNORMAL EVENT DETECTION FOR NETWORK FLOODING ATTACKS

1089

Fig. 11. Device interface information.

To evaluate the detection performance of our system implementation, 1000 network flooding attacks with a variety of background traffic types were automatically performed between 2003/9/1 and 2003/10/31 in our experimental networking environment. These attack trails included three major kinds of attacking packets: ICMP, UDP, and TCP. Our system achieved good performance with more then 91% accurrancy in the detection of these network flooding attacks during the test period. Currently, we are trying to deploy our system in networks in which traffic varies hour to hour (much like the traffic in our campus network).

5. CONCLUSIONS In this study, we combined pattern-matching and traffic change detection to cooperatively detect network flooding attacks. The computation-intensive pattern-matching mechanism is enabled only when network flooding attacks are detected, so the average CPU load on the IDS is not always high. A monitoring system based on the above combination has been implemented to show how network managers can use it to take actions to prevent, stop, or even control the spread of attacks. In addition, to effectively detect the network flooding attacks, an abnormal traffic change detection mechanism with corresponding time series analysis has also been incorporated into our system implementation. Nevertheless, according to the system performance evaluation, our detection method does not work well with highly utilized network links. This is because abrupt changes within heavy network traffic become quite unclear. Thus, in the future, we will try to develop a more precise and comprehensive method for network flooding attacks to solve this problem. Moreover, our system will be applied to a wireless networking environment to develop more detection applications.

1090

CHI-SHIH CHAO, YU-XIN CHEN AND AN-CHI LIU

REFERENCES 1. A. Chakrabarti and G. Manimaran, “Internet infrastructure security: a taxonomy,” IEEE Network, Vol. 16, 2002, pp. 13-21. 2. J. McHugh, A. Christie, and J. Allen, “Defending yourself: the role of intrusion detection systems,” IEEE Software, 2000, pp. 42-46. 3. M. Fisk and G. Varghese, “Fast content-based packet handling for intrusion detection,” UCSD Technical Report CS2001-0670, 2001. 4. C. J. Coit, S. Staniford, and J. McAlerney, “Towards faster string matching for intrusion detection or exceeding the speed of snort,” in Proceedings of DARPA Information Survivability Conference and Exposition, Vol. 1, 2001, pp. 124-130. 5. Snort 2.0, Open Source Network Intrusion Detection System, http://www.snort.org. 6. R. A. Maxion and F. E. Feather, “A case study of Ethernet anomalies in a distributed computing environment,” IEEE Transactions on Reliability, Vol. 39, 1990, pp. 433-443. 7. C. S. Hood and C. Ji, “Proactive network fault detection,” in Proceedings of INFOCOM ’97, Vol. 3, 1997, pp. 1147-1155. 8. M. Thottan and C. Ji, “Adaptive thresholding for proactive network problem detection,” in Proceedings of the 3rd IEEE International Workshops on Systems Management, 1998, pp. 108-116. 9. H. Hiraishi and F. Mizoguchi, “Design of a visual browser for network intrusion detection,” in Proceedings of the 10th IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises, 2001, pp. 132-137. 10. R. F. Erbacher, K. L. Walker, and D. A. Frincke, “Intrusion and misuse detection in large-scale systems,” IEEE Computer Graphics and Applications, Vol. 22, 2002, pp. 38-47. 11. J. B. D. Cabrera et al., “Proactive detection of distributed denial of service attacks using MIB traffic variables − a feasibility study,” in Proceedings of 2001 IEEE/ IFIP Integrated Network Management, 2001, pp. 609-622. 12. C. S. Hood and C. Ji, “Beyond thresholds: an alternative method for extracting information from network measurements,” in Proceedings of 1997 IEEE Global Telecommunications Conference, Vol. 1, 1997, pp. 487-491. 13. N. Brownlee, “Using NeTraMet for production traffic measurement,” in Proceedings of 2001 IEEE/IFIP Integrated Network Management, 2001, pp. 213-226. 14. S. Deng, “Empirical model of www document arrival at access link,” in Proceedings of 1996 IEEE International Conference on Communications, Vol. 3, 1996, pp. 1797-1802. 15. C. S. Chao, Y. S. Chen, and A. C. Liu, “Statistical detection for network flooding attacks,” in Proceedings of the 2003 National Computer Symposium, 2003, pp. 1264-1273. 16. L. Deri, R. Carbone, and S. Suin, “Monitoring networks using ntop,” in Proceedings of 2001 IEEE/IFIP Integrated Network Management, 2001, pp. 199-212. 17. J. Cao et al., “Internet traffic tends to poisson and independent as the load increases,” Bell Labs Technical Report, 2001.

ABNORMAL EVENT DETECTION FOR NETWORK FLOODING ATTACKS

1091

Chi-Shih Chao (趙啟時) received his M.S. and Ph.D. degrees in Information Engineering from Feng Chia University in 1996 and 2001, respectively. From 2002 to 2004, he was the director of the Computer Resource Center, OIT, Feng Chia University. Currently, he is an Assistant Professor in the Communications Engineering Department of Feng Chia University. His research interests include VoIP performance/fault measurement, wireless LAN management, and multimedia networks/communications. In addition, he is a member of IEEE, ACM, and Phi-TauPhi.

Yu-Xin Chen (陳昱欣) received his B.E. and M.S. degrees in Information Engineering from Feng Chia University in 2001 and 2004, respectively. Currently, he is a software engineer at the Tellus Group Corp. in Hsinchu, Taiwan. His research interests include network management and embedded systems.

An-Chi Liu (劉安之) received his B.S.E.E. and M.S. degrees from National Chiao Tung University in Taiwan, and his Ph.D. degree from the University of Illinois at Chicago, in 1973, 1977, and 1981, respectively. He is a Professor at Feng Chia University, Taiwan, which he joined in 1989. From 1989 to 1994, he was the Chair of the Department of Information Engineering. From 1994 to 1998, he was the Dean of Engineering and, since 1998, he has been the President of Feng Chia University. Previously, he was a faculty member at the Illinois Institute of Technology and at North Dakota State University. His research interests include distributed processing, network management, and software engineering.