The video is temporarily removed on request from the HP Security team.

Full paper

Presentation used at the conference

Citation: Polčák, L., Hranický, R., Matoušek, P.: Hiding TCP Traffic: Threats and Counter-measures, In: Security and Protection of Information 2013, Brno, CZ, UNOB, 2013, s. 83-96, ISBN 978-80-7231-922-0

IPv6 Neighbor Discovery, Router Advertisement, Rogue RA attack, RA Guard.

1. Introduction to NDP

The Neighbor Discovery Protocol (NDP) specified by RFC 4861 can be thought of as an IPv6 analogy to the set of IPv4 protocols, namely Address Resolution Protocol (ARP), ICMP Redirect and ICMP Router Discovery. To be more precise, it provides even more services, but as far as the Rogue RA Attack is concerned, the most important are Router Discovery and SLAAC. The main purpose of these services is to provide hosts with a unique IPv6 address and a default gateway. After a host connects to the network, the process is as follows:

1. A host creates an Interface ID, usually via EUI-64 procedure or in case of Privacy Extensions it uses a (pseudo)random ID.
2. The host creates a link-local IPv6 address by appending an Interface ID to the FE80::/10 prefix.
3. The host discovers routers by sending Router Solicitation (ICMPv6 message type 133).
4. IF there are any routers on the link, they announce themselves by replying with Router Advertisement (ICMPv6 message type 134), including:
   - Advertised prefix
   - Router Lifetime – a positive value indicates the remaining time a router is willing to behave as a default gateway
   - Additional parameters such as MTU, etc.
5. The host receives a Router Advertisement, creates an IPv6 Globally Unique Address by appending its Interface ID to the advertised prefix.
6. IF the Router Lifetime value is non-zero, it inserts the IPv6 address of a router to its Default Router List.

The following figure illustrates the whole process.

2. Rogue RA Attack

The main issue of the NDP protocol is that its messages are unsecured. Nodes receiving unsecured NDP messages cannot distinguish between valid and “bogus” NDP messages, so there are only two possible ways of treating them. Either to ignore (which is not acceptable) or to process all of them. This is a huge security issue, because an attacker can pretend to be a valid router and provide hosts with malicious information in order to disrupt their connectivity (Denial of Service) or worse, capture their data (Man-in-the-Middle). The outline of a typical MitM Rogue RA Attack can be as follows.

1. An attacker captures a valid Router Advertisement.
2. An attacker changes a Router Lifetime value to zero and sends such crafted message in order to force the victim to remove the current valid router from its Default Router List.
3. An attacker then creates another Router Advertisement, but this time announcing himself as a valid router, which effectively redirects the traffic through an attacker’s station. In fact, the traffic flowing back to the victim will be forwarded directly to the victim. An attacker can, however, perform a Neighbor Cache Poisoning Attack to change this, but this is beyond the scope of this article.

As mentioned above, currently there are few mitigation techniques available against this type of attack, but there is probably only one of them that is usable — RA Snooping.

3. RA Guard

Most of the networks have a common attribute that their nodes are on a link layer bonded by some intermediary device (usually switch), rather than directly. Such scenarios provide an opportunity to make use of a mechanism called RA Snooping. The idea of so-called snooping has been present in computer networks for long time, in the form of, for instance, IGMP Snooping or DHCP Snooping. It is well-known that switches use only information provided by link-layer header of received frames to forward them through the right interface. The concept of snooping exceeds this behavior in that the switch inspects also upper-layer information, based on which it takes beforehand defined actions. These actions have either optimizing (IGMP) or security (DHCP, RA) character.

RA Guard is a prevention mechanism against Rogue RA attack that utilizes RA Snooping. The key condition that must be met prior to RA Guard deployment is that there must be some intermediary device in a network that all traffic passes through. Typical example of such device is an Ethernet switch. RA Guard is implemented precisely on this device. The core functionality of RA Guard is that it inspects Router Advertisements and based on the information provided it decides whether to drop or forward them. Note that RA Guard is not any particular protocol or strictly defined mechanism. It is just common term describing a set of recommendations and general description of prevention mechanisms that were implemented by various vendors and appeared under various names. For example, while Cisco retains the name RA Guard, H3C uses the different label — ND Detection.

3.1 Configuring RA Guard on Cisco device

This section briefly describes, the configuration of RA Guard on Cisco devices. More details can be found in official Cisco documentation [4]

Switch(config)# ipv6 nd raguard policy POLICY-NAME   ! Defines the RA Guard policy name
Switch(config-ra-guard)# device-role {host | router} ! Specifies the role of the device attached to the port.

The RA Guard policy can have several other optional options checking the hop limit, router preference etc. After the policy is configured, it has to be applied to appropriate interfaces.

Switch(config)# interface INTERFACE
Switch(config-if)# ipv6 nd raguard attach-policy POLICY-NAME ! Applies the RA Guard policy

If a policy is configured with device-role host, a switch will drop any RA messages received on an interface where the policy is applied, thus eliminating the RA attack. Interfaces towards to a router should be configured with a policy where device-role is set to router.

3.2 Configuring RA Guard on H3C device

H3C devices incorporate RA Guard into more complex ND attack defense tool called ND Detection. Similarly to Cisco RA Guard implementation, also ND Detection function differentiates between trusted and untrusted ports. RA messages are not checked for correctness at trusted ports and are always forwarded.

[Switch] ipv6                                         # Enable IPv6, as it is disabled by default.
[Switch] vlan 1
[Switch-vlan1] ipv6 nd detection enable               # Enable ND Detection functionality on selected VLAN.
[Switch-vlan1] quit
[Switch] interface GigabitEthernet 1/0/1
[Switch-GigabitEthernet1/0/1] ipv6 nd detection trust # Set interface connected to router as trusted.

4. Bypassing RA Guard

Against the simplest form of this attack (i.e. IPv6 header and Rogue ICMPv6 message are the only content of an IPv6 packet) are both RA Guard and ND Detection effective. As it turns out, if an attacker modifies the Router Advertisement message in an appropriate way, RA Guard may not recognize such messages as bogus. For that purpose, an attacker can make use of the concept of IPv6 Extension Headers and/or IPv6 packet fragmentation.

4.1 RA Guard Bypass Using Extension Headers

Similarly to IPv4, also IPv6 provides the option to extend the protocol. IPv4 has the Options field in IPv4 packet header, which can contain an information of arbitrary length (with respect to the maximum length of an IPv4 packet and IHL maximum value) as specified by RFC 791. Some intermediary nodes, processing IPv4 packets need an access to upper-layer information (e.g. firewalls), but as the Options field is variable in size, the first octet of an upper-layer header must be calculated dynamically according to Internet Header Length (IHL) value of an IPv4 packet.

Also the specification of IPv6 (RFC 2460) provides a room for protocol extensions, but the realization is slightly different as with its predecessor. The size of an IPv6 header is now fixed, in order to speed up the forwarding process. The Options field is not present anymore, but its role was substituted by the Next Header field. Apart from the fixed-size main header of an IPv6 packet, there may be a number of supplementary Extension Headers. These Extension Headers are concatenated in a row, each containing the Next Header field in addition to data contained. Each Extension Header is identified by its identifier, which is contained in the Next Header field of a previous header. The semantics of the last Extension Header is the same as the Protocol field of an IPv4 packet (i.e. it identifies the payload of an IPv6 packet).

In most cases, ICMPv6 messages are transmitted without any Extension Header. Some of the implementations of RA Guard may reckon on this, so they inspect only the Next Header field of an IPv6 header. If it does not contain a value of 58, the packet is considered as non-ICMPv6, thus RA Guard does not prevent it from forwarding. This is, however, false premise, as an attacker can easily craft packets with additional Extension Header preceding the ICMPv6 message itself.

To build upon this idea, an attacker can concatenate more than one extension header in order to bypass RA Guard. In order to improve network performance, NDP messages inspection is usually implemented in hardware, which has limited resources. If an attacker creates a packet with absurdly long header chain and succeeds in exhausting all available resources of a switch, the device fails to identify spurious RA message and the defense fails. This may not be true for all devices, but there is a high probability that it may pose a significant challenge for low-end devices.

Further testing revealed that even RA Guard implementation of tested devices fails to inspect the whole chain of Extension Headers and already seven empty Destination Options Extension Headers are sufficient enough to bypass the RA Guard on tested Cisco devices. H3C device has even lower limit — three Extension Headers (see figure below). Tests have shown that if an attacker includes more than 16 extension headers (All of the conducted tests used empty Destination Options Extension Headers), the Cisco RA Guard Implementation is suddenly able to properly recognize bogus Router Advertisements. Based on the information provided by Cisco, hardware forwarding path is preffered to software forwarding. This means that if an IPv6 traffic filtering is in use, also Extension Headers must be inspected in hardware. In case of the header chain too large to fit into the resources allocated in hardware, the packet is punted to the software path. Based on this information, it is reasonable to assume that if a packet has an Extension Header chain short enough to fit into available resources, but consisting of sufficient amount of headers, so that they would not be inspected entirely, such packet would most probably not be dropped (Since this inspection is implemented in hardware, the number of headers that could actually be inspected must be fixed). This is probably only a flaw in implementation, but the fact remains that these devices are vulnerable from this kind of attack.

4.2 RA Guard Bypass Using Packet Fragmentation

The purpose of IP fragmentation is to transfer packets larger than the MTU of used link-layer technology. This is achieved by splitting the original packet into multiple fragments, each of the size less than given MTU and transferring each part separately, so that they can be reassembled by their receiver. As with IPv6, the idea remains the same as in IPv4, but there are some differencies. In IPv4, any device is allowed to fragment the transiting packet in case, when the MTU of a link that a packet is supposed to be sent to is smaller than the size of a packet itself. On the contrary, fragmentation of IPv6 datagrams is allowed only at the sender’s node. In case, when a datagram cannot be forwarded by some intermediary device because of too small MTU of the particular link, the device sends an ICMPv6 Packet Too Big message including the MTU that caused the failure to the sender. This behavior is a part of the Path MTU Discovery defined by RFC 1981, which is used to determine the minimum MTU size of all the links spanning from the sender to the receiver, so that IPv6 datagrams would not need to be fragmented. What is more, IPv6 specification requires that every link in the Internet have an MTU of 1280 octets or greater. Another difference from IPv4 is that in IPv4, all information needed for IP fragments assembly at receiving node are present directly in IPv4 header. On the other side, IPv6 excluded this information from an IPv6 header and introduced separate Extension Header for that purpose, because its aim is to avoid packet fragmentation at all.

