The Internet Protocol Flow Information Export (IPFIX) is a network flow protocol standard defined by the Internet Engineering Task Force (IETF). The IETF IPFIX project was initiated to create a widespread benchmark of export metadata about the traffic flow information from routers, switches, firewalls, and other infrastructure devices.
IPFIX describes how flow data should be laid out and transmitted from a sender to a receiver (collector). The metadata supplied by IPFIX and Netflow protocols is similar to how your phone bill shows your calls, displaying the source, destination and volume rather than showing the actual content of the conversations. With this information, you can gain useful insights about how to manage your traffic at a lower impact on your network management strategy (when compared to full packet capture).
IPFIX is regarded as a “push” protocol. Each IPFIX-supported device periodically transmits IPFIX messages to configured receivers (collectors) without any requests by the receiver. The sender controls most of the formulation of IPFIX data messages. IPFIX introduces the concept of templates, which make up these flow data messages to the receiver. IPFIX also allows the sender to use user-defined data types in its messages. IPFIX utilizes the Stream Control Transmission Protocol (SCTP) as its preferred transport layer protocol; however, it also supports the use of the Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) messages.
IPFIX network monitoring utilizes flow export, in which information about packets observed is aggregated into flows and exported for analysis. Per IETF IPFIX Protocol Specification (RFC 7011), a flow is defined as “a set of IP packets passing an observation point in the network during a certain time interval, such that all packets belonging to a particular flow have a set of common properties”. These common properties may include packet header fields, such as source and destination IP addresses and port numbers, packet properties, and information derived by IP packet forwarding.
The architecture of a typical IPFIX deployment comprises several aspects detailed in the following sub-sections.
Figure 1. IPFIX Architecture Overview
Packet observation is the process of capturing packets from a network observation point and pre-processing them for additional handling. Prior to any preprocessing being performed, packets must be read from the line. This operation, known as packet capture, is the first in the packet observation step and includes several checks such as checksum error checking. The second packet observation operation is packet timestamping. Precise packet timestamps are critical for many follow-on processing analysis applications. For example, when packets from separate observation points are combined into a single dataset, their ordering will be based on their timestamps.
Both packet capture and timestamping are mandatory operations performed on all packets. Ensuing operations in the packet observation step are optional. The first of them is packet truncation, which selects only those bytes of a packet that fit into a preconfigured number of packet bytes desired for packet capture. For example, IPFIX typically only utilizes packet header fields and ignores packet payloads.
The final operation of the packet observation stage is packet sampling and filtering. The packet capture operation may define sampling and filtering rules so that all or only a portion of the packets are designated for processing and metering. The impetus for sampling is to select a packet subset which enables the properties of the complete packet stream to be projected with a good degree of accuracy. The reason behind filtering is to eliminate all packets that are not required for follow-on processing or that are not relevant for the traffic analysis process.
The Flow Metering and Export process is the step in which the information about packets are aggregated into flows and flow records are exported, which makes it a key component of IPFIX architecture. Specifically, the Metering Process involves aggregation of packets into flows using flow definitions as per Information Elements (IEs).
Fields that can be exported in IPFIX flow records are called Information Elements (IEs). IPFIX permits IEs to comprise Internet Assigned Numbers Authority (IANA)-standard list of IEs for multi-vendor interoperability as well as proprietary vendor/enterprise-specific IEs. IEs can range from defined L2 through L7 attributes (including URLs). The structure of the Metering Process for processing IEs typically varies for each deployment. However, flow collectors are always instructed by flow exporters using templates which specify the IEs used in flow data.
Flow caches are entities utilized in the Metering Process for storing active network flows. Flow caches have entries that are composed of IEs, each of which can be either a key (or flow attribute) or non-key field. Commonly used key fields are source and destination IP addresses and port numbers. The set of key fields, commonly referred to as the flow key, is used to determine whether a packet belongs to a flow already cached or to a new flow, and thus defines how packets are grouped into flows. Flow cache entries are preserved in the flow cache until the matching flows are deemed to have ended, after which the entries are expired.
The first step of the Exporting Process is the optional flow record sampling and filtering for selecting a subset of flow records to reduce the processing requirements of the Exporting Process, the collector and all subsequent steps. In contrast to the packet sampling and filtering operation of the Packet Observation step, which are performed as part of the Packet Observation step, flow record sampling and filtering operations are executed following the Metering Process and therefore work on flow records instead of packets.
Construction of IPFIX messages for transmission to flow collectors follows flow sampling and filtering. An IPFIX message comprises a message header which includes a protocol version number, message length, export time and an observation domain ID. Following the header, the message contains header come one or more Sets, which have an ID and a variable length, and can be of any of the following types:
After constructing an IPFIX message for transmission to a flow collector, a transport protocol has to be selected (a differentiating feature of IPFIX is its support for multiple transport protocols) among SCTP, TCP and UDP transports.
Flow collectors are an integral part of flow monitoring setups, as they receive, store, and pre-process flow data from one or more flow exporters in the network. Data collection is performed by one or more Collector Processes within flow collectors. Common pre-processing tasks are data compression, aggregation, filtering, and summary generation. Typically, data collected is stored on a database that will be used for traffic analysis.
While IPFIX leverages the capabilities embedded within existing network switches and routers to obtain data about the information these devices process for enhanced network monitoring and threat detection, utilizing standard networking devices such as switches and routers for IPFIX flow-based data generation and processing can saddle network planners and administrators with a number of critical challenges.
IPFIX is the multi-vendor flow technology standard but it is usually only supported in higher-end switches and routers. For example, economical lower-end routers and switches may not include IPFIX support. Thus, in many parts of the network, especially at the edge (such as enterprise remote/branch office networks), IPFIX is costly to implement or you may be limited to using Netflow.
Predominantly, IPFIX flow-enabled devices are deployed in core networks. With countless network performance, monitoring and security applications relying upon IPFIX, non-IPFIX capable devices create major opaque zones across the network.
IPFIX captures all IP flow information flowing through an interface and reports data traffic across the entire network without missing any transaction. While flow sampling is a valid method for network management use cases, flow sampling is ineffective for security use cases because it can omit certain flows that could potentially be network breaches that should have been captured. IPFIX can provide un-sampled accounting of all network activity on an IP flow-enabled interface and is useful in event correlation and data analytics for network security purposes.
Capturing and exporting IPFIX flow data, however, can increase overhead on constrained routers and switches. The possibility of overburdening network infrastructure often inhibits network engineers from enabling IPFIX flow reporting on their network for fear of reducing capacity or affecting quality. The underlying concern may be regarding the introduction of increased jitter and delay, which may impact network services and applications utilizing these devices.
Passive purpose-built network devices utilizing probes for monitoring network links may provide an alternative to capturing flows from routers and switches. This approach may overcome some of the drawbacks of flow monitoring using routers and switches for flow monitoring.
While flow collection may be easier to implement in a dedicated appliance than in a router; for example, a purpose-built appliance does not impact packet-processing performance of routers, probes are required for every link for which flow capture is necessary.This imposes additional acquisition and operational costs while creating new network failure vulnerabilities.
Support of network metadata protocols like IPFIX within discrete networking devices such as network switches and routers produces data that exists in a silo. By integrating IPFIX capabilities into NPBs, you can forward flow records correlated across network links of interest to security and monitoring tools for deeper analysis.
Support of IPFIX in Network Packet Brokers (NPBs) enables improved overall network performance. As IPFIX flow monitoring is not the primary task of the network switch or router, packet forwarding performance of such devices may be affected by flow record generation which is why even under normal conditions, each network device may only sample a subset of the traffic for metadata processing. As a result, the ability of network administrators to detect and remedy network threats may be affected.
An NPB exporting IPFIX metadata into network security and performance monitoring tools can generate metadata on all traffic thus providing comprehensive coverage. In addition, aggregating multiple inputs from the network into a single NPB translates into a more efficient network security and performance monitoring capabilities. The NPB will generate the metadata for all traffic links and can simultaneously forward traffic metadata as well as selected raw data packets to security and performance monitoring devices.
Niagara Networks’ Packetron is an open system packet processor module for the N2 modular multi-purpose visibility node. The Packetron module is based on Intel’s Xeon x86 architecture and can directly process traffic from any one of the host’s 2.56 Tbps traffic streams. The N2 modular multi-purpose host can be used as a network tap, network bypass, or a network packet broker, or all three simultaneously. It can be deployed in various inline and out-of-band deployments on up to 100 GbE links.
Support of packet processing applications in the Packetron module enables optimum support for packet analysis, detection, prevention, processing, monitoring and more, in complex network security use cases. The host’s L5 filtering, replication, aggregation and load-balancing capabilities ensure that only relevant traffic reaches the application.
Full support of metadata protocols including IPFIX and NetFlow by Niagara Networks’ advanced N2 visibility node is also enabled by the optional Packetron packet processing module. Packetron module offloads network flow monitoring and removes the requirement for flow monitoring by discrete network router and switch devices and consequent impact on performance of such devices. Each Packetron module supports concurrent monitoring, collection, filtering of network flows for specific network segments using IPFIX, NetFlow v5, and NetFlow v9 protocols and export of network flow records to one of many collector security and performance monitoring systems for follow-on analysis.
Figure 2. Network Flow Monitoring in Niagara Packetron Module
IPFIX Best Practices and Use Cases
IPFIX has wide-ranging use in the networking market in general and for network security specifically and is used for a range of applications from internal/external threat detection to network capacity planning. Following are some of the main use cases for IPFIX data:
Conclusion
The IETF IPFIX project was initiated to create a widespread benchmark of export for flow information from routers, switches, firewalls, and other infrastructure devices. IPFIX describes how flow data should be laid out and transmitted from senders to one or more collector devices. IPFIX network monitoring utilizes flow export, in which packets are aggregated into flows and exported for storage and analysis. A flow consists of IP packets having a set of common properties such as packet header fields, such as source and destination IP addresses and port numbers, and information derived by IP packet forwarding.
The architecture of a typical IPFIX deployment comprises Packet Observation in which packets are observed and processed, Flow Metering and Export, which consists of a Metering Process and an Exporting Process in which packets are aggregated into flows and exported and a Collecting Process by collector devices for reception, aggregation, filtering, data compression, storage and summary generation of flow data.
While IPFIX leverages the capabilities embedded within existing network switches and routers to obtain data about the information these devices process for enhanced network monitoring and threat detection, utilizing standard networking devices such as switches and routers for IPFIX flow-based data generation and processing can saddle network planners and administrators with a number of critical challenges including creation of opaque zones with the network and impact on packet-forwarding performance of network switches and routers. In comparison, utilizing a network packet broker for generation, collection, and export of flow records enables holistic network-wide monitoring and removes any impact on packet-forwarding performance of network infrastructure devices.
Full support of IPFIX by Niagara Networks’ advanced N2 visibility node is enabled by the optional Packetron packet processing module. Packetron module offloads network flow monitoring and removes the need for flow monitoring by discrete network router and switch devices and consequent impact on performance of such devices. Each Packetron module supports concurrent monitoring, collection, filtering of network flows for specific network segments using IPFIX, NetFlow v5, and NetFlow v9 protocols and export of network flow records to one to many collector security and performance monitoring systems for follow-up analysis..
IPFIX has wide-ranging use in the networking market in general and for network security specifically and is used for a range of applications from internal/external threat detection to network capacity planning.
For more information on how metadata protocol support within Packetron-enabled N2 NPBs enable optimally flexible network monitoring and analysis capabilities for your network, contact Niagara Networks to arrange a consultation today.