Laurens Hellemons
email: l.a.j.hellemons@student.utwente.nl

Luuk Hendriks
email: l.hendriks@student.utwente.nl

Rick Hofstede
email: r.j.hofstede@utwente.nl

Anna Sperotto
email: a.sperotto@utwente.nl

Ramin Sadre
email: r.sadre@utwente.nl

Aiko Pras
email: a.pras@utwente.nl

SSHCure: A Flow-Based SSH Intrusion Detection System

SSH attacks are a main area of concern for network managers, due to the danger associated with a successful compromise. Detecting these attacks, and possibly compromised victims, is therefore a crucial activity. Most existing network intrusion detection systems designed for this purpose rely on the inspection of individual packets and, hence, do not scale to today's high-speed networks. To overcome this issue, this paper proposes SSHCure, a flow-based intrusion detection system for SSH attacks. It employs an efficient algorithm for the real-time detection of ongoing attacks and allows identification of compromised attack targets. A prototype implementation of the algorithm, including a graphical user interface, is implemented as a plugin for the popular NfSen monitoring tool. Finally, the detection performance of the system is validated with empirical traffic data.

Introduction

One third of the world population was connected to the Internet in 2011 [1]. The fact that the number of people using and relying on the Internet is increasing rapidly makes breaking into and compromising systems an ever more lucrative activity for hackers. One popular class of attack targets is that of Secure SHell (SSH) daemons. By means of SSH, a hacker can gain access to and potentially full control over remote hosts. Once compromised, a hacker can sabotage not only the host itself, but also use it for attacking other systems. The detection of intrusions, especially in the case of SSH, is therefore crucial for preventing damage to hosts and networks.

Most intrusion detection systems (IDSs) are packet-based, relying on the inspection of packet payloads [START_REF]Snort[END_REF]. In high-speed networks, specifically those with average throughputs in excess of 1 Gbit/s, such an approach is no longer feasible. Additionally, the encryption of traffic, as is the case for SSH, makes packet payload inspection problematic [START_REF] Koch | Security System for Encrypted Environments (S2E2)[END_REF]. Flow monitoring technologies, such as Cisco's NetFlow [START_REF] Claise | Cisco Systems NetFlow Services Export Version 9[END_REF] or the newer IPFIX [START_REF] Sadasivan | Architecture for IP Flow Information Export[END_REF] protocol, provide aggregated network data by means of flows. A flow is considered to be a set of packets passing by an observation point in a network during a certain time interval and having a set of common properties. Typically, these are the source/destination IP addresses and port numbers, and the transport-layer protocol [START_REF] Quittek | Requirements for IP Flow Information Export (IPFIX). RFC 3917[END_REF]. Although flow data only provides an aggregated view of the network activity, it can be used in various application areas, including network security (see [START_REF] Sperotto | An Overview of IP Flow-Based Intrusion Detection[END_REF] for an overview). As a consequence, flow-based technologies are inevitable when it comes to designing network-based intrusion detection systems for high-speed networks. In this context, Sperotto et al. have analyzed brute-force SSH attacks and identified their characteristics at the flow level [START_REF] Sperotto | Hidden Markov Model modeling of SSH brute-force attacks[END_REF][START_REF] Sperotto | Flow-Based Intrusion Detection[END_REF]. It has been shown that brute-force SSH attacks typically consist of three attack phases that can be identified using those flow characteristics.

Based on the above findings, we have developed our flow-based IDS called SSHCure for the real-time detection of brute-force SSH attacks originating from single attackers. The contribution of our work is two-fold. Firstly, we have designed an efficient and lightweight detection algorithm for SSHCure. The algorithm operates solely on flow data as exported by equipment such as NetFlow monitoring devices, and is able to both detect brute-force SSH attacks and identify compromised attack targets. Secondly, we have implemented a prototype of the IDS, realized as a plugin for the popular NfSen monitoring tool, and validated its detection performance with empirical traffic data.

The remainder of this paper is structured as follows. In Section 2, we discuss related work. The detection algorithm is presented in Section 3, followed by a description of our prototype in Section 4. The validation of the proposed detection algorithm is presented in Section 5. Finally, we close this paper in Section 6, where we draw our conclusions.

Related Work

Flow-based intrusion detection is a very active research topic [START_REF] Sperotto | An Overview of IP Flow-Based Intrusion Detection[END_REF]. The goal of the present paper is to design and implement a flow-based intrusion detection system for brute-force SSH attacks. In [START_REF] Sperotto | Hidden Markov Model modeling of SSH brute-force attacks[END_REF] it has been shown that such attacks typically consist of three phases, and a Hidden Markov Model has been proposed to model their behavior at the flow level. Often, an SSH attack starts with a horizontal scan of the (sub-)network, which means that a (usually large) set of hosts is scanned on a specific port number. This is considered the first phase of an SSH attack. Several publications have discussed flow-based detection methods for scans, such as [START_REF] Kim | A Flow-based Method for Abnormal Network Traffic Detection[END_REF], which are generally designed to detect various kinds of scans. In this paper, we use a lightweight method tailored to the specific characteristics of attacks targeting SSH daemons.

A work that is related to ours is [START_REF] Vykopal | Network-Based Dictionary Attack Detection[END_REF], which proposes an algorithm for the flow-based detection of SSH dictionary attacks. In the three-phase model that we use in our paper, dictionary attacks correspond to the second phase of the attack, while we aim to detect attacks earlier, during their scanning phase.

For implementing our IDS, several frameworks and architectures are possible. One option is a framework called TOPAS (Traffic flOw and Packet Analysis System), proposed in [START_REF] Münz | Real-time Analysis of Flow Data for Network Attack Detection[END_REF], which analyzes flow data in real-time through userdefined detection modules. Another modular approach to flow analysis applications is the plugin framework provided by NfSen (NetFlow Sensor) [START_REF] Nfsen | [END_REF]. This has been used by SURFmap [START_REF] Surfmap | [END_REF][START_REF] Hofstede | SURFmap: A Network Monitoring Tool Based on the Google Maps API[END_REF], for example. NfSen supports plugins for raw data processing, as well as data visualization. It is widely deployed, well known within the research community and is considered to be among the state-of-theart tools for network monitoring. As such, we have decided to develop SSHCure as a plugin for NfSen.

Detection Algorithm

In this section we will provide the background for the types of SSH attacks we consider, and discuss the metrics used for identification of the three attack phases (Section 3.1). After that, our algorithm will be presented in Section 3.2.

SSH Attack Analysis

The work in [START_REF] Sperotto | Hidden Markov Model modeling of SSH brute-force attacks[END_REF][START_REF] Sperotto | Flow-Based Intrusion Detection[END_REF] has analyzed the flow-level characteristics of SSH intrusion attacks, in particular focusing on SSH dictionary attacks. For this type of attack, the authors of [START_REF] Sperotto | Hidden Markov Model modeling of SSH brute-force attacks[END_REF][START_REF] Sperotto | Flow-Based Intrusion Detection[END_REF] have found that the analysis of the attacker behavior over time, based on flows, shows a clear pattern of the evolution of the attack. Such an analysis is based on the connection pattern between the attacker and its targets, and on the intensity of the traffic in terms of packets-per-flow (PPF).

Figure 1(a) visualizes such a connection pattern for an attack monitored at the University of Twente (UT). The UT campus network uses a /16 IPv4 address block. In the figure, we show how the attacker connects to the different IP addresses of the UT address block over the attack duration of around 2700 seconds. Every point in the plot corresponds to a flow record from the attacker to the UT network, respectively, from UT hosts back to the attacker. Three phases can be identified [START_REF] Sperotto | Hidden Markov Model modeling of SSH brute-force attacks[END_REF][START_REF] Sperotto | Flow-Based Intrusion Detection[END_REF]:

