RFC 5470
Architecture for IP Flow Information Export
RFC 5470: Architecture for IP Flow Information Export 🦋
Okay bestie, so this is RFC 5470, and it's giving architecture 💅. It's titled "Architecture for IP Flow Information Export" and was published in March 2009. The category is Informational, so it's sharing info with the Internet community and isn't an Internet standard. The authors are G. Sadasivan from Rohati Systems, N. Brownlee from CAIDA | The University of Auckland, B. Claise from Cisco Systems, Inc., and J. Quittek from NEC. There's no Obsoletes or Updates line in the title block, so it doesn't replace or update anything 🌸.
Status of This Memo ✨
This memo is for information only, so the Internet community can read it. It doesn't specify an Internet standard of any kind. Distribution is unlimited, so share it with everyone 💜.
Copyright Notice 🎀
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved 💖.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which are the rules in effect on the date it was published. You can read them at http://trustee.ietf.org/license-info. Please read them carefully, because they explain your rights and restrictions for this document 🧚.
This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. Some of that material's copyright owners may not have given the IETF Trust permission to allow changes to it outside the IETF Standards Process. So, unless you get a proper license from those copyright owners, this document may not be modified outside the IETF Standards Process, and you may not make derivative works of it outside the IETF Standards Process. The exceptions are formatting it for publication as an RFC and translating it into languages other than English 🌈.
Abstract 🦋
This memo defines the IP Flow Information eXport (IPFIX) architecture. It's for selectively monitoring IP Flows and exporting the measured IP Flow information from an IPFIX Device to a Collector 🔥.
Table of Contents 📖
1. Introduction ....................................................3
1.1. Document Scope .............................................3
1.2. IPFIX Documents Overview ...................................3
2. Terminology .....................................................4
3. Examples of Flows ...............................................8
4. IPFIX Reference Model ..........................................10
5. IPFIX Functional and Logical Blocks ............................12
5.1. Metering Process ..........................................12
5.1.1. Flow Expiration ....................................12
5.1.2. Flow Export ........................................13
5.2. Observation Point .........................................13
5.3. Selection Criteria for Packets ............................13
5.3.1. Sampling Functions, Si .............................14
5.3.2. Filter Functions, Fi ...............................15
5.4. Observation Domain ........................................15
5.5. Exporting Process .........................................15
5.6. Collecting Process ........................................16
5.7. Summary ...................................................17
6. Overview of the IPFIX Protocol .................................18
6.1. Information Model Overview ................................19
6.2. Flow Records ..............................................19
6.3. Control Information .......................................20
6.4. Reporting Responsibilities ................................21
7. IPFIX Protocol Details .........................................21
7.1. The IPFIX Basis Protocol ..................................21
7.2. IPFIX Protocol on the Collecting Process ..................22
7.3. Support for Applications ..................................22
8. Export Models ..................................................23
8.1. Export with Reliable Control Connection ...................23
8.2. Collector Failure Detection and Recovery ..................23
8.3. Collector Redundancy ......................................24
9. IPFIX Flow Collection in Special Situations ....................24
10. Security Considerations .......................................25
10.1. Data Security ............................................25
10.1.1. Host-Based Security ...............................26
10.1.2. Authentication-Only ...............................26
10.1.3. Encryption ........................................26
10.2. IPFIX End-Point Authentication ...........................27
10.3. IPFIX Overload ...........................................27
10.3.1. Denial-of-Service (DoS) Attack Prevention .........27
11. IANA Considerations ...........................................28
11.1. Numbers Used in the Protocol .............................28
11.2. Numbers Used in the Information Model ....................29
12. Acknowledgements ..............................................29
13. References ....................................................30
13.1. Normative References .....................................30
13.2. Informative References ...................................301. Introduction ✨
There are a bunch of applications that need Flow-based IP traffic measurements, like usage-based accounting, traffic profiling, traffic engineering, attack/intrusion detection, and quality-of-service (QoS) monitoring 📊. So it's important to have a standard way to export info about IP Flows. This document defines an architecture for IP traffic Flow monitoring, measuring, and exporting, and it gives a high-level look at an IPFIX Device's key components and what they do 🍓.
1.1. Document Scope 🌸
This document defines the architecture for IPFIX. Its main goals are to:
- Describe the key IPFIX architectural components, which include (at least) IPFIX Devices and Collectors that talk to each other using the IPFIX protocol 💅.
- Define the IPFIX architectural requirements, like recovery, security, and so on 🔐.
- Describe the characteristics of the IPFIX protocol 🎀.
1.2. IPFIX Documents Overview 📚
The IPFIX protocol gives network admins access to IP Flow information 👑. This document specifies the architecture for exporting measured IP Flow information from an IPFIX Exporting Process to a Collecting Process, following the requirements in RFC 3917 [1]. The IPFIX protocol document, RFC 5101 [3], explains how IPFIX data records and templates get carried over a congestion-aware transport protocol, from the IPFIX Exporting Process to the IPFIX Collecting Process 🚀. IPFIX also has a formal description of its information elements (fields), including their name, type, and extra semantic info, as specified in RFC 5102 [2] 🧠. Finally, RFC 5472 [4] describes what kinds of applications can use the IPFIX protocol and how they can use the info it provides. It also shows how the IPFIX framework fits in with other architectures and frameworks 🦋.
Heads up, bestie: the IPFIX system does not provide for remote configuration of an IPFIX device. Instead, implementors must provide an effective way to configure their IPFIX devices 🙈.
2. Terminology 📚✨
okay so bestie, this section is the glossary, and it's lowkey the most important part because every other section leans on these words 🤓💖. The basic IPFIX terms like IP Traffic Flow, Exporting Process, Collecting Process, and Observation Point mean the exact same thing as they do in the IPFIX requirements doc, RFC 3917 [1]. A few got expanded so the protocol stuff makes more sense, and some new ones were added for the architecture 🏗️. If a term shows up both here and in RFC 5101 [3], the definitions match in both docs, no cap 💅.
Observation Point 📍
An Observation Point is a spot in the network where IP packets can be observed 👀. Some examples are a line with a probe attached, a shared medium like an Ethernet-based LAN, a single port on a router, or a set of interfaces (physical or logical) on a router.
Every Observation Point is tied to an Observation Domain (more on that in a sec), and one Observation Point can be a superset of several others 🪆. For example, an entire line card can be an Observation Point, and the individual interfaces on that line card are the smaller ones inside it.
Observation Domain 🌐
An Observation Domain is the biggest set of Observation Points where a Metering Process can aggregate Flow information 🫶. A router line card can be an Observation Domain if it has several interfaces, and each interface is its own Observation Point. In the IPFIX Message it generates, the Observation Domain includes its Observation Domain ID, which is unique per Exporting Process. That's how the Collecting Process can figure out which Observation Domain the IPFIX Messages are coming from 🕵️♀️. Every Observation Point belongs to an Observation Domain, and it is recommended that Observation Domain IDs are also unique per IPFIX Device.
IP Traffic Flow or Flow 🌊
Okay, so the internet community has a bunch of different definitions for "flow," but inside IPFIX we use this one 💅:
A Flow is a set of IP packets that pass an Observation Point in the network during a certain time interval. All the packets in one Flow share a set of common properties. Each property comes from applying a function to the values of:
- one or more packet header fields (e.g., destination IP address), transport header fields (e.g., destination port number), or application header fields (e.g., RTP header fields [5]).
- one or more characteristics of the packet itself (e.g., number of MPLS labels)
- one or more fields derived from packet treatment (e.g., next hop IP address, output interface)
A packet counts as part of a Flow only if it completely satisfies all the defined properties of that Flow 🎯.
This definition is super flexible 🤸♀️. It covers everything from a Flow holding every packet seen on a network interface to a Flow that's just one single packet between two applications. It also includes packets picked by a sampling mechanism.
Flow Key 🔑
Each of the fields that:
- belongs to the packet header (e.g., destination IP address),
- is a property of the packet itself (e.g., packet length),
- is derived from packet treatment (e.g., Autonomous System (AS) number), and
- is used to define a Flow
is called a Flow Key 🗝️.
Flow Record 📝
A Flow Record has info about one specific Flow that was observed at an Observation Point. It holds measured properties of the Flow (e.g., the total number of bytes for all the Flow's packets) and usually some characteristic properties of the Flow too (e.g., source IP address) 💖.
Metering Process ⚙️
The Metering Process is the one that generates Flow Records 🏭. Its inputs are packet headers and characteristics observed at an Observation Point, plus the packet treatment at that Observation Point (like the selected output interface).
The Metering Process is a bundle of functions, including packet header capturing, timestamping, sampling, classifying, and maintaining Flow Records 🧩.
Maintaining Flow Records can mean creating new records, updating existing ones, computing Flow statistics, deriving further Flow properties, detecting Flow expiration, passing Flow Records to the Exporting Process, and deleting Flow Records 🧹.
Exporting Process 📤
The Exporting Process sends Flow Records to one or more Collecting Processes 💌. The Flow Records come from one or more Metering Processes.
Exporter 🚀
A device that hosts one or more Exporting Processes is called an Exporter 🛸.
IPFIX Device 📱
An IPFIX Device hosts at least one Exporting Process. It can host more Exporting Processes too, plus any number of Observation Points and Metering Processes 🧑💻.
Collecting Process 📥
A Collecting Process receives Flow Records from one or more Exporting Processes. It might process or store those Flow Records, but that stuff is out of scope for this doc 🙈.
Collector 🗄️
A device that hosts one or more Collecting Processes is called a Collector 🫡.
Template 🧾
A Template is an ordered sequence of <type, length> pairs. It's used to completely specify the structure and semantics of a particular set of information that needs to be communicated from an IPFIX Device to a Collector 🍓. Each Template can be uniquely identified by a Template ID.
Control Information, Data Stream 🎀
The info that needs to be exported from an IPFIX Device falls into two categories:
Control Information
This includes the Flow definition, the selection criteria for packets within the Flow that the Exporting Process sends, and the Templates describing the data to be exported. Control Information has everything the endpoints need to understand the IPFIX protocol, and especially what the Collector needs to understand and interpret the data the Exporter sent 🧠✨.
Data Stream
This includes Flow Records carrying the field values for the various observed Flows at each of the Observation Points 📊.
IPFIX Message 💬
An IPFIX Message is a message that starts at the Exporting Process, carries that Exporting Process's IPFIX records, and is headed to a Collecting Process 📨. An IPFIX Message gets encapsulated at the transport layer 🧃.
Information Element 🏷️
An Information Element is a description of an attribute that may appear in an IPFIX Record. It's independent of both protocol and encoding 🌈. The IPFIX information model, RFC 5102 [2], defines the base set of Information Elements for IPFIX. The type attached to an Information Element shows what it's allowed to contain and also decides which encoding mechanisms are valid for use in IPFIX 💅.
3. Examples of Flows 🦋
Here are some examples of Flows, bestie 🫶. In the IPv4 examples, we use interface addresses from three different 26-bit (/26) subnets 🌸. In the IPv6 examples, we use 'mac addr-nn' in the low-order 64 bits to show the IEEE MAC (Media Access Control) address of host interface nn 🧚.
Example 1: Flow Keys are the fields that tell Flows apart 🔍. Different combos of their field values make unique Flows. If {source IP address, destination IP address, DSCP} are Flow Keys, then all of these are different Flows:
1. {192.0.2.1, 192.0.2.65, 4}
2. {192.0.2.23, 192.0.2.67, 4}
3. {192.0.2.23, 192.0.2.67, 2}
4. {192.0.2.129, 192.0.2.67, 4}
5. {2001:DB8::0:mac-addr-01, 2001:DB8::1:mac-addr-11, 4}
6. {2001:DB8::0:mac-addr-02, 2001:DB8::1:mac-addr-13, 4}
7. {2001:DB8::0:mac-addr-02, 2001:DB8::1:mac-addr-13, 2}
8. {2001:DB8::2:mac-addr-21, 2001:DB8::1:mac-addr-13, 4}Example 2: A mask function can be applied to all the packets that pass through an Observation Point to aggregate some values 🪄. You can do this by defining the Flow Keys as {source IP address, destination IP address, DSCP} like in Example 1, then applying functions that mask out the source and destination IP addresses (least significant 6 bits for IPv4, 64 bits for IPv6). The eight Flows from Example 1 get squished into six Flows by merging Flows 1+2 and 5+6 into single Flows 🤯:
1. {192.0.2.0/26, 192.0.2.64/26, 4}
2. {192.0.2.0/26, 192.0.2.64/26, 2}
3. {192.0.2.128/26, 192.0.2.64/26, 4}
4. {2001:DB8::0/64, 2001:DB8::1/64, 4}
5. {2001:DB8::0/64, 2001:DB8::1/64, 2}
6. {2001:DB8::2/64, 2001:DB8::1/64, 4}Example 3: A filter defined by some Flow Key values can be applied to all packets that pass the Observation Point, so you only select certain Flows 🎀. The filter works by choosing fixed values for specific Keys from the packet.
All the packets going from a customer network 192.0.2.0/26 to another customer network 192.0.2.64/26 with a DSCP value of 4 define a Flow ✨. Everything else doesn't define a Flow and isn't counted. So the three Flows from Example 2 get reduced to just one Flow by filtering out Flows 2 and 3, leaving only Flow 1, {192.0.2.0/26, 192.0.2.64/26, 4} 💅.
Same deal for the IPv6 packets above: you could filter out Flows 5 and 6 and leave Flow 4 🌈.
The examples above can be thought of as a function F() that takes {source IP address, destination IP address, DSCP} as input 🧮. The function only selects packets that satisfy all three of these conditions:
- Mask out the least significant 6 bits of source IP address, match against 192.0.2.0.
- Mask out the least significant 6 bits of destination IP address, match against 192.0.2.64.
- Only accept DSCP value equal to 4.
Depending on the {source IP address, destination IP address, DSCP} values of the different packets observed, the Metering Process function F() picks, filters, and aggregates different sets of packets, which creates different Flows 🦋💖. For example, for various combinations of {source IP address, destination IP address, DSCP} values, F(source IP address, destination IP address, DSCP) would result in the definition of one or more Flows 👑.
4. IPFIX Reference Model ✨
okay bestie, this is the big picture 🖼️ the figure below covers literally every setup an IPFIX system could be in, so no scenario gets left out 💅
+----------------+ +----------------+
|[*Application 1]| ... |[*Application n]|
+--------+-------+ +-------+--------+
^ ^
| |
+ = = = = -+- = = = = +
^
|
+------------------------+ +-------+------------------+
|IPFIX Exporter | | Collector(1) |
|[Exporting Process(es)] |<---------->| [Collecting Process(es)] |
+------------------------+ +--------------------------+
.... ....
+------------------------+ +---------------------------+
|IPFIX Device(i) | | Collector(j) |
|[Observation Point(s)] |<--------->| [Collecting Process(es)] |
|[Metering Process(es)] | +---->| [*Application(s)] |
|[Exporting Process(es)] | | +---------------------------+
+------------------------+ .
.... . ....
+------------------------+ | +--------------------------+
|IPFIX Device(m) | | | Collector(n) |
|[Observation Point(s)] |<----+---->| [Collecting Process(es)] |
|[Metering Process(es)] | | [*Application(s)] |
|[Exporting Process(es)] | +--------------------------+
+------------------------+the functional bits are the ones in brackets [] 🎀 anything inside [*] isn't part of the IPFIX architecture, so it's not on the official guest list 🙈 the <-----> lines are defined by IPFIX, but the <= = = => ones are not 💅
Figure 1: IPFIX Reference Model
the next figure is a typical IPFIX Device, with the IPFIX components drawn as boxes 📦✨
+--------------------------------------------------+
| IPFIX Device |
| +-----+ |
| +------- ... ------------+---------> | |
| | | | | |
| +----+----+ +----+----+ | | |
| |Metering | |Metering | | E | |
| |Process 1| |Process N| | x | |
| +---------+ +---------+ | p | |
| ^ ^ | o | |
| +------+--------+ +---------+------+ | r | |
| | Obsv Domain 1 | | Obsv Domain N | | t | |
| |+-----+-------+| |+-------+------+| | i | |
| ||Obsv Pt 1..j || ... ||Obsv Pt j+1..M|| | n | |
| |+-------------+| |+--------------+| | g | | Export
Packets | +------^--------+ +---------^------+ | | | packets
--->----+--------+---------- ... ---------+ | | | to
In | | +--------->
| . . . . . | | |Collector
| | | |
| +------ ... -------------+---------> | |
| | | | | |
| +----+----+ +----+----+ | P | |
| |Metering | |Metering | | r | |
| |Process 1| |Process N| | o | |
| +---------+ +---------+ | c | |
| ^ ^ | e | |
| +------+--------+ +---------+------+ | s | |
| | Obsv Domain 1 | | Obsv Domain N | | s | |
| |+-----+-------+| |+-------+------+| | | |
| ||Obsv Pt 1..k || ... ||Obsv Pt k+1..M|| | | |
| |+-------------+| |+--------------+| | | |
Packets | +------^--------+ +---------^------+ +-----+ |
--->----+--------+---------- ... ---------+ |
In | |
+--------------------------------------------------+Figure 2: IPFIX Device
5. IPFIX Functional and Logical Blocks
5.1. Metering Process
every Observation Point in an IPFIX Device that's taking part in Flow measurements has to be tied to at least one Metering Process 🔍 every packet that comes into an Observation Point goes into each Metering Process linked to it 📬 basically, each Metering Process watches the packets going past an Observation Point, timestamps them, and sorts them into Flow(s) based on the selection criteria 🧚
the Metering Process is the functional block that manages all the Flows coming out of an Observation Domain 👑 its typical jobs may include:
- Maintaining database(s) of all the Flow Records from an Observation Domain. This includes creating new Flow Records, updating existing ones, computing Flow Records statistics, deriving further Flow properties, and adding non-Flow-specific information based on the packet treatment (in some cases, fields like AS numbers, router state, etc.)
- Maintaining statistics about the Metering Process itself, such as Flow Records generated, packets observed, etc.
5.1.1. Flow Expiration
okay so a Flow counts as expired under these conditions 💀
- If no packets belonging to the Flow have been observed for a certain period of time. This time period should be configurable at the Metering Process, with a minimum value of 0 seconds for immediate expiration. Note that a zero timeout would report a Flow as a sequence of single-packet Flows. 🫠
- If the IPFIX Device experiences resource constraints, a Flow may be prematurely expired (e.g., lack of memory to store Flow Records). 😭
- For long-running Flows, the Metering Process should expire the Flow on a regular basis or based on some expiration policy. This periodicity or expiration policy should be configurable at the Metering Process. When a long-running Flow is expired, its Flow Record may still be maintained by the Metering Process so that the Metering Process does not need to create a new Flow Record for further observed packets of the same Flow. 🦋
5.1.2. Flow Export
the Exporting Process is the one that decides when and whether to export an expired Flow 📤 a Flow can get exported because it expired for any of the reasons in Section 5.1.1, "Flow Expiration". for example, the Exporting Process exports a portion of the expired Flows every 'x' seconds ⏰
for long-lasting Flows, the Exporting Process should export the Flow Records on a regular basis or based on some export policy. This periodicity or export policy should be configurable at the Exporting Process 🌸
5.2. Observation Point
a Flow Record is way easier to analyse when you know which Observation Point it was measured from 🔎 so it's recommended that IPFIX Devices send this info to Collectors 🫶 if there's only one Observation Point, or the Observation Point info just isn't relevant, the Metering Process can skip adding it to the Flow Records ✨
5.3. Selection Criteria for Packets
a Metering Process can set up rules so only certain packets in an incoming stream get picked for measurement at an Observation Point 🎯 this can be done with one of the two methods below, or a mix of both, in either order. you can even combine them, like a sequence of {F1, S1, F2, S2, S3} run in a specific order at an Observation Point to select particular Flows 🧁
the figure below shows the operations a typical Metering Process might apply 👀
+---------------------------+
| packet header capturing |
+---------------------------+
|
v
+---------------------------+
| timestamping |
+---------------------------+
|
v
+---------------> +
| |
| v
| +----------------------------------------------+
| | sampling Si (1:1 in case of no sampling) |
| +----------------------------------------------+
| |
| v
| +----------------------------------------------+
| | filtering Fi (select all when no criteria) |
| +----------------------------------------------+
| |
| v
+-----------------+
|
v
+---------------------------+
| Flows |
+---------------------------+Figure 3: Selection Criteria for Packets
packets can be selected before or after any IP processing, so before IP checksum validation, IP filtering, etc., or after one or more of those steps 🧐 this changes what kinds of traffic (or erroneous conditions) IPFIX can observe 🙃 it's recommended that packets get selected after their checksums have been verified ✅
5.3.1. Sampling Functions, Si
a sampling function decides which packets in an incoming stream get selected for measurement, so the packets that meet the sampling criteria for this Metering Process 🎲
Example: sample every 100th packet that was received at an Observation Point.
choosing all the packets is just a special case where the sampling rate is 1:1 💖
5.3.2. Filter Functions, Fi
a Filter Function only picks the incoming packets that satisfy a function on fields from the packet header, fields grabbed while doing the packet processing, or properties of the packet itself 🔥
Example: Mask/Match of the fields that define a filter. A filter might be defined as {Protocol == TCP, Destination Port < 1024}.
several filters can be used, in any sequence, to select packets 🌈 and packets picked by a (sequence of) filter functions can get classified again by other filter functions, which means the selected packets might belong to several Flows, and any or all of them can be exported 🍓
5.4. Observation Domain ✨
okay so the Observation Domain is the logical block that gives a whole group of Observation Points inside an IPFIX Device one single identity 🫶 Every {Observation Point, Metering Process} pair belongs to exactly one Observation Domain. An IPFIX Device can have several Observation Domains, and each one holds only a subset of the Observation Points 🦋 Every Observation Domain must carry a unique ID within its IPFIX Device. And when there's more than one domain, a unique ID per domain must be passed as a parameter to the Exporting Function. That ID is called the IPFIX Observation Domain ID 🎀
5.5. Exporting Process 💅
The Exporting Process is the block that sends data to one or more IPFIX Collectors using the IPFIX protocol 🚀 On one side it talks to the Metering Process(es) to grab Flow Records, and on the other side it talks to a Collecting Process on the Collector(s) 💜
There may be extra rules set up inside an Observation Domain so that only certain Flow Records get exported. This can be done with Si, Fi, or a mix of both, as described in Section 5.3, "Selection Criteria for Packets" ✨
Example: only the Flow Records that meet these criteria get exported 🍓
- All Flow Records whose destination IP address matches
{192.0.33.5}. - Every other (i.e., sampling rate 1 in 2) Flow Record whose destination IP address matches
{192.0.11.30}.
5.6. Collecting Process 🧚
Collecting Processes use a Flow Record's Template ID to figure out that record's Information Elements, and that's the whole trick 🔥 So an IPFIX Exporter must make sure the IPFIX Collector knows the Template ID for each incoming Flow Record. To interpret incoming Flow Records, an IPFIX Collector may also need to know the function F() that the Metering Process used for each Flow 🌈
The functions of the Collecting Process must include:
- Identifying, accepting, and decoding the IPFIX Messages from different
<Exporting Process, Observation Domain>pairs. - Storing the Control Information and Flow Records received from an IPFIX Device.
At a high level, the Collecting Process does two things:
- Receives and stores the Control Information.
- Decodes and stores the Flow Records using the Control Information.
5.7. Summary 🌸
This figure shows the functions that the different functional blocks in an IPFIX Device perform, in sequence 👑
Packet(s) coming into Observation Point(s)
| |
v v
+----------------+-------------------------+ +-----+-------+
| Metering Process on an | | |
| Observation Point | | |
| | | |
| packet header capturing | | |
| | | | |
| timestamping |...| Metering |
| | | | Process N |
| | | | |
| +----->+ | | |
| | | | | |
| | sampling Si (1:1 in case of no | | |
| | | sampling) | | |
| | filtering Fi (select all when | | |
| | | no criteria) | | |
| +------+ | | |
| | | | | |
| | | Timing out Flows | | |
| | | Handle resource overloads | | |
+--------|---------------------------------+ +-----|-------+
| |
Flow Records (identified by Observation Domain) Flow Records
| |
+---------+---------------------------------+
|
+--------------------|----------------------------------------------+
| | Exporting Process |
|+-------------------|-------------------------------------------+ |
|| v IPFIX Protocol | |
||+-----------------------------+ +----------------------------+| |
|||Rules for | |Functions || |
||| Picking/sending Templates | |-Packetise selected Control || |
||| Picking/sending Flow Records|->| & data Information into || |
||| Encoding Template & data | | IPFIX export packets. || |
||| Selecting Flows to export(*)| |-Handle export errors || |
||+-----------------------------+ +----------------------------+| |
|+----------------------------+----------------------------------+ |
| | |
| exported IPFIX Messages |
| | |
| +------------+-----------------+ |
| | Anonymise export packet(*) | |
| +------------+-----------------+ |
| | |
| +------------+-----------------+ |
| | Transport Protocol | |
| +------------+-----------------+ |
| | |
+-----------------------------+-------------------------------------+
|
v
IPFIX export packet to Collector(*) indicates that the block is optional.
Figure 4: IPFIX Device functional blocks 🎀
6. Overview of the IPFIX Protocol 🦋
An IPFIX Device is a set of cooperating processes that implement the functional blocks from the last section 💖 Or, if you want a simpler way to look at it, an IPFIX Device is just a network entity that implements the IPFIX protocol ✨ The protocol stuff lives in the Exporting Process. The IPFIX Exporting Process gets Flow Records from a Metering Process and sends them to the Collector(s) 💅
At a high level, an IPFIX Device does four things:
- Encodes Control Information into Templates.
- Encodes packets observed at the Observation Points into Flow Records.
- Packetises the selected Templates and Flow Records into IPFIX Messages.
- Sends IPFIX Messages to the Collector.
The IPFIX protocol carries information from an IPFIX Exporter to an IPFIX Collector 🌈 That info isn't just Flow Records. It also includes stuff about the Metering Process, which is called Control Information. Control Information covers the details of the data fields in Flow Records, and it can also include Metering Process statistics, like how many packets were lost (i.e., not metered) 😭
For the full details of the IPFIX protocol, check out RFC 5101 [3] 🫶
6.1. Information Model Overview 🧚
IPFIX is all about transmitting information about measured IP traffic over the Internet 🌊 The protocol spec in RFC 5101 [3] defines how Information Elements get transmitted. It also specifies how a set of basic data types gets encoded for those elements. But the actual list of fields you can send, like Flow attributes (source IP address, number of packets, etc.) and info about the Metering and Exporting Process (packet Observation Point, sampling rate, Flow timeout interval, etc.), isn't in RFC 5101 [3] at all 💀 That list is defined in the IPFIX information model in RFC 5102 [2] 💜
The information model gives a complete description of every IPFIX Information Element's properties. It does this by listing each element's name, Field Type, data type, etc., and giving a description of each one. The descriptions explain the semantics of the element, meaning how it's derived from a Flow or other information available within an IPFIX Device 🍓
6.2. Flow Records 🌸
These rules are the guidelines to follow when encoding the Flow Records information 💅
A Flow Record contains enough information so that the Collecting Process can identify the matching <Per-Flow Control Information, Configuration Control Information> 🔥
The Exporting Process encodes a given Information Element (as specified in RFC 5102 [2]) based on the encoding standards laid out in RFC 5101 [3] ✨
6.3. Control Information 👑
These rules are the guidelines to follow when encoding the Control Information 🎀
- Per-Flow Control Information should be encoded so that the Collecting Process can capture the structure and semantics of the matching Flow data for each of the Flow Records exported by the IPFIX Device.
- Configuration Control Information is sent to a Collector so that its Collecting Process can capture the structure and semantics of the matching configuration data. The configuration data, which is also Control Information, should carry extra info about the Observation Domain where the configuration takes effect.
For example, say the same sampling algorithm, 1 in 100 packets, is configured on two Observation Points O1 and O2 🦋 That configuration may be encoded as {ID, observation points (O1,O2), sampling algorithm, interval (1 in 100)}, where ID is the Observation Domain ID for the domain containing O1 and O2. The Observation Domain ID uniquely identifies this configuration, and it must be sent within the Flow Records so the right configuration control information can be matched 🧚
The Collecting Process uses Control Information to:
- Decode and interpret Flow Records.
- Understand the state of the Exporting Process.
Sending Control Information from the Exporting Process in a timely and reliable way is critical to the proper functioning of the IPFIX Collecting Process 😭 There are a few approaches for exporting Control Information:
- Send all the Control Information pertaining to Flow Records before sending the Flow Records themselves. This includes any incremental changes to the definition of the Flow Records.
- Notify the Collecting Process, on a near real-time basis, of the state of the IPFIX Device. This includes all changes that the Collector needs to know about, like a configuration change that affects Flow behaviour, or changes to Exporting Process resources that alter export rates, etc. 🌈
- Since a Collecting Process has to keep accurate knowledge of the Exporter's state, the export of Control Information should reach the Collector reliably. One way to do that is to send the Control Information over a reliable transport 🫶
6.4. Reporting Responsibilities
okay bestie, so sometimes an IPFIX Device just can't observe every single packet hitting one of its Observation Points 😭 that can happen when a Metering Process is running on fumes and temporarily short of resources 🪫. for example, it might run out of packet buffers for IPFIX export. rip 💀
so in those moments, the IPFIX Device should try to count how many packet losses happened 🔢 and then report them to its Collector(s) 📩. but if it can't count the losses accurately (like when it detects transport layer errors, which are the non-IPFIX kind 👀), the IPFIX Device should at least report that fact, and maybe mention the time period when some packets might not have been observed ⏰. transparency is everything 🫶
7. IPFIX Protocol Details
ok so when the IPFIX Working Group got chartered, there were already some common practices for Flow export floating around 🌸 like NetFlow, CRANE (Common Reliable Accounting for Network Element), LFAP (Light-weight Flow Admission Protocol), RTFM (Real-time Traffic Flow Measurement), and more. the charter basically said the Working Group had to look at those existing practices and pick the one that was the closest fit to the IPFIX requirements in RFC 3917 [1] 🎯. then they'd tweak or add stuff to that protocol so it fit exactly into the IPFIX architecture 💅
7.1. The IPFIX Basis Protocol
the Working Group did a seriously thorough evaluation of the available protocols 🧐 weighing how well each one met the requirements, and then picked one candidate as the basis for IPFIX. if you want the full tea on that process, check out RFC 3955 [6] ☕
in the basis protocol, Flow Records are defined by Templates 📋. a Template is an ordered set of the Information Elements that show up in a Flow Record, along with their field sizes inside those records. iconic structure, no notes 💖
this approach gives us the following perks:
- using the Template mechanism, new fields can be added to IPFIX Flow Records without changing the structure of the export record format ✨
- Templates that get sent to the Collecting Process carry structural information about the exported Flow Record fields 🗂️. so if the Collector doesn't understand the semantics of a new field, it can ignore it and still interpret the Flow Record. no crashing, no drama 🫠
- because the template mechanism is so flexible, it lets you export only the required fields from the Flows to the Collecting Process 🎀. this helps reduce the exported Flow data volume and could possibly save memory at the Exporting Process and Collecting Process 🧠. sending only the info you need can also reduce network load 🌊
7.2. IPFIX Protocol on the Collecting Process
the Collecting Process has two main jobs 💼:
- receiving and decoding Flow Records from the IPFIX Devices.
- reporting on the loss of Flow Records sent to the Collecting Process by an IPFIX Exporting Process 📉.
the complete details of the IPFIX protocol live in RFC 5101 [3] 📖 go get 'em, bestie
7.3. Support for Applications
the info collected by IPFIX can be used by stuff like Billing or Intrusion Detection sub-systems, etc. 💸🚨 these applications might be an integral part of the Collecting Process, or they might just be co-located with it 🏠. how these applications interface with IPFIX systems to get the info they want is out of scope for this document, so we're not getting into it here 🙅♀️
8. Export Models
8.1. Export with Reliable Control Connection
as mentioned in RFC 3917 [1] 🔁, an IPFIX Device must be able to transport its Control Information and Data Stream over a congestion-aware transport protocol 🚦.
if the network that the IPFIX Device and Collecting Process are in doesn't guarantee reliability, then at least the Control Information should be exported over a reliable transport 🔒. the Data Stream may be exported over a reliable or an unreliable transport protocol, totally up to you 🤷♀️
possible transport protocols include:
- SCTP: supports reliable and unreliable transport. ✨
- TCP: provides reliable transport only. 🧱
- UDP: provides unreliable transport only. network operators would need to avoid congestion by keeping traffic within their own administrative domains 🏰. for example, one could use a dedicated network (or Ethernet link) to carry IPFIX traffic from Exporter to Collector 🛤️
8.2. Collector Failure Detection and Recovery
the transport connection (when it's a connection-oriented protocol) is pre-configured between the IPFIX Device and the Collector 🔗. the IPFIX protocol doesn't provide any mechanism for configuring the Exporting and Collecting Processes, so that setup happens outside of it 🙃
once connected, an IPFIX Collector receives Control Information and uses that info to interpret Flow Records 🧩. the IPFIX Device should set a keepalive (for example, the keepalive timeout in the case of TCP, or the HEARTBEAT interval in the case of SCTP) to a sufficiently low value, so it can quickly detect a Collector failure 👀. BUT note, extremely short keepalive intervals can incorrectly abort the connection during transient periods of congestion 😬. they can also cause some additional network load during otherwise idle periods 📶. so it's a balancing act, bestie ⚖️
a Collector failure refers to the crash or restart of the Collecting Process or of the Collector itself 💥. the IPFIX Device detects a Collector failure through the break in the connection-oriented transport protocol session 🔌. depending on the transport protocol, the connection timeout mechanisms are different 🕰️. when the IPFIX Device detects a keepalive timeout in a single Collector scenario, it should stop sending Flow Records to the Collector and try to reestablish the transport connection 🔄. if Collecting Process failover is supported by the Exporting Process, backup session(s) may be opened in advance, and Control Information can be sent to the failover Collecting Process 🛟
there could be one or more secondary Collectors with priorities assigned to them 🥇🥈. the primary Collector crash gets detected at the IPFIX Device. when it notices loss of connectivity, the IPFIX Device opens a Data Stream with the secondary Collector of the next highest priority 📈. if that secondary wasn't opened in advance, both the Control Information and Data Stream must be sent to it 📦. that Collector might then become the primary, or the Exporting Process might try to reestablish the original session 🔁
8.3. Collector Redundancy
configuring redundant Collectors is an alternative to configuring backup Collectors 👯♀️. in this model, all Collectors simultaneously receive the Control Information and Data Streams 📡. multiple {Control Information, Data Stream} pairs could be sent, each to a different Collector, from the same IPFIX Device 🌈. and since the IPFIX protocol requires a congestion-aware transport, achieving redundancy using multicast is not an option 🚫 sorry multicast fans 😭
9. IPFIX Flow Collection in Special Situations
an IPFIX Device can generate, receive, and/or alter two special types of traffic 🎭, which are listed below:
Tunnel traffic: the IPFIX Device could be the head, midpoint, or end-point of a tunnel 🚇. in those cases, the IPFIX Device could be handling Generic Routing Encapsulation (GRE) [8], IPinIP [7], or Layer Two Tunneling Protocol version 3 [9] traffic 🧁
VPN traffic: the IPFIX Device could be a provider-edge device that receives traffic from customer sites belonging to different Virtual Private Networks 🏢
similarly, IPFIX could be implemented on devices that do one or more of the following special services:
- explicitly drop packets. for example, a device that provides firewall service drops packets based on some administrative policy 🧱🔥
- alter the values of fields used as IPFIX Flow Keys of interest. for example, a device that provides NAT service can change the source and/or destination IP address 🔀
in cases like those listed above, there should be clear guidelines as to:
- how and when to classify the packets as Flows in the IPFIX Device 🗃️
- if multiple encapsulations are used to define Flows, how to convey the same fields (e.g., IP address) in different layers 🧅
- how to differentiate Flows based on different private domains, for example, overlapping IP addresses in Layer-3 VPNs 🫣
- what extra information needs to be exported so that the Collector can make a clear interpretation of the received Flow Records 🔍
10. Security Considerations
okay this section is SERIOUS, bestie, so pay attention 🚨🔐 Flow information can be used for all kinds of things, like usage-based accounting, traffic profiling, traffic engineering, and intrusion detection 🕵️♀️. the security requirements can differ a lot between those applications. so to meet the security needs of all the different IPFIX users, an IPFIX system must provide different levels of security protection 🛡️👑
10.1. Data Security
IPFIX data is made up of Control Information and Data Streams generated by the IPFIX Device 📦.
the IPFIX data may exist in both the IPFIX Device and the Collector 💾. on top of that, the data also gets transferred on the wire from the IPFIX Device to the Collector when it's exported 🛰️. to keep it safe, the data should be protected from common network attacks 🥷
the protection of IPFIX data within the end system (IPFIX Device and Collector) is out of scope for this document 🙅♀️. it's assumed that the end system operator will provide adequate security for the IPFIX data 🤝
the IPFIX architecture must allow different levels of protection for the IPFIX data on the wire 🎚️. wherever security functions are required, it is recommended that users leverage lower layers using either TLS or DTLS (Datagram Transport Layer Security), if these can successfully satisfy the security requirement of IPFIX data protection 🔐💜
to protect the data on the wire, three levels of granularity should be supported 🥉🥈🥇. they're described in the following subsections 👇
10.1.1. Host-Based Security
security may not be required when the transport between the IPFIX Device and the Collector is perceived as safe 🏡. this option lets the protocol run most efficiently without extra overhead, and an IPFIX system must support it 🏎️💨
10.1.2. Authentication-Only
authentication-only protection gives IPFIX users the assurance of data integrity and authenticity ✅. the data exchanged between the IPFIX Device and the Collector is protected by an authentication signature ✍️. any modification of the IPFIX data will be detected by the recipient, which results in the received data being discarded 🗑️. BUT the authentication-only option doesn't offer data confidentiality, so anyone can read it 👀
the IPFIX user should not use authentication-only when sensitive or confidential information is being exchanged 🚫🙈 an IPFIX solution should support this option, though. the authentication-only option should provide replay attack protection 🔁🛑. some means to achieve this level of security are:
- Encapsulating Security Payload (with a null encryption algorithm) 🔏
- Transport Layer Security (with a null encryption algorithm) 🧷
- IP Authentication Header 🪪
10.1.3. Encryption
okay bestie, encryption is the GOAT of IPFIX protection 🔐✨ the IPFIX data gets scrambled at the sender, and only the intended recipient can unscramble it and actually see what's inside 👀💅 this option must be used when the transport between the IPFIX Device and the Collector is unsafe and the IPFIX data needs to be protected 😭 it is recommended that the underlying transport layer's security functions be used for this purpose. some ways to get this level of security:
- Encapsulating Security Payload
- Transport Layer Security Protocol
the data encryption option adds overhead to the IPFIX data transfer 🥲 it may limit the rate that an Exporter can report its Flow Records to the Collector, because running encryption takes up resources. that's the price of the glow-up 🫶
10.2. IPFIX End-Point Authentication
it is important to make sure that the IPFIX Device is talking to the "right" Collector and not some masquerading Collector 🎭 this goes both ways 🦋 the Collector may want to make sure it's collecting Flow Records from the "right" IPFIX Device too. an IPFIX system should allow end-point authentication so that either one-way or mutual authentication can be performed between the IPFIX Device and Collector 🔥
the IPFIX architecture should use any existing transport protection protocols, such as TLS, to fulfil the authentication requirement 🌸
10.3. IPFIX Overload
an IPFIX Device could become overloaded under various conditions 🫠 this may happen because internal resources used for Flow generation and/or export have run out. overloading like this can cause loss of data from the Exporting Process, either from a lack of export bandwidth (possibly because an unusually high number of Flows was observed) or from network congestion on the path from Exporter to Collector 🚧
IPFIX Collectors should be able to detect the loss of exported Flow Records, and should at least record the number of lost Flow Records 📝✨
10.3.1. Denial-of-Service (DoS) Attack Prevention
okay so intrusion detection is one of the big jobs IPFIX might have 🕵️♀️ which means the IPFIX architecture needs to support some kind of DoS resistance. it's giving security-main-character energy 👑
10.3.1.1. Network under Attack
the network itself might be under attack, which can result in an overwhelming number of IPFIX Messages 😱 an IPFIX system should try to capture as much information as possible. but when a large number of IPFIX Messages are generated in a short period of time, the IPFIX system may become overloaded 💀
10.3.1.2. Generic DoS Attack on the IPFIX Device and Collector
the IPFIX Device and Collector may be hit by generic DoS attacks, just like any system on any open network 🙃 these types of attacks are not IPFIX specific. preventing and responding to them is out of the scope of this document, so that's a different slay 🧚
10.3.1.3. IPFIX-Specific DoS Attack
there are some specific attacks aimed at the IPFIX portion of the IPFIX Device or Collector 🚨
- The attacker could overwhelm the Collector with spoofed IPFIX Export packets. One way to solve this problem is to periodically synchronise the sequence numbers of the Flow Records between the Exporting and Collecting Processes.
- The attacker could provide false reports to the Collector by sending spoofed packets.
the problems above can be solved to a large extent if the control packets are encrypted both ways 🔒 that gives the Collector more information to identify and ignore spoofed data packets. literally the best defense energy 💖
11. IANA Considerations
the IPFIX Architecture, as set out in this document, has two sets of assigned numbers, as outlined in the following subsections 🎀
11.1. Numbers Used in the Protocol
IPFIX Messages, as described in RFC 5101 [3], use two fields with assigned values 🌈 these are the IPFIX Version Number, which indicates which version of the IPFIX Protocol was used to export an IPFIX Message, and the IPFIX Set ID, which indicates the type for each set of information within an IPFIX Message.
the values for the IPFIX Version Number and the IPFIX Set ID, together with the considerations for assigning them, are defined in RFC 5101 [3] 📚
11.2. Numbers Used in the Information Model
fields of the IPFIX protocol carry information about traffic measurement 📊 they are modelled as elements of the IPFIX information model in RFC 5102 [2]. each Information Element describes a field that may appear in an IPFIX Message. within an IPFIX Message, the field type is indicated by its Field Type 🧠
the values for the IPFIX Information Element IDs, together with the considerations for assigning them, are defined in RFC 5102 [2] 🦋
12. Acknowledgements
the document editors wish to thank everyone who contributed to the discussion of this document on the mailing list, and the design teams for many valuable comments 🫶 the following people made significant contributions:
- Tanja Zseby
- Paul Calato
- Dave Plonka
- Jeffrey Meyer
- K.C.Norseth
- Vamsi Valluri
- Cliff Wang
- Ram Gopal
- Jc Martin
- Carter Bullard
- Reinaldo Penno
- Simon Leinen
- Kevin Zhang
- Paul Aitken
- Brian Trammell
special thanks to Dave Plonka for the multiple thorough reviews 🌈👑
13. References
13.1. Normative References
- [1] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.
- [2] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information for Model IP Flow Information Export", RFC 5102, January 2008.
- [3] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
- [4] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IPFIX Applicability", RFC 5472, March 2009.
13.2. Informative References
- [5] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
- [6] Leinen, S., "Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX)", RFC 3955, October 2004.
- [7] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
- [8] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
- [9] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
Authors' Addresses
Ganesh Sadasivan
Rohati Systems
1192 Borregas Ave.
Sunnyvale, CA 94089
USA
EMail: gsadasiv@rohati.com
Nevil Brownlee
CAIDA | The University of Auckland
Private Bag 92019
Auckland 1142
New Zealand
Phone: +64 9 373 7599 x88941
EMail: n.brownlee@auckland.ac.nz
Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
1831 Diegem
Belgium
Phone: +32 2 704 5622
EMail: bclaise@cisco.com
Juergen Quittek
NEC Laboratories Europe, NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 6221 4342-115
EMail: quittek@nw.neclab.eu
URI: http://www.neclab.eu/📦 where this page comes from
- ietf: rfc5470 2009-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms