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

Monitoring network

We tested the operating systems on virtual machines in VMware Workstation 7.1., the network cards of the virtual machines were operating in Host-Only mode. You can see the topology on the following image: Additionally, Cisco 3725 router was connected to the topology:

Performed tests

Selection of a new address

1. The router is connected to the network and the tested interface is down on the tested OS
2. The tested interface is enabled and consequently, the OS generates a new address

Does the tested computer reply to DAD-NS (EUI-64, static, random, PE address)?

1. The router, the tested computer and a virtual PC with Ubuntu are present in the tested network.
2. The tested address (EUI-64, static, random, PE) is set on the Ubuntu computer, consequently Ubuntu issues DAD and the tested OS should reply with the NA.

Does the tested computer use duplicate EUI-64 address?

1. The router, the tested computer and a virtual PC with Ubuntu are present in the tested network. The tested interface is down.
2. The tested system is configured to generate EUI-64 if necessary.
3. Ubuntu is set up to use the same MAC address as the tested computer has.
4. The tested interface is enabled, the OS generates the same address as the Ubuntu computer already has. Ubuntu replies with NA.

Does the tested computer use duplicate global EUI-64 address?

1. Only the systems with EUI-64 addresses enabled by default were tested
2. The router, the tested computer and a virtual PC with Ubuntu are present in the tested network. The tested interface is down.
3. Ubuntu is set up to use the same IPv6 address as the tested computer would use as EUI-64 address.
4. The tested interface is enabled, the OS generates the same address as the Ubuntu computer already has. Ubuntu replies with NA.

Does the tested computer use duplicate random address?

1. Only the systems with random addresses enabled by default were tested (newer Windows).
2. The router, the tested computer and a virtual PC with Ubuntu are present in the tested network. The tested interface is down.
3. Ubuntu is set up to use the same IPv6 address as the tested computer would use as random address (the IID is generated once and then it stays constant).
4. The tested interface is enabled, the OS generates the same address as the Ubuntu computer already has. Ubuntu replies with NA.

Does the tested computer use duplicate PE address?

1. PE addresses are enabled on the tested OS.
2. The router, the tested computer and a virtual PC with Ubuntu are present in the tested network. The tested interface is down.
3. A script that replies with NA to all PE addresses is started on the computer with Ubuntu. The script does not reply to EUI-64 (link-local, global) a random addresses used by the tested Windows computers.
4. The tested interface is enabled, the OS generates PE address and the script replies with NA.

Captured PCAP files

During the test, we captured various PCAP files that can be downloaded used for your analysis. We have also analysed the PCAP files, see the following section and the publications below.

• POLČÁK Libor, HOLKOVIČ Martin a MATOUŠEK Petr. A New Approach for Detection of Host Identity in IPv6 Networks. In: Proceedings of the 4th International Conference on Data Communication Networking, 10th International Conference on e-Business and 4th International Conference on Optical Communication Systems. Reykjavík: SciTePress – Science and Technology Publications, 2013, pp. 57-63. ISBN 978-989-8565-72-3.
• POLČÁK Libor, HOLKOVIČ Martin and MATOUŠEK Petr. Host Identity Detection in IPv6 Networks. In: E-Business and Telecommunications. Berlin: Springer Verlag, 2014, pp. 74-89. ISBN 978-3-662-44787-1. ISSN 1865-0929. (This is an extended version of the previous paper.)
• POLČÁK, Libor. Lawful Interception: Identity Detection. Brno, 2017. PhD. Thesis. Brno University of Technology, Faculty of Information Technology. 2017-10-13. Supervisor Švéda Miroslav.

Test results

The tests result are presented in the following table

Notes to the tests

• 1.Random addresses:
  • They are only supported on Windows Vista and newer.
• 2. Privacy extension addresses:
  • PE was not configured
• 3. EUI-64 global addresses – reaction to duplicate address:
  • Tested OS keeps the address but it is marked as duplicate and it is not used by the OS (e.g. DAD, ping)
• 4. Privacy extension addresses – reaction to duplicate address:
  • Only one PE is tried, it is kept after DAD but it is marked as duplicate and it is not used by the OS (e.g. DAD, ping)