The concept of IPv6 packet fragmentation can be exploited to bypass RA Guard. The idea is as follows. An attacker inserts additional Extension Header (e.g. Destination Options), splits the Rogue RA message into more fragments, and sends them separately. Therefore, also a device with RA Guard configured will treat these fragments separately. Note, that most of the IP networks ensure high availability by means of path redundacy and therefore, if there are multiple paths available between the sender and the receiver, each fragment can take another path. Following figure illustrates the original Rogue RA message, prior to fragmentation, and the two resulting fragments which are subsequently sent as a part of the attack.

In this case, a device processing the second fragment is unable to locate the ICMPv6 header contained in this fragment. The reason for this is following. To locate the first byte of an ICMPv6 header a device needs to know the length of a previous header, which is, however, present in the first fragment. Thus, by leveraging the use of a Fragment Header together with another Extension Header (in our case Destination Options), the attacker is able to conceal the content of an ICMPv6 message including its type. The transit device with RA Guard configured has only two options. Either it blocks all such fragmented messages including those that are valid, or it forwards all of them, including the malicious ones. The reasonable choice is the second one, as it is unacceptable to drop any valid traffic.

If an attacker uses the approach mentioned above, a snooping device can at least detect that the original packet was an ICMPv6 message, since the Next Header field of the last Extension Header of the first fragment is set to 58. This idea can be pushed further, so that it is impossible for the intermediary device to even detect that it is an ICMPv6 message, actually. This can be achieved with an ICMPv6 message preceded with two or more Extension Headers that are splitted into fragments as illustrated in the following figure.

The challenge that the second fragment presents is the same as in the previous case, but this time, a device processing the first fragment is not even able to detect that ICMPv6 message is being transmitted. This is because the Next Header field of the last Extension Header of the first fragment has the value of 60, which indicates the Destination Options as the following Extension Header.

All of the tested devices are vulnerable from Rogue RA attack with packet fragmentation, as expected. Current specification of RA Guard actually does not take into account issues associated with packet fragmentation and therefore, practically all of the current implementations of RA Guard are vulnerable from this form of an attack.

There is, however, some work in progress [1] that recommends to drop all IPv6 packets that are first fragments (i.e., Fragment Offset is set to 0) and fail to include the entire header chain. Non-first fragments may be safely forwarded, because their destination would not be able to properly assemble all of the fragments, as the first one would be missing. At the time of this writing, such behavior of RA Guard has not been implemented yet and it is questionable, if it ever will be. There is, however, a possibility to achieve such behavior on Cisco devices by making use of an ACL deny ip any any undetermined-transport, but unfortunately, none of the tested devices supports such ACL. The main obstacle preventing this solution from being deployed is that it may drop unusual but valid packets.

Even if such restriction would be acceptable, there is still a chance to bypass RA Guard [3]. An attacker can create two overlapping fragments in a way so that the first fragment would contain some regular message (e.g. ICMPv6 Echo Request), so that it will not be dropped by RA Guard and the second fragment would contain malicious RA message with an offset being set in such a way that when these fragments will be assembled at their destination, RA message overwrites the message included in the first fragment. Following figure illustrates the situation.

Since different operating systems handled assembly of fragments in different ways and overlapping fragments represented critical security issue, RFC 5722 forbade their usage. According to research conducted by SI6 Networks [2], all of the current operating systems are converging towards the implementation of RFC 5722, so overlapping fragments should not pose a threat in most cases.

5. Conclusion

The presented attack was tested on following devices with RA Guard (resp. ND Detection) enabled:

• Cisco Catalyst 3750-X Series Switch with IOS version 15.0(2)SE1
• Cisco Catalyst 2960-S Series Switch with IOS version 15.0(2)SE2
• H3C A5800 with OS version 5.20

IPv6, security, campus network, transition

1. Introduction

The idea of IPv6 deployment proposed by RFC 5211 [1] expected that the Internet would be fully migrated to IPv6 in these days. Unfortunately, it seems that all deployment strategies defined in either political [2],[3] or technical documents were too optimistic. IANA IPv4 address pool is already depleted, more than 10% autonomous systems (AS) announces IPv6 prefix in global BGP table [4] and most of operating systems support IPv6. However, the content providers still indicate that less than 0.5% [5] of clients is being able to use IPv6 connectivity. What is worse, there are statistics showing that IPv6 connectivity in some networks might be broken or less stable comparing to IPv4 [6]. As the result, most of content providers are afraid to announce IPv6 for their services in fear of losing customers.

Observing the global IPv6 infrastructure and deployment, we believe there are no significant problems to have a good IPv6 connectivity for servers in data centers. Many transport networks can deliver IPv6 traffic today as well. We believe that the key problem of the low IPv6 penetration is on the side of ISPs providing last mile to customers. ISP must ensure a positive user experience, thus if the IPv6 is deployed, it is important that the deployment is secure and a service quality is the same as in IPv4 network. Unfortunately, there are not many devices able to implement IPv6 first hop security that is equivalent to IPv4 security. Ordinary user does not care about protocol used for connection, but does care if the connection is broken or unstable, which is sometimes a problem with IPv6 connection.

This article comprises experience with deploying IPv6 at the campus network at the Brno University of Technology (BUT) which is one of the biggest universities in the Czech Republic. Currently, the core of the network has fully enabled support for the dual-stack and the IPv6 network completely follows topology of IPv4 network. University also has own provider independent (PI) IPv6 address space to be able to use multihomed IPv6 connections in future. The university campus network connects more than 2,500 staff users and more than 23,000 students. The top utilization is present at student dormitories where more than 6,000 students are connected via 100 Mb/s and l Gb/s links.

In the following sections we will describe the most significant issues that we have been faced with during the deployment of IPv6 protocol in the campus network. The deployment started at the university in 2002. At the beginning, the experimental network on dedicated devices and links was created. Currently, the IPv6 and IPv4 share the same infrastructure that is operated as a dualstack network. Most of the network services support both protocols. However, the process of transition to IPv6 at the university has not been finished yet, and it would take a lot of time and effort to move all services to IPv6 with the equivalent stability and reliability as we have in IPv4.

2. Addressing issues

One of the main issues is address assignment for clients. The mixture of various OSs in a network requires automatic address assignment that is supported by most of the systems. Assigning addresses with a DHCP server became de-facto standard for IPv4. However, DHCPv6 protocol is different.

DHCPv6 features two basic modes. In practice, the first mode, stateless DHCPv6, is a layer on top of the autoconfiguration mechanism (SLAAC) and is used to provide recursive DNS server addresses. Two special flags are used for this purpose in the Router advertisement (RA) message: M – managed, O – other. These flags tell the client that it should ask a DHCPv6 server for more information related to the connection parameters. If the M flag is set, statefull DHCPv6 is used. If the O flag is set, SLAAC will be combined with stateless DHCPv6. The strong binding between SLAAC and DHCPv6 brings several problems.

• It is not possible to pass all necessary configuration options (e.g. option for default route) via DHCPv6 server. Authors of DHCPv6 protocol stated that because SLAAC has to be used anyway, default route is not necessary – client learns a default route from RA message. However, this forces to use both autoconfiguration mechanisms together and increases the complexity.
• When a client sees an RA with M flag on, a client sends a DHCPv6 Solicit message looking for a DHCPv6 server. A DHCPv6 server responds with appropriate configuration for the client. However, if the client has a DHCPv6 derived address, and receives an RA with M flag off, the client will release that DHCPv6 derived address. Unfortunately, RA messages can be easily spoofed so the attacker can force all clients in a local network to release their IPv6 addresses just with one packet. This can be solved by proper filtering on access layer; however this is sometimes a problem. The filtering possibilities are discussed later in the paper.

Using DHCPv6, we do not get the same results as with DHCPv4 server (MAC to IPv6 address binding).
DHCPv6 does not use a MAC address to identify the client; instead, it uses a specially created unique identifier called a DUID (DHCP Unique Identifier). The main idea behind this identifier is to release the clients from dependence on hardware and on a specific network interface. The advantage is that a change of a network adapter or a connection through another interface (such as WiFi instead of Ethernet) would mean that the user always obtain same IPv6 address. Unfortunately, there are several issues connected with the DUID identifier.

• DUID is controlled by software, thus it is not as stable as it should. E.g., if the client has dual boot, every OS will have different DUID.
• DUID is changed, after OS is reinstalled.
• If the administrator clones an OS image and copy it to another computer, two computers will have the same DUID.
• It is impossible to tie DUID with the host identification that is used in DHCP(v4) – host’s MAC address which complicates assigning address especially in a dualstack environment. Solution is either to extend existing systems for address management to support DUIDs or to use workarounds like MAC address option specified in RFC 6221. Unfortunately, vendors have not included the support for the RFC 6221 yet.

Moreover, statefull autoconfiguration using DHCPv6 is very difficult to be used today because of lack of support on many platforms including Windows XP, which is still very widespread OS. Most of mobile devices has not implemented support for DHCPv6 yet and some OSs (e.g. MAC OSX) must be updated to the latest version, which is a problem if the devices are not managed by an ISP.

The operational experience shows that according to these issues, the DHCPv6 protocol and its implementations are still not mature enough to be used in a production network and moreover, it is not feasible to use it for address assignment in networks where the hosts’ identification is required.

Another choice for address assignment available in IPv6 is to use the stateless utoconfiguration (SLAAC). Unfortunately, the stateless autoconfiguration in some OSs turns on privacy extensions. This means that devices generate a random end user identifier (EUI) – temporary IPv6 Address. This is a brand new IPv6 feature that allows a node to automatically generate a random IPv6 address on its own without the control of a network administrator.

However, this contradicts the need to identify a malevolent user. Private, temporary addresses hinder the unique identification of users/hosts connecting to a service. This prevents logging and tracking users based on IPv6 address. However, the knowledge of relation between an address and a device (or user) that has been used is necessary for solving security incidents and is required by law in several countries.
The Table 1 summarizes the autoconfiguration techniques in IPv6 protocol.