1. Scanning phase -The attacker scans an IP address block in order to find hosts running an SSH daemon (TCP port 22); 2. Brute-force phase -The attacker tries to login to a small subset of the scanned hosts, using a large number of username/password combinations; 3. Die-off phase -After a successful login, there is still traffic between the attacker and the compromised target. This residual traffic is due to commands being executed by the attacker on the target host.

For the specific case depicted in Figure 1(a), the scanning phase takes place from the beginning of the attack until t ≈ 1000s, immediately followed by the bruteforce phase, which terminates at t ≈ 1750s. Finally, residual traffic is present on the network until t ≈ 2750s after the beginning of the attack. A different view on the attacks is given by Figure 2(a). Each mark in the graph either represents a malicious connection from the attacker to a victim or the answering connection from the victim back to the attacker. The y-axis gives the 65,535 possible destination addresses in the university network. We identify three attack phases. During the scanning phase (first 1000 seconds), the attacker performs a sequential SSH scan spanning over the entire network address space. In this phases, the attacker gathers information on which hosts run a vulnerable SSH service. Only few victims respond to the attack. Once this phase is completed, the attacker initiates a brute-force user/password guessing attack (brute-force phase). In this phase, only a small subset of the hosts in A different view on the attacks is given by Figure 2(a). Each mark in the graph either represents a malicious connection from the attacker to a victim or the answering connection from the victim back to the attacker. The y-axis gives the 65,535 possible destination addresses in the university network. We identify three attack phases. During the scanning phase (first 1000 seconds), the attacker performs a sequential SSH scan spanning over the entire network address space. In this phases, the attacker gathers information on which hosts run a vulnerable SSH service. Only few victims respond to the attack. Once this phase is completed, the attacker initiates a brute-force user/password guessing attack (brute-force phase). In this phase, only a small subset of the hosts in (b) Time-series for packets-per-flow (PPF) Fig. 1. Traffic generated by SSH attack, from [START_REF] Sperotto | Hidden Markov Model modeling of SSH brute-force attacks[END_REF] Figure 1(b) provides a different view on the attack. It shows how the number of PPF changes over the attack duration: the scanning phase is characterized by small flows; the brute-force phase by the exchange of a significant number of packets in a short amount of time; finally, the die-off phase by sporadic residual traffic. Since detection of attack phase transitions is essential in SSHCure, the PPF metric will play a prominent role within our detection algorithm, which will be presented in the next subsection.

The three phases described above allow for a wide range of attack evolutions. For example, some attacks stop before passing through all three phases. In addition, measurements performed on the UT campus network have shown that a significant portion of recently observed SSH intrusion attacks start directly in the brute-force phase (i.e. without passing through the scanning phase). The state machine in Figure 2 describes how attacks can evolve through the different phases.

Algorithm

Core to the operation of SSHCure is the SSH intrusion detection algorithm, based on the attack analysis presented earlier. The algorithm classifies attacks into one or more subsequent attack phases, according to the state-machine in Figure 2. The traffic metrics used by the algorithm are calculated with a time granularity of 1 minute. In the remainder of this section, we present how the algorithm detects each attack phase.

Scanning phase

During the scanning phase, an attack has some clearly distinguishing characteristics. Since attacks are assumed to originate from a single attacker, many small flows from the attacking host to a large number of targets is an indication of an attack in the scanning phase. The detection algorithm selects suspicious traffic by means of the following two metrics: 1. Packets-per-flow (PPF): The algorithm uses an upper limit of 2 PPF during the scanning phase, which is a typical feature of a port scan. Unlike attack traffic, regular SSH connections will use the same TCP connection once established, which will result in a higher value for the PPF metric. 2. Minimum number of flow records: If only the PPF metric was used for distinguishing scanning traffic, regular SSH traffic could still be classified erroneously as scanning traffic. This is, for example, the case with SSH sessions involving sporadic activity, because flow monitoring devices divide long-lived flows into multiple flow records. This fact is not a limitation of our algorithm, but of the design of flow monitoring technologies [START_REF] Claise | Cisco Systems NetFlow Services Export Version 9[END_REF]. To overcome this issue, a threshold for the number of flow records per attack in the scanning phase has been defined. Based on measurements in the campus network of the UT in 2011, a value of 200 flow records per time interval of 1 minute was chosen. This threshold corresponds to roughly 200 SSH connection attempts per minute, which is almost guaranteed not to be regular SSH usage.

As soon as scanning traffic is detected, both the attacker and target IP addresses are stored for further processing.

Brute-force phase

As shown in the state-machine depicted in Figure 2, attacks can enter the bruteforce phase either after the scanning phase, or by starting the attack directly from this phase. For identifying the brute-force phase of an attack, the following metrics are used:

1. Packets-per-flow (PPF): Figure 1(b) shows a sharp increase for the PPF metric on the transition of the scanning phase (1.5 PPF on average) to the brute-force phase (11 PPF on average). A PPF value between 11 and 14 is likely to represent 3 (failed) login attempts on an sshd1 , depending on its configuration. To allow for some margin, our algorithm classifies traffic with a PPF of 8-14 as brute-force traffic. These bounds were chosen based on measurements in our campus network.

2. Minimum number of flow records: Since we allow intrusion attacks to enter the brute-force phase without passing through the scanning phase, regular SSH traffic can be classified as brute-force traffic when only the PPF metric is applied. This is the case for benign failed login attempts, for example. These false positives can be avoided by including a lower bound for the number of flow records in the brute-force phase. Measurements on the campus network of the UT in 2011 have shown that a threshold of 20 flow records per minute (per attacker) is a reliable metric for distinguishing brute-force traffic.

Attacker and target IP addresses involved in the brute-force phase are stored for further analysis. For example, to increase our confidence in the presence of an ongoing attack, SSHCure will try to correlate brute-force traffic with scanning traffic. It should be noticed that an attacker can only evade detection by performing both the scanning and the brute-force password guessing very slowly, thanks to the multi-phase detection approach used by SSHCure. Although such tactics are possible, they are atypical for dictionary attacks.

Die-off phase

Attacks can only progress to the die-off phase after passing through the bruteforce phase. The die-off phase will again be identified using the PPF metric, which will change significantly on transition from the brute-force phase. We identify die-off traffic when its characteristics differ from the brute-force phase.

In particular, we concentrate on the values P P F < 8 ∨ P P F > 14. Traffic with a P P F < 8 can indicate an idle connection between an attacker and a (compromised) attack victim. On the other hand, traffic with a P P F > 14 can be a sign of a victim being actively used by an attacker.

The intrusion detection algorithm, as has been discussed in this subsection, will be the core of our intrusion detection system. The next section will discuss SSHCure's overall architecture, which includes its other components, such as data visualization and anonymization components.

Prototype

In this section we present the developed prototype. SSHCure has been implemented as a plugin for NfSen, an open-source and highly customizable platform for flow monitoring [START_REF] Nfsen | [END_REF]. In the following subsections we describe its architecture and provide an introduction to the user interface and its functionality.

Architecture

