Vaibhav Bajpai
email: v.bajpai@jacobs-university.de

Nikolay Melnikov
email: n.melnikov@jacobs-university.de

Anuj Sehgal

Jürgen Schönwälder
email: j.schoenwaelder@jacobs-university.de

Flow-Based Identification of Failures Caused by IPv6 Transition Mechanisms

Keywords: IPv6, Transition, NAT64, Dual-Stack Lite, NetFlow

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Motivation

The IETF began work on IPv6 in the mid 1990s realizing that it would not take long for the IPv4 address space to run out, given the pace of Internet adoption and growth. By the mid 1990s IPv6 was defined, but it did little to displace IPv4 as the de facto standard. This has been due to the lack of any economic advantage for the network providers to deploy IPv6 and a lack of IPv6-only killer applications that can aggressively push the need for end users to look for any service benefit to make the switch. Studies show that IPv6 (as of February 2012) accounts for less than 1% of the global Internet traffic and only about 0.5% of the top 1 million websites are reachable over IPv6 [START_REF]IPv6 Adoption Monitor[END_REF].

Today, the issue of depleting IPv4 addresses has become more imminent and undeniable. APNIC announced that it had reached the final stage of IPv4 exhaustion in the Asia Pacific region with the release of all IPv4 addresses in its available pool [START_REF]APNIC IPv4 Address Pool Reaches Final /8[END_REF]. This occurred only few months after IANA allocated the last blocks of IPv4 addresses to the Internet Registries exhausting its pool of unallocated IPv4 addresses [START_REF]Available Pool of Unallocated IPv4 Internet Addresses Now Completely Emptied[END_REF]. Despite the foresight on the rapid decline, IPv6 is still in the very early stages of deployment. Very few network operators, even those with aggressive deployment plans, have completed IPv6 roll outs. Most network operators have not even begun IPv6 deployment. Usually two factors are attributed to such a reluctance: the amount of currently available IPv4 content and the large number of installed applications, both at home and at enterprise networks, that do not work over IPv6, which will make the transition from IPv4 to IPv6 to take multiple years. Therefore, the service providers and the enterprises will either need to better leverage the current pool of addresses by sharing the IPv4 addresses among many customers using wider/layered NAT deployments or employ technologies and mechanisms that allow to reach IPv4 content from IPv6-only hosts during the extended migration phase.

The findings of this study demonstrate that many of the existing applications and protocols interoperate well with the existing transition mechanisms. These findings correspond to some of the observations made in other independent studies [START_REF] Arkko | Experiences from an IPv6-Only Network[END_REF][START_REF] Hazeyama | Experiences from an IPv6-Only Network in the WIDE Camp Autumn[END_REF][START_REF] Skoberne | Practical Evaluation of Stateful NAT64/DNS64 Translation[END_REF]. There are, as we found out, several applications that do not work, and these are the border-line cases that many operators and service providers are afraid of. These failures can significantly decrease users' overall experiences or satisfaction with the provided services, and this would definitely hurt the reputation of the network operator or the service provider. The goal of our study is twofold. First, we wanted to understand which applications fail under IPv6 transition mechanisms and the reasons causing these applications to fail. Second, we wanted to investigate whether it is possible to identify these failures in network flow records. If this were possible, we could create a scalable tool that can be used by network operators deploying transition technologies to detect failures customers are facing and to take appropriate actions before a customer complains about his network service. In the following, we term a sequence of flow-records that is characteristic for an application failure due to a transition technology a failure signature. The failure signatures can be formalized by using our stream oriented flow-query language NFQL [START_REF] Marinov | Design of a Stream-Based IP Flow Record Query Language[END_REF][START_REF] Kanev | Implementation of a Streambased IP Flow Record Query Language[END_REF]. We assume that failure signatures are unique for each application, since each one of them performs a different sequence of network-related operations in the background. Once we understand and define what a failure signature of a certain application is, we can use that signature to automatically scan through massive amounts of flow records in order to automatically detect failures. This will allow service providers and network operators to take a proactive rather than a reactive approach to problems that users may face after deployment of transition mechanisms and this can likely mitigate some of the risks associated with the rollout of IPv6 transition technologies.

The structure of the paper is as follows. In the next section we briefly introduce the transition technologies Dual-Stack Lite and NAT64. Section 3 gives an overview of Net-Flow and our stream-oriented flow query language NFQL. Our experiments to evaluate the interoperability of different applications with DS-Lite and NAT64 are presented in Sections 4 and 5 respectively. In Section 6, we analyze the reasons for the failure of different applications. Related work is discussed in Section 7 before we conclude in Section 8.

Investigated IPv4-to-IPv6 Transition Technologies

We concentrated our analysis on the two transition technologies DS-Lite and NAT64. Related technologies not investigated are discussed briefly in Section 7.

Dual-Stack Lite

DS-Lite (Dual-Stack Lite) [START_REF] Durand | Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion[END_REF] is an approach that uses IPv6-only links between the ISP (Internet Service Provider) and the customer. When a device in the customer network Fig. 1. DS-Lite: IPv4 traffic is tunneled from a customer's network to a carried grade NAT in the provider network sharing an IPv4 address with potentially many customers sends an IPv4 packet to an external destination, the IPv4 packet is encapsulated in an IPv6 packet for transport into the provider network as shown in Figure 1. At the CGNAT (Carrier Grade NAT), the packet is decapsulated to IPv4 and NAT44 is applied (which translates an IPv4 address to another IPv4 address) before delivering the packet to the public Internet. Using this approach, a service provider can deploy IPv6 and take advantage of its large address space while still providing IPv4 service. In particular, this technique allows a global IPv4 address to be shared among a larger set of customers.

A DS-Lite CPE (Customer Premises Equipment) performs the IPv4-in-IPv6 encapsulation of the IPv4 packet sent by the device, setting the destination address of the IPv6 packet to the address of the DS-Lite enabled CGNAT. The CGNAT must adapt its NAT binding table to add the source address of the encapsulating IPv6 packet (the address of the customer end of the IPv6 link), the IPv4 source address and port. Such a combination makes the mapping unambiguous. As a result, when an IPv4 packet is received from outside, the IPv4 destination address and port are mapped back to the inside IPv4 destination address and port, encapsulated in IPv6 using the mapped IPv6 address as the IPv6 destination address, and then forwarded to the customer. The mapped IPv6 address not only disambiguates the customer's private address space [START_REF] Rekhter | Address Allocation for Private Internets[END_REF], it also provides the reference for the tunnel endpoint. On the other hand, if a device in the customer network sends an IPv6 packet, the packet is routed normally to the IPv6 destination. In this way, this model allows use of Dual-Stacked, IPv4-only, and IPv6-only devices behind the gateway. A variation on the DS-Lite Model implements DS-Lite on an individual end system rather than on a CPE device. One critical requirement for DS-Lite is that its tunnelling function must be added to existing customers CPE either through a software upgrade or by replacing the unit.

NAT64

An IPv4-to-IPv6 Network Address Translator (NAT64) [START_REF] Bagnulo | Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers[END_REF] allows IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or ICMP. The headers of packets passing between an IPv6-only end system and an IPv4-only end system are converted from one protocol to the other using the IP/ICMP Translation Algorithm [START_REF] Li | IP/ICMP Translation Algorithm[END_REF], allowing the end systems to communicate without knowing that the remote system is using a different IP version. A special DNS Application Level Gateway (ALG), known as DNS64 [START_REF] Bagnulo | DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers[END_REF], is used to trick IPv6 hosts into thinking that the IPv4 destination has an IPv6 address. The IPv6 host believes that it is communicating with another IPv6 system, and the IPv4 system believes that it is talking to another IPv4 system. Neither end system participates directly in the translation process.

The NAT64 server is the endpoint for at least one public IPv4 address and a 32-bit long IPv6 network prefix (64:FF9B::/96). The IPv6 client accommodates the IPv4 address it wishes to communicate within the left-over 96-bits, and sends its packets to the resulting address. The NAT64 server then creates a NAT-mapping between the IPv6 and the IPv4 address, allowing the end-points to communicate. DNS64 describes a DNS server that, when asked for a domain's AAAA records, synthesizes them from the requested domain's A records. The first part of the synthesized IPv6 address points to an IPv6/IPv4 translator and second part embeds the IPv4 address from the A record. The translator in question is usually a NAT64 server as shown in Figure 2.

The most significant limitation of this architecture is that all hosts and all applications within the NAT64 domain must be converted to IPv6. Legacy IPv4 hosts or IPv4 applications running on an IPv4 host will not work in this architecture. In addition the translation only works for cases where DNS is used to find the remote host address. If IPv4 literals are used, the DNS64 server will never be involved, and hence, there is no special IPv6 address to use. DNSSEC validation will also fail since DNS64 server needs to return records not specified by the domain owner. A high-level overview of the NetFlow protocol is shown in Figure 3. The flow exporter reads the IP packets that cross an observation point (typically a network interface of a router) to generate flow-records. The flow-records are exported based on some predefined expiration rules, such as a TCP FIN or RST, an inactivity timeout, a regular export timeout or crossing a low memory threshold. The flow-records are encapsulated in UDP datagrams and are deleted from the exporter once transmitted. On the other end, the collector on receiving these flow-records, decodes and stores them locally to be used for further processing.

The Network Flow Query Language (NFQL) [START_REF] Kanev | Implementation of a Streambased IP Flow Record Query Language[END_REF][START_REF] Schauer | Flowy 2.0: Fast Execution of Stream based IP Flow Queries[END_REF] is a stream-based flow record query language [START_REF] Marinov | Design of a Stream-Based IP Flow Record Query Language[END_REF]. The query language allows us to describe patterns in flow-records in a declarative and orthogonal fashion, making it easy to read and flexible enough to describe complex relationships among a given set of flows. A typical query consists of several branches where each branch consists of a number of independent stages that perform a specific task.

