IPFIX Module

IPFX Module
IPFX Module Screenshot
Developer	Alexey Mikhailov
First released
Latest preview version
Release date and age
Frequently updated	yes
Programming language
Platform	Gnu/Linux
Language	Multilingual
Status	active
Genre
License	GNU General Public License, LGPL
Website
Download

Network measurement is essential task for any network. Networks size and speed is growing. Packet-based solutions doesn't fit well into modern network, as computational complexity keeps getting higher. Most effective solutions are flow-based. Problem here is effective generating of flows at high-speed links. This problem is most essential for embeddable devices when we have limited CPU and memory resources. I propose new effective IPFIX probe for obtaining flows at high-speed links.

Summary

Network measurement is an essential task for any network. It can be used for:

a) Find anomalous behaviour in traffic behavior

b) Find 'bottlenecks'

c) Billing purposes

d) Vizualizing of network behavior

e) etc etc

Network size and speeds are growing. Packet-based solutions doesn't fit well into modern network, as computational complexity keeps getting higher. Most effective solutions are flow-based (we define flow as unidirectional sequence of packets which shares some common properties). Problem here is effective generating of flows at high speed links (metering proccess). This problem is most essential for small or embeddable devices when we have limited CPU and memory resources. I propose new effective metering process for obtaining flows at high-speed links even in embeddable devices.

Usually metering process is located in user-space, it uses libpcap to capture packets (notable example is OpenIMP that was proposed at ideas page). These solutions are sub-optimal as we need to pass network packet from kernel space to user space (context switches; excessive copying). We even can lost packets using these way (had you used tcpdump at high-speed links?). There are solutions for effective capturing of packets like using zero-copy mechanism (e.g. PF_RING) but they are still sub-optimal even if we avoid massive copying there're still context switches and we need to pass packets from kernel space to user space even if non-required copying is not involved.

Metering Process

I propose new efficient metering process that is based on using Netfilter conntrack subsystem. This subsystem is already aggregates packets into flows (using L3 attributes which is more then enough).

Firstly, we extend conntrack subsystem to hold more needed information about connection which are not in L3 layer (input/output interfaces, nexthop etc).

Secondly, we listen for DESTROY events to export finished connection. Another problem here is temporary export. Assume we have long TCP session (e.g. somebody downloads DVD from some FTP server), if we will export information about this connection only when it finishes then we lose relevance of current state of the network. Imagine plot of network load for some IP address, if we wouldn't pass temporary information such connection then this plot will hold spikes (download finished; flow exported) but we really want to obtain smooth one. That is why temporary export is essential here.

Thirdly, we need some protocol to pass information about flows. NetFlow is the most popular one (invented by Cisco and used at its hardware) but this protocol is proprietary. There's fresh, open and flexible standard for exporting IP flow information known as IPFIX (RFC 5101, RFC 5102, RFC 5103...). It based on Netflow V9, provides deep information model, flexible templates, bidirectional flows (RFC 5103). Bidirectional flows is essential for connection tracking as we need to know information about both endpoints, moreover it's very useful for measurement purposes. Some example applications are:

• Separate traffic into "answered" and not
• Obtain RTT is trivial task (reverse flow begtime - forward flow begtime)
• Full reconstruction of TCP session
• With Netflow version 5 you can't even support IPv6..

IPFIX is very young protocol, its RFC comes from 2008. There're not much tools for measurement purposes (openIMP, CERT software, VERMONT). They are all pcap-based, doesn't support bidirectional flows (e.g. SiLK divides bidirectional flow into two unidirectionals).

Fourthly, we need to develop effective way to pass IPFIX-formated flows from kernel-space in effective way. We can use Relay subsystem here, which provides effective zero-copy mechanism for user- and kernel- space communication. As it's poll-based, it can be effectively transformed to event-driven using Netlink protocol.

Basically it goes like

Conntrack --(export)--> conntrack_to_ipfix --(ipfix packet)--> relay_write()

User-space process --(listen for netlink events)--> relay_buffer_to_stdout()

I was working on this project for 10 months already, I have implementation of this ideas which is proven to be way more effective then any other tools. Using such ideas is most essential for embeddable devices as I mentioned before. What has already been done:

1) libipfix ported to Linux kernel. bidirectional flows support was added, memory footprint was reduced

2) extending conntrack to Netflow V5 format (at least)

3) relay/netlink communication mechanism implemented

4) user-space tools are working

It works now for very specifical environment (our network) though I will need to work on generalization. Code of this project is available on request (it's open-source, but i just don't like to publish software not intended to use by end-users).

Deliverables

1) IPFIX probe will be generalized and released as module.

2) IPFIX probe will be ported to OpenWrt platform.

3) Documentation will be written and it will be possible to configure probe for end-user in easy way (e.g. web-interface)

4) IPFIX support will be intergrated into freimap.

5) Implementation will be tested using freimap and test framework that will be provided with module.

Benefits

1) Any openwrt-enabled deviced could act as IPFIX probe. It will be reliable and highly effective. Even embeddable devices could rock on high-speed links. No overhead will be introduced as connection tracking subsystem is already there (e.g. it's required for NAT)

2) Freimap will get IPFIX power, that will lead to great amount of information we could vizualize in convient way.

3) IPFIX applications are non-countable really. E.g. you can use it for example finding anomalous behaviour in network traffic using statistical analysis (e.g. Holt-Winters).