If a security policy requires better control, either fixed IPv6 addresses must be centrally assigned and logged, which is not a feasible option for a large network, or statefull configuration using DHCPv6 has to be deployed. Before the deployment of IPv6 in a local network, a network administrator must decide whether:

• Addresses will be assigned by DHCPv6 – the advantage is better control over hosts with, but many devices will not be able to use IPv6.
• Hosts will create own address based on SLAAC – all hosts will be able to use IPv6, but an administrator either gives up to have control over user identification in the network or a new mechanism must be deployed to identify the users [21]. Example of our implementation is described later on.

The Table 2 summarizes the IPv6 autoconfiguration support among the OSs.

First hop security in IPv4

IP address autoconfiguration process might be perceived as a honey pot for a hacker. If the hacker is able to interfere the configuration process, the whole user’s traffic can be rerouted to the attacker’s PC. In many cases it does not need to be a targeted attack, but simply an accident, where a user connects a Wi-Fi router with a preconfigured DHCP server to the network and causes a network malfunction for other users. This problem, as the other problems with first hop security, is known in IPv4 world for quite long time. For this reason some mechanisms were created in the IPv4 world which would prevent or at least complicate some of these attacks. The best place to implement protection for end users is on the end-user switch access port that the user is connected to. Different vendors use slightly different terminology for individual types of protection but generally we can meet the following ones:

DHCP Snooping: Some ports are explicitly defined in the switch configuration so port is able to receive DHCP responses from DHCP (so called trusted port). It is assumed that somewhere behind the trusted port is a DHCP server. If a reply from a DHCP server arrives to a port not defined as trusted, the response is discarded. Any DHCP server running on the client system (whether intentionally or by accident) does not threaten other clients on the network because the answers will not reach further than the access port for which this protection has been activated. DHCP snooping is usually prerequisite for other protection mechanisms such as IP lockdown or ARP protection as described below.

Dynamic ARP protection, ARP inspection: DHCP snooping database contains MAC address – IP address – switch port combination. This database is then used on untrusted ports to inspect ARP packets. Other MAC addresses not recorded in the database are discarded. This eliminates attacks focused on creating fake records in the ARP table (poisoned ARP cache). Another often-appreciated feature of this mechanism is the fact that the client cannot communicate over the network unless an IP address from the DHCP server is obtained. That forces
user to use DHCP instead of configuring static address.

Dynamic IP Lockdown, IP source guard: Another degree of protection is achieved by inspecting source MAC and IPv4 address on untrusted ports for all packets entering the port. This eliminates spoofing a source IPv4 or MAC address.

The Table 3 describes different attacks and techniques available for mitigating the attacks in IPv4 network.

3. First hop security in IPv6

The above described solutions for mitigating attacks in IPv4 networks are implemented in various access switches on the market. As we wrote previously, the autoconfiguration techniques are different in IPv6 so new solutions are necessary. Security mitigation techniques in IPv6 networks are described below.

Source Address Validation Improvements (SAVI): The set of techniques that complement ingress filtering with finer-grained, standardized IP source address validation [11]. Framework has option for DHCP servers and tries to solve a mechanism similar to the one we described with DHCP snooping for IPv4. It is limited to DHCPv4 and DHCPv6 and does not deal with the problems of rogue Router Advertisement messages. SAVI is mainly supported in devices produced by Hewlett Packard – A series. Very similar technique called ND
inspection is implemented in Cisco devices.

Secure Network Discovery (SEND): This method tries to deal with autoconfiguration problem in a totally different way. SEND is based on signing packets with cryptographic methods [15]. Apart from a router it does not require support on the access switches. The validity verification itself through message certificate takes place at the end-user system. IPv6 address of the end-user system is a result of a cryptographic function (see, we have another auto configuration method). Using SEND directly excludes using static, EUI 64 and Privacy Extensions Address. However SEND provides great advantage – it not only solves the autoconfiguration problem but also other safety problems of the Network Discovery protocol (RFC 2461). Another advantage is independent infrastructure; hence it can also be used in the same way in the either wired or Wi-Fi networks.

The main shortcoming of SEND is the requirement for public key infrastructure according to X.509. To make the SEND works properly, a certificate of the certification authority have to be installed on each client that wants to use SEND. The certificate has to be issued for each router as well. So it grows the costs of the management of the network – certificates have to be reissued or replaced before they expire.

SEND is a patented Cisco technology (US patent number 20080307), therefore no one would be surprised that it is implemented especially on some devices of this company. Presence of the patent raised several discussions especially with SEND and RA Guard integration. According to Cisco statement, Cisco will however not assert any patents against any party that implements the standard [17].

Considering the SEND deployment, a network administrator will face the problem that the protocol is not supported on any operation system yet. There are only some basic Linux and Windows implementations; however thay cannot be used in a production environment. Windows OS, as the most widespread system, nor Mac OS do not support the SEND protocol even in the most recent versions. SEND protocol could potentially solve security problems of NDP protocol; however, it cannot be deployed and there are no indications that this should change in the near future.

Router Advertisement Guard (RA Guard): Another alternative, which unfortunately deals only with the issue of fake router advertisements, is IPv6 Router Advertisement Guard [9]. It is similar technique as DHCP snooping, but determined for Router Advertisement packets. It tries to block fake router advertisements on an access user port. Apart from tools that should ease the initial switch configuration (learning mode), it opens the
path to integration with SEND. In this mode the switch works as a so called node-in-the-middle, where the switch with activated RA Guard uses information from SEND to verify packet validity and for the connected end-user system it appears as normal Router Advertisement packet. As you could guess from the title RA Guard does not solve DHCP or DHCPv6 issues in any way. We can already find an implementation in some Cisco devices.

Access Lists on the switch (ACL/PACL): If a network device supports ACL or PACL (Port access list) it is possible to configure an ACL blocking the malevolent traffic. A network administrator can configure ACL that will block all ICMPv6 messages type 134 (RA messages) and also block traffic to the UDP target port 546 (dhcpv6-c1ient). The rules are subsequently applied to the inputs of ports to which the c1ients are connected. This can eliminate instances of rogue routers and DHCPv6 servers. A required condition to use this mechanism is IPv6 ACL support on the relevant switch. The problem of this solution is that very few access switches
supports creation of IPv6 access-lists today. Also price of that switches is usually two or three times higher comparing to the switches where IPv6 PACL and other IPv6 security features are not implemented.

The solution with RA-Guard and ACL/PACL has however big disadvantage. It works very well for accidently announced RA messages but can be easily avoided using combination of fragmented packets and extension header in the RA message [18]. Existing protection for the targeted IPv6 attack does not exist today. There are some proposed solutions how to solve the problem [19],[20], but all of them are only drafts and it will take a long time before support will be added to operating systems and network devices.

The most undesired option is blocking or disabling whole IPv6 traffic. It is obvious that this step protect a host against all attack related to IPv6, however it is against the idea of deploying IPv6. That solution can be used only as a short-term solution when the other possibilities are not available. IPv6 protocol can be suppressed on the client by disabling o uninstalling IPv6 protocol or blocking the whole IPv6 traffic on the access port by filtering out all Ethernet packets identified with Ether Type 0x86DD (Ether type for IPv6 protocol).

The Table 4 summarizes first hop security threads and protection in IPv6 network.

4. First hop security in IPv6 – current situation

Thinking about IPv6 deployment and security, network administrators will face the fact, that all of the above mentioned techniques can be used rather theoretically today. Either they are not implemented on client’s side or device support is missing. Another issue is that if the protective devices are to be truly purposeful they must be placed as close to the end-user system as possible. This could often mean a complete replacement of network infrastructure that is a job that few will want afford just to implement IPv6.

To summarize our experience, after two years of operating the IPv6 network in production environment and several more years of testing the IPv6 protocol, we did not observe a targeted attack to our IPv6 network. The main problems, we have to solve are above described problems with autoconfiguration, bogus router advertisements together with missing monitoring tools for IPv6 network.

Many rogue advertises are generated by Windows computers. This is a serious issue because computers propagate their own interface as a default gateway. Unfortunately this behaviour can be in some conditions caused by properly used Internet connection sharing service. The Figure 1 shows the number of rogue advertises on the network with approximately 2000 of connected hosts.

As we mentioned earlier, because of missing implementation of mitigation techniques on switches, more affordable solution that would at least alleviate efforts to paralyze the IPv6 autoconfiguration mechanism is detection of fake Router Advertisements. This will not protect the network from a well-crafted and targeted attack but it can at least detect incorrectly configured c1ients. For many networks it would be the only usable solutions for a long time. All tools for detection of rogue Router Advertisements work based on the same principle. They connect to the FF02::1 multicast group where the router advertises messages are sent and thus are
able to monitor all RA messages appearing on the network. The monitoring tool can then inform the
administrator about the undesirable status, call an automated action (Ndpmon [22], Ramond [23]), or even send a message cancelling the validity of fake Router Advertisements (rafixd [24]).

5. User tracking, monitoring and accounting

Long-term network monitoring, accounting and backtracking of security incidents is often achieved in IPv4 networks using NetFlow probes and collectors. This can be a problem if IPv6 is deployed and privacy extensions are allowed in the network. The same user can than communicate with different addresses. That means that address cannot be used as a unique identifier anymore. As the part of deploying IPv6 we tried to develop extension to existing monitoring systems to allow easier tracking users in an IPv6 network.

The main idea of the extension is collecting and putting together data obtained from differed parts of the network. A neighbour cache database on routers and forwarding databases on switches can provide information about relation between an IPv6 address port on a switch and a MAC address used by a user. In the next step the MAC address can be used for identifying a user in a database provided by radius server.

These pieces of information, together, provide a complex view of the network and can help to identify a host. A tuple (lPv6 address, MAC address, Login name) is sufficient to identify a host/user. In practice, an extended tuple is built: (Timestamp, IPv6 address, MAC address, Switch port, Login) as depicted in the following Figure 2.

