LD2: A SYSTEM FOR LIGHTWEIGHT DETECTION OF DENIAL-OF-SERVICE ATTACKS
Sirikarn Pukkawanna and Panita Pongpaibool Vasaka Visoottiviseth National Electronics and Computer Technology Center Mahidol University Pathumthani, THAILAND Bangkok, THAILAND
ABSTRACT This paper proposes a system for lightweight detection
of DoS attacks, called LD2. Our system detects attack activities by observing flow behaviors and matching them with graphlets for each attack type. The proposed system is lightweight because it does not analyze packet content nor packet statistics. We benchmark performance of LD2, in terms of detection accuracy and complexity against Snort, a popular open-source IDS software. Our evaluations focus on six types of DoS attacks, namely SYN flood, UDP flood, ICMP flood, Smurf, port scan, and host scan. Results show that LD2 can accurately identify all occurrences and all hosts associated with attack activities. Although LD2 uses higher CPU cycles than Snort, it consumes much less memory than Snort.
1. INTRODUCTION
Denial of Service (DoS) attacks pose a serious threat to the Internet. The main aim of DoS attacks is to disrupt service and network availability by attempting to reduce a legitimate user’s bandwidth, or preventing access to service or system [1]. This kind of attacks aims to make a network incapable of providing normal service by targeting either the network’s bandwidth or its connectivity. These attacks achieve their goal by sending a stream of packets to overload a victim’s network or its processing capabilities. Well-known examples of DoS attacks are flooding of TCP SYN packets, UDP packets, and ICMP packets. Before launching attacks, attackers use tools such as port scan and host scan to discover services they can break into.
In this paper, we propose a system for lightweight detection of DoS attacks, called LD2, based on the technique introduced in [2]. We systematically study effect of background traffic intensity and define appropriate threshold levels for each DoS attack. We benchmark performance of LD2, in terms of detection accuracy, CPU utilization, and memory requirement, against Snort [4], a well-known IDS software. Results show that LD2 can accurately identify all occurrences and all hosts associated with attack activities. Although LD2 uses higher CPU cycles than Snort, it consumes much less memory than Snort. We implement the LD2 system as a plug-in to a popular monitoring software called ntop [5].
This paper is organized as follows. Section 2 outlines the previous studies in the area of DoS attack detection, IDS, and Blind Classification. Section 3 describes the structure of our proposed system. The appropriate threshold level for each attack is determined in Section 4. Section 5 evaluates performance of our LD2 system. Section 6 discusses issues and concludes the paper.
2. RELATED WORK A. Intrusion Detection System (IDS)
An intrusion detection system (IDS) [6] is designed to analyze computer and network activities to detect intrusion attempts as they occur. IDSs can detect DoS attacks either by using traffic signatures or by recognizing anomalies in system behaviors. Signature-based IDS uses the signatures of the well-known attacks to determine if the packet represents a suspicious activity. On the other hand, anomaly-based IDS will detect abnormal behaviors by monitoring network traffic and comparing it with the baseline behaviors. The baseline will identify what is “normal” for that network. Then the system can trigger an alert when it finds a significantly deviation from the baseline. A hybrid IDS that uses both technologies is also possible, where both signatures and baseline behaviors are used together either in series or in parallel.
A signature-based model is common in commercial IDSs. Signature-based IDS uses known signatures, so it may not be able to catch new attacks. However, the accuracy is high and the false positive rate is relatively low. On the other hand, anomaly-based IDS can detect unknown attacks, but it may result in a high false positive rate. That is, it may flag a normal activity as an intrusion. It remains a challenge
2 of 7
for current intrusion detection technology to achieve high accuracy and low false alarms [7].
B. Snort Snort [4] is a popular signature-based IDS. It can perform
real-time traffic analysis and packet logging on IP networks. It can do protocol analysis, content searching/matching and can detect a variety of attacks and probes, such as buffer overflows, stealth port scans, CGI attacks, SMB probes, and OS fingerprinting attempts. Snort uses a flexible rule language to describe traffic that it should filter or pass. Snort has real-time alerting capability as well. It can be integrated with an alerting mechanism such as Syslog.
Since snort needs a specific signature for each attack, it may not be able to detect a new emerging attack immediately. Moreover, as we apply a lot of rules to snort, it will consume a lot of computational resources. As a result, it may start dropping packets and fail to detect attacks in real-time.
C. BLINC Port-based classification has been used extensively for
detection of applications. However, it is ineffective for applications whose ports change dynamically. A new trend of traffic classification is based on summarized flow information, such as flow duration, number of packets and packet inter-arrival time [8], [9], [10], [11]. Blind Classification or BLINC [3] introduces a new approach for traffic classification without knowledge of port numbers, user payload, or summarized flow information. BLINC represents traffic patterns with graphlets. Graphlets are created by observing behaviors of hosts in three levels—social level, functional level, and application level. At the social level, BLINC focuses on the popularity of a host, namely the number of distinct hosts that a node communicates with. At the functional level, BLINC identifies the role of a host by observing the number of source ports that a particular host uses for communication. At the application level, BLINC combines knowledge from two previous levels with transport layer interactions between hosts to identify the application of origin. BLINC classification is the process of matching flow behaviors to a set of pre-defined graphlets. A key advantage of BLINC is that it can identify unknown applications, such as a new P2P protocol and malicious flows, which may follow certain behaviors but may not use pre-defined port numbers.
3. LD2 SYSTEM
This section describes our LD2 system for lightweight DoS attack detection. The system utilizes the idea of Blind Classification. The system observes and classifies flow behaviors into graphlets of different attack types. The LD2 system targets six types of DoS attacks, namely SYN flood, ICMP flood, port scan, host scan, UDP flood, and Smurf. The six graphlets are shown in Figure 1.
A graphlet is a signature that captures behavior of a particular attack application. Each graphlet represents relationship between the use of source and destination ports, the sets of unique ports and IPs as well as the magnitude of these sets. For example, graphlets of ICMP flood, UDP flood and Smurf consist of just a single set of source/destination ports and IPs. The difference between Smurf and ICMP flood is that Smurf sends an ICMP echo request (with source address of a victim) to a broadcast address. The victim will get bombarded with ICMP echo replies from other nodes in its network. Another group of graphlets consist of multiple flows sharing all but one flow parameters. For example, SYN flood uses multiple source ports to connect to a single destination port of a victim. Port scan targets multiple destination ports with a single source port, and host scan targets multiple destination IPs.
The component of the LD2 system is shown in Figure 2. The system analyzes attack activities every one-minute interval. (See [2] for a study of appropriate interval.) Within each interval, packets are captured and classified into flows based on five tuples (srcIP, protocol, dstIP, srcPort, and dstPort). At the end of the interval, all flow records are mapped to the graphlets in Figure 1. If any graphlet is matched, we classify all flows in that graphlet as associated with attack activities. Then that graphlet is removed from the system. Unmatched graphlets are carried over once to the next analysis interval. Note that there could be multiple graphlets for each type of attack because a graphlet is indexed by source IP addresses.
We implement the LD2 system as a plug-in for ntop, an open-source software for traffic monitoring [5]. The LD2 plug-in runs as a separate thread in ntop. The LD2 thread analyzes traffic captured by the main thread of ntop. Users have options to activate, deactivate, configure, and view attack report as shown in Figure 3.
Figure 3. GUI of LD2 plug-in for ntop 4. DETERMINING GRAPHLET THRESHOLDS
A crucial element in the LD2 system is the Graphlet matching module. We note that graphlets for SYN flood, port scan, and host scan have all but one parameter fixed. For example, flows that belong to SYN flood will have the same (srcIP, prot, dstIP, dstPort), but various srcPort. Thus, the decision that a SYN flood occurs depends on how many different srcPorts we see in a SYN flood graphlet. Similarly for port scan and host scan, decision is based on number of different dstPorts and dstIPs respectively. As for UDP flood, ICMP flood and Smurf, each graphlet consists of a single flow1. Therefore, the decision is based upon number of packets in that flow. The accuracy of LD2 will depend on these decision parameters.
This section derives appropriate thresholds for each of the six graphlets. We hypothesize that the thresholds for graphlet matching would depend on intensity of background traffic. We suspect heavy background traffic would slow down the attack rate. Thus the LD2 system
1 The term “flow” here refers to ICMP packets with the same (source, destination, protocol) tuples.
would see less attack traffic in heavy traffic than in light traffic. To determine the threshold levels, we train the LD2 to recognize attack traffic at various intensity levels of background traffic.
A. Background Traffic Traces We use two types of background traffic: controlled and
real traffic traces. We run experiments at various packet rates ranging from 5,000 to 11,000 packets per second (pps).
For controlled background traffic, we use Iperf [12] to generate UDP traffic at 50 Mbps. We vary Iperf packet rates by changing average packet sizes. For example, to send background traffic at 5,000 pps, we set the packet size at 1,250 bytes and bit rate at 50 Mbps.
As for real traffic, we obtain traffic traces from the MAWI traffic traces from WIDE project [13]. These traces are collected from two sampling points at WIDE Backbone, namely samplepoint-B (100 Mbps) and samplepoint-F (150 Mbps), Traces at both sampling points are captured daily during 14.00 to 14.15. We select traces which have packet rates between 5,000 and 11,000 pps, and replay them to a controlled network environment using tcpreplay [14].
B. Experiment Setup
Figure 4. Experiment setup for LD2 threshold training
A testbed for our experiments is set up as shown in Figure 4. Three computers are connected via a hub. COM I is the traffic generator while COM II emulates an attacker computer. COM III is a target victim on which we run the LD2 system. Attack traffic is generated on COM II using following software tools: Neptune [15] for SYN flood, nmap [16] for port scan and host scan, jping [17] for ICMP flood, udpflood.c [18] for UDP flood, and smurf.c [19] for Smurf attack. For each experiment we generate one type of DoS attack for the duration of five minutes on top of a single background trace. We repeat this experiment three times for the total of 15 minutes. Then we repeat with a different type of DoS attack. Therefore one set of experiments consists of 15 minutes per attack for six attack types.
C. Learning the Thresholds We train the LD2 system to recognize all instances of
attack traffic at different levels of background traffic intensity. We obtain the graphlet thresholds by counting the number of flow parameters seen in each interval. For
COM III: Victim Sniffer (LD2 system)
COM II: Attacker
Hub
COM I: Traffic generator
4 of 7
example, to obtain a threshold for a SYN flood graphlet, we count number of source ports that manifest through the background traffic for each group of (srcIP, dstIP, dstPort) over the one-minute interval. This means if the threshold is set to be this number or lower, the instance of SYN flood will be detected. Each training set employs seven background traces, whose packet rates are from 5,000 to 11,000 pps. We use five training sets for a total of 35 background traces. Examples of training results for SYN flood over real traces are shown in Figure 5.
Figure 5. Threshold training of SYN flood
From the training results, we recognize that there is no evident relationship between the thresholds and the intensity of background traffic. Results from the other five attack types and from Iperf traces similarly invalidate our hypothesis. As a result, we consider appropriate thresholds for each attack to be independent of background traffic rate. To make the LD2 detect all attack traffic, the threshold should be at most the minimum of the values found in all training sets. To provide a safety margin, we suggest lowering the trained thresholds by another 20%. The suggested thresholds for the six graphlets are shown in Table 1.
Table 1 Suggested thresholds for attack graphlets DoS Type Threshold Parameters
(per minute) Upper Bound
Suggested Value
SYN flood Source ports 1,998 1,598UDP flood Number of UDP packets 1,918 1,534ICMP flood Number of ICMP packets 543 434Smurf Number of ICMP packets
to broadcast address 2,151 1,721
Port scan Destination ports 391 313
Host scan Destination IP addresses 5 4
The suggested thresholds seem reasonable for all types of attacks except for host scan. The minimum number of destination addresses seen per host scan activity in one-minute interval is only 5. Since the threshold value is too low, it is likely to cause false alarms, i.e., alerting normal traffic as attacks. Although the host scan graphlet seems not practical to use in real environment, it will be interesting to see what kind of traffic has a similar behavior as host scan.
It is also interesting to note that our thresholds are lower than default values suggested by firewall and Intrusion Prevention System (IPS) products [20]. Our results imply that vendor’s default thresholds would miss some attack activities. However, setting the thresholds too low may create false alarm. We evaluate effectiveness of our suggested thresholds in terms of detection accuracy and false alarms in the next section.
5. PERFORMANCE EVALUATION
In this section, we benchmark the performance of the LD2 system against that of Snort, a popular open-source IDS. Performance metrics of interest are detection accuracy, CPU utilization, and memory usage.
A. Accuracy of Single Attack Detection In this section, we evaluate the detection accuracy of our
technique against Snort. Accuracy is defined as a percentage of attack flows correctly classified as DoS attack over the total number of attack flows. In this experiment, we generate a single instance of DoS attack on top of real background traffic from MAWI whose packet rates ranges from 5,000 pps to 11,000 pps. We use two sets of background traces which are different from the traces used in the previous section in order to determine effectiveness of the trained thresholds. The setup is the same as in Figure 4. We run six sub-experiments for each of the six types of DoS attack. Within each sub-experiment, we generate six instances of the same attack over 15 minutes. We repeat this again for another 15 minutes on a second set of background traces. So there are 12 instances of generated attacks in each sub-experiment.
To evaluate LD2 detection accuracy, we enable all six attack graphlets. We configure the suggested thresholds for each graphlet according to Table 1. For Snort configuration, we configure three related default rule sets, namely dos.rule, icmp.rule, and scan.rule. The dos.rule contains a small set of signatures for detecting DoS activities. The icmp.rule contains signatures for detecting anomalous ICMP activities, such as Smurf and ICMP parameter problem. Finally, the scan.rule contains signatures to detect scanning activities, such as port scan, port sweep, and proxy scan. Note that Snort does not alert a generic host scan activity. Moreover, there is no default Snort rule that supports detection of flooding attack. Therefore, we cannot evaluate Snort’s ability to detect host scan, SYN flood, UDP flood, and ICMP flood.
Table 2 shows number of attacks correctly identified by the LD2 system at varying background traffic rate. Since we generate 12 instances of attacks in each sub-experiment, and the LD2 detects all 12 instances, the accuracy of the system is 100%. Moreover, Table 3 shows additional LD2 alerts due to flows in the background traces. Upon confirmation, additional ICMP flood and UDP flood alerts
5 of 7
are indeed ICMP and UDP flood activities. Some host scan alerts, however, are false alarms due to the low threshold. We discuss these false alarms in Section 6.
Table 2. LD2 alerts from generated attacks DoS Type Background Traffic Intensity (pps)
As for accuracy of Snort, using its default signatures,
only port scan and Smurf activities can be identified. Table 4 shows number of alert messages which correctly identify our generated port scan and Smurf. We note that number of port scan activities detected by Snort is less than 12 in most background traces. This means Snort misses some instances of port scan activities. On the other hand, Snort reports over 80,000 Smurf alerts. It is difficult to determine correctness of such report because Snort generates alerts on a per-packet basis, instead of a per-flow basis like LD2. Therefore, we show number of Snort alerts instead of computing percentage of accuracy in this case. Moreover, there are other related Snort alert messages caused by background traffic. We report them in Table 5. Most of additional alerts are due to port scan activities in background traces. Snort is able to tell which tool the port scan originates from, such as nmap or port sweep.
B. Accuracy of Mixed Attacks Detection Next we evaluate accuracy of the LD2 system when
network is under multiple attacks at once. We generate 12 instances for each of the attack types, except host scan, simultaneously over a 30-minute interval. Table 6 and Table 7 show number of attacks identified by the LD2 system and Snort, respectively. LD2 performs quite well with 100% detection accuracy for most attack types except
port scan where some activities are not detected. In addition, LD2 detects extra ICMP flood and port scan. Similarly, Snort misses some generated port scan activities, but detects other port scans from background traffic.
Table 6. Total LD2 system alerts (mixed attacks) DoS Type Background Traffic Intensity (pps)
C. CPU Utilization We compare CPU utilization between the LD2 system
and Snort. The experiment is set up as shown in Figure 4. Real traffic traces are fed into both systems for the duration of five minutes. We record CPU and memory usage of LD2 and Snort processes with sysstat tool [21] every two seconds. For LD2, we enable six attack graphlets. For Snort, we enable 36 default sets of rules (7,121 detection rules). The CPU utilization of the LD2 system and Snort are shown in Figure 6 and Figure 7.
Figure 6. CPU utilization of LD2 system
Figure 7. CPU utilization of Snort
Figure 6 shows a peak of CPU usage every 60 seconds.
That is because the LD2 system must first classify packets
6 of 7
into flows, and match the flows to graphlets every one minute. The flow state maintenance alone requires high CPU resource. Moreover, increasing packet rate of background traffic also increases the CPU usage. In our experiments, the maximum CPU utilization of LD2 is 16 percents at 7,000 pps. Snort, on the other hand, requires high CPU during the first 12 seconds. After that CPU load becomes stable. We think it is because Snort attempts to load all attack rules during startup. In our experiments, the maximum CPU utilization of Snort is 0.4 percents at 7,000 pps. In both systems, increasing traffic intensity increases the CPU utilization.
D. Memory Consumption This section uses the memory information recorded by
the sysstat tool from Section 5C. The memory usage of the LD2 system and Snort are shown in Figure 8 and Figure 9. Memory requirement of the LD2 system climbs up gradually during the first 60 seconds and becomes stable around 20 MB. On the other hand, Snort’s memory requirement is steep during the first 12 seconds. After that it becomes stable at around 300 MB. This result is similar to the behavior of CPU utilization. In addition, there is no obvious relationship between traffic intensity and memory usage.
Figure 8. Memory usage of LD2 system
Figure 9. Memory usage of Snort 6. DISCUSSION AND CONCLUSION
In this section, we discuss some issues in terms of performance evaluation between LD2 system and Snort and summarize our contributions.
Threshold—selecting appropriate threshold levels is a crucial step that determines the success of the LD2 system. In this work we demonstrate a process of threshold selection based on training the system with real traffic traces at varying intensity. We find thresholds to be independent of traffic intensity. We also find that the level of accuracy depends on choosing appropriate thresholds. We recommend network operators to fine tune the suggested threshold values to control the strictness of the detection.
Accuracy—the LD2 system can accurately identify all six types of DoS attacks as we intend to in all traces. On the other hand, Snort, with default rule sets, can only identify two types of attacks, namely port scan and Smurf activities. This is a limitation of Snort as it cannot detect rate-based attacks [22].
False alarm—setting the threshold level too low could create false alarms. In our experiments most false alarms are host scan alert messages because its threshold of host scan graphlet value is very low. However, false alarms are not always bad. It may give some information to you should concern. For example, the LD2 system is able to recognize following interesting and sometimes malicious applications as host scan.
• Bittorrent: this peer-to-peer application uses a few source ports to connect to a certain destination port at multiple destination IPs. From our traces, LD2
recognizes a lot of traffic destined to port 16881 as host scan activity. It turns out that this port is widely recommended for Azureus, a Bittorrent client.
• WinMX: this is another peer-to-peer file sharing application. A WinMX user is likely to connect to several peers using the same source and destination ports. In our experiments, LD2 identifies traffic from and to TCP port 6257 (default WinMX port) as host scan activity.
• DNS: DNS traffic is often misclassified as host scan in our experiments because a DNS server may contact a destination port of multiple clients using source UDP port 53. In addition, DNS server may connect with multiple DNS servers to update DNS cache using source and destination ports 53.
• Windows Messenger Services: we find a lot of scanning traffic on UDP port 1026. Such activity is often due to Windows Messenger Service Pop-up Spam [23].
• Trojan: we found many destination hosts are contacted at port 1027. This MS-RPC port is often exploited by Trojan horses like Backdoor.Padonock, PWSteal.ABCHlp [24].
• Worm: W32.Sasser.Worm spreads by scanning randomly-chosen machines that are vulnerable to
7 of 7
the LSASS exploit. Traffic induced by Sasser Worms behaves like host scan on TCP ports 445, 5554, 9996, and 9898 [24].
Complexity—because the LD2 system is based on flow analysis, it is more CPU intensive than Snort, which is based on packet analysis. However, the downside of packet payload analysis is that it is memory intensive. Our experiments show that Snort requires as much as 300 MB while the LD2 system requires only 20 MB of memory.
Report Readability—as shown in Section 5, LD2 system reports attack activities on a per-source-IP basis. This makes the attack report readable. Snort, on the other hand, generate alerts for every packet that matches with its signatures. This results in a large volume of alert messages that might be too complex for network operators to discern the problem. Third-party log analysis tools are necessary to help make Snort’s output more readable.
In summary, the LD2 system is better than Snort in the following features. LD2 can detect rate-based attack such as SYN flood, UDP flood, and ICMP flood. Although its goal is to detect DoS attacks, LD2 is flexible enough to recognize abnormal traffic, such as P2P file-sharing, worms and Trojans. Finally, it is less memory intensive than Snort.
On the other hand, Snort is more favorable than LD2 in following aspects. First because of more comprehensive rules, Snort can identify many types of bad traffic, besides DoS attacks. Second, it also requires less CPU resources than LD2.
Traffic monitoring and classification is necessary for organizations to observe network usage and anomalous activities in their network. In this paper, we proposed a lightweight DoS attack detection system called LD2, which is intentionally designed for the real-time traffic monitoring. We implement our system based on the concept of BLINC. The original BLINC technique is not designed for real-time classification, but in this paper, we perform experiments to prove that we can use the BLINC graphlet concept to detect DoS attacks in a near real-time manner.
LD2 offers an alternative way to monitor abnormal traffic. However, we do not intend to replace existing IDS systems, such as Snort, with LD2. Like Snort, LD2 needs some prior knowledge about attack characteristics in order to detect them. Snort requires signatures, while LD2 needs graphlets. Maintaining up-to-date LD2 graphlets, as well as their appropriate threshold levels, is crucial for a success of the LD2 system. The benefit of graphlets is that it is more flexible than the Snort rules. Graphlets can identify new attacks and emerging anomaly as long as they have similar behaviors as a known attack. In this work, we show a testament to the power of graphlets in detecting worms, Trojans, and Spam traffic. Future work includes extending LD2 to support detection of distributed DoS attacks.
REFERENCES [1] J. Mirkovic, J. Martin, and P. Reiher, “A Taxonomy of DDoS
[2] S. Pukkawanna, V.Visoottiviseth, P.Pongpaibool, "Lightweight Detection of DoS Attack", In Proc. of IEEE ICON2007, Adelaide, South Australia, November 2007.
[3] T. Karagiannis, K. Papagiannaki, and M. Faloutsos, “BLINC: Multilevel Traffic Classification in the Dark,” In Proc. of ACM Sigcomm, 2005.
[4] Snort, http://www.snort.org. [5] Ntop, http://ntop.org. [6] S. Axelsson, "Intrusion detection systems: A survey and
taxonomy," Technical Report 99-15, Department of Computer Engineering, Chalmers University, March 2000.
[7] Yan Qial and Xie Weixin, “A Network IDS with Low False Positive Rate,” In Proc. of the 2002 Congress on Evolutionary Computation, Vol.2, pp. 1121-1126, 2002.
[8] M. Roughan, S. Sen, O. Spatscheck, and N. Duffield, “Class-of-service mapping for QoS: A statistical signature-based approach to IP traffic classification,” Internet Measurement Conference, 2004.
[9] A. McGregor, M. Hall, P. Lorier, and J. Brunskill, “Flow clustering using machine learning techniques,” In Proc. of Passive and Active Measurement Workshop, 2004.
[10] D. Zuev and A. Moore, “Traffic classification using a statistical approach,” In Proc. of Passive and Active Measurement Workshop, 2005.
[11] A. Moore and D. Zuew, “Internet traffic classification using Bayesian analysis,” In Proc. of ACM SIGMETRICS, 2005.
[12] Iperf, http://dast.nlanr.net/Projects/Iperf/ [13] MAWI Working Group Traffic Archive,
dir=Misc/Exploit_Code_Archive/&sort=size&sort_mode=a [19] smurf.c, http://www.hackerzlair.org/software/c/. [20] Juniper Networks, “Denial of Service and Attack Protection,”
Firewall/VPN Feature Brief, http://www.juniper.net/products/integrated/dos.pdf, June 2006.
![Page 1: [IEEE MILCOM 2008 - 2008 IEEE Military Communications Conference (MILCOM) - San Diego, CA, USA (2008.11.16-2008.11.19)] MILCOM 2008 - 2008 IEEE Military Communications Conference -](https://reader035.documents.pub/reader035/viewer/2022080403/5750823f1a28abf34f9801d8/html5/thumbnails/1.jpg)
![Page 2: [IEEE MILCOM 2008 - 2008 IEEE Military Communications Conference (MILCOM) - San Diego, CA, USA (2008.11.16-2008.11.19)] MILCOM 2008 - 2008 IEEE Military Communications Conference -](https://reader035.documents.pub/reader035/viewer/2022080403/5750823f1a28abf34f9801d8/html5/thumbnails/2.jpg)
![Page 3: [IEEE MILCOM 2008 - 2008 IEEE Military Communications Conference (MILCOM) - San Diego, CA, USA (2008.11.16-2008.11.19)] MILCOM 2008 - 2008 IEEE Military Communications Conference -](https://reader035.documents.pub/reader035/viewer/2022080403/5750823f1a28abf34f9801d8/html5/thumbnails/3.jpg)
![Page 4: [IEEE MILCOM 2008 - 2008 IEEE Military Communications Conference (MILCOM) - San Diego, CA, USA (2008.11.16-2008.11.19)] MILCOM 2008 - 2008 IEEE Military Communications Conference -](https://reader035.documents.pub/reader035/viewer/2022080403/5750823f1a28abf34f9801d8/html5/thumbnails/4.jpg)
![Page 5: [IEEE MILCOM 2008 - 2008 IEEE Military Communications Conference (MILCOM) - San Diego, CA, USA (2008.11.16-2008.11.19)] MILCOM 2008 - 2008 IEEE Military Communications Conference -](https://reader035.documents.pub/reader035/viewer/2022080403/5750823f1a28abf34f9801d8/html5/thumbnails/5.jpg)
![Page 6: [IEEE MILCOM 2008 - 2008 IEEE Military Communications Conference (MILCOM) - San Diego, CA, USA (2008.11.16-2008.11.19)] MILCOM 2008 - 2008 IEEE Military Communications Conference -](https://reader035.documents.pub/reader035/viewer/2022080403/5750823f1a28abf34f9801d8/html5/thumbnails/6.jpg)
![Page 7: [IEEE MILCOM 2008 - 2008 IEEE Military Communications Conference (MILCOM) - San Diego, CA, USA (2008.11.16-2008.11.19)] MILCOM 2008 - 2008 IEEE Military Communications Conference -](https://reader035.documents.pub/reader035/viewer/2022080403/5750823f1a28abf34f9801d8/html5/thumbnails/7.jpg)