• 5. EUI-64 – reaction to DAD:
  • Marked systems ignore DAD from the same MAC address as is used by the system.
• 6. Solaris – static address:
  • Static address was not tested because it was not used by the system.

Introduction

Zabbix is a semi-distributed, open source monitoring solution with central management. This monitoring solution has been successfully used in the BUT campus area for several months. It has reached the state where optimization of it’s database was needed due to a high amount of new data being inserted to the tables. This article describes how we achieved the optimization of the Zabix’s PostgreSQL database with an installation manual and what results were accomplished.

2 Description of the BUT network

The BUT campus network that Zabbix monitors is a 10Gbit backbone network connected to the CESNET academic network. The networks consists mainly of network switches, uninterruptible power sources, network printers and some other elements. Since 2005 the team managing this network also manages the student’s dorm network called KolejNet which consists of more than 7000 end stations. To get a general idea about the size of the network we provide a table with specific information from the Zabbix monitoring client.

Table 1: Key performance indicators of the BUT Zabbix server

As you can see from the table 1, approximately 32 new values are added to the tables every second. With the current way of storing the data, this means that the biggest table in the database has more than 530 millions of rows and the total size of the whole database is nearly 120 GBs. This makes working with such a huge database very time and performance consuming.

3 State of the BUT Zabbix server before optimization

The current way of maintaining this huge database is quite simple. Perform a series of DELETE queries on the table rows and  delete those that match the criteria of being older than 365 days. There are two problems with this approach:

1. SQL query DELETE does not free up the space on hard drive after deleting the rows due to the Multiversion concurrency control in PostgreSQL
2. Using DELETE on so many rows increases the CPU utilization and slows down the system

As we can see on the picture 1, the size of the database on the hard drive is constantly increasing, even though we are performing DELETE queries on old rows.

 Picture 1: The size of the PostgreSQL database before optimization

Picture 2 shows how periodic deleting of rows using the DELETE query affects CPU utilization (increase of the CPU load marked with red arrows).

Picture 2: Increase of the CPU utilization when using DELETE queries on many rows

We’ve also taken a look at how the PostgreSQL planner plans queries before the optimization. The following query:

EXPLAIN ANALYZE SELECT *
FROM history
WHERE clock > 1394841600 AND clock < 1395014400

will be executed the following way:

QUERY PLAN
--------------------------------------------------------------
Seq Scan on history  (cost=0.00..926510.60 rows=2839499 width=21) (actual time=636.116..5824.925 rows=2858660 loops=1)
  Filter: ((clock > 1394841600) AND (clock < 1395014400))
  Rows Removed by Filter: 40412381
Total runtime: 5928.246 ms

We can see that the planner uses a sequential scan on the whole table which takes almost 6 seconds to return the results.

4 Optimization proposal

The main idea of optimization is to replace the function which deletes rows using the DELETE query with a function which firstly, changes the structure of the database and secondly, doesn’t use DELETE queries at all.

The proposed approach is to partition the huge parent tables into smaller child partitions as shown in the picture 3.

Picture 3: New structure of the database

We’ve compared two existing partitioning solutions for Zabbix:
[1] requires an empty database
[2] does not require an empty database

We decided to implement the second solution mainly because:

•  when a new value is being added, if the partition where the new value should be stored doesn’t exists, it will be created automatically
• it does not require an empty database
• the code is simpler than the first version
• it does not use any emergency or temporary tables like the first version
• it contains a function to delete old partitions

5 Implementation

We will implement this optimization using these five steps:

1. Creation of the partitioning function
2. Setting triggers for every table
3. Creation of the function which will be deleting partitions
4. Migrating of the old records to the new partitions

The implemented solution uses the procedural language pgSQL. To install these functions to your PostgreSQL server, just run them as you would any other SQL query.

Creation of the partitioning function

CREATE SCHEMA partitions
AUTHORIZATION zabbix;

CREATE OR REPLACE FUNCTION trg_partition()
RETURNS TRIGGER AS
$BODY$
DECLARE
prefix text := 'partitions.';
timeformat text;
selector text;
_interval INTERVAL;
tablename text;
startdate text;
enddate text;
create_table_part text;
create_index_part text;

BEGIN
selector = TG_ARGV[0];