Due to the fact that SSHCure has been implemented as a plugin for NfSen, it consists of a front-end and a back-end. The purpose of the front-end is data visualization, while the back-end is used for flow data processing. Figure 3 depicts the plugin's architecture. SSHCure builds upon the NfSen internal architecture, -Time window selector -A user can select the time period for which attacks and statistics regarding frequent attackers and targets will be displayed. All contents of the Dashboard page are subject to this selection; -Attack history graph -This graph shows a history of the number of ongoing attacks during the selected time period; -Attacks listing -This table shows all attacks that occurred during the selected time period, including the IP address of the attacker, the number of targeted hosts, the most advanced phase detected, and whether the attack is still ongoing; -Top attackers listing -This table contains the most prolific attackers during the selected time period. For each of these attackers, the number of involved attacks and targets are shown; -Top targets listing -This table lists the hosts that were targeted most often during the selected time window. It shows the number of times each target was attacked, the number of different attackers that targeted it and the number of times it was compromised.

Attack details

The user is able to obtain detailed information about any attack, attacker or target by clicking on its entry on the Dashboard page. When an attack is selected in this way, the user is taken to the Attack Details page. A screenshot of this page, which allows the user to browse through all information relating to a specific attack, is shown in Figure 5. It consists of the following elements: the phases each of them was involved in. Clicking on an entry shows the flows between that target and the attacker in the Flow listing; -Flow listing -This table lists all flows between the attacker and a selected target captured during the attack, sorted by start time. For each flow, the start and end times, flags, number of packets and bytes, and the direction (whether it was initiated by the attacker or by the target). This listing enables the user to do a detailed investigation and analysis of the events during the attack.

Finally, we aim at extending the user interface with a Host Details page, which would present detailed information about an attacker or target, such as reverse DNS and geolocation data, together with an overview of the attacks in which the selected host has played a role. Such an extension is currently under development.

To validate the proposed detection algorithm, we utilized two data sets. The first set, which was also used in [START_REF] Sperotto | Hidden Markov Model modeling of SSH brute-force attacks[END_REF], was captured at the UT in 2008 and consists of one week of flow data. The second data set is comparable to the fist one (one week of data captured in the UT network), but it has been captured in February 2012. The aim of our validation was to investigate whether the proposed algorithm is able to identify attacks and classify them according to the attack phases discussed before. Both data sets were analyzed manually to establish a ground truth for validation, with each incident being classified according to the phases found to have occurred. The detection algorithm was then run on the data sets and the reported incidents were cross-referenced with the manual analysis.

The results are listed in Table 1. This table lists, most importantly, the number of true positives (incidents from the ground truth classified correctly by the algorithm), false negatives (incidents not classified correctly) and false positives (non-incidents classified as attacks by the algorithm). By manual inspection, we identified 29 attacks in the data set of 2008 and 101 incidents in the data set of 2012. According to our algorithm, 17 attacks progressed to the brute-force phase, and only 16 to the die-off phase. Similarly, we have 58 incidents labeled as brute-force attacks in 2012, of which 25 reached the die-off phase.

Several remarks can be made regarding these results. Firstly, there were no false positives at all, so all the reported incidents were actual attacks. Secondly, only two false negatives were identified. Closer inspection of both of these cases revealed that this was due to the the chosen threshold values in the algorithm. Since the algorithm averages PPF values of flow records over a time interval of one minute, the scanning phase detection was distorted by unexpected intermediate traffic, which resulted in an artificially high PPF value. When the scanning phase's PPF value was then finally measured, the threshold for the minimum number of flow records was no longer satisfied. These issues are therefore both due to the choice of limits and thresholds, not the nature of the algorithm itself.

Our validation confirms that the algorithm conforms to the analysis presented in Section 3.1 and that it is still valid for use in today's networks. It is important to note that attacks measured to have reached the die-off phase indicate that hosts were most likely compromised. The number of attacks measured during the comparatively brief measuring periods that were classified as such, serves as an affirmation of the need for a network-wide intrusion detection system.

Conclusions

In this paper, we presented an intrusion detection system (IDS) plugin for NfSen, named SSHCure, which is able to detect SSH intrusion attempts and compromised hosts using flow data. These attacks consist of three phases: a scanning phase, a brute-force phase and a die-off phase, based on the analysis in [START_REF] Sperotto | Hidden Markov Model modeling of SSH brute-force attacks[END_REF]. Our algorithm utilizes a set of rules for identifying attacks and profiling them according to these phases, based on metrics such as packets-per-flow (PPF) and the number of flow records per minute. The upper/lower limit values for these metrics were established based on measurements on the UT campus network in 2011.

Validation of the proposed detection algorithm has shown that SSH intrusion attacks and compromised hosts are identified accurately and that the number of false positives and false negatives is low. This can be concluded from a ground truth validation using the data set used in an earlier work, and from manual ground truth validation using data collected in 2012 on the UT campus network.

As future work we plan to investigate the effects of packet sampling on the accuracy of our algorithm. Depending on the sizes of SSH attacks, the used metrics for detecting the various attack phases may need adaption to the applied sampling ratio. In addition, we plan to extend the algorithm to explicitly target distributed SSH dictionary attacks. In its current state, distributed attacks appear as a set of individual attacks in the algorithm's results, without further aggregation.

Fig. 2 .

 2 Fig. 2. Temporal visualization of a brute-force SSH scan (a) and variation of packets per flow during the scan (b)

Fig. 2 .

 2 Fig. 2. Temporal visualization of a brute-force SSH scan (a) and variation of packets per flow during the scan (b)

Fig. 2 .

 2 Fig. 2. Attack phase state-machine

Fig. 4 .

 4 Fig. 4. Screenshot of SSHCure's Dashboard page

Fig. 5 .

 5 Fig. 5. Screenshot of SSHCure's Attack Details page

Table 1 .

 1 Validation results

	Data set	2008 2012
	Incidents (scanning phase)	29 101
	Incidents (brute-force phase) 17	58
	Incidents (die-off phase)	16	25
	True positives	28 100
	False negatives	1	1
	False positives	0	0

sshd is a commonly used abbreviation for SSH daemons.

Note that all IP addresses in this paper are anonymized.

Acknowledgments

The presented work is supported by the EU FP7-257513 UniverSelf Collaborative Project and the SURFnet GigaPort3 Project for Next-Generation Networks.

thus being able to access flow data in 5-minute chunks from the NfSen flow data repository. The NetFlow Data Processor component accesses the data and applies the detection algorithm discussed in Section 3.2 to it. More precisely, data chunks of 5 minutes are divided into chunks of 1 minute, to increase the precision of the algorithm's metric calculations. To make sure that the original flow data remains unchanged, SSHCure produces new attack meta-data on SSH intrusions, which is stored in a database by the Database Handler.

When SSHCure's front-end is called from a Web browser, attack meta-data is retrieved from the database by the Database Handler. The Visualization Processor is in charge of building a graphical representation of this data, which is presented to the user by means of SSHCure's Web interface. The Visualization Processor requests graphs from the Graph Generator, which is located in the back-end in order to take advantage of NfSen's internal graphing functionality. Although SSHCure's main information source is the attack meta-data, raw flow data and several types of statistics can be accessed from the front-end as well, in order to provide as much information about attacks as possible. Both the raw flow data and the meta-data can be anonymized before visualization.

User Interface

The SSHCure Web interface allows a user to browse the detected attacks, to obtain all information needed for analysis or administrative purposes. As described above, this information includes both attack meta-data, produced by SSHCure's detection algorithm, and raw flow data. The Web interface consists of the following pages: the Dashboard page, providing an overview of ongoing and completed attacks; the Attack Details page, providing insights on a specific attack; and the Host Details page, focusing on a single attacker or target host.

Dashboard Figure 4 shows a screenshot 2 of SSHCure's Dashboard page, which is the main page of the plugin. The Dashboard page contains the following elements:


Ricardo De O Schmidt
email: r.schmidt@utwente.nl