Testing Dual-Stack Lite

We used three physical machines in our Dual-Stack Lite setup. One of the Debian machine works as our CPE, one as our CGNAT and the third one as our IPv4 only host running Mac OS X as shown in Figure 4. The CGNAT machine is a combination of an IPv4-in-IPv6 tunnel end-point and an IPv4-IPv4 NAT implemented on the same node [START_REF] Durand | Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion[END_REF]. The machine has two interfaces, one (on eth0) with a Global Scope IPv6 address (2020::1) to underpin the virtual IPv4-in-IPv6 tunnel and the other one (on eth1) with a public IPv4 address to reach the IPv4 infrastructure. A virtual interface (tun0) was defined with an IPv4 address (172.0.0.1) on top of eth0 to establish an ipip6 tunnel to the CPE. At this point, all 172.0.0.0/64 traffic was routed to tun0 and all 2020::/64 traffic was routed to eth0. We used iptables to forward all the traffic from tun0 to eth1 and to allow NATing with the public IPv4 address. We also enabled IPv4 forwarding on all interfaces for the iptables forwarding to work.

The CPE machine is an IP router in the customer premise functioning as a home gateway that is connected to the service provider network. The B4 element [START_REF] Durand | Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion[END_REF] implemented on a Dual-Stack capable node within the CPE creates a tunnel to route all IPv4 requests to the CGNAT machine. The machine has two interfaces, one (eth0) with a Global Scope IPv6 address (2020::2) to underpin the virtual IPv4-in-IPv6 tunnel similar to the CGNAT machine, and the other one (eth1) with a private [START_REF] Rekhter | Address Allocation for Private Internets[END_REF] address (192.168.1.1) which serves as the DHCP server for IPv4 clients directly connected to it. We added a default route for all IPv6 packets to pass through eth0 with 2020::1 (CGNAT) as their next hop. At this point we could test IPv6 connectivity from both endpoints. A virtual interface (tun0) was defined with an IPv4 address (172.0.0.2) on top of eth0 to establish an ipip6 tunnel to the CPE. We added a default route for all IPv4 packets to pass through this virtual tunnel. At this point we could test IPv4 connectivity of tunnel endpoints. We also added a specific route for our private subnet 192.168.0.0/16 to route all local traffic through to eth1. We again used iptables to forward all the traffic, but this time from eth1 to tun0 and to allow NATing with the tunnel's IPv4 address (172.0.0.2). We also enabled IPv4 forwarding on all interfaces for the iptables forwarding to work.

The IPv4 only host has one interface eth0 with a private address. A default IPv4 route was added on this machine to send all its IPv4 requests to the CPE. At this point we could test its IPv4 connectivity with the IPv4 world. Once the setup of DS-Lite was performed, we carried out a number of application evaluations. As such, we ran the set of applications and protocols listed in Table 1. Contrary to our expectations, we were not able to identify any failures. All of these installed applications worked out-of-the-box. Since there were no failures, we naturally could not define any failure signatures as well. Later, we evaluated NAT64 on the same set of applications, and observed different results as described in the next section.

Testing NAT64

The NAT64/DNS64 experimental setup is shown in Figure 5. A Debian machine functions as our IPv6 only host. It has one interface with one global scope IPv6 address to directly reach the IPv6 world and another global scope IPv6 address to reach the IPv4 world using NAT64. Another Debian machine, located within the same subnet as the IPv6 only host, functions as our DNS64 server to which our IPv6 only host sends all DNS queries. To achieve this, our IPv6 only host defines the DNS64 server as the only name-server. In order to process all IPv6 DNS requests, totd [START_REF]Trick Or Treat Daemon') DNS proxy[END_REF] was installed on the DNS64 server, which is a stateless user-space implementation of DNS64 which forwards the requests to a real IPv4 name-server and then constructs fake IPv6 address based on a pre-defined IPv6 NAT64 prefix (64:FF9B::) and the IPv4 address received from the IPv4 name-server answering the DNS request.

The NAT64 machine runs Debian and has two network interfaces. One of the interfaces (eth0) has a public IPv4 address and is connected to the IPv4 world. The !"##$%""!3.4"0% 2" = > ? ) Fig. 5. Experimental NAT64/DNS64 setup other interface (eth1) has a Global Scope IPv6 address to connect back to our IPv6 only host. In order to route all IPv6 requests with a NAT64 prefix (64:FF9B::) to the NAT64 machine, a default route was setup on the IPv6 only machine. In order to get the IPv6-IPv4 translation working, we installed Ecdysis [START_REF] Perreault | Ecdysis: Open-Source DNS64 and NAT64[END_REF], which is an open-source implementation of NAT64 to translate all IPv6 packets received at eth1 (from the IPv6 only machine) to IPv4 packets and to send them via the eth0 interface to the IPv4 infrastructure. At this point we could access IPv4 websites from our IPv6 only host. Since, our IPv6 only host is also directly connected to the IPv6 infrastructure, we were also able to reach IPv6 only websites.

We tested the same set of applications and protocols as presented in Table 1. For the majority of applications the experiences have been similar to those of DS-Lite. However, four of the applications failed to interoperate with NAT64: Skype, OpenVPN, Transmission (bit-torrent) and SIP clients. In the next section we discuss the reasons for failure of these applications.

Failure Analysis

These failures correspond to similar experiences with NAT64, documented in other independent studies [START_REF] Arkko | Experiences from an IPv6-Only Network[END_REF][START_REF] Hazeyama | Experiences from an IPv6-Only Network in the WIDE Camp Autumn[END_REF][START_REF] Skoberne | Practical Evaluation of Stateful NAT64/DNS64 Translation[END_REF]. Skype, for instance has its own unique behavior during the startup and sign-in procedure. At the start of the sign in procedure, Skype tries to discover clients in the local network. It tries to send a multicast message using the multicast DNS (mDNS) protocol. To perform that, it uses a specific IPv4 multicast address and mDNS port (224.0.0.251:5353) combination. On an IPv6-only host, this phase obviously fails. With the start of the second phase, Skype tries to establish contact to the Skype login server. The login server resides on an IPv4 address, but that address is mapped into an IPv6 address by the DNS64 server. There are three subsequent attempts with increasing duration and decreasing number of packets to establish contact with the login server. However, each attempt fails owing to the lack of IPv6 support in the Skype client.

There are applications with partial IPv6 support, but they fail to operate without a dual-stacked environment. Transmission, a bit-torrent client, for instance, could successfully connect to the tracker of the torrent file and retrieve the list of peers and seeders. However, it failed to connect to any of the peers when the client ran on an IPv6-only host. OpenVPN is another such example where the client failed to transport VPN packets over IPv6. Obviously, applications failing to generate sufficient amounts of traffic due to incomplete IPv6 support are difficult to identify using flow records.

Linphone, a SIP client with well-recognized IPv6 support, showed potential to be a candidate for defining failure signatures. To be able to identify behavior which would be unique to SIP clients, we decided to capture and analyze the transmissions at the packet-level using WireShark. The NAT64 box was chosen as the monitoring point since it was the best place to get a perspective from both ends of the network. We observed that the client initially tried to register with ekiga.net using its IPv6 address and port number 5060, but received a 606 error, which means that agent was recognized successfully but some aspects of the session description (addressing style) were not accepted [START_REF] Rosenberg | SIP: Session Initiation Protocol[END_REF]. The 606 error response, however, also contained the public IPv4 address of the NAT64 box, which was used as a source in the subsequent REGISTER requests by the agent. This second attempt eventually succeeded and resulted in a OK (200) response code in the SIP reply. During call initiation, different behaviors were observed for both incoming and outgoing calls from the IPv6-only host. An outgoing call showed up expected behavior, with an INVITE, triggering a TRYING (100), RINGING (180) and eventually an OK (200) response from the other end. An incoming call on the other hand led to two additional responses from the IPv6-only host just after receiving an INVITE, namely Dialog Establishment (101) and an OPTIONS packet [START_REF] Rosenberg | SIP: Session Initiation Protocol[END_REF]. In both cases, however, while the SIP signaling works out correctly, the call itself does fail. This is due to IPv4 address literals carried in SDP records identifying the endpoints for the voice streams.

After having learned the reason why SIP clients fail, we looked at the identification of the failure at the flow-level. We defined a sample config file with a flow-template containing 5 keys (srcIP, dstIP, srcPort, dstPort, protocol) and 2 aggregation elements (packetCount, totalBytes). Setting an appropriate export time to segregate the flows was a challenge, whereby a large number smeared all packets into a single flow, while a lower value diverged the related packets in separate flows making them less useful. It would have been possible to get an appropriate value looking at the WireShark traces, but then that value would correspond to a specific scenario, and thus could not be used as a general case study. Furthermore, it was difficult to clearly distinguish session initiation or teardown SIP exchanges from registration exchanges. Since SIP registrations establish soft state, they need to be renewed periodically. While certain implementation use known defaults for the timeouts, there is nothing suggested or even mandated in the SIP specification and thus registration traffic is implementation specific. Furthermore, users starting a VoIP client only when they place calls will have the registration traffic very likely merged with the call initiation traffic into a single flow record.