IF selector = 'day' THEN
timeformat := 'YYYY_MM_DD';
ELSIF selector = 'month' THEN
timeformat := 'YYYY_MM';
END IF;

_interval := '1 ' || selector;
tablename :=  TG_TABLE_NAME || '_p' || TO_CHAR(TO_TIMESTAMP(NEW.clock), timeformat);

EXECUTE 'INSERT INTO ' || prefix || quote_ident(tablename) || ' SELECT ($1).*' USING NEW;

RETURN NULL;

EXCEPTION
WHEN undefined_table THEN

PERFORM delete_partitions(quote_ident(tablename));

startdate := EXTRACT(epoch FROM date_trunc(selector, TO_TIMESTAMP(NEW.clock)));
enddate := EXTRACT(epoch FROM date_trunc(selector, TO_TIMESTAMP(NEW.clock) + _interval ));

create_table_part:= 'CREATE TABLE IF NOT EXISTS '|| prefix || quote_ident(tablename) || ' (CHECK ((clock >= '
|| quote_literal(startdate) || ' AND clock < ' || quote_literal(enddate) || '))) INHERITS ('|| TG_TABLE_NAME || ')';

IF TG_TABLE_NAME = 'events' THEN
	create_index_part:= 'CREATE INDEX '|| quote_ident(tablename) || '_1 on ' || prefix
|| quote_ident(tablename) || '(eventid,clock)';
ELSE
	create_index_part:= 'CREATE INDEX '|| quote_ident(tablename) || '_1 on ' || prefix
|| quote_ident(tablename) || '(itemid,clock)';
END IF;

EXECUTE create_table_part;
EXECUTE create_index_part;

EXECUTE 'INSERT INTO ' || prefix || quote_ident(tablename) || ' SELECT ($1).*' USING NEW;

RETURN NULL;
END;
$BODY$
LANGUAGE plpgsql VOLATILE
COST 100;
ALTER FUNCTION create_partition()
OWNER TO postgres;

Setting triggers for every table

CREATE TRIGGER partition_trg BEFORE INSERT ON history FOR EACH ROW EXECUTE PROCEDURE trg_partition('day');
CREATE TRIGGER partition_trg BEFORE INSERT ON history_text FOR EACH ROW EXECUTE PROCEDURE trg_partition('day');
CREATE TRIGGER partition_trg BEFORE INSERT ON history_str  FOR EACH ROW EXECUTE PROCEDURE trg_partition('day');
CREATE TRIGGER partition_trg BEFORE INSERT ON history_text FOR EACH ROW EXECUTE PROCEDURE trg_partition('month');
CREATE TRIGGER partition_trg BEFORE INSERT ON events FOR EACH ROW EXECUTE PROCEDURE trg_partition('day');
CREATE TRIGGER partition_trg BEFORE INSERT ON trends FOR EACH ROW EXECUTE PROCEDURE trg_partition('day');
CREATE TRIGGER partition_trg BEFORE INSERT ON trends_uint FOR EACH ROW EXECUTE PROCEDURE trg_partition('day');

Creation of the function which will be deleting partitions
While the existing solution uses a more complicated function which uses cron to delete old partitions, we propose a new function which will use a new table “partition_life”.
In the new table (Picture 4) we’ll store how long should the partitions for each parent table stay undeleted. If you don’t want to delete the partitions of a particular table, set -1 to the days column. This way you don’t need to use cron to automatically delete partitions, it’s pure pgSQL.

 Picture 4: New table partition_life

CREATE OR REPLACE FUNCTION delete_partitions(partitionname  text)
  RETURNS text AS
$BODY$
DECLARE
result RECORD;
prefix text := 'partitions.';
table_timestamp TIMESTAMP;
delete_before_timestamp TIMESTAMP;
v_tablename text;
v_max_partition_age integer := -1;