Anna Sperotto
email: a.sperotto@utwente.nl

Ramin Sadre
email: r.sadre@utwente.nl

Aiko Pras
email: a.pras@utwente.nl

Towards Bandwidth Estimation using Flow-level Measurements

Bandwidth estimation is one of the prerequisite for efficient link dimensioning. In the past, several approaches to bandwidth estimation have been proposed, ranging from rules-of-thumb providing overprovisioning guidelines to mathematically backed-up provisioning formulas. The limitation of such approaches, in our eyes, is that they largely rely on packet-based measurements, which are almost unfeasible considering nowadays load and speed (1-10 Gbps). In this context, flow-based measurements seems to be a suitable alternative, addressing both data aggregation as well as scalability issues. However, flows pose a challenge for bandwidth estimation, namely the coarser data granularity compared to packet-based approaches, which can lead to a lower precision in the estimation of the needed bandwidth. In this paper, we investigate what is the impact of flow-based measurements on bandwidth estimation. In particular, we are interested in quantifying the impact of flows on main statistical traffic characteristics, in particular the traffic rate variance. Our approach is validated on real traffic traces captured from 2002 to

Introduction

Bandwidth provisioning is one of the key activities of network management toward achieving desired levels of quality of service. Current practices of provisioning by network operators are based on rules-of-thumb and on rough traffic measurements. For example, traffic averages can be obtained using the Simple Network Management Protocol (SNMP) [START_REF] Schönwalder | Simple Network Management Protocol (SNMP) Context EngineID Discovery[END_REF], usually at timescales of 5 minutes. The link provisioning is done by adding to the average obtained via SNMP a safety margin (e.g., 30% of the calculated average). However, as shown in [START_REF] Meent | Traffic Measurements for Link Dimensioning, A Case of Study[END_REF] and [START_REF] Papagiannaki | Network Performance Monitoring at Small Time Scales[END_REF], such practices based on traffic measurements at large timescales (i.e., intervals of minutes) completely overlook traffic variations on smaller timescales due to averaging. Consequently, the link usage and the bandwidth need are not correctly estimated, resulting in poor network performance (in the case of underestimation), respectively waste of resources (in the case of overestimation).

In general, the key challenge in bandwidth provisioning is to create an adequate model of the current and future traffic behavior. For example, the work in [START_REF] Meent | Network Link Dimensioning -a measurement & modeling based approach[END_REF][START_REF] Pras | Dimensioning Network Links: A New Look at Equivalent Bandwidth[END_REF] is based on the assumption that the traffic rate in fast networks is Normal distributed. Gaussianity is also exploited in [START_REF] Fraleigh | Provisioning IP Backbone Networks to Support Latency Sensitive Traffic[END_REF]. Although these approaches provide accurate results, they require the knowledge of the variance of the traffic rate on small timescales. The variance, as well as other statistics, are usually obtained from packet traces. Similarly, also non-Gaussian models, such as the Batch Markovian processes used in [START_REF] Klemm | Modeling IP traffic using the batch Markovian arrival process[END_REF], rely on packet traces for their parameterization.

Considering the high traffic rates observed in today's networks, such as Internet backbones, approaches relying on packet measurements can be considered as problematic. Packet monitoring suffers from scalability and requires powerful and often expensive monitoring devices. Researchers try to circumvent this problem. For example, in [START_REF] Meent | Network Link Dimensioning -a measurement & modeling based approach[END_REF], an inversion procedure was proposed to indirectly estimate traffic statistics by sampling the buffer content.

In this light, flow monitoring seems to be promising approach to the bandwidth estimation problem. A flow is defined as a set of packets sharing common properties and passing through an observation point [START_REF] Quittek | Requirements for IP Flow Information Export (IPFIX)[END_REF]. Flow monitoring is supported by various software tools, as well as by network equipment [START_REF][END_REF]. Hence, flow-based approaches are considered to be easily deployable into existing highspeed networks.

However, flow monitoring generally results in an inherent loss of information, because individual network packets are aggregated by flow probes into so-called flow records. Such a flow record only contains a summary of the characteristics of the packets inside a flow. This problem has led us to the following research question: Is it possible to use flow-level measurements instead of packet-level measurements to obtain traffic statistics? and, if so, what is the error in flowlevel measurements introduced by the averaging of traffic information?. In order to answer these questions, we will estimate the bandwidth variation in network traffic from flow measurements and compare the results with those obtained from packet measurements. Furthermore, we will study the impact of the parameters of the flow building operation on the accuracy of the results.

We are not the first to study flow-based approaches for provisioning. Most notably, the authors of [START_REF] Barakat | Modeling Internet backbone traffic at the flow level[END_REF] estimate statistics of the traffic rate from flow characteristics. The underlying model requires that the network links are not congested and an adaptation to the considered traffic is needed. In [START_REF] Bonald | Dimensioning high speed IP access networks[END_REF], a link shared by several users is studied, assuming that the traffic can be described by a superposition of flows. However, only elastic data traffic (TCP connections) is considered. Differently to the work above, our approach is more measurement oriented, focusing on the limitations of flow-level measurements and on the information that can be gained from flow monitoring, while using a simple model of the traffic behavior on flow level.

The rest of this paper is organized as follows. A more detailed description of the problem is given in Section 2. In Section 3, we introduce our approach to estimate the bandwidth variation. In Section 4, our experiments are described and results are presented. Finally, conclusions are drawn in Section 5.

Problem Definition

Flow-level measurements are a suitable alternative to packet-based measurements in cases in which scalability is a requirement, as it is often the case in high-speed environments with traffic rates of several Gbps. However, scalability does not come for free: since flows provide an aggregated view of streams of packets, we are dealing with information at a coarser granularity compared to packet-based measurements. Particularly and importantly for the case of bandwidth estimation, flow monitoring does not provide us any information about the timing distribution of packets within the flow. Typically, the flow record exported by the flow probe specifies, among others, the total number of packets and bytes, and the observation time of the first and last packet of the flow. Figure 1 presents an example comparing packet and flow measurements. Host A sends a stream of packets of constant size S to host B over a link from time t s to time t e . Around time t i host A generates a burst of packets, which would be correctly reported by a packet-based measurement. From a flow perspective, the stream of packets from host A to host B is seen as a single flow of n packets with duration t e -t s . Consequently, we would observe a constant bandwidth usage equal to nS/(t e -t s ) bytes/sec, and the traffic burst would be canceled out, as shown in the example time series of Figure 1(b).

To overcome this problem, in our approach we assume the bytes to be uniformly distributed within the duration of the flow. Such an assumption is critical for the problem of bandwidth estimation, since it can have a direct impact on the measured bandwidth. Under the assumption of uniform distribution, each flow record contributing to the bandwidth calculation also introduces a measurement error compared to the real traffic situation. The aim of this paper is to quantify the impact of such an error in the overall statistical characteristics of the traffic.

Step 4:

Calculate traffic statistics

Step 3:

Time series creation

Step 2:

Packets to flows conversion

Step 1: Traffic capture at packet-level Fig. 2: The steps of the approach.

Flow-based Approach

In this section we describe our approach for answering the research questions presented in Section 1. We begin with a general description of the approach and its components, followed by the procedure for creating flow-based time series and extracting the desired statistics from them.

Approach Structure

As already mentioned, a flow is a set of packets that have common properties and pass through an observation point in the network. Depending on how flow probes are implemented, a single observed flow can be exported as several flow records.