Timestamp is added to provide a history of communication. Switch port is necessary if the user is blocked or if an unregistered MAC address is used on a port. In addition to these values, the VLAN number and interface statistics are stored; however, these data are not necessary for host identification.

It is important to note that this data structure is not created at once, but it is filled in when data are available. For instance, NetFlow data are taken from the NetFlow probe when they are sent to the collector. However, there is no information about MAC addresses yet. The address is downloaded later from the switch’s ND cache. Login data from RADIUS can also be added. However, RADIUS data are not available for every user – only for those who are connected using 802.1x authentication. For other users, only the IPv6 address and the switch port number and MAC address are used for identification.

Data are collected using the SNMP protocol and stored in the central database where the network administrator can search data using the IPv6, IPv4 or MAC addresses as keys. Useful tool for polling and storing information from switches and routers is Network Administration Visualized (NAV) [12]. SNMP polls the data from switches every fifteen minutes. The mapping between the IPv6 address and its corresponding MAC address is downloaded from the router’s neighbour cache. Port, VLAN number and other information comes from the switch’s FDB (Forwarding Database) table. Traffic statistics are obtained from NetFlow. NetFflow records alone
are not sufficient for user surveillance and activity tracking because of the temporary IPv6 addresses as described in previous sections.

The time dependency of gathering different data is crucial when accessing the ND Cache. This temporary memory at the router stores information needed to build the link between the IPv6 address and the MAC address. Because IPv6 addresses change in time and have limited validity, if the ND entry is lost, there is no way to link the IPv6 address and the user/host. To ensure that all information is stored properly in the monitoring system, the SNMP polling interval has to be shorter than the expiration timeout of the ND Cache. Otherwise, some entries in the ND Cache could expire without being downloaded into the central system. Typical timeouts for collecting
SNMP and RADIUS data are fifteen minutes. The ND Cache expiration timeout is usually set to more than one hour.

6. Conclusion

This paper presents security and addressing issues in IPv4 and IPv6 protocol environment and solutions how to solve them. Nowadays, the IPv6 traffic volume is low, but this is caused by the lack of IPv6 sources (web pages, servers) on the Internet. Also widespread operation systems such as Windows XP support IPv6 but IPv6 is not enabled by default.

Next generation Windows systems together with Linux, Mac OS and Unix systems have however IPv6 protocol enabled by default and penetration of these systems is growing every day. Security and addressing issues discussed in this paper present the overview of problems we encountered when we deployed IPv6 protocol in BUT campus network. Addressing issues and problems with user tracking in IPv6 protocol introduce the necessity for a new monitoring system that is able to overcome the specific problems in IPv6 address assignment. Solutions, how to solve these issues, are proposed. We discussed possibilities, how we are able to limit the impact of security problems in IPv6 network together with monitoring and tracking system that is able to identify and track a host in IPv4 and IPv6 network.

References

[1] J. Curran: An Internet Transition Plan, [online], url: http://tools.ietf.org/html/rfc5211

[2] Commission of the European Communities: Action Plan for the deployment of Internet Protocol version
6 (IPv6) in Europe, [online], url: http://ec.europa.eu/information_society/policy/ipv6/action_plan/

[3] Transition Planning for Internet Protocol Version 6 (IPv6), [online],
url: http://georgewbush-whitehouse.archives.gov/omb/memoranda/fy2005/m05-22.pdf

[4] IPv6 CIDR REPORT, [online],
url: http://www.cidr-report.org/v6/as2.0/, http://bgp.potaroo.net/index-bgp.html

[5] Lorenzo Colitti, Steinar H. Gunderson, Erik Kline, Tiziana Refice, Evaluating IPv6 Adoption in the
Internet, [online], url: http://www.google.com/intl/en/ipv6/statistics/

[6] Geoff Huston: Flailing IPv6, [online], url: http://www.potaroo.net/ispcol/2010-12/6to4fail.html

[7] S.Thomson, T.Narten, and T.Jinmei. IPv6 Stateless Address Autoconfiguration. RFC 4862, September
2007, [online], url: http://tools.ietf.org/html/rfc4862

[8] J. Curran: An Internet Transition Pian, RFC 5211, July 2008, url: http://tools.ietf.org/html/rfc5211

[9] E. Levy-Abegnoli, G. Van de Velde, C. Popoviciu, J. Mohacsi: IPv6 Router Advertisement Guard, RFC
6105, February 2011, [online], url: http://tools.ietf.org/html/rfc6105

[10] S. Frankel, R. Graveman, and J. Pearce. Guidelines for the Secure Deployment of IPv6. Technical
Report 800-119, National Institute of Standards and Technology, 2010, [online],
url: http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf

[11] J. Bi, J. Wu, G. Yao, F. Baker: SAVI Solution for DHCP (work in progress) July 2011, [online], url: http://tools.ietf.org/html/draft-ietf-savidhcp-10

[12] UNINETT and Norwegian University of Science and Technology: NAV, [online], 2011-03-15,
[online], url: http://metanav.uninett.no/

[13] J. Bi, G. Yao, J. Wu, F. Baker.: Savi solution for Stateless Address – work in progress, April 2010,
[online], url: http://tools.ietf.org/html/draft-bi-savi-stateless-00

[14] E. Levy-Abegnoli, G. Van de Velde, C. Popoviciu, J. Mohacsi.: IPv6 Router Advertisement Guard.
RFC 6105, February 2011. [online], url: http://tools.ietf.org/html/rfc6105

[15] J. Arkko, Ed., J. Kempf, B. Zill, P. Nikander: SEcure Neighbor Discovery (SEND). RFC 3971,
Febuary 2011, [online], url: http://tools.ietf.org/html/rfc3971

[16] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogl: Source Address Validation Improvement
Framework”, draft-ietf-saviframework-04 (work in progress), March 2011.

[17] R. Albright, Cisco System’s Statement of IPR related to draft-ietf-v60ps-ra-guard-02, April 2009,
[online], url: http://www.ietf.org/ietfftpIlPR/cisco-ipr-draft-ietf-v60ps-ra-guard-02.txt

[18] F. Gont, IPv6 Router Advertisement Guard (RA-Guard) Evasion, December 2011, [online], url: http://tools.ietf.org/html/draft-gont-v6ops-ra-guard-evasion-01

[19] F. Gont, Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard), Febuary 2012,
[online], url: http://tools.ietf.org/html/draft-gont-v6ops-ra-guard-implementation-01

[20] F. Gont, Security Implications of the Use of IPv6 Extension Headers with IPv6, January 2012,
[online], url: http://tools.ietf.org/html/draft-gont-6man-nd-extension-headers-02

[21] Grégr, M., Podermański, T., Šoltés, M., Žádník, M.: Design of Data Retention System in IPv6 network,
December 2011, [online],http://www.fit.vutbr.cz/~igregr/pubs.php?id=9840

[22] Frederic Beck, Ndpmon, August 2009, [online], url: http://ndpmon.sourceforge.net/

[23] Ramond, [online], url: http://ramond.sourceforge.net/

[24] Rafixd, [online], url: https://github.com/strattg/rafixd

[25] Tony Cheneau, Ndprotector, March 2012, [online], http://amnesiak.org/NDprotector/

[26] Meinel Ch.: Winsend, March 2012, [online],
url: http://www.hpi.uni-potsdam.de/meinel/forschung/security_engineering/ipv6_security/winsend.html

It is now a few months since IANA has run out of IPv4 addresses. Large ISPs have usually reserved some address pool for the future, but requesting new IPv4 addresses from LIRs will be much more difficult and probably impossible. Unfortunately there are more and more devices, which require an Internet connection – smart phones, PDAs, netbooks etc. One solution for the ISP to meet their requirements is to use NAT. This works well for basic connectivity, but causes difficulties to many applications. There are also scenarios where large ISPs will trade with their unallocated IPv4 addresses. However both of them can be considered as only short term solutions.

Figure 1 – Topology of Campus BUT network

The only perspective solution is deploying IPv6. IPv6 is not compatible with IPv4 so the networks will have to run both protocols, until all services are available on IPv6. Deploying IPv6 brings many new issues. Techniques for IPv6 address assignment implemented differently in various operating systems (OS) can be one of the examples. Missing implementations of security tools (RA Guard, SEND etc.) is also a serious issue. The new feature – privacy extensions [1], makes user’s identification more difficult. This behavior is desired to ensure user privacy, however it is in contradiction with a unique user identification in a local network which is necessary for a network administrator. New ways to deal with this feature needs to be developed. Transition techniques raise security problems [7]. Improperly configured operation systems sending rogue Router Advertisement can cause network malfunctioning [2]. These are other examples of problems that network administrators are facing. New ways to manage IPv6 network needs to be found.

This article assembles experience with deploying IPv6 at the campus network at Brno University of Technology (BUT) that is one of biggest universities in the Czech Republic. The network was built up as the result of cooperation amongst other universities placed in Brno and Czech Academy. The campus network connects together several institutions (University faculties, research Institutions, Czech Academy, high schools) placed on over 20 locations in different parts of Brno. Each location is connected at least with two optical cables from two independent directions to achieve maximum reliability of the network. The total length of the optical cables is over 100km.

The core of the network is based on 10 Gb/s Ethernet technology using HP ProCurve and Extreme Networks devices. OSPF and OSPFv3 routing protocols are used as the interior routing protocol. External connection to the National Research and Education
Network (NREN) that is run by CESNET is provided over two 10Gb/s lines with BGP and BGP+ routing. The topology of the core of the network is shown in the Figure 1.

The IPv6 campus connectivity is implemented according to the Internet Transition Plan [4]. Most of the parts of the university already provide native IPv6 connectivity and significant part of devices connected to the campus network can fully use IPv6.
From the user perspective the BUT university campus network connects more than 2,500 staff users and more than 23,000 students. The top utilization is at student dormitories where more than 6,000 students are connected via 100 Mb/s and 1Gb/s links. It is a really big challenge to provide functional and stable IPv6 connectivity to that amount of users.

2 Current status of IPv6 deployment at Brno University of Technology

IPv6 related activities started at university several years ago. In that time a temporary IPv6 network was created especially for testing purposes. Routing was performed on the PC based routers with routing software XORP and outside connectivity to NREN was encapsulated inside tunnels. The IPv6 infrastructure was completely separated in order to minimize impact of IPv6 infrastructure to running IPv4 services. That means the IPv6 network was run on dedicated routers and cable/fiber infrastructure. There were not any critical services running on IPv6 in that phase.