Another challenge is the identification of the absence of RTP flows between call initiation and call teardown. Note that there are no fixed port numbers for RTP [START_REF] Schulzrinne | RTP Profile for Audio and Video Conferences with Minimal Control[END_REF]. The reserved port numbers may be used by applications, but applications are essentially free to use any ephemeral port. Hence, any UDP flow matching the start and end times could be a possible RTP stream. Looking at the traffic characteristics of the UDP flows also is of minor value. While some traditional codecs lead to more or less constant bitrate flows, smarter more recent codecs may not send traffic at all if there is no audio signal to carry. Hence, our attempts to formulate failure signatures as NFQL queries did lead to queries that are very client specific and which can easily produce a high number of false positives. It is likely that we could have produced sharper queries if the flow records would contain more details about the protocol exchanges taking place. For example, if the flow records would indicate which SIP methods were invoked during the time interval covered by a flow record, we would have been able to match UDP flows more easily. Furthermore, if the UDP flows have been tagged as RTP flows, we could have easily ignored other UDP flows. As such, Flexible NetFlow [START_REF]Cisco IOS Flexible NetFlow Technology White Paper[END_REF] with its packet section export capability to allow deep packet inspection of flow-records can serve as a good candidate to identify this behavior and is a potential item for future work.

Related Work

A number of technologies, besides NAT64 and DS-Lite have also been proposed that attempt to provide their perspective on how to go about this transition. The author of [START_REF] Huston | Transitioning Protocols[END_REF] provides a detailed discussion on these technologies. For instance, TAYGA [START_REF] Tayga | No-fuss NAT64 for Linux[END_REF] is a user space stateless NAT64 implementation for Linux that uses the tun driver to exchange IPv4 and IPv6 packets with the kernel. It is intended to provide production-quality NAT64 service for networks where dedicated NAT64 hardware would be an overkill. Routing TAYGA's IPv4 path through a stateful NAT44 can also make it stateful.

Address Plus Port [A+P] [START_REF] Bush | The Address plus Port (A+P) Approach to the IPv4 Address Shortage[END_REF] is another transition technology that uses a NAT in (or close to) the customer premise for access to the IPv4 Internet. The Service Provider conveys both an IPv4 address (as done today) and a range of TCP/UDP ports to the NAT. Outgoing IPv4 traffic is NAT'ed to that range of TCP/UDP ports, and the Service Provider routes packets to the appropriate customer using both the destination IPv4 address (as done today) and destination TCP/UDP port. This way, a global IPv4 address can be shared between multiple customers and there is only a single NAT involved.

NAT444 [START_REF] Yamagata | NAT444. Internet-Draft[END_REF] is very similar to Dual-Stack Lite, however, it has an advantage of not imposing any special requirement on the CPE. It uses two IPv4 NATs and three layers of addressing instead of an IPv4-in-IPv6 tunnel. One layer uses a private IPv4 block behind the CPE, another uses a separate private IPv4 block between the CPE and CGNAT, and the third layer uses a public IPv4 address routing outside from the CGNAT to the IPv4 world.

Teredo [START_REF] Huitema | Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)[END_REF] is a technology to provide IPv6 connectivity to IPv4 endpoints whose service providers have not deployed IPv6 yet. Teredo is a platform-independent tunneling protocol designed to provide IPv6 connectivity by encapsulating IPv6 packets within IPv4 User Datagram Protocol (UDP) datagrams that can pass through NAT devices. Other Teredo nodes elsewhere, called Teredo relays, have access to the IPv6 network then receive the packets and route them on.

Conclusion

We investigated failures caused by IPv6 transition technologies and whether they can be detected in network flow records by defining failure signatures. Using such signatures, an interested ISP could automatically identify failures and customers that might experience problems while rolling out IPv6 transitioning technologies. We tested a variety of applications and protocols under DS-Lite and NAT64. All of the tested applications performed well with DS-Lite while some problems occurred with NAT64. We identified four applications that failed to function with our NAT64 setup and we carried out an analysis to identify as to what causes the applications to fail. However, with an apparent lack of IPv6 support in three of them, it made little sense to define failure signatures since there is only a very small amount of traffic that can be observed (if any). Linphone, the fourth application with full IPv6 support, was analyzed at both the packet and flow level. It turned out that VoIP failures with NAT64 are difficult to identify in flow records due to the aggregation of traffic inherent in network flow records and the difficulty to identity the SIP methods being invoked and the lack of precision with which UDP flows can be classified as RTP flows. For our approach, it seems necessary that flow exporters provide more information about the application protocols carried in network flows.

Fig. 2 .

 2 Fig. 2. NAT64/DNS64: A special DNS64 server synthesizes AAAA records out of A records and an associated NAT64 translates IPv6 packets into IPv4 packets

Fig. 3 .

 3 Fig. 3. NetFlow: A flow exporter aggregates packets passing an observation point into flow records that are sent to a flow collector for further analysis