BEGIN
   -- (?=_p) Positive Lookahead
   v_tablename := substring(partitionname  FROM '^([a-z_]*)(?=_p)');
   -- Find the maximum partition age for current table
   SELECT days INTO v_max_partition_age FROM partition_life WHERE name = v_tablename;
   -- If selected table is set to have old partitions deleted
   IF (v_max_partition_age  -1) THEN
      delete_before_timestamp := TO_TIMESTAMP(substring(partitionname FROM '[0-9_]*$'), 'YYYY_MM_DD') -
      (v_max_partition_age * INTERVAL '1 day');
      FOR result IN SELECT * FROM pg_tables WHERE schemaname = 'partitions' AND pg_tables.tablename LIKE
         (v_tablename || '_p%') LOOP
         table_timestamp := TO_TIMESTAMP(substring(result.tablename FROM '[0-9_]*$'), 'YYYY_MM_DD');
         IF table_timestamp <= delete_before_timestamp THEN
            RAISE NOTICE 'Deleting table %', quote_ident(result.tablename);
	    EXECUTE 'DROP TABLE ' || prefix || quote_ident(result.tablename) || ';';
         END IF;
      END LOOP;
   END IF;
RETURN delete_before_timestamp;
END;
$BODY$
  LANGUAGE plpgsql VOLATILE
  COST 100;
ALTER FUNCTION delete_partitions(text)
  OWNER TO postgres;

Migrating of the old records to the new partitions

INSERT INTO history SELECT * FROM history;

Once you have ran these queries in your SQL server, the new partitions should start appearing under the partitions schema.

6 Conclusion

After the optimization we reviewed the graphs once again to see if there were any improvements in the CPU utilization and disk size.

Picture 5: Database size after the optimization

In the picture 5 we can see that the disk size increasing has been significantly reduced (1 GB vs 400 MB in 4 days) and that the increased CPU utilization is no longer present in picture 6 as the new approach uses DROP queries for deleting partitions instead of DELETE for every row.

Picture 6: CPU utilization after the optimization

We also reviewed how the PostgreSQL planner plans queries after the optimization. We ran the same query again:

EXPLAIN ANALYZE SELECT *
FROM history
WHERE clock > 1394841600 AND clock < 1395014400

The result was:

QUERY PLAN
--------------------------------------------------------------
 ->  Append  (cost=0.00..64049.25 rows=2858109 width=21) (actual time=0.101..766.664 rows=2858660 loops=1)
   	->  Seq Scan on history  (cost=0.00..10.15 rows=1 width=21) (actual time=0.089..0.089 rows=0 loops=1)
         	Filter: ((clock > 1394841600) AND (clock < 1395014400))
         	Rows Removed by Filter: 410
   	->  Seq Scan on history_p2014_03_15 history  (cost=0.00..31506.61 rows=1406096 width=21) (actual time=0.012..274.342
rows=1406361 loops=1)
         	Filter: ((clock > 1394841600) AND (clock < 1395014400))
         	Rows Removed by Filter: 13
   	->  Seq Scan on history_p2014_03_16 history  (cost=0.00..32532.49 rows=1452012 width=21) (actual time=0.019..271.521
rows=1452299 loops=1)
         	Filter: ((clock > 1394841600) AND (clock < 1395014400))

Total runtime: 1205.666 ms

This proves that the planner knows about the CHECK constraints on our partitions and it only scans the partitions which have the CHECK constraints in the specified interval in our query.
The result of the query was therefore returned in 1.2 seconds which is almost 6x times faster than before the optimization (5.9 seconds).

7 Bibliography

[1] PostgreSQL Database Partitioning with Zabbix 2 [online]. [cit. 13. 05. 2014]. https://www.zabbix.org/wiki/Docs/howto/zabbix2_postgresql_partitioning
[2] Auto Partitioning with Zabbix 2.0 and Postgresql [online]. [cit. 17. 05. 2014]. https://www.zabbix.org/wiki/Docs/howto/zabbix2_postgresql_autopartitioning.

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

Traditional firewall can’t detect traffic inside the tunnel if the DPI of every UDP packet is not performed. Unfortunately, firewalls in current network equipment (Cisco, Juniper, HP …) do not support this functionality. To make things worse, these firewalls are often used as border firewalls in enterprise networks. The presentation focuses on our monitoring solution of IPv6 transition techniques. The probe monitors network traffic and generates NetFlow statistics. The type of transition technique is encoded in NetFlow data. We support AYIYA, 6to4, 6in4, Teredo and ISATAP.