The significant change became in 2010 when university started participating on HP ProCurve beta testing program. That was mainly focused on IPv6 features in the HP ProCurve devices that are widely used on the BUT network. Thanks to pretty good results from beta testing program the decision to move the core of the network to dualstack was made in the middle of 2010. IPv6 was enabled on all devices in the core network. At the end of 2010 the topology and the IPv6 network started completely following the topology of the IPv4 network. In the same time university decided to get own provider independent (PI) IPv6 address space to be able to use multihomed IPv6 connections. Today, the IPv6 and IPv4 network provide almost same services on wire speed.

During the process of moving to IPv6 we have encountered with several problematic issues. Some of them are very essential and nowadays there are still not proper solutions for them. In the following lines we will try to point out some of them.

3 IPv6 problems to solve and possible solutions.

3.1 Addressing issues

One of the basic problems is address assignment for the client systems. The mixture of various OSs requires a solution of automatic address assignment that is supported by most systems. The stateful autoconfiguration using DHCPv6 is very difficult to use today because the lack of support in Windows XP, which is still very widespread OS, and older version of MAC OS. DHCPv6 does not support all configuration options (e.g. option for default route), so the stateless autoconfiguration (SLAAC) [3] has to be used as well. Unfortunately, the stateless autoconfiguration in some operating systems turns on privacy extensions which mean that the devices use a random end user identifier (EUI) named Temporary IPv6 Addresses. This is a brand new IPv6 feature that allows a node to automatically generate a random IPv6 address on its own.

However, this requirement contradicts the need to identify a malevolent user. Private, temporary addresses hinder the unique identification of users/hosts connecting to a service. This affects logging and prevents administrators from effectively tracking which users are accessing IPv6 services. Many internal resources require the ability to track the end user’s use of services.

If a local security policy requires better control, either fixed IPv6 addresses must be centrally assigned and logged, which is not a feasible option for a large network, or stateful configuration using DHCPv6 has to be deployed. However, in that case, same operating systems (Windows XP, older versions of MAC OS, some Linux and BSD systems) will not have access to IPv6 network.

IPv6 auto configuration options also increase complexity. There are two fundamentally different mechanisms and protocols where one cannot fully work without the other. Configuration of Recursive DNS servers is nowadays not possible using SLAAC and with DHCPv6 it is not possible to configure the default gateway address (default route). As a result, the only working method is to use both protocols simultaneously. Failure of either mechanism whether through faulty configuration, bugged software or targeted attack, leads to denial of IPv6 connection to the user. Moreover diagnostics are fairly complicated and it requires good knowledge of both mechanisms.

3.2 First hop security

IP address autoconfiguration process might be perceived as a honey pot for a hacker. If the hacker is able to interfere the configuration process, the whole user’s traffic can be rerouted to the attacker PC. In many cases it does not need to be a targeted attack, but simply an accident, where a user connects a Wi-Fi router with a preconfigured DHCP server to the network and cause a network malfunction for other users.

This problem, as the other problems with first hop security, is known in IPv4 world for quite long time. For this reason some mechanisms were created in the IPv4 world which would prevent or at least complicate some of these attacks. The best place to implement protection for end users is on the end-user switch access port to which the user is connected. Different vendors use slightly different terminology for individual types of protection but generally we can meet the following ones:

• DHCP Snooping: Some ports are explicitly defined in the switch configuration so port is able to receive DHCP responses from DHCP (so called trusted port). It is assumed that somewhere behind the trusted port is a DHCP server. If a reply from a DHCP server arrives to a port not defined as trusted the response is discarded. Any DHCP server running on the client system (whether intentionally or by accident) does not threaten other clients on the network because the answers will not reach further than the access port for which this protection has been activated. DHCP snooping is usually prerequisite for other protection mechanisms such as IP lockdown or ARP protection as described below.
• Dynamic ARP protection, ARP inspection: DHCP snooping database contains MAC address – IP address – switch port combination. This database is then used on untrusted ports to inspect ARP packets. Other MAC addresses not recorded in the database are discarded. This eliminates attacks focused on creating fake records in the ARP table (poisoned ARP cache).
• Dynamic IP Lockdown, IP source guard: Another degree of protection is achieved by inspecting source MAC and IPv4 address on untrusted ports for all packets entering the port. This eliminates spoofing a source IPv4 or MAC address. Another often appreciated feature of this mechanism is the fact that the client cannot communicate over the network unless an IP address from the DHCP server is obtained.J

The IPv6 autoconfiguration and neighbor discovery can be vulnerable to similar attacks as autoconfiguration in IPv4 networks [7]. Nowadays, network administrators of IPv6 networks are facing mainly to problem with rogue router advertisements, which is similar to the problem of fake DHCP server in IPv4 networks. Many rogue advertises are generated by Windows computers. This is a serious issue because computers propagate their own interface as a default gateway. Unfortunately this behavior can be in some conditions caused by properly used Internet connection sharing service. The Figure 2 shows the number of rogue advertises on the network with approximately 2000 active devices connected to.

Figure 2 – Number of Rogue’s routers

Described solutions for mitigating attacks in IPv4 networks are implemented in most of access switches on the market. IPv6 techniques for autoconfiguration are different so new solutions are necessary. Security mitigation techniques in IPv6 networks are described below.

• Source Address Validation Improvements (SAVI): The Source Address Validation Improvement method was developed to complement ingress filtering with finer-grained, standardized IP source address validation [13]. Framework has option for DHCP servers [8] and tries to solve a mechanism similar to the one we described with DHCP snooping for IPv4. It is limited to DHCPv4 and DHCPv6 and does not deal with the problems of rogue Router Advertisement messages. SAVI is
  mainly supported in devices produced by Hewlett Packard – A series.
• SEND – Secure Network Discovery: This method tries to deal with autoconfiguration problem in a totally different way. SEND is based on signing packets with cryptographic methods [12]. Apart from a router it does not require support on the active network devices level. The validity verification itself through message certificate takes place at the end-user system. IPv6 address of the end-user system is a result of a cryptographic function (see, we have another auto configuration method). Using SEND directly excludes using EUI 64 addresses and Privacy Extensions. SEND has one big advantage – it not only solves the auto configuration problem but also other safety problems of the Network Discovery protocol (RFC 2461). Another advantage is independent infrastructure; hence it can also be used in Wi-Fi networks for instance.

The main shortcoming of SEND is the fact that it requires the support of public key infrastructure according to X 509. To make it work properly you need to install a certificate of the authority which issues router certificates. There are other than security risks associated with SEND. SEND is a patented Cisco technology (US patent number 20080307), therefore no-one would be surprised that it is implemented especially on devices of this company. Presence of patent raised several discussion especially with SEND and RA Guard integration. According to Cisco statement, Cisco will not assert any patents against any party that implements the standard [14].

SEND protocol is not supported on any operation systems. There are some basic Linux implementation and kernel patches, however that cannot be used in production environment. Windows OS, as the most widespread OS, nor Mac OS do not support the SEND protocol even in the most recent versions. SEND protocol could potentially solve security problems of NDP protocol, however it cannot be deployed and there are no indications, that this should change in the future.

• RA Guard: Another alternative which however deals only with the issue of fake router advertisements is IPv6 Router Advertisement Guard [5]. It is similar technique as DHCP snooping, but for Router Advertisement packets. It tries to block fake router advertisements on the access user port. Apart from tools which should ease the initial switch configuration (learning mode), it opens the path to integration with SEND. In this mode the switch works as so called node-in-the-middle, where switch with activated RA Guard uses information from SEND to verify packet validity and for the connected end-user system it appears as normal Router Advertisement packet. As you could guess from the title RA Guard does not solve DHCP or DHCPv6 issues in any way. We can already find an implementation in some Cisco devices.

All of the above possibilities can be used rather theoretically today. Either they are not implemented on clients or the device support is missing. Another issue is that if the protective devices are to be truly purposeful they must be placed as close to the end-user system as possible. This could often mean a complete replacement of network infrastructure which is a job that few will want to undergo just to implement IPv6. More affordable solutions which would at least alleviate efforts to paralyze the IPv6 auto configuration mechanism are following.

• Access Lists on the switch: This solutions was published by Petr Lampa within the CESNET working group. It assumes that we can configure IPv6 access lists on the active device.

The aforementioned access list will block all ICMPv6 messages type 134 (RA messages line no. 2) and it will block traffic to the 546 target port (dhcpv6-client, line no. 3). The rules are subsequently applied to the inputs of ports to which the clients are connected (line no. 7). This can eliminate instances of rogue routers and DHCPv6 servers. The aforementioned example can be used for some HP switches and can be an inspiration for other platforms as well. A required condition to use this mechanism is IPv6 ACL support on the relevant switch. The problem of that solution is that very few access switches supports creation if IPv6 access-lists today. Also price of that switches is usually two or three times higher comparing to the switches where those IPv6 are not implemented.

Passive monitoring

Another option is detection of fake Router Advertisements. This will not protect us much from a well-crafted and targeted attack but it can at least detect incorrectly configured clients. We will need to use this solution if none of the options above can be used. For many networks it would be the only usable solutions for a long time. All tools for detection of rogue Router Advertisements work based on the same principle. They connect to the ff02::1 multicast group where the aforementioned messages spread and thus will be able to monitor all messages appearing on the network. They can then tell the administrator about the undesirable status, call an automated action (Ndpmon, Ramond), or even send a message canceling the validity of fake Router Advertisements (rafixd) back to the network.

3.3 User tracking, monitoring and accounting

Long-term network monitoring, accounting and backtracking of security incidents is often achieved in IPv4 networks using NetFlow probes and collectors. This can be a problem if IPv6 is deployed and privacy extensions are allowed in the network. Same user can than communicate with different addresses. That means that address cannot be used as a unique identifier anymore. As the part of deploying IPv6 we tried to develop extension to existing monitoring systems to allow easier tracking users in an IPv6 network.