!Fig. 4 .

 4 Fig. 4. Experimental Dual-Stack Lite setup

  )%,"-("-'-"!19% !"##$%"" &'():/4$2% ;"<%,"-("-&'()*+,-.)/#,-)!"#$ &&&'())(*+',)-0/-12-3)&'()*+,-. &&&'())(*+',)-&'()4,56. .!'/01'!2'/!.&'()4,56.

Table 1 .

 1 Applications and services tested with DS-Lite and NAT64

	Safari 5, Google Chrome 10, Firefox 4, Opera 11	Apple Mail 4
	-WebMail: Gmail using TLSv1	-IMAP: Gmail and Microsoft Exchange
	-Media: YouTube using Flash and HTML5	-POP3: Gmail
	-Google Maps, HTTP Downloading	-SMTP: Gmail and Microsoft Exchange
	-Web Chat: Gmail, Yahoo, Freenode IRC	Instant Messaging and VoIP
	Miscellaneous	-iChat
	-SSH, FTP, IRC, Git, Mercurial, OpenVPN	-Skype
	-Transmission: Bit Torrent	-SIP


Radek Krejčí

Pavel Čeleda

Jakub Dobrovolný

Traffic Measurement and Analysis of Building Automation and Control Networks

Keywords: BACnet, BACnetFlow, network, measurement, analysis, building, automation, control. WAN

This paper proposes a framework for a flow-based network traffic monitoring of building automation and control networks. Current approaches to monitor special environment networks are limited to checking accessibility and a state of monitored devices. On the other hand, current generation of flow-based network monitoring tools focuses only on the IP traffic. These tools do not allow to observe special protocols used, for example, in an intelligent building network. We present a novel approach based on processing of flow information from such special environment. To demonstrate capabilities of such approach and to provide characteristics of a large building automation network, we present measurement results from Masaryk University Campus.

Introduction

Network traffic monitoring and measurement using IP flow information has become useful instrument for network operators. It provides information about who is communicating with whom, at what time, for how long and how much data is transferred. Today, flow monitoring technologies are limited to IP networks. Flow information can be used for billing and accounting, network profiling, network planning and network security. There are similar needs to know what happens in special networks, like various sensor networks, Building Management System (BMS) networks or Supervisory Control And Data Acquisition (SCADA) networks.

With experiences from IP networks, we believe that the flow-based monitoring of special environment networks can have a positive impact on their management and security. Security of industrial and automation networks becomes much more important [START_REF]Security Predictions 2012&2013 -The Emerging Security Threat[END_REF]. An attacker could set off a fire alarm, turn off an airconditioning or turn off security systems such as a closed-circuit television (see Figure 1). The controll networks were originally physically separated from other networks. Now, they have become more and more IP-enabled and they are now accessible to hackers from the other side of the world. In comparison to common IP networks, security of automation networks is still underestimated.

In case of BMS networks, the definition of a network traffic flow and information related to the flow is different in comparison to IP networks. Today, Cisco NetFlow [START_REF]Cisco IOS NetFlow[END_REF] technology is a de facto standard for IP flow monitoring. However, NetFlow is inappropriate for the traffic monitoring of non-IP BMS networks due to the fixed NetFlow data format which is relevant mainly to IP networks. Possible approach to deal with this issue is to use the IP Flow Information Export (IPFIX) [START_REF] Claise | Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information[END_REF] protocol introduced by the Internet Engineering Task Force (IETF) as a new standard for flow information processing. The IPFIX enables anyone to define new information elements using enterprise IDs assigned by the Internet Assigned Numbers Authority (IANA). We plan to use IPFIX to transfer and store a specific information related to a BMS network traffic. Currently, we use SQL database for these purposes.

In this paper we present results of the network traffic monitoring using the special framework for measurement of flow information in an environment of BMS network based namely on the BACnet protocol [START_REF]Refrigerating and Air-Conditioning Engineers: Standard 135-2010 -BACnet A Data Communication Protocol for Building Automation and Control Networks[END_REF], [START_REF]BACnet Website -ASHRAE SSPC[END_REF]. Presented data comes from the measurement performed in the BMS network of the Masaryk University Campus in Brno [6]. Detailed description of the measurement framework is also provided.

The paper is organized as follows. After the Introduction, Section 2 summarises state of the art in the field of security of the automation and control networks. Section 3 defines BACnetFlow as an equivalent of the IP flow in the environment of BMS network. Proposed framework for observation, storage and further processing of BACnet network traffic flow information is described in Section 4. Section 5 reports on measurement results from monitoring Masaryk University Campus network. Deployment evaluation of the monitoring system is also included. Finally we conclude the ideas and propose further work in Section 6.

Related Work

Current monitoring of BMS networks is focused mainly to checking accessibility and a state of devices. Mainly Nagios [START_REF]Nagios -The Industry Standard In IT Infrastructure Monitoring[END_REF] and other monitoring systems are used to actively access devices in the network and to check their proper functionality. However, this approach misses information about unexpected (forgotten or enemy) devices in the network or about a misconfigured device function which is not explicitly checked.

Barbosa et al. [START_REF] Barbosa | Difficulties in Modeling SCADA Traffic: A Comparative Analysis[END_REF] apply flow monitoring in SCADA networks. However, they are limited to observe only IP related information. In contrast, we get insight into the specific BMS protocol such as the BACnet. To achieve this, we have modified the original IP flow definition to BACnetFlow (see Section 3) and we observe much more detailed information.

There is some research on securing BMS networks and connected devices using special protocols or systems preventing unauthorised operations [START_REF] Novak | Common approach to functional safety and system security in building automation and control systems[END_REF][START_REF] Granzer | Security in networked building automation systems[END_REF]. The main issue of this approach is a very limited computational power and a lack of other resources available in such devices [START_REF] Perrig | SPINS: security protocols for sensor networks[END_REF]. Therefore, it is quite challenging task to protect these devices when it is needed to implement any special, e.g. cryptographic, functions inside them.

Monitoring and analysing network traffic in BMS network is not a common approach. Analysing application part of the traffic is used for example in some firewalls as [START_REF]Honeywell selects Tofino Modbus Read-only Firewall to Secure Critical Safety Systems[END_REF], which is used to protect Modbus devices from dangerous commands.

BACnetFlow

BACnet is a communication protocol for BMS networks. As a transport protocol, BACnet supports usage of LonTalk, PTP, MS/TP, ARCNET and Ethernet protocols. The last two mentioned protocols can be supplemented by an IP layer. Information carried by BACnet protocol is divided into separated layers (see Figure 2). Especially the information from the network layer protocol data unit (NPDU) is crucial to describe flows related to the BACnet protocol.

To identify flows related to the BACnet protocol, we defined specific set of items to distinguish particular BACnet flows. We named such flow record BAC-netFlow (see Figure 3). Key fields are used to identify BACnetFlow, while nonkey fields contain traffic statistics (timestamps, counters) and BACnet specific values.

Using the standard 5-tuple1 identifying the IP flow is not possible since IP is not the mandatory transport protocol for BACnet. Furthermore, even if IP is used as the transport protocol, BACnet messages are often broadcasted to the whole network and identification of BACnet communication participants is not possible solely from the IP flow information.

System Architecture

Figure 4 shows the proposed system for a real-time network monitoring of BMS networks. The architecture of the proposed system consists of the following three parts.

BACnet network carrying data over Ethernet at a rate of 10-1000 Mbps. The system is connected to the network through mirror ports or network Test Access Ports (TAPs) inserted in backbone links. This approach provides the real-time overview of all traffic on the observed BACnet network.

BACnetFlow probes based on stand-alone FlowMon probes adapted to the specific environment of BMS networks. This part of the system is described in detail in Section 4.1.

BACnetFlow collectors supporting both BACnetFlow and NetFlow protocols. This part of the system stores flow information for a further analysis.

BACnetFlow probe

NetFlow collector

Fig. 4. Architecture of flow-based monitoring system for BMS networks using the BACnet protocol.

BACnetFlow Probe

According to our best knowledge, there exists no tool which can be used to generate flow-based statistics from a BACnet network. We decided to use Flow-Mon exporter engine [START_REF]INVEA FlowMon Exporter -Community Program[END_REF] providing plugin API and to write own set of BACnet plugins. Source codes of the BACnet plugins are available at [START_REF]BACnet Monitoring Plugins[END_REF]. The plugins control how the packets are parsed, stored into a flow cache and exported.

BACnet input plugin reads packets, extracts information into BACnetFlow record fields and stores the records into the flow cache. Besides parsing standard IP traffic for NetFlow export, plugin processes BACnet packets of the following forms.

eth:llc:bacnet-npdu:bacnet-apdu eth:ip:udp:bvll:bacnet-npdu:bacnet-apdu

BACnet over Ethernet uses Logical Link Control (LLC) as its data link layer. BACnet traffic is identified by Destination Service Access Point (DSAP) and Source Service Access Point (SSAP) both set to the value 0x82. This value is stored as the flow's ethertype to identify BACnet over Ethernet flow.

In case of BACnet over IP, the UDP protocol with source and destination ports 47808 is used. The Type field with value 0x81 is extracted from BVLL and stored as the flow's ethertype as an identifier of the BACnet over IP flow.

VLAN tagging (IEEE 802.1Q) is often used to share a physical Ethernet network link by multiple independent logical networks. Therefore, to distinguish traffic in various VLANs, the VLAN identifier is also extracted and used as one of the BACnetFlow key fields (see Figure 3).

Figure 5 shows the difference between BACnetFlow provided by the input plugin and standard NetFlow. In addition to NetFlow information, BACnetFlow provides information describing BACnet protocol. BACnet filtering plugin is used to separate standard IP traffic from the rest of traffic processed by a BACnet input plugin. Common IP traffic is then exported by probe's standard NetFlow exporting plugin to the NetFlow collector, while BACnet data are processed by BACnet exporting plugin described below.

Originally, all flows including standard IP flows were processed by BACnet exporting plugin and stored in SQL database. This approach was not successful due to high amount of IP traffic that was hard to process by SQL database.

BACnet exporting plugin sends observed data to a storage for further analysis. The PostgreSQL database is currently used. To increase efficiency of database queries, the database partitioning is used. Commands for the database to add a new record are printed on the standard output by default. The output is redirected to the PostgreSQL interactive terminal (psql(1)) which sends database commands to the (remote) database server.

We are working on IPFIX export for a future use, which will enable to transport and store user-defined information elements. The IP flow and BACnetFlow information will be exported together this way.

Performance of the BACnetFlow probe was measured on a commodity PC2 . The BACnet input plugin is able to process over 2 Mpps of BACnet traffic on each processor core. Furthermore, there can be multiple instances of the input plugin running simultaneously and processing the network traffic from dedicated input interfaces. The maximum packets per second (pps) rate on 1 Gbps network is 1,488,095 pps [15]. Thus, the proposed system using multi-core processor probe is able to process input data from several 1 Gbps fully saturated networks.

A bottleneck of the current implementation is a computation of the flow record hash which is implemented using OpenSSL MD5 hash functions. Performance of the BACnet input plugin can be further increased by reimplementing this part.

The limit of the BACnet exporting plugin is 63,000 processed BACnetFlows per second. Bypassing current connection with database via psql(1) and con-necting the plugin directly to the database should increase the performance if needed. According to measured values (see Figure 12), there were only several tens of BACnetFlows per second in the monitored BMS network.

BACnet Measurement and Analysis

In this Section, we present measurement results to demonstrate the capabilities of the BACnet monitoring plugins and to provide information on the characteristics of BMS network in Masaryk University Campus. The results are organized in two categories. First, we present NetFlow version 9 statistics (e.g., traffic load, protocol breakdown and top statistics). These results are not unique to our measurement system. They can be obtained using standard NetFlow tools such as standalone probes, routers and collectors. However, these results are the first published traffic statistics from a large building network, and they show the impact of various systems connected to the network. The second category shows the BACnet statistics. These results show the native BACnet traffic, and they demonstrate the behaviour of control devices in a production network.

Deployment and Description of the Measurement System

BMS is an essential part of Masaryk University Campus. More than 24 teaching and research pavilions are monitored and controlled by BMS -dedicated LAN, BACnet over Ethernet and BACnet over IP network, interconnect several power systems, fire systems, security systems, data information systems, lighting, and so on. The network is managed from Windows servers and desktops through web user interface. Any system failure or attack against BMS can be critical for the entire Campus.

Our measurement system is connected to the mirror port (1 Gbps) of network core switch. The BMS management servers are located behind a firewall in a demilitarized zone. The management servers support BACnet stack and are able to access BACnet data. The mirror port can monitor traffic on up to 8 source ports. We selected the most significant ports to get as much as possible data from the monitored network. We generate non-sampled flow statistics using an active timeout 300 s and an inactive timeout 30 s.

Due to space limitation, we present week-long measurement results from January 16 12:00, 2012 till January 23 12:00, 2012. Week-long statistics were chosen in order to take into account time-of-day and day-of-week variations.

NetFlow Statistics

Table 1 summarizes the traffic observed in BMS network over one week using NetFlow version 9. We identified about 220 unique hosts (IPv4 addresses) in BMS network. NetFlow statistics do not include any BACnet traffic.

Figure 6 shows the traffic load. The majority of the traffic belongs to TCP video streams generated by closed-circuit television system (CCTV). Unfortunately, the video streams do not use well-known ports (see Figure 8). Instead, we use the domain names to identify and to verify the applications. In our case, the domain names are based on a host functionality such as DVR or CCTV. We observe a diurnal TCP pattern, as can be seen in Figure 8. To distinguish between dominant TCP and other protocols we use a logarithmic scale which makes the TCP diurnal pattern less visible (Figure 6).

Fig. 9. TOP 5 dst UDP ports/bytes

Figure 9 shows UDP traffic. This traffic corresponds to well-known port numbers (165 -SNMP, 1985 -HSRP, 123 -NTP, 138 -NetBIOS, 67 -DHCP). UDP traffic is constant most of the time. Most of the flows are generated by UDP. The discrepancy in load (Figure 6) and flow (Figure 7) numbers shows the asymmetry based on the nature of the used applications.

We found that the ICMP traffic is generated by the monitoring tools checking the hosts availability. They use ping-like tools to send ICMP echo request packets. The remote host answer is carried by the echo reply message.

BACnetFlow Statistics

Table 2 summarizes the traffic observed in BMS network during one week using BACnetFlow. We include ARP and other link layer protocols (LLDP, ISMP) supported by BACnetFlow to show this typically invisible traffic in a standard NetFlow. Figure 10 shows the BACnet traffic load. We identified 42 BACnet over IP devices (IPv4 addresses), 103 BACnet over Ethernet devices (MAC addresses), 63 BACnet networks and 201 BACnet addresses in the BMS network. We observe that both BACnet protocols have similar characteristics. We suspect this is due to evolution of the BMS network. The Campus construction took place in several stages. In each stage the network evolved and new approaches were used. Early BACnet over Ethernet installations are now connected through BACnet over IP gateways. 12 virtual LANs are used to transport the traffic in BMS. This makes the observation even trickier.

We observe distinct diurnal and weekly patterns for BACnet traffic in Figures 10 and 11. The load comes up during the business hours. On the weekend and at nights, the traffic is constant and does not exhibit clear pattern.

Figures 12 and13 show the flow statistics. The traffic load peaks (busy hours) do not necessarily translate in the high number of flows in Figure 12. The results in Figure 13 show distribution of packets per flow. We observe a large number of flows with a small of packets. Number of single packet flows (SPF) is further shown in Figure 14. We found out that the maximum transmission unit (MTU) is about 500-550 octets (see Figure 14). This corresponds with BACnet over MS/TP (masterslave/token-passing) which uses the maximum NPDU of 501 octets. MS/TP is used to connect the "last mile" devices of building infrastructure (RS-485 bus). We introduced BACnetFlow as BMS networks' equivalent of the IP flow. We described innovative system for observing and storing BACnetFlow information in the environment of the BMS networks. We presented the observation results and experiences of using such system for monitoring the Masaryk University Campus.

In contrast to [START_REF] Barbosa | Difficulties in Modeling SCADA Traffic: A Comparative Analysis[END_REF], our measurement results include diurnal patterns (see Figure 10). While Barbosa is monitoring highly automatic SCADA network with a low level of human activity, our BMS network is closely connected with a human activity in the university campus. We deduce, that a network traffic profile of an automation network depends on a way how it is used.

The pilot system deployment serves to prove the concept of flow-based monitoring in BMS networks. It will be further extended to support IPFIX collection instead of currently used SQL database back-end. Currently, we have a flowbased profile of the whole network. Furthermore, we plan to validate anomaly detection techniques in the special environment of BMS and SCADA networks. In the long term, the goal of our research effort is to identify which metrics should be monitored in real-time to provide situational awareness in BMS networks.

Fig. 1 .

 1 Fig. 1. Example of a BMS network with interconnected subsystems managing: (1) heating, ventilation, and air conditioning (HVAC), (2) access control to secure particular parts of the building, (3) life safety / fire systems, (4) digital video circuits observing important places and (5) systems controlling power consumption.

APDUFig. 2 .

 2 Fig.2. BACnet over IP consists of IP layer, BACnet virtual link layer (BVLL), network layer protocol data unit (NPDU) and application layer protocol data unit (APDU). The MAC layer is unspecified.

Fig. 3 .

 3 Fig. 3. BACnet flow record consists of key fields extracted from MAC/BACnet/BIP layer and non-key fields with additional statistics.

Fig. 5 .

 5 Fig. 5. Comparison of NetFlow and BACnetFlow coverage of packet information.

Fig. 7 .

 7 Fig. 7. Traffic load in flows per second

Fig. 8 .

 8 Fig. 8. TOP 5 dst TCP ports/bytes

  0

Fig. 12 .Fig. 13 .

 1213 Fig. 12. BACnet flows per second

Fig. 14 .

 14 Fig. 14. BACnet average packet size and single packet flow (SPF) size

Fig. 15 .Fig. 16 .

 1516 Fig. 15. BACnet TOP 10 destination addresses / bytes

Table 1 .

 1 Protocols observed with NetFlow version 9

	Protocol	Bytes	Packets	Flows	bps	pps
	TCP	3.6 T 100.0 %	3.6 G 99.6 % 533628 12.7 % 47.4 M 6013
	UDP	814.0 M 0.0 %	6.6 M 0.2 %	2.5 M 60.6 %	10757	10
	ICMP	722.4 M 0.0 %	7.0 M 0.2 %	1.1 M 26.1 %	9550	11
	OSPF	25.6 M 0.0 % 191079 0.0 %	1990 0.0 %	338	0
	PIM	4.6 M 0.0 %	61131 0.0 %	6435 0.2 %	60	0
	IGMP	2.0 M 0.0 %	31509 0.0 %	14012 0.3 %	26	0
	ICMP6	1.7 M 0.0 %	18362 0.0 %	1261 0.0 %	22	0
	Total	3.6 T	3.7 G	4.2 M	47.4 M 6034

Table 2 .

 2 Protocols observed with BACnetFlow

	Protocol	Bytes	Packets	Flows	bps	pps
	BACnet/IP	7.2 G 53.9 %	79.5 M 52.9 %	5.3 M 38.1 %	95.2 K 131.4
	BACnet/Eth	5.4 G 40.5 %	59.8 M 39.7 %	6.2 M 44.6 %	71.4 K	98.9
	ARP	0.68 G 5.1 %	10.5 M 7.0 %	1.8 M 13.0 %	8995	17.4
	Other	63.7 M 0.5 %	0.6 M 0.4 %	0.6 M 4.3 %	105	1
	Total	13.3 G	150.4 M	13.9 M	175.7 K 248.7

source IP address, destination IP address, source port, destination port and transport protocol

Intel R Core TM 2 Duo CPU P8600 at 2.40 GHz with 4 GiB RAM running Linux kernel

3.1.0 for x86-64 hardware platform.

Acknowledgments. This material is based upon work supported by Masaryk University and also supported by the "CESNET Large Infrastructure" project LM2010005 funded by the Ministry of Education, Youth and Sports of the Czech Republic.


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

Aiko Pras
email: a.pras@utwente.nl

Real-Time and Resilient Intrusion Detection: A Flow-Based Approach

Flow-based intrusion detection will play an important role in high-speed networks, due to the stringent performance requirements of packet-based solutions. Flow monitoring technologies, such as Net-Flow or IPFIX, aggregate individual packets into flows, requiring new intrusion detection algorithms to deal with the aggregated data. These algorithms are subject to constraints on real-time and accurate detection of intrusions, due to the nature of current flow monitoring technologies. In this paper, we propose a framework for flow-based intrusion detection, aiming to detect intrusions in real-time, and to be resilient against negative effects of attacks on monitoring systems. This research is still in its initial phase and will contribute to a Ph.D. thesis after four years.

Introduction

Monitoring high-speed networks is a crucial and challenging task. Packet-level monitoring technologies became almost unfeasible, due to limited processing power and storage capacity on monitoring systems. Especially for monitoring links with line speeds of 10 Gbps and higher, scalable monitoring technologies are inevitable. Flow monitoring technologies, such as Cisco's NetFlow [START_REF] Claise | Cisco Systems NetFlow Services Export Version 9[END_REF] or IPFIX [START_REF] Sadasivan | Architecture for IP Flow Information Export[END_REF], were designed for this purpose, and are widely deployed in routers, switches and dedicated probes. Following this trend, security analysis applications should evolve from packet-based to flow-based solutions [START_REF] Zseby | IP Flow Information Export (IP-FIX) Applicability[END_REF]. Research has already been performed on flow-based anomaly detection in past years, such as in [START_REF] Sperotto | An Overview of IP Flow-Based Intrusion Detection[END_REF][START_REF] Sperotto | Flow-Based Intrusion Detection[END_REF][START_REF] Münz | Real-time Analysis of Flow Data for Network Attack Detection[END_REF].

Besides line speeds and available bandwidth, also the size and frequency of attacks are increasing. When these attacks target monitoring systems (either directly or indirectly), these systems -as well as the associated data -will be affected [START_REF] Sadre | The Effects of DDoS Attacks on Flow Monitoring Applications[END_REF]. For the specific case of flow monitoring, this applies to flow Exporters and Collectors, which represent the flow data export and collection processes, respectively. Exporters account traffic statistics by aggregating packets that share certain properties, known as the flow key1 . Thereafter, this aggregated flow data is sent to flow Collectors for persistent storage and analysis.

In order for intrusion detection systems (IDSs) to be reliable, detection should be done as accurate and early as possible. However, due to the design of current flow monitoring technologies, flow-based monitoring systems are subject to the following problems:

1. Exporters send flow records to Collectors after expiration. Several expiration rules can be implemented [START_REF] Claise | Cisco Systems NetFlow Services Export Version 9[END_REF][START_REF] Quittek | Information Model for IP Flow Information Export[END_REF], but timeout-based expiration rules are required. As a consequence, data analysis applications, which retrieve flow data from a Collector, always receive the data after a certain delay. Besides that, many Collectors make the stored flow data only available after a certain time interval, which should also be added to the total incurred delay. 2. When an Exporter is monitoring an ongoing attack, it might become overloaded and start to behave differently [START_REF] Sadre | The Effects of DDoS Attacks on Flow Monitoring Applications[END_REF]. Collectors might start to experience problems as well, because of the immense amount of flow records they need to process (e.g. for filtering, compressing and generating statistics) as part of an attack, for example.

To overcome these delay and performance issues, a scalable and resilient solution is needed for detecting and regulating (i.e. to avoid overloading the equipment) attack traffic for analysis by IDSs. We believe it to be a promising approach to move a part of the intrusion detection logic to the Exporter, such that detection algorithms are not subject to delays during the flow export. Besides that, Exporters and Collectors should share their knowledge about ongoing anomalies, in order to take countermeasures against overload as a consequence of an attack.

The remainder of this paper is organized as follows: Section 2 will discuss the research questions for this work, followed by a description of the proposed approach in Section 3. After that, we conclude and close this paper in Section 4.

Research Questions

The goal of this research is to design a scalable framework for real-time and resilient intrusion detection. A flow-based approach will be chosen in order to satisfy the requirement of scalability. In the remainder of this paper, we refer to this goal as the framework. To conduct the research presented above, we define the following research questions:

1. What are the implications for flow monitoring architectures when intrusion detection needs to be done in real-time? 2. How can scalability of flow-based IDSs be improved, in order to make these systems resilient against attacks? 3. How can requirements for real-time and resilient intrusion detection be modeled in a framework?

The approach used for answering each of these research questions will be discussed in the next section.

Approach

Research question 1, as presented in the previous section, aims to get a thorough understanding of performance bottlenecks in current Exporters and Collectors, which prevent these systems from serving flow data to IDSs in real-time. A realtime intrusion detection framework might require some architectural changes to flow monitoring systems, as anomaly detection should be done as close as possible to the flow Exporter (i.e. the measurement point). This study will be performed by conducting a literature study, combined with real-world measurements.

The goal of research question 2 is to investigate how scalability of flow-based IDSs can be improved. A naive approach would be to increase the sampling rate in various stages of the analysis process, for decreasing the load of the involved systems. Also flow expiration timeouts could be increased for the same purpose. Although both changes will result in a higher flow record aggregation, the quality and usefulness of the flow data for intrusion detection will be negatively impacted [START_REF] Bartos | Optimizing Flow Sampling for Network Anomaly Detection[END_REF][START_REF] Duffield | Properties and Prediction of Flow Statistics from Sampled Packet Streams[END_REF]. Hence, a tradeoff should be made between 1) flow data quality and 2) scalability of the framework, which will be covered by research question 2.