The number of exported flow records reporting a single flow will be determined by the exact flow definition used by the flow probe, as further explained in Section 4.2. Usually, flow records contain information such as: start and end time, number of packets and bytes, source and destination IP addresses and ports, and others. The main goal of our approach is to estimate the variance of the traffic rate from flow-level measurements. Figure 2 illustrates the different steps of our approach. Traffic data captured on packet level in step 1 is first converted into flow records in step 2. In the third step, we create the traffic rate time series. This procedure is detailed in Section 3.2. We calculate the traffic statistics from the resulting data in step 4. Importantly, in the first step we use packet-level captures done with tools like tcpdump because our implementation currently operates offline. These captures are stored in pcap files and converted into flow records in the second step. For this conversion we use the tool YAF (Yet Another Flowmeter) [START_REF] Inacio | YAF: Yet Another Flowmeter[END_REF].

Creating Flow-level Time Series

In this section we detail the procedure of creating flow-level time series. For this, we only need the following information from the flow records: the start time s, the end time e and the number of bytes b. Initially, the flow records are placed in a timeline that lasts from s of the first flow record to e of the last flow record in the measurement period.

A flow time series T F is a sequence of values that represent the link usage (i.e., traffic rate) during the entire measured period. The timeline is defined as T F = {B F,i }, 1 ≤ i ≤ m, where B F,i is the link usage in the time interval t i = [i∆, (i + 1)∆[. The interval size ∆ defines the time granularity for the following computations (i.e., timescale).

In order to create T F , we have to calculate for each time interval t i the amount of bytes transfered in that interval, under the assumption that the bytes belonging to a flow (record) are uniformly distributed over the flow duration. Let's consider a set of flow records F that contains n records f j , 1 ≤ j ≤ n. The subset of flow records that contribute to the traffic rate in time interval t i is given by

κ i = {f j ∈ F : s j < (i + 1)∆ ∧ e j i∆}.
Then, we calculate for each flow record in κ i the amount of bytes it contributes to the time interval t i . The sum over all flow records in κ i gives the total number of bytes S i transferred in t i

S i = fj ∈κi max (min((i + 1)∆, e j ) -max(i∆, s j ), 1)
max(e j -s j , 1)

• b j (1)
The above formula accounts for the fact that flows do not necessarily start (end) exactly at the beginning (end) of the time interval t i . It considers the fraction of bytes in relation to the flow record duration within the specific interval. The max function in the divisor avoids a division by zero when the flow record only contains one packet, i.e., the start time is equal to the end time. The flow-based link usage B F,i in t i is then given by dividing S i by the size of the chosen timescale

B F,i = S i ∆ (2)
Analogously, we can create a packet timeseries T P from the packet data. For a time interval t i , B P,i gives the overall number of bytes of all packets that have been monitoring in that interval, divided by the timescale ∆. In the following, we express B F,i and B P,i in Mbps.

Metrics of Interest

In this paper, we are interested in assessing the impacts of averaging in flows on the main statistical characteristics of the traffic. Since all packets are accounted in the flow measurements, it will clearly be able to correctly estimate the mean bandwidth usage B F . In our experiments we particularly focus our attention on the following metrics of interest.

Variance of the traffic rate:

The averaging introduced by the use of flow measurements can have an impact on the variance of the time series T F . This is due to the fact that short traffic peaks can be evened out by the assumption that the bytes are uniformly distributed over the duration of a flow record. The variance V F of the flow time series is defined as

V F = 1 m m i=1 B F,i -B F 2 . ( 3
)
For the packet data, V P is defined accordingly.

Variance error:

We investigate the error introduced by the flow-based approach by calculating the variance relative error, expressed in percentage

V e rr = |V P -V F | V P • 100%. ( 4
)
Bandwidth error: In addition to the error of the variance, we are also interested in the error introduced per time interval t i , i.e. the average bandwidth error calculated by comparing the packet-based and flow-based time series. We define:

B err = 1 m m i=1 |B P,i -B F,i |. ( 5
)

Experiments

This section presents the experimental results obtained when using flow-level traffic time series. First, we describe the measurement dataset used in our analysis. Then, we discuss how different flow definitions may impact on the time series. Finally, we present our analysis methodology and our results.

Traffic Traces

The dataset used to validate our approach contains hundreds of 5-minute traces measured in three different links. These traces have been collected in 2002, 2003 and 2011. The measurements from 2002 and 20031 have already been used for validation in [START_REF] Meent | Network Link Dimensioning -a measurement & modeling based approach[END_REF][START_REF] Pras | Dimensioning Network Links: A New Look at Equivalent Bandwidth[END_REF], and the 2011 traces were collected for these experiments. Traces from 2002 have been captured on a 300 Mbps Ethernet link that connects a residential network to the core network of a university. At the time of the measurements, the network segment had about 2000 users, each with a 100 Mbps access link, and the link average usage was around 60%. We will refer to this set of traces as Location 1 (abbr. loc1 ).

Traces from 2003 have been collected on a 1 Gbps link connecting a large college to the Dutch academic and research network. At that time, about 1000 users had access to the link, each with a 100 Mbps access link. The average usage of the measure link was between 10% and 15%. We refer to this set of traces as Location 2 (abbr. loc2 ).

Finally, traces from 2011 consist of the incoming/outgoing traffic of a university's building, captured on the uplink and downlink connecting the building to the university's main router. Both links allow for 1 Gbps traffic and they have an average usage of around 15%. We will refer to this set of traces as Location 3 (abbr. loc3 ). Table 1 summarizes our dataset.

Flow Definitions

The flow creation process, which converts packet-based measurements into flows, can influence the precision of the flow-based time series as created by the approach described in Section 3.2. Flow records are usually exported on the basis of timers, namely active and inactive timeouts. Such timeouts are parameters by which we can obtain shorter or longer flow records. The active timeout controls the maximum duration of a flow record before it is exported. Inactive timeout, on the other hand, is used to decide if a flow can be considered definitely idle, and therefore exported.

In our experiments we generate flow-level time series using different combinations of timeouts, as listed in Table 2. The different timeouts allow us to analyze the loss on traffic information due to averaging at the flow-level and, at the same time, they control the number of flow records we should analyze. When timeouts are considerably long, the traffic averaging may have a significant impact, since the real packet arrival rate is smoothed out for the entire duration of the flow. Consequently, significant traffic fluctuations may completely vanish from the time series. On the other hand, the number of flows to be processed is reduced.

With shorter timeouts, the effect of averaging will be limited because longs flows are divided into multiple flow records. This way, traffic fluctuations may still be present in the flow-level time series. But, due to a larger number of exported flows, there may also be an additional overhead. Our aim is to quantify the error introduced by traffic averaging for different combinations of timeouts.

Methodology

In this paper, we compare flow-based time series with a ground truth consisting of the packet-based time series for the same traffic. The methodology adopted to analyze the traffic traces is structured according to the following two steps:

1. Qualitative analysis: the first step consists in the manual comparison of the flow-based and packet-based time series. The aim of this step is to identify situations in which these time series show a different behavior, and to investigate the causes for such a deviation. Such analysis is conducted for different flow timeouts, as explained above. 2. Error analysis: the second step targets the quantitative analysis of the statistical characteristics of the flow-based time series compared to the packetbased one. For this analysis, we compute the main metrics of interest, described in Section 3.3. Also in this case, we investigate the effect of the flow timeouts on the statistical metrics.

Qualitative Analysis

Due to space issues, we present the qualitative analysis for a single trace from Location 2 only. We chose this particular trace because it illustrates well all the significant differences between packet-level and flow-level time series. To facilitate explanations and comparisons, the following plot only contain flowlevel time series of two flow definitions: a5i2 and a120i30. Time is ∆ = 1 second. Figure 3 illustrates the differences between packet-level and flow-level time series. At the beginning of the time series, one can clearly see the impact of the averaging process. The situation between 12:05:01 and 12:07:01 illustrates the problems of averaging when defining flows with long timeouts. During this period, most traffic was generated by a single flow and, for the definition a120i30, it was exported as a single flow record. As one can see from the packet-level time series, the traffic increased significantly at around 12:05:40. That is, the major portion of bytes was transmitted few seconds after the beginning of the flow. Ignoring the actual distribution and assuming uniformity, our approach averages all the bytes within the entire flow duration. Comparing the two flow time series, we observe that the a5i2 series closely follows traffic fluctuations. The is that, unlike a120i30, the a5i2 definition exports long flows as several consecutive and smaller flow records. It means that the averaging of traffic is limited to intervals of 5 seconds (the active timeout) at maximum.

The problem of averaging in flows is present again at 12:09:21 -12:09:41 , shown in isolation in Figure 4(a). In this period, there is a sudden drop in the traffic rate for a few seconds. The flow-level time series do not follow this drop because they take into account bytes of flows that started before and ended after this specific time bin. As can be seen in the figure, this effect is stronger for larger timeouts.

A third interesting situation is presented in Figure 4(b), extracted from the period 12:07:41 -12:08:01 of the trace. In this case, both flow definitions do follow remarkably well the traffic fluctuations occurring on packet level. This happens when (i) flows have a constant traffic rate, i.e., the flow records represent well the packet-level dynamics, or when (ii) flows are short (including flows consisting of only one packet) and fit into one time interval.

Error Analysis

This section presents the traffic statistics calculated from flow-level time series and compares them with those from packet-level time series. Note that we give all results in Mbps.

Table 3 gives the results for the traces from Location 1 for three different timescales ∆ (1, 10 and 30 seconds). For each timescale, we show the average bandwidth error B err between the flow and the packet timeseries, the variance V of the traffic rate, and the relative error V err of the variance. One can observe that the best approximation to the packet timeseries is mostly obtained by the flow timeseries with shorter timeouts because they reproduce traffic fluctuations better. Compared to the mean bandwidth of around 277.4 Mbps, the average bandwidth error is very small, although the variance error is much higher. In addition, we see that the variance and the errors generally decrease with increasing timescale ∆. This is expected because larger timescales smooth short-term fluctuations in the traffic rate. Table 4 gives the results for Location 2. For the first five timeout settings, the variance error is significantly lower than in the first trace, even for small ∆. This also holds for B err which is small compared to the mean traffic rate of 153 Mbps. In contrast, we observe large errors for a120i30 and a300i50. This is due to the phenomenon described in Section 4.4.

Finally, Table 5 presents the statistics for Location 3. These traces have a much higher variance than the other ones (the mean bandwidth is 440 Mbps) and the variance also remains on larger timescales. Consequently, we observe that the errors quickly increase for longer timeouts. However, for small timeouts, the results are still acceptable.

Conclusions

The research presented in this paper aimed to evaluate whether flow-level time series could be used in place of packet-level time series for extracting traffic statistics. Since flow monitoring generally results in a loss of knowledge of the arrival times of individual packets, we proposed an approach for creating flowlevel time series assuming that traffic is uniformly distributed within the flow. We validated the performance of the approach by means of experiments with several empirical traffic traces. In addition, we studied the influence of the parameters (timeouts) of the flow building process on the results.

The results suggest that our approach is promising, that is, it allows to estimate the variance of the traffic bandwidth with low errors compared to packetlevel time series. This is especially true when flow timeouts are small. In future work we are going to embed our approach into bandwidth estimation and link dimensioning methods, such as [START_REF] Meent | Network Link Dimensioning -a measurement & modeling based approach[END_REF][START_REF] Pras | Dimensioning Network Links: A New Look at Equivalent Bandwidth[END_REF], and assess whether applying estimated variance from flows into dimensioning formulas will still lead to good results on link dimensioning. In addition, we want to identify whether traffic distribution inside flows changes accordingly to different properties, like transport protocol and flow duration. If significant differences are observed, improvements can be expected by refining the uniformity assumption depending on such properties.

  Packet transmission from host A to host B.

Fig. 1 :

 1 Fig. 1: Packet-level vs. flow-level measurements.

Fig. 4 :

 4 Fig. 4: Intervals of the time series for trace from Location 2.

Table 1 :

 1 Overview of measurements dataset.

	abbr. descr.	period # hosts avg. usage
	loc1 residential	2002	2000	60%
	loc2 college	2003	1000	10-15%
	loc3 univ. building 2011	1000	15%

Table 2 :

 2 Flow definitions.

	abbr.	timeouts (sec.) active inactive
	a2i1	2	1
	a5i2	5	2
	a15i5	15	5
	a30i10	30	10
	a60i20	60	20
	a120i30 120	30
	a300i50 300	50

Table 3 :

 3 Statistics summary for the trace from Location 1.

	source	Berr	1s V	Verr(%) Berr	10s V Verr(%) Berr	30s V Verr(%)
	packets	-	137.11	-	-	31.70	-	-	20.11	-
	a2i1	3.3402 107.49 21.60 0.4580 31.15 1.74 0.2900 19.52 2.93
	a5i2	6.3638 92.78 32.33 0.8587 28.89 8.86 0.6420 17.46 13.18
	a15i5 6.5670 83.34 39.22 1.6737 28.23 10.95 0.5070 18.04 10.29
	a30i10 6.9092 83.13 39.37 2.9030 31.00 2.21 0.7250 17.10 14.97
	a60i20 7.0905 77.54 43.45 3.8253 6.50 2.7210 12.52 37.74
	a120i30 7.0022 73.91 46.09 3.6260 30.77 2.93 2.4570 15.98 20.54
	a300i50 6.8888 84.66 38.25 3.9047 49.71 56.81 3.0890 33.51 66.63

Table 4 :

 4 Statistics summary for the trace from Location 2.

	source	Berr	1s V	Verr(%) Berr	10s V	Verr(%) Berr	30s V	Verr(%)
	packets	-	1042.75	-	-	968.30	-	-	983.27	-
	a2i1	2.4249 1037.74 0.48 0.2507 967.95 0.04 0.0590 984.02 0.08
	a5i2	3.4849 1036.74 0.58 0.3850 967.18 0.12 0.1450 984.04 0.08
	a15i5	3.5848 1039.64 0.30 1.0290 964.88 0.35 0.1470 978.84 0.45
	a30i10 3.8320 1053.13	1	1.8563 976.22 0.82 0.5120 975.37 0.80
	a60i20 3.6490 1053.08 0.99 1.9730 989.39 2.18 0.9880 999.68 1.67
	a120i30 12.6345 656.16 37.07 10.8620 616.19 36.36 9.1510 611.76 37.38
	a300i50 12.5833 687.18 34.10 10.9383 652.53 32.61 9.3790 653.35 33.55

Table 5 :

 5 Statistics summary for the trace from Location 3. .32 16.15 30.5776 27130.78 9.70 6.3456 27437.85 7.44 a30i10 74.7265 27710.80 22.04 51.7083 27264.21 9.26 16.4878 27597.72 6.90 a60i20 100.6202 20264.41 42.99 80.7528 19936.01 33.65 74.1400 20093.97 32.22 a120i30 90.0240 20017.42 43.68 69.9117 20192.62 32.79 62.4544 20663.48 30.29 a300i50 95.4344 13331.16 62.49 75.4097 13352.82 55.56 65.5011 13427.02 54.71

	source	Berr	1s V	Verr(%) Berr	10s V	Verr(%) Berr	30s V	Verr(%)
	packets	-	35543.35	-	-	30045.00	-	-	29643.97	-
	a2i1	26.9391 33835.18 4.81 2.3910 29260.62 2.61 0.9589 27215.77 8.19
	a5i2	38.1607 32617.15 8.23 4.0286 28989.83 3.51 1.7722 27188.32 8.28
	a15i5	62.0467 29804

The anonymized traces are available at http://traces.simpleweb.org


Viktor Puš
email: pus@cesnet.cz

Hardware Acceleration for Measurements in 100 Gb/s Networks

Keywords: FPGA, 100 Gb/s, hardware acceleration, Ethernet, PCI Express

The paper presents the NetCOPE experimental platform for evaluation of 100 Gb/s networks. The platform consists of acceleration boards with FPGAs, FPGA firmware and control software. While the NetCOPE for 10 Gb/s networks is a mature platform, multiplying the throughput ten times brings major challenges in the platform design.

Introduction

With the growing amount of Internet traffic, it is inevitable that current 10 Gb/s lines, often used in data centers and backbones, will be eventually replaced by faster technologies. Standard for 100 Gb/s Ethernet was proposed as IEEE standard 802.3ba in 2008 and ratified in June 2010. While it is still waiting for wider deployment, preparing and evaluating the tools and algorithms for this technology is a major research topic.

While theoretical works in this area certainly have significant impact, we argue that experimental research will also bring many valuable results. We aim to create and evaluate general measurement platform for 100 Gb/s networks, which can not be examined by means of formal description and analysis. Our work falls into the category of experimental computer science [START_REF]Academic Careers for Experimental Computer Scientists and Engineers[END_REF]. We expect the first application to employ a limited set of operations, but the platform allows to create wide selection of complex applications. The NetCOPE platform is a team work of several researchers, author's contribution is the overall design of the platform firmware and the design of several firmware modules, such as the packet header parser HFE-M and the packet filter with TCAM.

The following chapters introduce the hardware, firmware and software design of the experimental platform together with several selected challenges in the 100 Gb/s application design.

Platform Design

Our experimental platform employs Virtex-6 FPGA [START_REF]Xilinx Virtex-6 FPGA Family[END_REF] to receive, process and transmit the 100 Gb/s traffic. FPGA is placed on the COMBO family acceleration boards [START_REF] Combo-Lxt | CESNET[END_REF]. Daughter card communicates with the mother card via several high-speed channels and is equipped with the 100 Gb/s CXP connector. The mother card is connected to the host PC via the PCI-Express Gen2 x8 slot. The Linux operating system running on the host PC is supplemented by the device drivers to support configuration accesses as well as high-speed DMA transfers. Structure of the platform is shown in Fig. 1. This arrangement requires smart partitioning of the platform functions between firmware and software. Fig. 2 shows the basic arrangement of firmware modules in the FPGA. Mother card is responsible for packet reception, basic processing (compute frame checksum, check MTU, etc.) and eventually packet transmission. Valid packets are passed to the following modules, where additional processing, such as packet parsing and filtering is done. Filtered packets are then sent to the host RAM by the DMA controller via the PCI Express interface. Additional modules can be connected as plug-ins into the system. The software part of the platform can perform various functions such as routing, traffic storage, monitoring, etc.

Challenges

While the platform design is straightforward and logical, there are several design considerations that must be engineered carefully. This chapter presents some of the most interesting research topics.

On-chip Communication

The 100 Gb/s Ethernet is capable of packet transmission at the rate of 150 million packets per second (6.6 ns/packet) for the shortest 64 B packets. Due to the minimal 20 B inter-frame gap, more data is effectively transmitted with long packets. The example of data bus capable of transmitting the full 100 Gb/s data stream is 512 bits wide and runs at 196 MHz. It is important to use the bus bandwidth effectively. For example, if the first byte of the packet is always aligned to the lowest byte of the data bus, then 65 B packet occupies two clock cycles on the bus, limiting its throughput to 50.78 %. However, if the packet is allowed to start at eight different positions of the data word (every eight bytes), then the second data word of 65 B packet can already carry 56 bytes of the next packet and only seven bytes are unused. Protocol effectivity is 90.27 % in the worst case.

Frame Checksum

The Ethernet requires each frame to be followed by the 32-bit CRC frame checksum (FCS) to detect transmission errors. FCS is checked when frame is received and appended when frame is sent. FCS computing is complicated by the fact that the packet may start at different positions of the data word and can also end at any position in the data word. Adding leading or trailing zeros is not acceptable, as it would affect the FCS value.

We resolve the unaligned frame starts by using carefully selected CRC initial vector. Our solution for the unaligned frame ends is similar to [START_REF] Walma | Pipelined cyclic redundancy check (crc) calculation[END_REF]: unaligned last word of the frame is computed in the tree hierarchy of smaller CRC modules.

Header Parsing

High-speed header parsing is another interesting research topic. Key issue is that the protocol fields appear at various offsets in the packet. This is due to shim protocols (VLAN, MPLS) and variable header lengths (IPv4/IPv6 option headers).

Our Modular Header Field Extractor (HFE-M) employs pipelined architecture to determine protocol headers offset. Each protocol parsing module has the protocol start offset as the input and the next protocol type and start offset as the output. These messages are passed among protocol parsing modules which are connected in the expected order of protocol headers. Once the types and offsets of present protocols are known, extracting the fields of interest from the packet is relatively simply done by multiplexers.

Packet Filtering

The PCI-Express bus supported by the card has the theoretical throughput 32 Gb/s. Therefore most applications require hardware preprocessing of incoming packets. One suitable operation may be packet shortening, which is useful for applications processing only packet headers. Other possibility is to filter out uninteresting traffic and pass only the selected packets into the host RAM.

Our first version of packet filtering engine uses the TCAM to classify packets. Our implementation of TCAM in FPGA is inspired by [START_REF] Brelet | An overview of multiple cam designs in virtex family devices[END_REF]. It uses Look-Up Tables to match the input to the stored value. 6-input LUT matches 6 bits in 1 cycle or 10 bits in two different TCAM rows in two cycles if one bit is used to select the row. For example, TCAM storing 128 IPv6 addresses occupies 2816 LUTs if new matching must be done in each clock cycle, or 1664 LUTs if the matching may take two clock cycles.

Conclusion

Our experimental work is targeted at post-10 Gb/s network traffic processing. We aim to create universal extensible platform for experiments with high-speed network algorithms and technologies.

The platform is currently being intensively developed, using the experience from our previous 1 Gb/s and 10 Gb/s experimental platforms.

Fig. 1 .

 1 Fig. 1. Structure of the experimental platform.

Fig. 2 .

 2 Fig. 2. Firmware structure.

Acknowledgments This work is supported by the "CESNET Large Infrastructure" project no. LM2010005 funded by the Ministry of Education, Youth and Sports of the Czech Republic.


Cynthia Wagner
email: cynthia.wagner@uni.lu

Thomas Engel
email: thomas.engel@uni.lu

Detecting Anomalies in Netflow Record Time Series by Using a Kernel Function

Keywords: Netflow records, Aggregation, Kernel Function

This paper presents current work for the detection of anomalies in Netflow records by leveraging a kernel function method. Netflow records are spatially aggregated over time, such that the designed kernel function can capture topological and quantitative changes in network traffic time series.

Introduction

Network operators are faced to new challenges on a daily base, while trying to keep their network in good health. Anomalies in networks can be triggered from various sources, ranging from simple network failures (e.g. hardware or software crash,...) to harmful attacks launched against the network (e.g. Worms, Denial-of-Service,...). To identify the anomalies, an available resource is Netflow records due to their compact format, but on ISP-level the storage of all Netflow records needs large storage capacities, since peak-rates of 60 000 flows/second are quite common. Therefore, the need for representing times series of Netflow records in an aggregated form is needed. In this paper, an accurate kernel method is introduced that captures topological and quantitative changes in aggregated network traffic with aim of detecting anomalies or attacks.

This paper is organized as follows: Section 2 describes the model. Section 3 presents experimental results and relevant work is presented in section 4. Conclusions and future work are presented in section 5.

The model

Aggregation of Netflow records

Spatial and temporal aggregation was first presented in [START_REF] Cho | An aggregation-based traffic profiler[END_REF], [START_REF] Kaizaki | Characteristics of Denial of Service Attacks on Internet using Aguri[END_REF] for full packet captures. The aim of spatial aggregation is to extract host IP address (from source (src) or destination (dst)) and volume information from Netflow records and to spatially aggregated this data into tree-like profiles. A profile holds nodes, which represent IP subnets or IP addresses. An IP address is split into two parts, IP src,dst =(prefix, prefixlength). By this, the tree-like structures respect the IP address hierarchy space. The processing task analyses a new Netflow record by matching source/destination IP addresses with the most similar node, sharing the longest common IP prefix. If there is a matching node, the volume part (vol src,dst (i)) is updated. When no match is found, then a new node and a branching point in the parent node are generated. This step is done by using Patricia trees [START_REF] Morrison | PATRICIA--Practical Algorithm To Retrieve Infromation Coded in Alphanumeric[END_REF] with a fixed tree size (N M AX nodes).

For a spatially aggregated tree T , traffic profiles can be defined as, N a set of nodes for source or destination, where T = {n 1 , ..., n N } with n i =< pref ix i , pref ix length i , vol i > and a relation child : T → P(T ), providing a set of child nodes for a given node. Temporal aggregated profiles are time series of profiles, defined as:

{< T src,byt 1 , T dst,byt 1 , T src,pkt 1 , T dst,pkt 1 >, . . . , < T src,byt M , T dst,byt M , T src,pkt M , T dst,pkt M
>} where T src,byt i is a profile in a time window i for source IP address information and T dst,byt i for destination information. Both use also volume in terms of bytes.

The Kernel Function Model

Kernel functions are accurate mathematical tools for evaluating complex data. In [START_REF] Vapnik | Statistical Learning Theory[END_REF], [START_REF] Schoelkopf | Learning with kernels[END_REF], a kernel function can be defined as a mapping from an input space X,

s.t. K : X × X → [0, ∞[, towards a similarity score K(x, y) = i φ i (x)φ i (y) = φ(x) • φ(y)
, with a feature vector φ i (x) over x. For tracking quantitative and topological pattern changes in profiles, a new kernel function is introduced,

K src,dst (Tn, Tm) = i∈T src,dst n ,j∈T src,dst m s src,dst (i, j) × v src,dst (i, j) (1)
The first part s src,dst (i, j) is used for modeling changes in the network topology by analyzing node suffix lengths.

s src,dst (i, j) =            2 pref ixlength j 2 pref ixlength i if pref ixi prefix of pref ixj 2 pref ixlength i 2 pref ixlength j if pref ixj prefix of pref ixi 0 otherwise (2)
The second part v src,dst (i, j) is a Gaussian kernel treating traffic volume changes in tree nodes, defined as v src,dst (i, j) = exp -

|vol(src,dst)i-vol(src,dst)j | 2 σ 2
. A more comprehensive version of the kernel function is presented in [START_REF] Wagner | Machine Learning Approach for IP-Flow record Anomaly Detection[END_REF]. The kernel function takes as input successive traffic profiles and determines the similarity between these profiles and the higher the K-value, the more similar are the successive trees.

Experimental Results

For the experiments a small data set (of 5 minutes duration) provided by a local ISP from Luxembourg has been used (see Fig. 1). The aggregation method has been applied to the data set to generate traffic profiles. The kernel function is applied to the traffic profiles for detecting similarities between these profiles. In Fig. 1, the evaluation of applying the designed kernel function to aggregated Netflow records is presented. It can be seen that between profile 60 and 120 there was an attack. By a manual investigation of the data set for these time periods, it was observed that there was a UDP-flooding attack.

!"!!#$!!% &"!!#$&'% ("!!#$&'% )"!!#$&'% *"!!#$&'% '"!!#$&'% +"!!#$&'% ,"!!#$&'% !% (!% *!% +!% -!% &!!% &(!% &*!% &+!% &-!% !"#$"

Related Work

Nowadays network architectures are monitored, such that an available source of information are IP flow records. In a work by [START_REF] Karpilovsky | Quantifying the Extent of IPv6 Deployment[END_REF], Netflow records are used to quantify the IPv6 deployment. Since large quantities of Netflow records are available, flow sampling is a common approach to reduce data [START_REF] Paredes-Oliva | Portscan Detection with Sampled NetFlow[END_REF], [START_REF] Estan | Building a better NetFlow[END_REF], but a major problem is to find good sampling rates. Another possibility to handle large quantity of data is to use aggregation, as used in this paper. In [START_REF] Cho | An aggregation-based traffic profiler[END_REF], [START_REF] Kaizaki | Characteristics of Denial of Service Attacks on Internet using Aguri[END_REF], full packet captures are spatially aggregated into tree-like profiles. With aid of these generated traffic profiles, the authors were able to identify denial-of-service and flooding attacks. Besides the monitoring itself, the evaluation of such data is essential and a lot of techniques based on statistical evaluations exist, e.g. [START_REF] Lakhina | Mining Anomalies Using Traffic Feature Distributions[END_REF], [START_REF] Karagiannis | BLINC: Multilevel Traffic Classification in the Dark[END_REF]. More recent evaluation techniques refer to Machine Learning techniques, e.g. [START_REF] Mcgregor | Flow Clustering using Machine Learning[END_REF]. Kernel methods for example, a sub-domain of Machine Learning, are often applied as evaluation tools on large data sets to analyze this data on common pattern. In [START_REF] Culotta | Dependency Tree Kernels for Relation Extraction[END_REF], parsed and pre-processed sentences are decomposed into tree-like structures and a kernel function is applied in order to detect similarities between these trees. In computer security, kernel methods are mainly used for intrusion detection and anomaly detection [START_REF] Kahn | A new intrusion detection system using support vector machines and hierarchical clustering[END_REF]. In [START_REF] Kahn | A new intrusion detection system using support vector machines and hierarchical clustering[END_REF], Support Vector Machines (SVMs) based on a tree kernel functions are used for classifying sequences of data.

In this paper, a new method for evaluating large quantities of IP flows has been presented. The contribution of the presented approach is twofold. First, the approach is based on a spatial aggregation technique that summarizes Netflow records into tree-like profiles. Second, with the design of an new kernel function, anomalies respectively attacks in Netflow data can be detected. Since IP address information is sensitive data, by evaluating data with the kernel function, the initial records is not needed anymore for further processing (e.g. SVMs), as it has been shown that the kernel function is able to highlight incidents. An optimization of the spatial-temporal aggregation and the kernel approach for traffic profiles is planned. Another future step is to integrate the kernel function within an online classication algorithm to run real-time network traffic analysis.

Fig. 1 .

 1 Fig. 1. Attack Detection by Evaluating Netflow Records with the Kernel Function and the used Data Set

Acknowledgments

We address special thanks to RESTENA Luxembourg for their support.