The main idea of the extension is collecting and putting together data obtained from differed parts of the network. A neighbor cache database [6] on routers and forwarding databases on switches can provide to us information about relation between IPv6 address port on switch and a MAC address used by user. In the next step a MAC address can be used for identifying user in the database provided by radius server.

All of these pieces of information, together, provide a complex view of the network and can help to identify a host. A tuple (IPv6 address, MAC address, Login name) is sufficient to identify a host/user. In practice, an extended tuple is built: (Timestamp, IPv6 address, MAC address, Switch port, Login) as described in the Figure 3.

Figure 3: Extended NetFlow record

Timestamp is added to provide a history of communication. Switch port is necessary if the user is blocked or if an unregistered MAC address is used on some port. In addition to these values, the VLAN number and interface statistics are stored; however, these data are not necessary for host identification.

It is important to note that this data structure is not created at once, but it is filled in when data are available. For instance, NetFlow data are taken from the NetFlow probe when they are sent to the collector. However, there is no information about MAC addresses yet. The address is downloaded later from the switch’s ND cache. Login data from RADIUS can also be added. However, RADIUS data are not available for every user – only for those who are connected using 802.1x authentication. For other users, only the IPv6 address and the switch port number and MAC address are used for identification.

Collecting Monitoring Data

Data are collected using the SNMP protocol and stored in the central database where the network administrator can search data using the IPv6, IPv4 or MAC addresses as keys. Useful tool for pooling and storing information from switches and routers is Network Administration Visualized (NAV) [9]. SNMP pools the data from switches every fifteen minutes. The mapping between the IPv6 address and its corresponding MAC address is downloaded from the router’s neighbor cache. Port, VLAN number and other information comes from the switch’s FDB (Forwarding Database) table. Traffic statistics are obtained from NetFlow. NetFflow records alone are not sufficient for user surveillance and activity tracking because of the temporary IPv6 addresses as described in previous sections.

Figure 4: The Central Monitoring System for IPv4 and IPv6 at BUT

Therefore, NetFlow records are extended by additional information called flow tags. The flow tag is added to a flow record after its creation, usually when the information is received and stored at the main database. The tag is a unique identifier of the user, because NetFlow records are generated for every single connection of the user, even with different IPv6 addresses. Flow tags can be used as keys to identify the activities of any user stored in the system. This is necessary because not all data are available immediately in the central monitoring system, for example, due to a delay caused by SNMP pooling. When flow tags are added, more complex statistics based on the flow data are created, for example, top-N users.

The time dependency of the gathering of different data is crucial when accessing the ND Cache. This temporary memory at the router stores information needed to build the link between the IPv6 address and the MAC address. Because IPv6 addresses change in time and have limited validity, if the ND entry is lost, there is no way to link the IPv6 address and the user/host. To ensure that all information is stored properly in the monitoring system, the SNMP polling interval has to be shorter than the expiration timeout of the ND Cache. Otherwise, some entries in the ND Cache could expire without being downloaded into the central system. Typical timeouts for collecting SNMP and RADIUS data are fifteen minutes. The ND Cache expiration timeout is usually set to more than one hour.

4 Conclusion

This paper presents security and addressing issues in IPv4 and IPv6 protocol and solutions how to solve them. Nowadays, the IPv6 traffic volume is low, but this is caused by the lack of IPv6 sources (web pages, servers) on the Internet. Also widespread operation systems such as Windows XP supports IPv6 but IPv6 is not enabled by default.

Next generation Windows systems together with Linux, Mac OS and Unix systems have however IPv6 protocol enabled by default and penetration of these systems is growing. Security and addressing issues discussed in this paper present overview problems we encountered when deploying IPv6 protocol on BUT campus network. Addressing issues and problems with user tracking in IPv6 protocol introduce the necessity for the new monitoring system which is able to overcome the specific problems in IPv6 address assignment. Solutions, how to solve these issues, are proposed. We discussed possibilities, how we are able to limit the impact of security problems in IPv6 network together with monitoring and tracking system which is able to identify and track a host in IPv4 and IPv6 network.

5 Bibliography

Monitoring of present-day networks can be divided into two basic groups. The first one is based on inspection of packet contents. The contents of the packet are compared to a fairly large database of known samples (regular expressions), and if a match is found a relevant action takes place, for example, communication from the computer that sent the packet is blocked. Most contemporary IDS (Intrusion Detection Systems) are based on this principle.

The second group concerns collection and analysis of statistics describing network behaviour. Statistics are gathered with various level of detail, depending on what information we are willing to omit. Basic information is obtained by monitoring the status of key network components. For instance, by monitoring values of SNMP counters at network interfaces. The collected data are very approximate because the counters aggregate information about all traffic. Another option is to use the RMON (Remote Monitoring) architecture. RMON agents are able to carry out several actions, such as collecting statistics about interfaces (network load, CRC errors etc.), creating history out of selected statistics, specifying alarms for statistics thresholds being exceeded and generating events (sending alerts). Some agents allow setting up statistics monitoring for several selected users.

This is insufficient from the perspective of present-day networks. Nowadays companies build their infrastructure (stock exchange and payment transactions, IP telephony, e-commerce) on reliable and secure networks, and hence advanced technologies must be used to get detailed statistics.

The NetFlow technology introduced by Cisco in the late 1990s is among the most popular technologies today. The popularity of NetFlow is due to its convenient level of abstraction. The whole traffic mix is divided into flows based on a quintuple of key data, and besides the quintuple (source and destination IP address, source and destination port, protocol number) other statistics are also monitored for each flow, such as the number of packets and bytes, the time of flow start and end, set TCP flags and more. The collected data can help you identify and locate network incidents, show network load, tune QoS settings etc. The NetFlow data can be further aggregated and thus various views of network traffic may be created and important information about applications and users may be obtained, and these can be used later for strategic planning of company development or to verify conformance to network usage policy.

Examples include observing limits for the amount of incoming/outgoing traffic from/to a local network, where the IP-address-based aggregation and sorting according to the number of bytes will display the statistics of the users that violate their limits most heavily.

2 NetFlow Architecture

NetFlow architecture is based on two types of components. The first type are components (let us call them agents) able to collect statistics (records about flows) and send them through the NetFlow protocol. The other type of component is a collector that receives statistics measurements and saves them for further analysis. Agents can be implemented in routers or autonomous probes placed at important network locations. For example, at the gateway of a local network to the Internet, at campus network nodes or data centres etc. A collector can be placed anywhere on the network and collect information from several exporters at the same time. The network administrator accesses the data through a web interface or a terminal.

Picture 1: Architecture to measure flows based on the NetFlow protocol

3 NetFlow Agent

The agent runs two important processes, a measuring one and an exporting one. The measuring process consists of several subtasks. The most basic subtask is receiving the packet, assigning a unique timestamp to it and extracting important items from the packet header. Then the relevant flow record must be found in the memory. Records are usually organised into a field of lists and the address of the relevant list is obtained by calculating the hash value out of the five key flow items (addresses, ports, protocol). The correct record is found sequentially in the list. If a specific record does not exist, it is the first packet of the flow and a new record is therefore created. The next packets of the given flow will contribute to the statistics of the same record. When the flow ends, the record must be released from the memory so that it does not needlessly occupy space for newly created records. This is not so simple. For TCP connections, the end of communication can be detected in packets by looking for the FIN and RESET flags, but if such a packet goes through a different route or gets lost, the record will be in the memory for quite a long time. Furthermore, such flags do not exist for other protocols (UDP, ICMP and others). Besides the flags mentioned above, heuristics is also used; heuristics detect the end of flow if no packet came to a given record for a long time. If the agent is saturated with new flows, the records are also released. The record can be handed to the exporting process after it was released. The exporting process will process the records and create NetFlow protocol packets out of them.

3.1 Agent Parameters and Configuration

We can tailor the measuring and exporting processes to the network and administrator needs. For instance, if the agent runs on a router the parameters must be set to let the router carry out its main function, i.e. routing.

Sampling is the first parameter that has an impact on the performance of the agent. Sampling determines the probability of the passing packet being the subject of monitoring. Decreasing the probability lowers the load of the measuring process, but unfortunately the quality of the exported statistics is also lowered. When the probability is too low (usually less than 1:10), some characteristics that can be deduced from unsampled data disappear (e.g., the original number of flows). Some NetFlow agents explicitly require sampling with a low probability; therefore it is advisable to learn about the agent capabilities before you start monitoring.

Inactive timeout is another parameter that influences performance; specifically it influences the size of the allocated memory. Inactive timeout is an interval that is used as a heuristic to release records from memory (if the record was not updated during this interval it is released). Too low inactive timeout causes a premature release of the record. In that case several records are created for a flow, which is similar to the broken spaghetti effect (lots of short flows). Increasing the timeout interval will improve the situation, but the allocated memory space will increase. Optimal timeout for present-day networks is 10 to 30 seconds.

So far we described how to release the record after the flow ends. But what if the flow lasts too long? Imagine a user with a slow Internet connection downloading the latest Linux distribution. To let the administrator learn about such events, you must introduce so-called active timeout, and if the flow takes more than that interval then it is released from memory and reported.

For the export process it is necessary to set the destination of the measured statistics, i.e. the collector’s IP address and port, or more collectors if the exporter supports that. For some exporters the sampling of outgoing NetFlow data can be configured to prevent the collector being overloaded.

The agent configuration is not provided by the NetFlow protocol, but rather by proprietary methods using a terminal or web interface. For example, with Cisco routers you can use the following commands to launch and configure NetFlow (2800, IOS 12.4):

Global NetFlow configuration at the router (definition of destination collector and export protocol version)

Router(config)#ip flow-export destination 192.168.0.100 60001
Router(config)#ip flow-export version 5

Configuration of monitored networks

Router(config-if)#ip flow egress

Checking flow memory and export

Router#show ip cache flow
Router#show ip flow export

4 Collector

Just like an agent, a collector runs several processes. The basic process is saving data received from NetFlow agents in a defined format to specified storage. Depending on the type of collector you can encounter other processes such as the presentation process displaying saved data (usually through a web interface) or a process analysing received data (development trends, calculations of long-term statistics, discovering network anomalies). Apart from these processes the administrator can access the stored NetFlow data at any time and collect information he is currently interested in.