By means of research question 3, we will propose a framework for flow-based intrusion detection, in which the knowledge obtained in the previous research questions will be incorporated. Nowadays, a single, one-directional data stream is used between Exporters and Collectors, by means of which flow records are transferred. Our aim is to enrich this architecture with the following complementary data streams, as depicted in Figure 1: 1. Exporter to Collector. After moving a part of the intrusion detection logic to the Exporter, detected anomalies should be shared with the Collector. 2. Collector to Exporter. Intrusions detected by the Collector should be shared with the Exporter. Both the Collector and the analysis application can instruct the Exporter to adjust the data export process. This can be done for several reasons, such as performance constraints during ongoing attacks. Finally, the Collector sends status information about its available processing capacity, to which the Exporter can adapt the NetFlow/IPFIX data stream. 3. Exporter to Exporter. The Exporter should monitor its own available processing capacity and change the data granularity accordingly, in order to stabilize its load.

After proposing the framework, its correctness and applicability will be validated by implementing a proof-of-concept. The result will be validated against a ground truth in a lab environment. After that, the accuracy and resilience of the proposed solution will be verified in a backbone network, such as the SURFnet [11] network.

Final Considerations

When flow-based technologies are used in an intrusion detection context, flow data should be accurate and the infrastructure resilient. The nature of these technologies, however, poses constraints on these requirements. This Ph.D. research aims to design a framework that should satisfy the requirements on flow-based IDSs. The main goal of this work, as described before, should be achieved within a period of four years, as part of a Ph.D thesis.