IPv4 address configuration is mainly based on two methods. Manual address configuration or dynamical configuration via DHCPv4 server. Dynamic configuration via DHCPv4 became the de-facto standard for IPv4 address assignement. Network administrator usually bounds user’s MAC address (network-card link-address) to user’s IPv4 address in DHCPv4 server configuration. The IPv4 address is than assigned by DHCPv4 server to the user with corresponding MAC address. This allows to the administrator to track malevolent users because there is knowledge which IP address belongs to which MAC address and thus the user. This basically means, that the IPv4 address uniquely identify a user.

IPv6 (Internet Protocol version 6) is a new version of the fundamental Internet Protocol. IPv6 support is available for all operating systems such as Unix, Mac OS, Windows and usually enabled by default. However, address assignement in IPv6 networks is different. New concepts – autoconfiguration, multiple IPv6 addresses per interface or temporary IPv6 addresses introduce new challenges for users’ identification. In IPv6 networks, IPv6 address no longer identifies a user.

The following sections describe the address configuration process in IPv6 networks and problems connected with user identification.

2. Autoconfiguration and temporary addresses

The original idea of autoconfiguration was based on the notion of an IPv6 device connecting to a network and autoconfiguring everything automatically, without requiring any interaction from the user. Similar idea exists also in IPv4 network [1], however was not widely deployed.

Stateless Address Autoconfiguration (SLAAC) [2] can be described in simple terms. The network router tells all the connected nodes in a network segment what network they appear in, and what router they should use for packets travelling to the Internet (message RA – Router Advertisement). Of course, announcing alone would not be flexible enough. Hence, a newly connected device may send a request to the network (message RS – Router Solicitation) asking for information about what network it is in, and what is the way out. The whole autoconfiguration mechanism is a part of Neighbor Discovery for IPv6 [4], and all communication takes place using the ICMPv6 protocol. End nodes now have information, which network prefix should they used and how to route packets. However, this information is insufficient. The host still needs to know, how to create a host part (end user identifier) of his IPv6 address. The host part of the IPv6 address can be derived from information that the host already has, such as, a network-card link-address. This creates a mechanism to define the host part of the network address via a modified EUI 64 algorithm.

Because of user privacy, IPv6 addresses with randomly generated 64-bits interface identifiers are preferred instead of IEEE EUI-64. The RFC 4941 standard [3] defines a way to generate and change temporary addresses. The important requirement is that the sequence of temporarily generated addresses on the interface must be totally unpredictable. However, this requirement contradicts the need to identify a malevolent user in local networks. 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 what services. Figure 1 shows addresses used by one computer during one week. The computer communicates usually by more than one IP address at the same time.

Another problem connected with IPv6 address autoconfiguration is lack of necessary information providing to clients. In order to have complete communication in the network, other details are required, such as, the IPv6 addresses of recursive DNS servers. However, this information is not in the Router Advertisement. In practice, the efforts to resolve this problem have taken three different routes.

Figure 1: Addresses used by one computer during one week

Adding recursive DNS server information to the information transmitted within SLAAC. The standard suggests the addition of two items to Router Advertisement messages, namely recursive DNS server addresses and Domain Search List. So far, this support has been implemented in the RA daemon tool for Linux/UNIX (radvd), but it is not supported in other current systems – both routers and client systems. At the moment, it is very difficult to estimate how willing manufacturers would be to implement this extension to their systems. SLAAC is usually processed at the OS kernel level, and expansion to other items would necessarily mean changing it directly. We probably cannot expect support for this addition during a normal update.

Using anycast addresses for recursive DNS servers. The client would send the translation request to this anycast address and the nearest Recursive DNS Server would provide an answer. Because the specification used Site-Local addresses, which were deprecated by RFC 3879 in 2004, this proposal was abandoned. An implementation can be found on Microsoft systems.

Using different protocol. A third proposed solution was the transmission of Recursive DNS Server addresses, and perhaps other parameters, with a different protocol, independent of the SLAAC mechanism. Quite logically, there is an opportunity to use something already known, and that is DHCP.

3. DHCPv6

Assigning addresses with a DHCP server became the de-facto standard for IPv4. There has been an effort to re-use this mechanism in the IPv6 world. However, contrary to what one might expect, DHCPv6 is not merely DHCP that has been adapted to IPv6, with mostly the same functions.