The saving process may be implemented differently for different collectors. The two most important formats for saving NetFlow data are saving to standard databases (for example MySQL), where database server services are used and the subsequent analysis is run via SQL queries, or saving directly into binary files in a specific format depending on the collector.

The advantage of database collectors is easy query processing for saved data, because the database system does most of the work. Conversely, for binary collectors the queries are implemented in the application and the creator of the collector decides what query types to support. Poor performance while accepting NetFlow data, i.e. inserting them into the database, is a clear-cut disadvantage of database-based collectors.

Approximate volumes of saved NetFlow data are around 300 MB per hour for a loaded 100-Mb/s network and 600 MB per hour for a 1 Gb/s moderately utilized network, but it always depends on the specific composition and type of traffic. Most collectors therefore provide advanced tools for long-term administration of saved NetFlow data, such as automatically replacing the oldest data with new data if a predetermined level of data storage allocation is reached or decreasing granularity (level of detail) of older data while maintaining all the details for the newest flows. This also reflects the way NetFlow data are used, i.e., incidents are dealt with immediately or within a few days at most, while older are used for top-N statistics and trend monitoring.

The presentation and analysis processes always depend on a specific collector implementation. Usually there is a graphic interface accessible through a web interface, with optional display of graphs from received data on various time scales, filtering the defined traffic type only, displaying waveforms according to the amount of transferred data, number of flows or packets, summary statistics for a selected period, list of the largest data transfers and IP addresses with the highest load, trend estimates etc.

4.1 Collector Parameters and Configuration

Collectors can be differentiated according to the amount and intensity of the incoming NetFlow data or according to the subsequent usage of stored data.

Sampling of incoming NetFlow data is the first critical parameter. A surplus of performance capacity should be maintained, especially for heavily loaded collectors. For database collectors almost always a longer sampling interval must be set to prevent unexpected packet loss. This is of course also true for collectors which use their own method to save data to disk storage. But these are less sensitive to the amount of NetFlow data and they are usually able to process all data without sampling.

Time intervals according to which the data are saved are another parameter. We commonly meet one- or five minutes’ intervals, but other intervals can be defined as well.

Most collectors let you specify NetFlow data sources and ports where NetFlow data can be accepted. These countermeasures make it harder for an adversary to pollute your NetFlow storage with forged data, which is relatively easy because the UDP transport protocol is used.

5 NetFlow Protocol

The most widespread protocol today is NetFlow v5, which is the de-facto standard to transmit flow data. Thanks to its simple structure it is widely supported by both exporters and collectors. The NetFlow v5 record format contains only the source and destination IPv4 address, source and destination port, protocol number, start and end timestamp, the number of transferred packets and bytes, TCP flags, the ToS/DiffServ field and the number of network interfaces at which the flow was measured.

Nowadays this format appears to be restrictive, and a flexible record format defined by the NetFlow v9 protocol is being introduced. Introduction of templates is the most important difference between v5 and v9. Templates are used to define your own record structure and record items. The user will thus define which values she wants to export and how much space she wishes to assign to them. The collector will process these templates and interpret the incoming records based on them. Moreover, the exporter can send much more information about the agent itself (number of received packets, discarded packets, number of sent flows etc.) when using NetFlow v9. Unfortunately, neither NetFlow v5 nor NetFlow v9 supports secure data transfer from agent to collector, because they are assumed to be placed on the same private network. This is not always possible and then records are transmitted over the Internet. In such cases the protocol is susceptible to eavesdropping and submission of forged records. Moreover, the records can get lost because the UDP transport protocol is used; for NetFlow v9 SCTP (Stream Control Transmission Protocol) can also be used.

The NetFlow protocols were developed by Cisco and as such are a proprietary solution (NetFlow v9 is described in the informational RFC 3954). The IETF (Internet Engineering Task Force) therefore started to work on a more general, broader definition of a protocol to transfer flow records called IPFIX (Internet Protocol for Flow Information Export). This definition is based upon NetFlow v9, from which it adopts the use of templates but it defines possible record items more precisely and defines more measurable values. Unlike NetFlow, IPFIX requires PR-SCTP (RFC 3785) to transport data, which is a reliable protocol and it prevents congestion. The definition has been published in several RFC documents (RFC 3917, 5101, 5472, and others). IPFIX is expected to replace NetFlow and presently there are several prototype implementations of exporters and collectors which are able to work with the IPFIX protocol.

6 NetFlow Data Analysis

NetFlow data are received at the collector side where they are saved to disk and subsequently analysed. Either the analysis runs automatically or the user runs the analysis with queries. This creates various views on the network traffic and important data are obtained, for instance, daily traffic distribution, information about users and many more.

An example shows how to discover users who violate the limit for the amount of outgoing traffic from the local network to the Internet. The process is shown on the publicly available NfSen collector.

1. First we select a time interval of interest in the chart (picture 2).
   
   Picture 2: Traffic Amount vs Time Chart
2. We will select aggregation of NetFlow records according to source IP addresses and sorting according to number of bytes, and for brevity’s sake we will be interested in the first five only.
3. Listing (pic. 3) will display a table of the users who violate their limit most heavily.
4. If we want to learn whom those users communicated with, we can list all records containing the user’s source IP address and sort these records again according to the amount of transferred data.
   
   Picture 3: Top-10 users with the largest outgoing traffic

7 Usage

If you recall the NetFlow v5 record definition it is clear that it is possible to discover who talks to whom, for how long, and what application he uses. And many other kinds of information can be gathered with the advent of the NetFlow v9 and IPFIX protocols.

Measuring network traffic based on flows has many practical applications which contribute to network reliability and security. NetFlow implementations and use differ according to traffic and network characteristics. The most popular applications of NetFlow include the following areas.

• Observing limits and security policies. NetFlow data can be used to monitor how the users comply with network usage policy. For example, whether the limits for incoming and outgoing traffic per user are exceeded. Moreover, with the help of NetFlow data we can display a spectrum of network traffic, i.e., distribution of data between services, and we can focus on the most used services.
• Locating illegally installed servers on the network is an example of complying with security policies. Imagine a common user who brings her laptop to work and connects it to the company network. An FTP server is running on this laptop, and Internet users connect to this server and download data, which increases the amount of outgoing traffic and decreases the available capacity for legitimate traffic. Such a server can be exposed by pairing NetFlow data about incoming and outgoing flow and comparing which flow happened first. If the incoming flow initiated the communication then we just revealed a server.
• Another group of undesirable applications are P2P networks. Locating them on the network is advisable for several reasons: the data sent and parties communicating over these networks are not trustworthy, illegal data are shared (BitTorrent), applications are disturbing people (ICQ, Messenger, …). Analysis of NetFlow data makes it possible to reveal such applications by observing known ports, for instance, BitTorrent traditionally opens several connections on ports 6881-6889. However, most modern P2P applications are not permanently bound to specific ports, and if standard ports are blocked they scan ports and try to connect to the central server using an open port. Such applications can be detected by a specific IP address (address prefix) of the central server to which the application normally connects to log in to the network. Unfortunately, once such applications become blocked on the firewall, they start to mask their activity in various ways and their detection becomes hard. A blocked Skype can create a HTTP or HTTPS connection to a secret proxy and through such a proxy it can get to the central server.
• Detection of attacks and suspect activities is a very broad subject, and this report therefore covers only some examples for which it describes how they appear in NetFlow data and how to find them in NetFlow data. A search for an incident can be carried out directly on flows coming from the attacker or on data which are the reaction of attacked computers to the attack.
  • Most attacks are preceded by scans of IP addresses and ports. The attacker is in this way looking for ports on which applications listen so that she can exploit their vulnerability.There are two types of scans: vertical and horizontal. Vertical scan means scanning ports of a single computer. The list of open ports gives the attacker information about the type and version of the operating system and the possibility to exploit a known vulnerability. Conversely, with a horizontal scan the attacker selected a particular application (port) and she tries to discover which computers are using this application.

    Both types of scans are revealed by an increased number of flows (if the scan is intensive enough). The administrator can then focus on the relevant section and search via aggregation which target user accounts for the largest increase in flows, and then find out who the scanner is (vertical scan discovery). Aggregation by ports can discover an unusual increase in flows for a specific port and locate a scanning user (horizontal scan discovery). Scanning flows will contain only a small number of packets (usually one packet).

    When analysing the reaction of attacked computers we should focus on any unusual increase in TCP RESET packets which a computer generates in response to a TCP SYN packet on a blocked port (vertical scan). To detect a horizontal scan we monitor increased numbers of ICMP Host Unreachable. UDP traffic can be analysed in a similar manner.

  • Detection of Denial-of-Service (DoS) attacks. The attacker tries to deny legitimate users access by using server resources or even network resources.A well-known attack is TCP SYN-flood, where the attacker keeps opening new TCP connections, which depletes the victim’s resources. The victim may try to close the connection by sending a TCP packet with an RST flag set.

    This can be found in NetFlow data by looking for a large number of TCP flows containing a single packet, or in a roundabout way by monitoring an increased number of RST flags in the opposite direction of communication. Trying to identify the attacker is useless, because the source addresses are usually forged.

    DoS attacks are nowadays usually run from so-called botnets, networks of computers belonging to normal users that were attacked by the attacker and to which the attacker gained unauthorised access. Such computers generate legitimate requests for services (for instance, a web page request), but the number of requests saturates the server. Such attacks show up as a flash-crowd
    effect, where many users try to connect to the server, for instance, to download the newest music video. In both cases, the administrator should be informed.

  • Flow monitoring can expose the spread of worms. Worms, unlike viruses, spread using the file system or network. The infected computer opens new connections to other computers and the worm tries to exploit the application vulnerability to spread. In order to identify compromised computers, look for large numbers of unexpected open connections to other computers.
• Quality of Service (QoS) monitoring is another field where you can use flow monitoring. Unlike active QoS measurement where special packets are inserted into the network traffic this is a passive measurement. QoS parameters are thus measured on real traffic.This is advantageous on the one hand because measurement runs on user data and the network load does not increase, but on the other hand the experiments cannot be controlled precisely and the measured data might be biased. Usually, data from multiple agents must be compared for so-called oneway measurement, which requires an exact time synchronisation at all measurement points (using GPS for instance). Delay can thus be measured for all network flows on components and transport lines between agents. This can be used to monitor varying times to process specific traffic, for instance, processing of multicast packets on routers may take longer as their processing is more complicated than that of normal traffic.

  A flow is considered one-way in NetFlow; however, the two-way connection features can be measured as well, such as RTT (round-trip-time), but then the relevant flows must be paired – outgoing and incoming.