Fig. 1 .

 1 Fig. 1. Flow-based framework for real-time and resilient intrusion detection

A commonly used flow key consists of source/destination IP addresses and port numbers, transport-layer protocol, IP Type of Service (ToS) and SNMP input interface.

Acknowledgments

This research is supported by the EU FP7-257513 UniverSelf Collaborative Project and the SURFnet GigaPort3 Project for Next-Generation Networks.


Thorsten Ries
email: thorsten.ries@uni.lu

Radu State
email: radu.state@uni.lu

Thomas Engel
email: thomas.engel@uni.lu

Instant Degradation of Anonymity in Low-Latency Anonymisation Systems

Low-latency anonymisation systems are very popular, both in academic research and in operational environments. Several attacks against these systems exist aiming to reveal the identity of a particular user, mostly by trying to assign the real IP address of the sender to a known connection. Nevertheless, the hidden identity of a user is not only based on the IP address, also location information can be of relevance. In this paper, we propose an alternative approach to instantly disclose the location of users based on Round Trip Time measurements. Even if the identity of a user can not be revealed, the correlated location information may already provide sufficient information to degrade the level of anonymity significantly. Our attack is based on virtual network coordinate systems, mapping physical nodes to a n-dimensional space to reveal a geographical proximity. Taking advantage of this feature, we define a model that leverages network coordinates based on only a single connection of a user to a malicious website for instance. Evaluation on the Planet-Lab research network proves that by the use of our proposed model a local attacker has good chance to disclose the location of a user and to utilise this information to create an low-latency anonymity system independent anonymity measure.

Introduction

In today's world of extensive online communication, the need of staying anonymous is day-to-day business for many people [START_REF]Proxy Server Usage[END_REF]. The reasons may vary, but the proper operation and performance are essential criteria for users. Particularly if it comes to low-latency anonymisation systems, which allow the use of interactive applications as web browsing for instance. Surprisingly, only a few of the many scientific approaches in this area are practically usable. One common architectural pattern is the operation of intermediate nodes to mediate between the sender and receiver. Basically, two groups are currently deployed: Onion Routing and simple proxy based solutions. The latter is attractive in its simplicity, but lacks anonymity and security. As most times only one intermediate node is operated, harvesting sensitive information and linking a connection to a sender is very attractive and easily achieved. Onion Routing [START_REF] Michael | Anonymous connections and onion routing. Selected Areas in Communications[END_REF] instead tries to avoid these issues by sending multi-encrypted messages over a path of intermediate nodes, everyone only obtaining the minimum information necessary to forward the message to the next node. Over the last years, the Onion Routing approach has been further extended and resulted in Tor [START_REF] Dingledine | Tor: the second-generation onion router[END_REF], the current predominant low-latency anonymisation system used by approximately 400,000 users per day [START_REF] Appelbaum | How governments have tried to block tor[END_REF]. Tor supports dynamic changes of the message path, provides anonymity also for servers by operating location-hidden services and protocol cleaning (i.e., removing unnecessary protocol headers before sending the message). Based on a similar approach, JonDonym [START_REF] Jondonym | [END_REF] operates static cascades of either two or three nodes in contrary. Nevertheless, all these approaches can not offer perfect anonymity because of the need of making concession for the benefit of acceptable performance. In this context, recent studies have shown the trade-off between performance and the expected degree of anonymity (e.g., [START_REF] Ries | Comparison of low-latency anonymous communication systems -practical usage and performance[END_REF]).

Proper functioning of an anonymity system does not rely on a single measure, it consists of a combination of several aspects. Even a basic latency or Round Trip Time (RTT) information can reveal sufficient information to disclose the location of a user. Hopper et al. [START_REF] Hopper | How much anonymity does network latency leak?[END_REF] recently presented a general vulnerability of Tor and multi-proxy-based anonymisation to identify the location of users with the help of a network oracle like a virtual network coordinate system (VCS). Their main limitations are the applicability of the attack to Tor and multi-proxy systems only and the very high number of required RTT measurements. Therefore, we propose an alternate approach, which is not limited to these constraints by treating the anonymisation system as black box and incorporating VCSs to a wider extend. Particularly the use of VCS's allow a large-scale attack without the need of large-scale measurements. Our aim is to compare the precision of typical low-latency anonymisation systems in terms of success rates for different location sizes (i.e., Country, Autonomous System (AS) and routable Internet network), using as few as possible (malicious) RTT-measurements to predict a users location and to utilise this information to create a system independent anonymity measure.

The rest of the paper is structured as follows: First, section 2 presents the related work and existing attacks on anonymisation systems. Then, the attack model is being described. Practical measurements and evaluation show the applicability of the attack and its implications on the degree of anonymity in section 4. Finally, we summarise and conclude the work and give an outlook to future work in section 5.

Related Work

Naturally, the purpose of low-latency anonymisation networks raises the interest of people to lever out its security features and even more important its anonymity. In fact many attacks against these networks exist; some are of more theoretical value, others can be practically capitalised. While operating a malicious node in an anonymisation system is certainly the easiest and cheapest way to infiltrate communications and to gather sensitive information, many other attacks exist. For instance, timing attacks have been shown to be a powerful type of attacks against anonymisation networks [START_REF] Bauer | Low-resource routing attacks against Tor[END_REF][START_REF] Levine | Timing attacks in low-latency mix-based systems[END_REF][START_REF] Murdoch | Sampled traffic analysis by internetexchange-level adversaries[END_REF][START_REF] Zhu | On flow correlation attacks and countermeasures in mix networks[END_REF]. The basic idea is that attackers observe and correlate message timing patterns between the sender and receiver in order to link the two parties.

VCS-based attacks

Virtual coordinate systems are widely used to predict the distance between nodes in the Internet. They are based on latency or RTT measurements and position network nodes in an d-dimensional coordinate system in order that the distance d(a, b) ≈ latency (or RT T respectively) between nodes a and b in the physical network. The aim of such systems is to increase topology awareness and as such to optimise network traffic behaviour by predicting latency with scalable measurements: O(N ) complexity instead of O(N 2 ). Global Network Positioning (GNP) [START_REF] Golle | Towards global network positioning[END_REF], Vivaldi [START_REF] Dabek | Vivaldi: A decentralized network coordinate system[END_REF] or Phoenix [START_REF] Chen | Phoenix: A weight-based network coordinate system using matrix factorization[END_REF] are well known systems in this area.