DHCPv6 features two basic modes. In practice, the first mode, Stateless DHCPv6, is only a layer on top of the autoconfiguration mechanism described above (SLAAC) and is used to provide only recursive DNS server addresses. Two special flags are used for this purpose in the router advertisement: M – managed, O – other. These tell the client that it should ask in the relevant network for more information related to the connection parameters, through DHCPv6. If the M flag is set, stateful DHCPv6 is used. If the O flag is set, SLAAC will most likely be combined with stateless DHCPv6. If both flags are reset, the end-user stations know that there is no DHCPv6 server available in the network.

The behaviour of stateful DHCPv6 is more like the behaviour of DHCP that is known from IPv4. The server assigns an address to the client for a definite period, and the assignment is confirmed. It would seem that the SLAAC mechanism could be completely de-activated, and everything would depend on DHCPv6 alone. This idea is certainly right – except for one detail. All of the required parameters can be transferred through DHCPv6 except the most important one, which is the default gateway. The client expects to receive this information only via the Router Advertisement. This means that the client can create “uncontrolled” addresses, either with EUI 64 or Privacy Extensions. This behaviour could be suppressed by setting (or resetting) the Autonomous option in the Router Advertisements.

If an administrator decides to assign addresses through DHCPv6 and would like to use same functionality as with DHCPv4 server (MAC to IPv6 address binding) he faces to a problem. 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) [5]. The main idea behind creating such an identifier is to free the clients from dependence on hardware and on a specific network interface. The advantage is that a change of network adapter or a connection through another interface (such as WiFi instead of Ethernet) would not mean that the end-user station would start to behave as “someone else”. The standard defines three ways to obtain a DUID. The creator of the DHCPv6 client decides which one he chooses to use. In practice, this means that each system creates a DUID in a different way. If a PC has multiboot, with more than one operating system, then each system will have a different DUID. Most likely, the DUID will also change after reinstallation of the operating system. To use DHCPv6 in a network, while retaining a sufficient overview of who has which address, there is no other solution than to create completely different mechanisms and methods to register clients and end-user stations.

4. User identification and long term monitoring

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 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) 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. 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.

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.

5. Conclusion

The IPv6 autoconfiguration options are not straightforward. There are two different sets of mechanisms and protocols, and one cannot work effectively without the other. Currently, it is not possible to configure Recursive DNS Servers addresses with SLAAC, but with DHCPv6 it is not possible to configure the default gateway address. As a result, the only working method is to use both protocols. Failure of either mechanism, whether through faulty configuration, poorly debugged software or targeted attacks, leads to denial of the communication for the end-node, and thus, for the user. Moreover, diagnostics are fairly complicated in this situation and require a good understanding of the way both mechanisms work. These problems, together with lack of security mechanism are probably also the reason, why the IPv6 is still not widely deployed. ISP will not deploy a new protocol which allows to an attacker to restrict the connectivity to the ISP‘s customers. Even though that IPv4 and IPv6 protocols are incompatible, when both protocols are deployed, inproper functionality of IPv6 would have also an impact to IPv4 connections – e.g. long delay when a user is accessing a website. Unfortunately, considering the standartization process in IETF, it does not look like, there will be any changes in the near future.

6. Acknowledgement

This work is part of the project VG20102015022 supported by Ministry of the Interior of the Czech Republic and was partially supported by the research plan MSM0021630528.

Bibliography

[1] Deering, S. ICMP Router Discovery Messages. 1991. http://tools.ietf.org/html/rfc1256

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

[3] Narten, T., Draves, R. and Krishnan, S. RFC 4941 – Privacy Extensions for Stateless Address Autoconfiguration in IPv6. [online] 2007. url: http://tools.ietf.org/html/rfc4941

[4] Narten, T., Nordmark E., Simpson W., and Soliman H. Neighbor Discovery for IP version 6 (IPv6). RFC 4861, September 2007. url: http://tools.ietf.org/html/rfc4861

[5] R.Droms, J.Bound, B.Volz, T.Lemon, and C.Perkins. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) . RFC 3315, July 2003. url: http://tools.ietf.org/html/rfc3315

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.