• Flow monitoring can be used for optimisation purposes. Imagine that a company has a SLA(Service Level Agreement) with its Internet Service Provider to guarantee bandwidth for VoIP traffic. Using NetFlow, it is possible to verify the assigned bandwidth and to plan a decrease or increase of bandwidth according to a maximum load.NetFlow statistics can also help balance routing between ISPs and plan peering strategies thanks to the knowledge of source, destination and intermediate nodes that data travel through.
• NetFlow records can be useful for accounting of transferred data or services. Since the statistics contain information about communicating parties, time and amount of transferred data, it is possible to charge individual users according to the communication interval, time of day and amount of data transferred.

8 Ethical Perspective of NetFlow

If we compare flow measurement to packet content analysis, we find that NetFlow describes network traffic from the perspective of its behaviour and not from the perspective of the data itself. Thus it is not possible to use NetFlow to block a specific flow that a worm uses to spread, which is generally possible when inspecting packet contents. In NetFlow data, it is possible to see that the attacked computer initiates too many outgoing connections, which is suspect and then we can focus on such a computer and possibly block its communication at the firewall.

Monitoring flows appears to be most acceptable by all parties concerned (ISPs and users) from the ethical point of view. A simple explanation of the difference between NetFlow and packet inspection can be given by making a comparison with the postal services. Looking at packet contents is de-facto opening the envelope and searching through its contents, while flow monitoring is reading and copying the information on the envelope about sender and addressee, which are publicly known anyway.

In this respect, monitoring based on flows will often meeting the requirements of national legislations about collection by network operators of operational and localisation data of electronic communications.

9 Available Solutions

Cisco routers were originally the only components capable of collecting and exporting NetFlow data. Thanks to the popularity of NetFlow, software agents were written for common PCs, and thus autonomous NetFlow probes were created. Real usage has shown that ordinary computers with no hardware support suffer from packet loss during peaks of network traffic or on lines with intense traffic. Hardware-accelerated probes therefore appeared; these consist of a special network card and a computer.

If a Cisco device is on the network, the first option for flow monitoring is to configure IOS to monitor and export NetFlow data. NetFlow can run on Cisco IOS routers series 800 to 7500, and also on Cisco Catalyst 6500 Switch and routers series 7600, 10000, 12000 a CRS-1 devices. The measured statistics are exported to one or more collectors in the NetFlow v5 or v9 format. The most interesting features of Cisco NetFlow include incoming traffic filtering (measurement runs only on a subset of the total traffic), support of monitoring MPLS (Multiprotocol Label Switching) packets and definition of additional items for security analysis. Features of individual agents can differ with different versions of IOS and types of device.

NetFlow data collection consumes the routers’ computing resources according to current network traffic and configured parameters of the monitoring process. Before starting experimentation it is advisable to visit a Cisco page (www.cisco.com/go/netflow, NetFlow Performance Analysis) where you can find details about allocated computational resources for individual devices and types of network traffic.

The amount of allocated resources can be one of the reasons to use autonomous NetFlow probes. The advantage of such a solution is the fact that the router carries out its primary function, i.e. routing, and is not burdened with another task. As a consequence, experimenting with a NetFlow probe has no impact on the network traffic. NetFlow probes will naturally be used on networks with no source of NetFlow data, e.g., not built upon Cisco technology.

The Czech company INVEA-TECH (www.invea-tech.com) offers an interesting solution in this area. Its portfolio includes probes (called FlowMon) capable of measuring networks from 10 Mb/s to 10 Gb/s. Probes create statistics fully compatible with NetFlow v5, v9 and IPFIX and send them to an embedded or external collector. Probes are connected to the network through a mirror port of the router/switch or by direct insertion of an optical or metallic fork (TAP). The FlowMon product series includes standard probe models for ordinary networks and hardware-accelerated models for critical and heavily loaded lines. Exporters of these probes can send data to several collectors and also filter them according to a scope of IP addresses at the same time. An ISP which provides connectivity to several companies can hand over relevant NetFlow data directly to the relevant companies, which can use them for applications as those mentioned above. If NetFlow data need to be presented to third parties they can be made anonymous (IP addresses or ports can be modified) and users can thus be protected from potential misuse.

NetFlow data generated with the FlowMon probe are sent to an integrated or external collector. Any third-party application or a FlowMon monitoring centre that is part of the package can be used as a collector.

Publicly available software NetFlow agents can be downloaded from the Internet and installed on an ordinary computer. It is advisable to carefully optimise such agents, so that no large packet losses occur. The first tunable parameter is cutting the size of the received packet (snap length). The reason is that only the packet header must be processed during monitoring. Normally, capturing the first 96 bytes is sufficient; this saves unnecessary memory allocation and speeds up the monitoring. It is also advisable to limit the maximum number of monitored flows. Such a countermeasure prevents the measuring process exhausting the computational resources of the probe in critical situations (DoS). Additional optimisation requires recompilation of the operating system kernel, so that classic reading of packets from the network card is replaced with constant probing of the network card to check if any packets are available. This removes a system bottleneck caused by an interrupt storm (in a classical system, one interrupt is generated per packet). After these optimisations, the probe can measure even Gigabit lines with normal traffic.

nProbe (http://www.ntop.org/nProbe.html) is one of the popular, commercially available agents. Its distinctive features are an export format of NetFlow v9 or IPFIX, and that it is offered for Unix and Windows systems. Compared to standard NetFlow/IPFIX items it also contains proprietary items which focus on VoIP monitoring (specifically on SIP and RTP protocols).

Publicly available software NetFlow agents include fprobe (http://fprobe.ourceforge.net/), which provides data in NetFlow v5 only (and also in v1 and v7, which are not described in this report).

Once the proper probe is selected we need to focus on a collector. To choose the right collector we need to make sure that both agent and collector can process data in the chosen format: NetFlow or IPFIX. It pays off to be especially careful with the IPFIX protocol. Even though both exporter and collector may support IPFIX, this protocol is still under development and interoperability might be an issue.

An example of a typical publicly available collector with an advanced graphical interface is the NfSen collector (http://nfsen.sourceforge.org). It is able to process NetFlow v5 and v9 protocols or the multipurpose tool ntop (http://www.ntop.org) with a special plug-in to collect NetFlow and IPFIX.

The benefit of commercial solutions is technical support and often sophisticated advanced functions such as automatic generation of detailed exports, detection of network anomalies and attacks. Popular collectors include Cisco NetFlow Analyzer (http://manageengine.adventnet.com/products/netflow/cisco-netflow.html) and Caligare Flow Inspector (http://www.caligare.com), or the FlowMon solution mentioned above.

The FlowMon monitoring centre is accessible through a secure web interface and it offers many options such as displaying network statistics as charts and tables with various time scales, generation of top-N statistics, filtering of data according to required criteria, creating user profiles, running security analyses, or setting the generation of automatic alerts to required events such as breaches of security policies. By using expansion modules these functions can be further extended to include SNMP monitoring or automatic anomaly detection.

10 Future Outlook

The development of applications based on flow monitoring keeps advancing. Search and discovery of network incidents (port scanning, attacks, exceeding limits or faulty network configurations) becomes automated. Some alerts can be generated by the NetFlow agent itself (record memory overflow can indicate a DoS attack), but thorough analysis of NetFlow data runs on a collector, most often on a fixed interval (5 minutes).

Automated searching in NetFlow data for suspect activities is usually based on exceeding limits for allowed deviation from normal traffic. This means that the search method first starts to learn after it is deployed, and later searches for unusual network traffic behaviour.

The second approach is searching known behaviour patterns for certain anomalies. This could be used when exposing network scans for instance. Such an activity will appear as a line segment in a four-dimensional space built upon source IP address, destination IP address, source port, and destination port (we draw a point in this space for each NetFlow record). By finding all such line segments we also find all scanning activities during a given interval.

The agents themselves are developing, and they are modified to deliver the best quality data about current network traffic. One example is embedding an application decoder into the agent monitoring process. Its task is to locate the application which generated the data transferred. This is simple for applications which use known ports. Unfortunately, if another application uses the same ports (popular port 80 for HTTP traffic) or unassigned ports, then it is misidentified or not identified at all. Blocked applications may exploit this and hide their traffic from the firewall or monitoring device behind traffic of another application. If we expand the NetFlow monitoring process to include searching in the package contents before the contents is thrown away, it is possible to more precisely identify the communicating applications (a pattern to detect an ssh connection looks like this: ^ssh- [12].[0-9]). If an application has no significant pattern or it encrypts its traffic, then pattern detection is rendered useless. As an alternative, feature analysis (statistical indexes) of such flows needs to be used. Data measured include maximum, minimum, variance and average packet length, and the same indexes are measured for intervals between packets of each flow. This can give you a behaviour fingerprint that you can use to estimate the type of application. For example, interactive voice communication would have the following fingerprint: regular intervals between packets up to 150 ms, low data volume, interval at least 10 seconds, and the same pattern in the other direction.

Statistics about intra-packet intervals are very valuable information not only to detect the application, but they can also be used to measure QoS by determinig uneven delay between packets (so-called jitter).

The future of devices that measure flows lies in extending the monitoring statistics and implementing pattern detection in the packet contents. This will add valuable information to data reported by agents, which will allow related methods such as locating suspect traffic or measuring line quality to perform better.

11 Conclusion

Detailed network monitoring is becoming more important nowadays because the amount of illegal activities increases every year. The attackers become professional and making money is their motivation. It is useful to recall that attackers keep adapting to new challenges, they change types of attacks and try to mask behind legitimate traffic.

From this perspective, flow monitoring appears to be a robust and promising method which makes automated search and differentiation of network incidents possible. Moreover, the trend is to expand the functionality of agents and collectors (such as Cisco MARS security system) to provide reliable sources of data about network traffic.