Approaches to exploit RTT information already exist for some while. As the first, Back et al. [START_REF] Back | Traffic analysis attacks and trade-offs in anonymity providing systems[END_REF] analysed traffic in low-latency anonymisation systems, describing a general vulnerability against latency-based attacks and discussing the trade-off's between the degree of anonymity and performance. Based on this work, Hopper et al. [START_REF] Hopper | How much anonymity does network latency leak?[END_REF] use latency measurements to determine the location of a victim node by calculating the remaining entropy of the system [START_REF] Diaz | Towards measuring anonymity[END_REF]. With every connection to a malicious web site certain bits of information are collected and with the help of an assisting malicious node, the RTT between the victim and the entry node of the anonymisation system is being calculated. In order to determine the exact RTT, they perform max. 1,000 RTT measurements per server visit, so in total, up to 50,000 measurements are required to operate the attack successfully when concluding that the attacker needs 41 server visits of the potential victim in a multi-proxy environment and 50 visits when the victim is using Tor. As a result, a static location of the victim is required during the attack. We would like to stress that the attack relies on the existence of different entry nodes to determine the victims' location and thus is limited to the two discussed anonymisation systems.

Attack methodology

Considering the anonymisation system as a black box allows to attack and quantify location anonymity of all practically systems used. Contrary to Hopper et al., there is no need of iterative client access on the malicious server, neither the need of pre-required attacks like the necessary identification the first node in the anonymisation system via e.g. Tor path discovering [START_REF] Chakravarty | Traffic analysis against low-latency anonymity networks using available bandwidth estimation[END_REF][START_REF] Murdoch | Low-cost traffic analysis of tor[END_REF]. The objective is to identify the location of a user instantly, thus also covering victims with frequent changes of their network location and by this to quantify the systems' anonymity.

The attack model necessitates only a single connection from the victim u i to a malicious node N m . Optimally, N m requires a certain number of collaborative landmarks {k 1 , ..., k p } ∈ K in different locations {l 1 , .., l n } ∈ L and k h ∈ l j (see Fig. 1). Depending on the expected granularity, a location can be a country, AS or a routable Internet network location. This in turn means that a certain uncertainty about the accurate location of the node still remains, depending on the location size (i.e. number of possible victim nodes within), but for a correct identification of the location, the degree of anonymity is potentially degraded nevertheless.

The landmarks in known locations serve as reference points and are required as neighbours in the VCS calculation to achieve precise node placements. Based on the RTT data captured between u i and the landmarks, the attacker computes such a VCS (here: Phoenix) taking the available landmarks, the victim and himself into account. The main idea of Phoenix is that through factorisation, the linear dependence among rows in most Internet distance matrices is characterised best. Therefore Phoenix creates two n × d-matrices X and Y with X storing the linear coefficients and Y the basic vectors for all n nodes in d dimensions to calculate the overall distance matrix D = X • Y . We refer to [START_REF] Chen | Phoenix: A weight-based network coordinate system using matrix factorization[END_REF] for more details on the computation.

D is used to prove our assumption that nodes with corresponding row values in D, are also neighbours in the physical network. The predicted distance (D p ) between two nodes a and b is then:

. . . N m k 2 k 1 k n Anonymisation Network Y [ms] X [ms] k n k 2 k 1 u i u i l 1 l 2 l j l 1 l j l 2 N m
D p (a, b) = d i=1 X(a, i) • Y (b, i) (1)
Based on D, the location of the different nodes needs to be determined. Hence, the attack is successful if the physical location l j of a victim u i can be disclosed. As classifier, e.g. k-nearest neighbour [START_REF] Cover | Nearest neighbor pattern classification[END_REF] or instance-based learning [START_REF] Aha | Instance-based learning algorithms[END_REF] can be considered. This group of supervised learning methods analyses the given data (D , a n -1 × m matrix, corresponding to D, but the row of u i being removed) and predicts the class (l j ) for an input(u i ) based on classification patterns. In our case using the Phoenix coordinate system, l j (u i ) is predicted based on the similarity of the matrix rows for two corresponding nodes. Using instance-based learning and n nodes, l j (u i ), the closest neighbour of u i can be calculated using the Euclidian distance as follows [START_REF] Aha | Instance-based learning algorithms[END_REF]:

k = f   D, min n   d q=1 (D iq -D nq ) 2     (2)
where D i is the row vector of u i and q the column (node) index of D, f being a function to map the closest distance to the corresponding node in K. If l j (u i ) = l j (k), the attack is successful.

The main advantage of this approach is that virtual coordinate systems generally do not require a full set of measurements. Consequently, the usage of virtual coordinate systems allows us large-scale attacks of all anonymisation systems without the need of large-scale measurements.

Experimental Evaluation

In order to evaluate our model, we rely on the PlanetLab research network [14] with known locations and the ability to perform distance measurements from every node. The test-bed consisted of 90 nodes located in 25 Countries and the nodes were further distributed in 53 AS's and 58 routable Internet locations. We first carried out reference measurements using direct links (without the use of any anonymisation system) to allow a general validation of our approach. Then the same measurements have been repeated against the selected anonymisation networks:

a single proxy server located in Steinsel/Luxembourg, -JonDonym using a premium cascade with nodes in the Czech Republic, Luxembourg and the Netherlands1 , -Tor with standard configuration.

All measurements have been performed during 5 days in April 2011.

Round-Trip time measurements

Using typical TCP mechanisms to measure RTTs through anonymisation services may cause incorrect results as e.g. the entry node of Tor acknowledges packets immediately so that the RTT is actually measured between the client and the entry node [START_REF] Hopper | How much anonymity does network latency leak?[END_REF]. For our measurements, we therefore used a self-developed client-server application measuring the RTT between the nodes on application level by sending and requesting one Byte messages (plus the corresponding TCP and IP headers). The results may vary from 'real' RTT measurements by processing delay and slightly increased package size. We accept this systematic error that also incorporates into the VCS, but which is not expected to have a significant impact in classification the nodes. Table 1 shows the mean RTT's as well as the high standard deviation of our measurements. Even without anonymisation service, the standard deviation is very high and depicts the additional problem of overloaded nodes and related traffic congestion in PlanetLab. This aspect introduces a certain impreciseness and impact on the attack, which we do not expect to such a degree in a 'real world' environment.

Evaluation

In a first evaluation all available nodes have been considered as collaborative landmarks. As already mentioned, we chose Phoenix because of its high prediction accuracy compared to other VCSs. Furthermore Phoenix converges quickly to a steady state, which is of particular importance for the intended small number of measurements and its robustness against measurement anomalies. Another advantage is the resistance against the triangle inequality violation (TIV) [START_REF] Chen | Phoenix: A weight-based network coordinate system using matrix factorization[END_REF], which is persistent on the Internet [START_REF] Zheng | Internet routing policies and round-trip-times[END_REF] and particularly in overlay-routing, as the routing nodes can easily cause additional delays.

For the classification, we used the instance-based classifier [START_REF] Aha | Instance-based learning algorithms[END_REF] to identify the location of the nodes on the different levels based on a distance measure that compares the rows of the matrix D. Previous experiments have shown this algorithm for being most efficient. Based on n = 90 nodes Country AS Routable network q q q q q q q q q

No Proxy Single Proxy JonDonym Tor Fig. 2. Success rates for all anonymisation systems and m = 100 Phoenix runs, the success rate has been calculated for every node (NSR):

N SR = m i=1 hit(u i ) m (3) hit(u i ) = 0 if classification fails 1 if u i is correctly classified
The success rates for every node are then summarised to describe the system success rate (SR) (equation 4):

SR = n j=1 N SR j n (4)
Figure 2 shows the classification rates achieved for all systems including the computed reference values without anonymisation. While achieving a disclosure rate of 0.9 on country-level the values decrease on AS and Internet routable network level and depict the difficulty of exact nodepositioning and classification with current coordinate-based systems and q q q q q q q q q 0 20 40 60 80 q q q q q q q q q q q q q q q q q q Country AS LAN q q q q q q q q q 0 20 40 60 80 0 20 40 60 80 100

Single Proxy

Landmarks Success Rate [%] q q q q q q q q q q q q q q q q q q Country AS LAN q q q q q q q q q 0 20 40 60 80 q q q q q q q q q q q q q q q q q q Country AS LAN q q q q q q q q q 0 20 40 60 80 q q q q q q q q q q q q q q q q q q Country AS LAN Fig. 3. Performance comparison using different number of landmarks leaves room for improvement. The problem is mainly based on very similar node characteristics in D and the high variation of measurements, which cause difficult location assignments.

The proxy generally showed the worst protection against our attack, for which we achieve a disclosure rate of 0.51 on country-level. Though the values decrease to 0.25 on AS-and 0.22 on subnet-level, the vulnerability against this kind of attacks is apparent. Overall, Tor shows the best resistance against the attack, having disclosure rates of 0.13 on countrylevel and only 0.04 on AS-and 0.03 on Internet routable network level, which basically does not allow much inference on the location. Slightly higher rates of 0.34, 0.12 and 0.11 have been achieved for the comparable anonymisation approach of JonDonym. The differences are mainly the static circuit/cascade and the higher available bandwidth. The study shows that the overall resistance of the systems against such a RTT-based attack seems to depend on the variance of the measurements. The higher the variation, the better the protection. However, the values allow the description of anonymity system in regard to the disclosure of a users location and thus as a measure of anonymity.

We also evaluated the systems performance for different numbers of landmarks, with the results shown in Figure 3. Again, we ran calculations for every node acting a victim and the values in the graphs depict the percentage of cases in which a node has been identified successfully. The results are comparable the previous evaluation but show that an attacker only needs approximately 20 cooperative landmark nodes in order to execute the disclosure attack effectively and thus keeps the needed number of landmarks reasonable in regard the time needed to perform the measurements.

Conclusion and Future work

This work presents an initial system independent approach to disclose the location of users with the help of virtual coordinate systems aiming to define an anonymity measure, with a low complexity. We show that an attacker may be in a position to instantly locate a user who connects to a malicious web server on several levels of precision. Therefore we set up a test bed in Planet-Lab and combined the principle of virtual network coordinates with instance-based class if to a practical attack.

Our evaluation shows that an attacker has a good chance to disclose a victims' location on country level. The success rates in more fine-grained locations are lower, but still show a potential for further improvement, so future work will therefore be directed towards improved node-mapping and classification approaches as well as approaches to explore the attack in a 'real world' environment in order to minimise errors due to PlanetLab overload. However, even if the victim node is not located in one of the observed classes, the classification reveals a geographic proximity and can provide useful information especially for location-based services. Thus, though a detailed identification of a user may be not possible directly, the anonymity set size can be reduced, hence the degree of anonymity.

In low-latency anonymisation networks, mitigation against our attack and latency or RTT-based attacks in general is rather difficult without decreasing performance. If, for instance higher variance are incorporated, interactive applications may get unusable. As a side effect, users may get disappointed about the low performance, not further use the system(s) and thereby decreasing the size of the anonymity set and consequently the degree of anonymity.

Fig. 1 .

 1 Fig. 1. Schematic description of the location model. Locations in the physical network are mapped in a virtual coordinate system, aiming to reflect real-world distances.

Table 1 .

 1 Mean and Standard deviation of RTT measurements

	Anon Sys Mean RTT Standard
			Deviation
	No Proxy	192ms	169ms
	Single proxy	278ms	192ms
	JonDonym	509ms	299ms
	Tor	737ms	464ms

JonDonym is the commercial version of JAP[START_REF]JAP Anonymity and Privacy[END_REF]. JonDonyms' free cascades of only two intermediate nodes have a much higher anonymity set, but due to their popularity, they are very often overcrowded and reject additional connections.

Acknowledgements This experimental research was conducted using the Planet-Lab research network and we thank Emmanuel Nataf from INRIA Nancy -Grand Est for quickly and simply providing us access to the network.


Václav Bartoš
email: ibartosv@fit.vutbr.cz

Martin Žádník

Network Anomaly Detection: Comparison and Real-time Issues

This paper discusses several issues of evaluation and comparison of anomaly detection algorithms, namely lack of publicly available implementations and annotated data sets. Another problem of many methods is a detection delay caused by operating on data binned to a long time intervals. The paper presents a library under development which aims to tackle the comparison and evaluation issues. Further, the paper proposes a novel anomaly detection approach that can contribute to anomaly detection in real-time.

Introduction

Anomaly detection systems helps to keep track of security violations and disruptions to network and its services. Methods of anomaly detection have received great research attention and large number of methods have been proposed. This paper addresses some of the issues in the area of anomaly detection (AD).

There is a lack of comprehensive comparison of existing methods and a lack of annotated data sets for their evaluation. Therefore a library of AD algorithms is proposed and being implemented. Its goal is to provide reference implementations of AD methods and to annotate available data sets in a semi-automated manner. At the same time various methods may be compared in terms of their precision and types of detected anomalies.

Further, the attention is focused on real-time anomaly detection. A novel method of anomaly detection is proposed. The method is based on observing flow cache behavior, namely, detection of its hit ratio deviations.

Problematic comparison of anomaly detection methods

There are many methods proposed for anomaly detection systems. But they usually vary in their properties. Some of them are specialized for detection of particular category of intrusions, others are general. Some work upon short time scales and detect anomalies within seconds, some can detect only a long-term anomalies. Each method generates certain ratio of false alarms and misses certain portion of existing anomalies. There are also great differences in computational complexity.

Although several papers [START_REF] Patcha | An overview of anomaly detection techniques: Existing solutions and latest technological trends[END_REF][START_REF] Zhang | A survey of anomaly detection methods in networks[END_REF] categorize various methods according to their properties, there is a lack of experimental evaluation and direct comparison of their detection capabilities. Such evaluation is usually done in papers proposing new methods, where authors compare proposed method with one or two previous ones. But this may not be sufficient for a designer who wants to build an anomaly detection system and needs to choose methods to use. A thorough comparison with other methods is rendered hard due to missing library of AD algorithms which would be publicly available. Moreover, many papers do not provide specific details which may turn out to be crucial for correct implementation and setup of the algorithm. Therefore it would be very useful if authors of the methods publish also its reference implementations. But this is not usual.

Another problem of evaluation and comparison of methods is a lack of testing data. There are only few public sources of real network data (MAWI traffic archive [START_REF]Mawi traffic archive[END_REF] seems to be the most popular). Researchers often use their own data (e.g. from a university network) but these data cannot be usually published due to privacy or security issues. The data set should be annotated, i.e. all anomalies in the data set should be labeled. But available data sets are only a plain data1 , so researchers have to annotate them themselves. These problems may lead to a biased results of the same method implemented by various researchers.

Because of the reasons discussed above, we propose and currently implement a library containing reference implementations of several anomaly detection methods. The library will create a basis for a framework allowing intuitive evaluation and comparison with other methods. Besides the anomaly detectors, the framework will contain several supporting tools, for example software flow generator, modules for loading data (packet traces, flow records) in various formats, modules for plotting results, etc. There will also be several data sets with different levels of abstraction -packet traces, flow records and traffic volume/entropy timeseries. These data will be annotated automatically (by combining data from several detectors) or semi-automatically (with manual checking and labeling of anomalies found by detectors). Of course, details of all methods used for annotation and values of their parameters will be provided.

Such library allows for an objective comparison of methods by using the reference implementations and the reference data. It will also help authors to easily compare their new algorithm with others and designers to select a fitting set of algorithms for their particular system. Most of the library is being written in Python as it allows for fast prototyping, readable and well-documented code, although several time demanding parts are being written more effectively in C++. The library is being developed within research group ANT@FIT and its first version will be published in near future on group's web site2 .

Flow-cache based anomaly detection

Most of the anomaly detection methods work upon traffic volumes such as number of bytes, packets, flows or upon some information extracted from flow records. The prevailing source of such data are flow exporters. The flow exporters (either a dedicated probe or router) report on observed flows via NetFlow or IPFIX protocol to a collector. The collector stores reported flows into files or database. Collected flow records are then subject to the anomaly detection.

The above measurement pipeline introduces several obstacles which renders anomaly detection delayed and unreliable. First, there are delays or even a reporting losses at the exporter side. The exporter contains a flow cache which stores records describing ongoing active flows. The record is removed from the flow cache if the corresponding flow becomes inactive or if the flow cache is full. A removed flow record is queued in the exporter and awaits assembly of a reporting packet which consists of multiple flow records.

In case of a sudden flood of new flows (anomaly), there may be necessary to remove large number of flows from the flow cache. This may result in a loss of reported flow records due to the lack of performance allocated for reporting removed flow records. There can also be a delay or loss at the collector side.

Another delay is introduced by the collecting engine or the analysis engine. Former or latter gathers flow records into fixed-size time bins (e.g. 1 or 5 minutes) which are convenient for the analysis [START_REF] Estan | Building a better netflow[END_REF] but renders real-time detection impossible.

We propose a fast detection mechanism which do not rely on this measurement pipeline. It is based directly on observing behavior of the flow cache. Several statistics can be measured upon the flow cache. One of them is flow cache hit ratio -number of packets whose flow record is found in the cache (cache hit) divided by total number of packets received.

According to preliminary experiments, the hit ratio is very stable under normal conditions. But it changes significantly during flood anomalies (DoS attacks, port scans, etc.), which makes it a suitable metric for anomaly detection.

Figure 1 shows the hit ratio of a flow cache sampled every second using 4 different packet traces from MAWI archive [START_REF]Mawi traffic archive[END_REF]. The graphs show that the hit ratio stays within 0.8 and 0.95 most of the time except for a few sharp spikes. Little investigation reveals that all these spikes are caused by network scans or similar malicious activity. This example shows that it is possible to detect at least some network anomalies only by measuring the hit ratio of a flow cache.

Much more experiments must be conducted to find out real capabilities of this approach. But even if it does not outperform other methods in terms of detection sensitivity, it has one important advantage -it can operate on very short time scales (1 second or even less). Inherently, it can detect anomalies much faster than methods processing flow records on a collector.

As a result it may raise alert immediately. Also, it should be possible to derive a filtering rule describing flood traffic. Then only an aggregated information about the flood may be sent to the collector (e.g. via IPFIX) in order to reduce performance and bandwidth usage.

Conclusion

This paper describes author's work in the field of network anomaly detection. First, issues of evaluation and comparison of anomaly detection methods were discussed. These issues are addressed by a library which aims to cope these problems byroviding publicly available implementations of several anomaly detection methods, supporting tools and annotated data sets. Second part of the paper was devoted to description of novel method using a flow cache statistics for anomaly detection. The preliminary experiments shows promising results but more detailed investigation of flow cache properties and its usability for an anomaly detection is needed. It will be part of our future work.

Fig. 1 .

 1 Fig. 1. Hit ratio of a flow cache for 4 different packet traces.

There exist annotated data sets from DARPA Intrusion Detection Evaluation 1998 and 1999, and KDD Cup 1999 data set, evidently these are very outdated now.

http://merlin.fit.vutbr.cz/ant/

Acknowledgment

This work has been partially supported by the Research Plan MSM 0021630528, IT4Innovations Centre of Excellence project CZ.1.05/1.1.00/02.0070 and the grant BUT FIT-S-11-1.