RFC 5101
Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information
Hey bestie, welcome to RFC 5101 🎀
Okay so this one is the official spec for IPFIX (IP Flow Information Export) 💅 and it's giving "how do computers tell each other about internet traffic without being confusing" energy 🦋 It's from the Network Working Group, and B. Claise, Ed. wrote it while at Cisco Systems, Inc. (the "Ed." just means they were the editor 📝). It's a Standards Track doc, dated January 2008 🌸 Also, the title block doesn't list any RFCs it obsoletes or updates, so this one is standing on its own 👑 This is part 1 of 13 ✨
Status of This Memo 🧾
Okay, this bit is the paperwork, but it matters! This is an Internet standards track protocol for the Internet community, and it's literally asking people to talk about it and suggest improvements 🫶 For the current standardization state and status, you check the "Internet Official Protocol Standards" (STD 1) doc. And distribution is unlimited, so share it with everyone 🌈
Abstract 🦋
Okay so the whole point is that IPFIX is the protocol for sending IP Traffic Flow information across the network 🌐 To get that info from an Exporting Process to an information Collecting Process, you need two things: a common representation of flow data (so everyone speaks the same language 🗣️) and a standard way of communicating it 📡 This doc explains how IPFIX Data and Template Records get carried over a bunch of different transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. It's giving main character energy 👑
Table of Contents 📚
Network Working Group B. Claise, Ed.Wait, bestie, let me fix that, the TOC is what I actually meant 🙈 Here it is, copied exactly:
1. Introduction ....................................................3
1.1. IPFIX Documents Overview ...................................4
2. Terminology .....................................................4
2.1. Terminology Summary Table ..................................9
3. IPFIX Message Format ...........................................10
3.1. Message Header Format .....................................11
3.2. Field Specifier Format ....................................13
3.3. Set and Set Header Format .................................14
3.3.1. Set Format .........................................14
3.3.2. Set Header Format ..................................15
3.4. Record Format .............................................16
3.4.1. Template Record Format .............................16
3.4.2. Options Template Record Format .....................18
3.4.2.1. Scope .....................................19
3.4.2.2. Options Template Record Format ............20
3.4.3. Data Record Format .................................22
4. Specific Reporting Requirements ................................23
4.1. The Metering Process Statistics Option Template ...........23
4.2. The Metering Process Reliability Statistics Option
Template ..................................................24
4.3. The Exporting Process Reliability Statistics
Option Template ...........................................25
4.4. The Flow Keys Option Template .............................26
5. IPFIX Message Header "Export Time" and Flow Record Time ........27
6. Linkage with the Information Model .............................28
6.1. Encoding of IPFIX Data Types ..............................28
6.1.1. Integral Data Types ................................28
6.1.2. Address Types ......................................28
6.1.3. float32 ............................................28
6.1.4. float64 ............................................28
6.1.5. boolean ............................................28
6.1.6. string and octetarray ..............................28
6.1.7. dateTimeSeconds ....................................29
6.1.8. dateTimeMilliseconds ...............................29
6.1.9. dateTimeMicroseconds ...............................29
6.1.10.dateTimeNanoseconds.................................29
6.2. Reduced Size Encoding of Integer and Float Types ..........29
7. Variable-Length Information Element ............................30
8. Template Management ............................................31
9. The Collecting Process's Side ..................................34
10. Transport Protocol ............................................36
10.1. Transport Compliance and Transport Usage .................36
10.2. SCTP .....................................................37
10.2.1. Congestion Avoidance ..............................37
10.2.2. Reliability .......................................37
10.2.3. MTU ...............................................37
10.2.4. Exporting Process .................................38
10.2.4.1. Association Establishment ................38
10.2.4.2. Association Shutdown .....................38
10.2.4.3. Stream ...................................38
10.2.4.4. Template Management ......................39
10.2.5. Collecting Process ................................39
10.2.6. Failover ..........................................39
10.3. UDP ......................................................39
10.3.1. Congestion Avoidance ..............................39
10.3.2. Reliability .......................................40
10.3.3. MTU ...............................................40
10.3.4. Port Numbers ......................................40
10.3.5. Exporting Process .................................40
10.3.6. Template Management ...............................40
10.3.7. Collecting Process ................................41
10.3.8. Failover ..........................................42
10.4. TCP ......................................................42
10.4.1. Connection Management .............................42
10.4.1.1. Connection Establishment .................42
10.4.1.2. Graceful Connection Release ..............43
10.4.1.3. Restarting Interrupted Connections .......43
10.4.1.4. Failover .................................43
10.4.2. Data Transmission .................................43
10.4.2.1. IPFIX Message Encoding ...................43
10.4.2.2. Template Management ......................44
10.4.2.3. Congestion Handling and Reliability ......44
10.4.3. Collecting Process ................................45
11. Security Considerations .......................................46
11.1. Applicability of TLS and DTLS ............................47
11.2. Usage ....................................................48
11.3. Authentication ...........................................48
11.4. Protection against DoS Attacks ...........................48
11.5. When DTLS or TLS Is Not an Option ........................50
11.6. Logging an IPFIX Attack ..................................50
11.7. Securing the Collector ...................................51
12. IANA Considerations ...........................................51
Appendix A. IPFIX Encoding Examples ...............................52
A.1. Message Header Example.....................................52
A.2. Template Set Examples......................................53
A.2.1. Template Set Using IETF-Specified Information
Elements ...........................................53
A.2.2. Template Set Using Enterprise-Specific Information
Elements ...........................................53
A.3. Data Set Example ..........................................55
A.4. Options Template Set Examples .............................56
A.4.1. Options Template Set Using IETF-Specified
Information Elements ...............................56
A.4.2. Options Template Set Using Enterprise-Specific
Information Elements ...............................56
A.4.3. Options Template Set Using an Enterprise-Specific
Scope ..............................................57
A.4.4. Data Set Using an Enterprise-Specific Scope ........58
A.5. Variable-Length Information Element Examples ..............59
A.5.1. Example of Variable-Length Information Element
with Length Inferior to 255 Octets .................59
A.5.2. Example of Variable-Length Information Element
with Length 255 to 65535 Octets ....................59
References ........................................................59
Normative References ...........................................59
Informative References .........................................60
Acknowledgments ...................................................611. Introduction ✨
Okay so picture a data network full of IP traffic. Mostly, it's just IP flows zooming through the network elements 🚀 Sometimes it's super interesting, useful, or even required to peek at info about those flows, for admin stuff or other purposes 👀 The IPFIX Collecting Process should be able to receive flow info from multiple network elements across the whole data network 💖 But that only works if everyone represents flow info the same way and has a shared method for sending flows from the network elements to the collection point 🤝 This doc is the protocol that makes all of that happen 💅 It goes deep on how different flows get represented, what extra data you need to interpret them, the packet format, the transport mechanisms, security concerns, and more 🔐
1.1. IPFIX Documents Overview 🎀
The IPFIX protocol is what gives network admins access to IP flow info 🌸 The architecture for exporting measured IP flow info from an IPFIX Exporting Process to a Collecting Process is defined in [IPFIX-ARCH], following the requirements in [RFC3917] 📐 This doc specifies how IPFIX data records and templates get carried over a bunch of transport protocols, from IPFIX Exporting Processes to IPFIX Collecting Processes 🚚 IPFIX also has a formal description of IPFIX Information Elements, with their name, type, and extra semantic info, as specified in [RFC5102] 🧠 And finally, [IPFIX-AS] tells you 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 🧚
2. Terminology ✨
okay bestie, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read the way [RFC2119] describes 🧚
The basic terms, like IP Traffic Flow, Exporting Process, Collecting Process, Observation Points and so on, mean the same thing as they do in the IPFIX requirements document [RFC3917] 💜 A few of them got expanded so the protocol part makes more sense, and some brand new ones were added just for the protocol. The definitions here and in [IPFIX-ARCH] are equivalent. The only difference is that anything that only matters to the IPFIX protocol shows up here 🎀
The terminology summary table in Section 2.1 is a quick cheat sheet for how the different terms connect to each other 🦋
Observation Point
An Observation Point is a location in the network where IP packets can be observed. Examples include: a line to which a probe is attached, a shared medium, such as an Ethernet-based LAN, a single port of a router, or a set of interfaces (physical or logical) of a router. 🌸
Every Observation Point is associated with an Observation Domain (defined below), and one Observation Point can be a superset of several other Observation Points. For example, one Observation Point can be an entire line card. That would be the superset of the individual Observation Points at the line card's interfaces. 🫶
Observation Domain
An Observation Domain is the largest set of Observation Points for which Flow information can be aggregated by a Metering Process. For example, a router line card may be an Observation Domain if it is composed of several interfaces, each of which is an Observation Point. ✨
In the IPFIX Message it generates, the Observation Domain includes its Observation Domain ID, which is unique per Exporting Process. That way, the Collecting Process can identify the specific Observation Domain from the Exporter that sends the IPFIX Messages. Every Observation Point is associated with an Observation Domain. It is RECOMMENDED that Observation Domain IDs also be unique per IPFIX Device. 🔥
IP Traffic Flow or Flow
There are several definitions of the term 'flow' floating around the Internet community. Within the context of IPFIX, we use the following definition: 💅
A Flow is defined as a set of IP packets passing an Observation Point in the network during a certain time interval. All packets belonging to a particular Flow have a set of common properties. Each property is defined as the result of 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 [RFC3550]).
- one or more characteristics of the packet itself (e.g., number of MPLS labels, etc...).
- one or more of fields derived from packet treatment (e.g., next hop IP address, the output interface, etc...).
A packet is defined as belonging to a Flow if it completely satisfies all the defined properties of the Flow. 👑
This definition covers the whole range, from a Flow containing all packets observed at a network interface to a Flow consisting of just a single packet between two applications. It includes packets selected by a sampling mechanism. 🌈
Flow Key
Each of the fields that:
- belong to the packet header (e.g., destination IP address),
- are a property of the packet itself (e.g., packet length),
- are derived from packet treatment (e.g., Autonomous System (AS) number),
and that are used to define a Flow are termed Flow Keys. 🍓
Flow Record
A Flow Record contains information about a specific Flow that was observed at an Observation Point. A Flow Record contains measured properties of the Flow (e.g., the total number of bytes for all the Flow's packets) and usually characteristic properties of the Flow (e.g., source IP address). 📊
Metering Process
The Metering Process generates Flow Records. Its inputs are packet headers and characteristics observed at an Observation Point, plus packet treatment at the Observation Point (for example, the selected output interface). 🧚
The Metering Process is a set of functions that includes packet header capturing, timestamping, sampling, classifying, and maintaining Flow Records. 🎀
Maintaining Flow Records may include 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. Lots going on, no cap 😭
Exporting Process
The Exporting Process sends Flow Records to one or more Collecting Processes. The Flow Records are generated by one or more Metering Processes. 🦋
Exporter
A device that hosts one or more Exporting Processes is termed an Exporter. 💖
IPFIX Device
An IPFIX Device hosts at least one Exporting Process. It may host further Exporting Processes and arbitrary numbers of Observation Points and Metering Processes. 🌸
Collecting Process
A Collecting Process receives Flow Records from one or more Exporting Processes. The Collecting Process might process or store received Flow Records, but those actions are out of scope for this document. 🫶
Collector
A device that hosts one or more Collecting Processes is termed a Collector. ✨
Template
A Template is an ordered sequence of <type, length> pairs 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 is uniquely identifiable by means of a Template ID. 🔥
IPFIX Message
An IPFIX Message is a message originating at the Exporting Process that carries the IPFIX records of this Exporting Process and whose destination is a Collecting Process. An IPFIX Message is encapsulated at the transport layer. 💅
Message Header
The Message Header is the first part of an IPFIX Message. It provides basic information about the message, such as the IPFIX version, length of the message, message sequence number, etc. 👑
Template Record
A Template Record defines the structure and interpretation of fields in a Data Record. 🌈
Data Record
A Data Record is a record that contains values of the parameters corresponding to a Template Record. 🍓
Options Template Record
An Options Template Record is a Template Record that defines the structure and interpretation of fields in a Data Record, including defining how to scope the applicability of the Data Record. 🧚
Set
Set is a generic term for a collection of records that have a similar structure. In an IPFIX Message, one or more Sets follow the Message Header. 🎀
There are three different types of Sets: Template Set, Options Template Set, and Data Set. 🦋
Template Set
A Template Set is a collection of one or more Template Records that have been grouped together in an IPFIX Message. 💖
Options Template Set
An Options Template Set is a collection of one or more Options Template Records that have been grouped together in an IPFIX Message. 🌸
Data Set
A Data Set is one or more Data Records, of the same type, that are grouped together in an IPFIX Message. Each Data Record is previously defined by a Template Record or an Options Template Record. 📊
Information Element
An Information Element is a protocol and encoding-independent description of an attribute that may appear in an IPFIX Record. The IPFIX information model [RFC5102] defines the base set of Information Elements for IPFIX. The type associated with an Information Element indicates constraints on what it may contain and also determines the valid encoding mechanisms for use in IPFIX. 🫶
Transport Session
In Stream Control Transmission Protocol (SCTP), the transport session is known as the SCTP association, which is uniquely identified by the SCTP endpoints [RFC4960]. In TCP, the transport session is known as the TCP connection, which is uniquely identified by the combination of IP addresses and TCP ports used. In UDP, the transport session is known as the UDP session, which is uniquely identified by the combination of IP addresses and UDP ports used. ✨
2.1. Terminology Summary Table 🎀
+------------------+---------------------------------------------+
| | contents |
| +--------------------+------------------------+
| Set | Template | record |
+------------------+--------------------+------------------------+
| Data Set | / | Data Record(s) |
+------------------+--------------------+------------------------+
| Template Set | Template Record(s) | / |
+------------------+--------------------+------------------------+
| Options Template | Options Template | / |
| Set | Record(s) | |
+------------------+--------------------+------------------------+Figure A: Terminology Summary Table 🦋
A Data Set is composed of Data Record(s). No Template Record is included. A Template Record or an Options Template Record defines the Data Record. 💅
A Template Set contains only Template Record(s). 🌈
An Options Template Set contains only Options Template Record(s). 🍓
3. IPFIX Message Format ✨
okay so an IPFIX Message is basically a Message Header followed by one or more Sets 🎀 and each Set can be one of three types: a Data Set, a Template Set, or an Options Template Set. the vibe is very layered, ngl 🧚
the overall shape is in Figure B 👇
+----------------------------------------------------+
| Message Header |
+----------------------------------------------------+
| Set |
+----------------------------------------------------+
| Set |
+----------------------------------------------------+
...
+----------------------------------------------------+
| Set |
+----------------------------------------------------+Figure B: IPFIX Message Format
bestie, the Exporter MUST code all binary integers of the Message Header and the different Sets in network-byte order (also known as the big-endian byte ordering) 💅 no exceptions, no vibes-based byte order 😭
here are some examples of IPFIX Messages, and they're so iconic 🌈
- An IPFIX Message with interleaved Template, Data, and Options Template Sets 🦋 a newly created Template gets exported as soon as possible. so if there's already an IPFIX Message with a Data Set being prepped for export, the Template and Options Template Sets get interleaved right in with that info, as long as there's space for them 🫶
+--------+--------------------------------------------------------+
| | +----------+ +---------+ +-----------+ +---------+ |
|Message | | Template | | Data | | Options | | Data | |
| Header | | Set | | Set | ... | Template | | Set | |
| | | | | | | Set | | | |
| | +----------+ +---------+ +-----------+ +---------+ |
+--------+--------------------------------------------------------+Figure C: IPFIX Message, Example 1
- An IPFIX Message made entirely of Data Sets 💖 once the right Template Records have been defined and sent to the Collecting Process, most IPFIX Messages are just Data Sets. the main character era 👑
+--------+----------------------------------------------+
| | +---------+ +---------+ +---------+ |
|Message | | Data | | Data | | Data | |
| Header | | Set | ... | Set | ... | Set | |
| | +---------+ +---------+ +---------+ |
+--------+----------------------------------------------+Figure D: IPFIX Message, Example 2
- An IPFIX Message made entirely of Template and Options Template Sets 🍓
+--------+-------------------------------------------------+
| | +----------+ +----------+ +----------+ |
|Message | | Template | | Template | | Options | |
| Header | | Set | ... | Set | ... | Template | |
| | | | | | | Set | |
| | +----------+ +----------+ +----------+ |
+--------+-------------------------------------------------+Figure E: IPFIX Message, Example 3
3.1. Message Header Format
the Message Header has the layout shown in Figure F 🌸
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation Domain ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure F: IPFIX Message Header Format
Message Header Field Descriptions 🔥 here's the breakdown:
Version 💜 this is the version of the Flow Record format exported in this message. the value is 0x000a for the current version, which is the NetFlow services export version 9 [RFC3954] version number, incremented by one 🦋
Length 🌈 the total length of the IPFIX Message, measured in octets. this counts the Message Header and the Set(s) together ✨
Export Time ⭐ the time, in seconds since 0000 UTC Jan 1, 1970, at which the IPFIX Message Header leaves the Exporter 🕰️
Sequence Number 🫶 an incremental sequence counter, modulo 2^32, of all IPFIX Data Records sent on this PR-SCTP stream from the current Observation Domain by the Exporting Process. when UDP or TCP is the transport protocol, check the subsections of Section 10 for what this field means specifically 🎀 the Collecting Process SHOULD use this value to figure out whether any IPFIX Data Records got missed 😭 and Template and Options Template Records do NOT bump the Sequence Number, so they're not counted here 💅
Observation Domain ID 🧚 a 32-bit identifier for the Observation Domain, locally unique to the Exporting Process. the Exporting Process uses it to tell the Collecting Process exactly which Observation Domain metered the Flows 💖 it is RECOMMENDED that this identifier is also unique per IPFIX Device. Collecting Processes SHOULD use the Transport Session and the Observation Domain ID field together to separate different export streams coming from the same Exporting Process 🍓 the Observation Domain ID SHOULD be 0 when no specific Observation Domain ID is relevant for the whole IPFIX Message, like when exporting the Exporting Process Statistics, or when a hierarchy of Collectors is exporting aggregated Data Records 👑
3.2. Field Specifier Format
okay this part is so important bc vendors literally need to be able to make their own proprietary Information Elements 💅 maybe they're shipping a pre-standards product, or the Information Element is commercially sensitive, so keeping it private makes sense 🙈 this section explains the Field Specifier format for both IETF-specified Information Elements [RFC5102] and enterprise-specific Information Elements 🦋
the Information Elements get identified by their Information Element identifier. when the Enterprise bit is 0, the identifier points to an IETF-specified Information Element, and the Enterprise Number MUST NOT be present 🌸 when the Enterprise bit is 1, the identifier points to an enterprise-specific Information Element, and the Enterprise Number MUST be present 🫶 there's an example of this in Section A.4.2 ✨
the Field Specifier format is in Figure G 👇
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Information Element ident. | Field Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure G: Field Specifier Format
Where 🧚
E 💖 the Enterprise bit, which is the very first bit of the Field Specifier. if this bit is zero, the Information Element Identifier names an IETF-specified Information Element, and the four-octet Enterprise Number field MUST NOT be present. if this bit is one, the Information Element identifier names an enterprise-specific Information Element, and the Enterprise Number field MUST be present 🔥
Information Element identifier 🍓 a numeric value that represents the type of Information Element. refer to [RFC5102] for these 🌈
Field Length 🦋 the length of the corresponding encoded Information Element, in octets. refer to [RFC5102] for this one too 💅 the field length may be smaller than the definition in [RFC5102] if the reduced size encoding is used (see Section 6.2). the value 65535 is reserved for variable-length Information Elements (see Section 7) 🫶
Enterprise Number 👑 the IANA enterprise number [PEN] of the authority defining the Information Element identifier in this Template Record ✨
3.3. Set and Set Header Format
so a Set is a generic term for a collection of records that all share a similar structure 🎀 there are three types of Sets: Template Sets, Options Template Sets, and Data Sets. each one has a Set Header plus one or more records. the Set Format and the Set Header Format are defined in the following sections 🌸
3.3.1. Set Format
a Set has the format in Figure H. the records can be Template Records, Options Template Records, or Data Records, and bestie, the record types MUST NOT be mixed within a Set 🙅♀️ no mixing 💅
+--------------------------------------------------+
| Set Header |
+--------------------------------------------------+
| record |
+--------------------------------------------------+
| record |
+--------------------------------------------------+
...
+--------------------------------------------------+
| record |
+--------------------------------------------------+
| Padding (opt.) |
+--------------------------------------------------+Figure H: Set Format
The Set Field Definitions are as follows 🦋
Set Header ✨ the Set Header Format is defined in Section 3.3.2 🫶
Record 🌈 one of the record Formats: Template Record, Options Template Record, or Data Record Format 🍓
Padding 💖 the Exporting Process MAY insert some padding octets, so the next Set starts on an aligned boundary. and for security reasons, the padding octet(s) MUST be made of zero (0) valued octets 🔥 the padding length MUST be shorter than any allowable record in this Set. if you want padding for the whole IPFIX Message together with very short records, you can use the padding Information Element paddingOctets [RFC5102] to pad records so their length goes up to a multiple of 4 or 8 octets 🧚 and since Template Sets are always 4-octet aligned by definition, padding is only needed for other alignments, like 8-octet boundaries 👑
3.3.2. Set Header Format ✨
Okay so every Set comes with a common header, bestie 🎀 It's defined in Figure I, and it's giving clean and simple 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure I: Set Header Format
Here are the Set Header Field Definitions, so you know exactly what each field does 🦋
Set ID
The Set ID value identifies the Set. A value of 2 is reserved for the Template Set. A value of 3 is reserved for the Option Template Set. All other values from 4 to 255 are reserved for future use. Values above 255 are used for Data Sets. The Set ID values of 0 and 1 are not used for historical reasons [RFC3954]. Not me being like "why 0 and 1 are skipped" 💀 but that's the history 🌸
Length
This is the total length of the Set, in octets. It includes the Set Header, all records, and the optional padding. Here's the tea 🫖 Because an individual Set MAY contain multiple records, the Length value MUST be used to determine the position of the next Set. So you always read Length to find where the next Set starts, no guessing ✨
3.4. Record Format 📦
IPFIX defines three record formats, and we'll go through each of them in the next sections: the Template Record Format, the Options Template Record Format, and the Data Record Format. Three formats, three vibes 🧚
3.4.1. Template Record Format
Templates are one of the essential elements in the IPFIX record format, and they're honestly iconic 👑 They make the record format super flexible because they let the Collecting Process handle IPFIX Messages without needing to know how to interpret every single Data Record. A Template Record can hold any mix of IANA-assigned and/or enterprise-specific Information Elements identifiers. Main character energy for sure 💜
The Template Record is shown in Figure J. It's made of a Template Record Header plus one or more Field Specifiers. The Field Specifiers are defined in Figure G above, so go back there if you need a refresher 🍓
+--------------------------------------------------+
| Template Record Header |
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
...
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+Figure J: Template Record Format
The Template Record Header is shown in Figure K, and it's literally so clean 😭
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID (> 255) | Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure K: Template Record Header Format
These are the Template Record Header Field Definitions:
Template ID
Every newly generated Template Record gets its own unique Template ID. That uniqueness only has to hold locally, within the Transport Session and Observation Domain that generated the Template ID. Template IDs 0-255 are reserved for Template Sets, Options Template Sets, and other reserved Sets that haven't been created yet. Template IDs of Data Sets are numbered from 256 to 65535. There are no constraints on the order of Template ID allocation, so you can allocate them in any order you like 🌈
Field Count
This is the number of fields in this Template Record. Simple, but important 🫶
Next up is the example in Figure L. It shows a Template Set with a mix of standard and enterprise-specific Information Elements. It's made of a Set Header, a Template Header, and several Field Specifiers, and this is where it all clicks ✨
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 256 | Field Count = N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element id. 1.1 | Field Length 1.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number 1.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Information Element id. 1.2 | Field Length 1.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element id. 1.N | Field Length 1.N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number 1.N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 257 | Field Count = M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Information Element id. 2.1 | Field Length 2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element id. 2.2 | Field Length 2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number 2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element id. 2.M | Field Length 2.M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number 2.M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure L: Template Set Example
Information Element Identifiers 1.2 and 2.1 are defined by the IETF (Enterprise bit = 0), so they don't need an Enterprise Number to identify them. Easy win 💖
3.4.2. Options Template Record Format
Thanks to the notion of scope, The Options Template Record lets the Exporter give the Collector extra information that Flow Records alone just can't provide 🔥
One example is the "Flow Keys". It reports the Flow Keys for a Template, and that Template is what's defined as the scope. Another example is the "Template configuration", which reports the configuration sampling parameter(s) for the Template, which is also defined as the scope 🦋
3.4.2.1. Scope
The scope only shows up in the Options Template Set. It gives the context for the reported Information Elements in the Data Records 🌸 The IPFIX Message Header already has the Observation Domain ID (the identifier of the Observation Domain), so note that. If that ID isn't zero, it can be treated as an implicit scope for the Data Records in the IPFIX Message. Big warning 🚨 The Observation Domain ID MUST be zero when the IPFIX Message contains Data Records with different Observation Domain ID values defined as scopes.
Multiple Scope Fields MAY be present in the Options Template Record. When they are, the composite scope is the combination of those scopes. For example, if the two scopes are "metering process" and "template", the combined scope is this Template for this Metering Process 🧚 The order of the Scope Fields, as defined in the Options Template Record, is irrelevant in this case. But if the order of the Scope Fields in the Options Template Record is relevant, the order of the Scope Fields MUST be used. For example, say the first scope defines the filtering function and the second scope defines the sampling function. Then the order of the scope matters a lot, because applying sampling first and then filtering can lead to different Data Records than applying filtering first and then sampling. In this case, the Collector works out the function order by looking at the order of the scope in the Options Template Record 💅
The scope is an Information Element specified in the IPFIX Information Model [RFC5102]. An IPFIX-compliant implementation of the Collecting Process SHOULD support this minimum set of Information Elements as scope: LineCardId, TemplateId, exporterIPv4Address, exporterIPv6Address, and ingressInterface. Other Information Elements, like meteringProcessId, exportingProcessId, observationDomainId, and so on, are valid scopes too. The IPFIX protocol doesn't stop you from using any Information Element for scope. That said, some Information Element types don't make sense as scope. For example, the counter Information Elements are a no-go 🙈
Last thing: the Scope Field Count MUST NOT be zero 💀
3.4.2.2. Options Template Record Format 🎀
okay so an Options Template Record can hold any mix of IANA-assigned and/or enterprise-specific Information Elements identifiers 🦋 it's giving "build your own menu" energy
The layout is shown in Figure M. Each record has an Options Template Record Header plus one or more Field Specifiers, and the Field Specifiers are defined back in Figure G 💅
+--------------------------------------------------+
| Options Template Record Header |
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
...
+--------------------------------------------------+
| Field Specifier |
+--------------------------------------------------+
Figure M: Options Template Record FormatThe Options Template Record Header is shown in Figure N 🌸
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID (> 255) | Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure N: Options Template Record Header FormatHere's what each header field means 🧚
Template ID
The Template ID of this Options Template Record. This value is > 255 (greater than 255) ✨
Field Count
The number of all fields in this Options Template Record, including the Scope Fields 💖
Scope Field Count
The number of scope fields in this Options Template Record. The Scope Fields are normal Fields, except they get interpreted as scope at the Collector 👑 The Scope Field Count MUST NOT be zero. Not zero, bestie, that's a hard no 💀
Figure O is an Option Template Set with a mix of IETF and enterprise-specific Information Elements 🌈 It's made of a Set Header, an Option Template Header, and a bunch of Field Specifiers 🍓
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 258 | Field Count = N + M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = N |0| Scope 1 Infor. Element Id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length |0| Scope 2 Infor. Element Id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 2 Field Length | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |1| Scope N Infor. Element Id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope N Field Length | Scope N Enterprise Number ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Scope N Enterprise Number |1| Option 1 Infor. Element Id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option 1 Field Length | Option 1 Enterprise Number ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Option 1 Enterprise Number | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |0| Option M Infor. Element Id. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option M Field Length | Padding (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure O: Option Template Set Example3.4.3. Data Record Format 🦋
Data Records ride along in Data Sets 💜 The layout is in Figure P, and it's only one or more Field Values, nothing else. The Template ID that the Field Values belong to is encoded in the Set Header field "Set ID", so "Set ID" = "Template ID" ✨
+--------------------------------------------------+
| Field Value |
+--------------------------------------------------+
| Field Value |
+--------------------------------------------------+
...
+--------------------------------------------------+
| Field Value |
+--------------------------------------------------+
Figure P: Data Record FormatHeads up: Field Values do NOT necessarily have a length of 16 bits 😭 Each one is encoded according to its data type, as specified in [RFC5102]. Don't assume 16 bits, bestie.
You can only interpret a Data Record if the Template Record for its Template ID is available at the Collecting Process 🙈 No template, no decoding, periodt 🔥
Figure Q shows a Data Set: a Set Header plus a bunch of Field Values 🌈
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = Template ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 1 - Field Value 1 | Record 1 - Field Value 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 1 - Field Value 3 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 2 - Field Value 1 | Record 2 - Field Value 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 2 - Field Value 3 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 3 - Field Value 1 | Record 3 - Field Value 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record 3 - Field Value 3 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Padding (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure Q: Data Set, Containing Data Records4. Specific Reporting Requirements 🎀
There are some specific Options Templates and Options Template Records that give you extra info about the Flow Records and the Metering Process 🔥
These ones, the Option Template and Options Template Records defined in this section, put some constraints on the Metering Process and Exporting Process implementations. They MAY be implemented 🦋 If you do implement them, the specific Option Templates SHOULD be implemented as specified in these subsections 💅
The minimum set of Information Elements is always specified in these Specific IPFIX Options Templates. You're allowed to add extra Information Elements to these specific Options Templates though ✨
4.1. The Metering Process Statistics Option Template 📊
The Metering Process Statistics Option Template describes the structure of a Data Record for reporting Metering Process statistics. It SHOULD contain the following Information Elements, which are defined in [RFC5102]:
observationDomainId
An identifier of an Observation Domain that is locally unique to the Exporting Process. This Information Element MUST be defined as a Scope Field 👑
exportedMessageTotalCount
The total number of IPFIX Messages that the Exporting Process successfully sent to the Collecting Process since the Exporting Process re-initialization 🌸
exportedFlowTotalCount
The total number of Flow Records that the Exporting Process successfully sent to the Collecting Process since the Exporting Process re-initialization 🍓
exportedOctetTotalCount
The total number of octets that the Exporting Process successfully sent to the Collecting Process since the Exporting Process re-initialization 🧚
The Exporting Process SHOULD export the Data Record specified by the Metering Process Statistics Option Template on a regular basis or based on some export policy. That periodicity or export policy SHOULD be configurable ⏰
Note that if several Metering Processes are available on the Exporter Observation Domain, the Information Element meteringProcessId MUST be specified as an additional Scope Field 🫶
4.2. The Metering Process Reliability Statistics Option Template 🌈
The Metering Process Reliability Option Template describes the structure of a Data Record for reporting lack of reliability in the Metering Process. It SHOULD contain the following Information Elements, which are defined in [RFC5102]:
observationDomainId
An identifier of an Observation Domain that is locally unique to the Exporting Process. This Information Element MUST be defined as a Scope Field 👑
ignoredPacketTotalCount
The total number of IP packets that the Metering Process did not process 💀
ignoredOctetTotalCount
The total number of octets in observed IP packets that the Metering Process did not process 🙈
time first ignored
The timestamp of the first IP packet that was ignored by the Metering Process. For this timestamp, any of the "flowStart" timestamp Information Elements flowStartMilliseconds, flowStartMicroseconds, flowStartNanoseconds, and flowStartDeltaMicroseconds can be used 💖
time last ignored
The timestamp of the last IP packet that was ignored by the Metering Process. For this timestamp, any of the "flowEnd" timestamp Information Elements flowEndMilliseconds, flowEndMicroseconds, flowEndNanoseconds, and flowEndDeltaMicroseconds can be used 💜
The Exporting Process SHOULD export the Data Record specified by the Metering Process Reliability Statistics Option Template on a regular basis or based on some export policy. That periodicity or export policy SHOULD be configurable ⭐
Note that if several Metering Processes are available on the Exporter Observation Domain, the Information Element meteringProcessId MUST be specified as an additional Scope Field 🫶
4.3. The Exporting Process Reliability Statistics Option Template ✨
Okay bestie, this template is how the exporter tells the collector when it had to let data go 😭🫶. The Exporting Process Reliability Option Template describes the structure of a Data Record for reporting lack of reliability in the Exporting process. It SHOULD contain the following Information Elements that are defined in [RFC5102]:
- Exporting Process ID: the identifier of the Exporting Process that lack of reliability is being reported for. Three Information Elements from [RFC5102] can do this job:
exporterIPv4Address,exporterIPv6Address, orexportingProcessId. This Information Element MUST be defined as a Scope Field 💅 notSentFlowTotalCount: the total number of Flows that the Metering Process generated but then dropped, either itself or through the Exporting Process, instead of sending them to the Collecting Process 💀notSentPacketTotalCount: the total number of packets in Flow Records that the Metering Process generated but then dropped, either itself or through the Exporting Process, instead of sending them to the Collecting Process 📦notSentOctetTotalCount: the total number of octets in packets in Flow Records that the Metering Process generated but then dropped, either itself or through the Exporting Process, instead of sending them to the Collecting Process 🧮- time first flow dropped: the timestamp of the first Flow that the Metering Process dropped. For this timestamp, you can use any of the "flowStart" timestamp Information Elements:
flowStartMilliseconds,flowStartMicroseconds,flowStartNanoseconds, andflowStartDeltaMicroseconds🕰️ - time last flow dropped: the timestamp of the last IP packet that the Metering Process ignored. For this timestamp, you can use any of the "flowEnd" timestamp Information Elements:
flowEndMilliseconds,flowEndMicroseconds,flowEndNanoseconds, andflowEndDeltaMicroseconds⏳
The Exporting Process SHOULD export the Data Record specified by the Exporting Process Reliability Statistics Option Template on a regular basis or based on some export policy. This periodicity or export policy SHOULD be configurable 🎀
4.4. The Flow Keys Option Template 🗝️
The Flow Keys Option Template specifies the structure of a Data Record for reporting the Flow Keys of reported Flows. A Flow Keys Data Record extends a particular Template Record that is referenced by its templateId identifier. The Template Record gets extended by specifying which of the Information Elements in the matching Data Records describe the Flow properties that act as Flow Keys for the reported Flow. It's giving organization 📚
The Flow Keys Option Template SHOULD contain the following Information Elements that are defined in [RFC5102]:
templateId: an identifier of a Template. This Information Element MUST be defined as a Scope Field.flowKeyIndicator: a bitmap with the positions of the Flow Keys in the Data Records.
5. IPFIX Message Header "Export Time" and Flow Record Time ⏰
The IPFIX Message Header "Export Time" field is the time in seconds since 0000 UTC Jan 1, 1970, at which the IPFIX Message Header leaves the Exporter. The time-related Information Elements specified in [RFC5102] MAY use this "Export Time" as their base time and specify an offset relative to it, instead of using a common base time such as 0000 UTC Jan 1, 1970. All Information Elements that do not have their base time defined by their data type MUST have the base time clearly specified in their description. Main character energy for real 🌸
For example, Data Records that need microsecond precision can export the flow start and end times with the flowStartMicroseconds and flowEndMicroseconds Information Elements [RFC5102], which contain the time since 0000 UTC Jan 1, 1970. An alternate solution is to export the flowStartDeltaMicroseconds and flowEndDeltaMicroseconds Information Elements [RFC5102] in the Data Record. These report the flow start and end time offsets compared to the IPFIX Message Header "Export Time". The latter solution lowers the export bandwidth requirement, but it increases the load on the Exporter, because the Exporting Process must calculate the flowStartDeltaMicroseconds and flowEndDeltaMicroseconds of every single Data Record before exporting the IPFIX Message. Trade-offs, bestie 🫠
It must be noted that using time-related Information Elements with offset times, compared to the IPFIX Message Header "Export Time", puts some time constraints on the Data Records contained in the IPFIX Message. In the example of the flowStartDeltaMicroseconds and flowEndDeltaMicroseconds Information Elements [RFC5102], the Data Record must be exported within a maximum of 71 minutes after its creation. Otherwise, the 32-bit counter would not be big enough to hold the flow start time offset. Not me panicking about a 71-minute deadline 💀⏱️
6. Linkage with the Information Model 🧩
The Information Elements [RFC5102] MUST be sent in canonical format in network-byte order (also known as the big-endian byte ordering). Big-endian or bust 💖
6.1. Encoding of IPFIX Data Types ✨
The following sections define the encoding of the data types specified in [RFC5102].
6.1.1. Integral Data Types
Integral data types -- octet, signed8, unsigned16, signed16, unsigned32, signed32, signed64, and unsigned64 -- MUST be encoded using the default canonical format in network-byte order. Signed Integral data types are represented in two's complement notation. 🔢
6.1.2. Address Types
Address types -- macAddress, ipv4Address, and ipv6Address -- MUST be encoded the same way as the integral data types. The macAddress is treated as a 6-octet integer, the ipv4Address as a 4-octet integer, and the ipv6Address as a 16-octet integer. 🌐
6.1.3. float32
The float32 data type MUST be encoded as an IEEE single-precision 32-bit floating point-type, as specified in [IEEE.754.1985]. 🦋
6.1.4. float64
The float64 data type MUST be encoded as an IEEE double-precision 64-bit floating point-type, as specified in [IEEE.754.1985]. 💜
6.1.5. boolean
The boolean data type is specified according to the TruthValue in [RFC2579]: it is an integer with the value 1 for true and a value 2 for false. Every other value is undefined. The boolean data type MUST be encoded in a single octet. ✅❌
6.1.6. string and octetarray
The data type string represents a finite length string of valid characters of the Unicode character encoding set. The string data type MUST be encoded in UTF-8 format. The string is sent as an array of octets using an Information Element of fixed or variable length. 📝
The length of the Information Element specifies the length of the octetarray. 🧵
6.1.7. dateTimeSeconds
The data type dateTimeseconds represents a time value in units of seconds normalized to the GMT timezone. It MUST be encoded in a 32-bit integer containing the number of seconds since 0000 UTC Jan 1, 1970. The 32-bit integer allows the time encoding up to 136 years. 🗓️
6.1.8. dateTimeMilliseconds
The data type dateTimeMilliseconds represents a time value in units of milliseconds normalized to the GMT timezone. It MUST be encoded in a 64-bit integer containing the number of milliseconds since 0000 UTC Jan 1, 1970. ⚡
6.1.9. dateTimeMicroseconds
The data type dateTimeMicroseconds represents a time value in units of microseconds normalized to the GMT timezone. It MUST be encoded in a 64-bit integer, according to the NTP format given in [RFC1305]. 🕒
6.1.10. dateTimeNanoseconds
The data type of dateTimeNanoseconds represents a time value in units of nanoseconds normalized to the GMT time zone. It MUST be encoded in a 64-bit integer, according to the NTP format given in [RFC1305]. 🔬
6.2. Reduced Size Encoding of Integer and Float Types 🪶
Information Elements containing integer, string, float, and octetarray types in the information model MAY be encoded using fewer octets than those implied by their type in the information model definition [RFC5102]. This works on the assumption that the smaller size is enough to carry any value the Exporter may need to deliver. It reduces the network bandwidth requirement between the Exporter and the Collector. Note that the Information Element definitions [RFC5102] will always define the maximum encoding size. Smart and lean 🍓
For instance, the information model [RFC5102] defines byteCount as an unsigned64 type, which would require 64 bits. However, if the Exporter will never locally encounter the need to send a value larger than 4294967295, it may chose to send the value instead as an unsigned32. For example, a core router would require an unsigned64 byteCount, while an unsigned32 might be sufficient for an access router. 🛜
This behavior is indicated by the Exporter by specifying a type size with a smaller length than the one associated with the assigned type of the Information Element. In the example above, the Exporter would place a length of 4 versus 8 in the Template. 📏
If reduced sizing is used, it MUST only be applied to the following integer types: unsigned64, signed64, unsigned32, signed32, unsigned16, and signed16. The signed versus unsigned property of the reported value MUST be preserved. The reduction in size can be to any number of octets smaller than the original type if the data value still fits, i.e., so that only leading zeroes are dropped. For example, an unsigned64 can be reduced in size to 7, 6, 5, 4, 3, 2, or 1 octet(s). 🧼
Reduced sizing can also be used to reduce float64 to float32. The float32 not only has a reduced number range, but due to the smaller mantissa, it is also less precise. 🫧
The reduced size encoding MUST NOT be applied to dateTimeMicroseconds or to dateTimeNanoseconds because these represent an inherent structure that would be destroyed by using fewer than the original number of bytes. Hands off the timestamps, periodt 🙅♀️💖
7. Variable-Length Information Element ✨
Okay bestie, so the IPFIX Template mechanism is basically built for fixed-length Information Elements 💅 [RFC5102]. But when an Information Element has a variable length, you MUST use the following mechanism to carry the length info, and this applies to both the IETF and the proprietary Information Elements 🫶
In the Template Set, the Information Element Field Length gets recorded as 65535 🔥 That's a reserved length value, and it tells the Collecting Process that the length of the Information Element is carried inside the Information Element content itself 🧚
Most of the time, the Information Element will be less than 255 octets, so the length encoding is designed to keep the overhead tiny in that majority case ✨ The length goes in the octet right before the Information Element, like Figure R shows 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (< 255)| Information Element |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... continuing as needed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure R: Variable-Length Information Element (length < 255 octets)
If the Information Element is 255 octets or longer, the length gets encoded into 3 octets before the Information Element instead 🌸 The first octet is 255, and the actual length lives in the second and third octets, as shown in Figure S 💜
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 255 | Length (0 to 65535) | IE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... continuing as needed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure S: Variable-Length Information Element (length 0 to 65535 octets)
The octets that carry the length (the first octet, or the first three octets) MUST NOT be counted in the length of the Information Element 🙈 Don't double count, bestie!
8. Template Management 🎀
This section is all about Template Management when you're using SCTP and PR-SCTP as the transport protocol 🦋 If TCP or UDP need any Template Management changes, those live in Section 10 💅
The Exporting Process assigns and keeps track of the Template IDs per SCTP association, for the Exporter's Observation Domains ✨ When a brand new Template Record shows up, the Exporting Process gives it a Template ID that isn't being used yet 🌈
If a specific Information Element is required by a Template but it isn't available in the observed packets, the Exporting Process MAY choose to export Flow Records without that Information Element, in a Data Record defined by a new Template 🧚
If an Information Element is required more than once in a Template, the different occurrences SHOULD follow the logical order of how the Metering Process treated them 💖 For example, say a selected packet goes through two hash functions and both hash values get sent in one Template. Then the first occurrence of the hash value should belong to the first hash function in the Metering Process 🔥 Another example: when exporting the two source IP addresses of an IPv4 in IPv4 packets, the first sourceIPv4Address Information Element occurrence should be the IPv4 address of the outer header, while the second occurrence should be the inner header one 👑
Template Sets and Options Template Sets may be sent on any SCTP stream 🫶 But Template Sets and Options Template Sets MUST be sent reliably, using SCTP-ordered delivery ✨ That means the Collecting Process MUST store the Template Record information for as long as the SCTP association lasts, so it can make sense of the Data Records that come in later Data Sets 💜
The Exporting Process SHOULD send the Template Set and the Options Template Set before any Data Sets that use that (Options) Template ID 🌸 This helps make sure the Collector already has the Template Record before the first Data Record shows up 😭 Data Records that match a Template Record MAY show up in the same IPFIX Message(s) and/or in later ones 🦋
Different Observation Domains from the same SCTP association are allowed to use the same Template ID value for different Templates 🌈
Templates that aren't used anymore SHOULD be deleted 🧹 Before you reuse a Template ID, the Template MUST be deleted 💅 To delete an allocated Template, you withdraw it with a Template Withdrawal Message ✨
The Template Withdrawal Message MUST NOT be sent until enough time has passed for the Collecting Process to receive and process the last Data Record that used this Template information ⏳ That time MUST be configurable 🎀 A suitable default is 5 seconds after the last Data Record has been sent 💖
The Template ID from a withdrawn Template MUST NOT be reused until enough time has passed for the Collecting Process to receive and process the Template Withdrawal Message 🙈
A Template Withdrawal Message is a Template Record for that Template ID with a Field Count of 0 🧚 Its format is shown in Figure T 👑
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = (2 or 3) | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID N | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID ... | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID M | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure T: Template Withdrawal Message Format
The Set ID field MUST contain the value 2 for a Template Set Withdrawal, and the value 3 for an Options Template Set Withdrawal 🔥 Multiple Template IDs MAY be withdrawn with a single Template Withdrawal Message, and if that happens, padding MAY be used 🌈
The Template Withdrawal Message withdraws the Template IDs for the Observation Domain ID that's in the IPFIX Message Header 💜
The Template Withdrawal Message may be sent on any SCTP stream 🦋 But the Template Withdrawal Message MUST be sent reliably, using SCTP-ordered delivery 🫶
The Template Withdrawal Message MUST NOT contain any new Template or Options Template Records 🙅♀️ Keep it clean, bestie!
If the measurement parameters change so that a new Template is needed, then the Template MUST be withdrawn (using a Template Withdraw Message and a new Template definition), or an unused Template ID MUST be used 🧚 Some examples of measurement changes are a new sampling rate, a new Flow expiration process, a new filtering definition, and so on ✨
When the SCTP association shuts down or the Exporting Process restarts, all Template assignments are lost, and the Template IDs MUST be reassigned 💀
If the Metering Process restarts, the Exporting Process MUST either reuse the Template ID it previously assigned for each Template, or it MUST withdraw the previously issued Template IDs by sending Template Withdraw Message(s) before reusing them 🌸
A Template Withdrawal Message that withdraws all Templates for the Observation Domain ID in the IPFIX Message Header MAY be used 🍓 Its format is shown in Figure U 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 2 | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure U: All Data Templates Withdrawal Message Format
A Template Withdrawal Message that withdraws all Options Templates for the Observation Domain ID in the IPFIX Message Header MAY be used too 🦋 Its format is shown in Figure V 🧚
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 3 | Field Count = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure V: All Options Templates Withdrawal Message Format
When the SCTP association restarts, the Exporting Process MUST resend all the Template Records 🌈💖
9. The Collecting Process's Side 🎀
okay bestie, this section is all about the Collecting Process when it's running over SCTP with PR-SCTP. Anything that's specific to TCP or UDP lives over in Section 10 💅
The Collecting Process SHOULD listen for a new association request from the Exporting Process. The Exporting Process is the one that asks for a number of streams to export on, and an Exporting Process MAY request and support more than one stream per SCTP association ✨
Now the malformed stuff 😭 If the Collecting Process gets a malformed IPFIX Message, it MUST reset the SCTP association, toss that IPFIX Message, and SHOULD log the error. Non-zero Set padding does not count as malformed, so no panic over that 🫶
Template Sets and Option Template Sets only get sent once, so the Collecting Process MUST store the Template Record information for the whole association. That's how it can decode the Data Records that show up later in Data Sets 🧚
Template IDs are unique per SCTP association and per Observation Domain. If a Template comes in that was already received and hasn't been withdrawn (same Exporter Observation Domain, same Template ID, same association), then the Collecting Process MUST shut down the association. Yikes 💀
When an SCTP association closes, the Collecting Process MUST discard all the Templates it got over that association and stop decoding IPFIX Messages that use them 🥀
Usually the Template Records arrive before the Data Records. The Data Records then get decoded and stored by the Collector. If the Templates haven't arrived yet, the Collecting Process MAY store those Data Records for a short while and decode them once the Template Records show up. A Collecting Process MUST NOT assume that the Data Set and its associated Template Set (or Options Template Set) are exported in the same IPFIX Message. Not me assuming things 🙈
If the Collecting Process runs into an Information Element it doesn't understand, it MUST note that Information Element identifier, and it MAY discard that Information Element from the Flow Record 🍓
The Collector MUST accept padding in Data Records and Template Records. The padding size is the Set Length minus the size of the Set Header (4 octets for the Set ID and the Set Length), modulo the Record size deduced from the Template Record 🧮
The IPFIX protocol has a Sequence Number field in the Export header that goes up with the number of IPFIX Data Records in the IPFIX Message. A Collector can spot out-of-sequence, dropped, or duplicate IPFIX Messages by tracking that number 🔍 A Collector SHOULD provide a logging mechanism for tracking out-of-sequence IPFIX Messages. Those can happen because of Exporter resource exhaustion (it can't send at the rate it creates messages), an Exporting Process reset, congestion on the network link between the Exporter and Collector, Collector resource exhaustion (it can't process at the arrival rate), out-of-order packet reception, duplicate packet reception, or an attacker injecting false messages 😱
If a Collecting Process receives a Template Withdrawal Message, the Collecting Process MUST delete the corresponding Template Records associated with that specific SCTP association and that specific Observation Domain, and stop decoding IPFIX Messages that use the withdrawn Templates 🗑️
If the Collecting Process receives a Template Withdraw message for a Template Record it hasn't received before on this SCTP association, it MUST reset the SCTP association, discard the IPFIX Message, and SHOULD log the error, the same way it does for malformed IPFIX Messages 🚫
A Collecting Process that gets IPFIX Messages from several Observation Domains on the same Transport Session MUST be aware that the uniqueness of the Template ID is not guaranteed across Observation Domains. Keep your eyes open, babe 👀
The Collector MUST support the use of Templates containing multiple occurrences of similar Information Elements 💜
10. Transport Protocol 🌸
The IPFIX Protocol Specification was designed to be transport protocol independent, which is so iconic. Also, the Exporter can export to multiple Collecting Processes using independent transport protocols 🦋
The IPFIX Message Header has a 16-bit Length field, which limits an IPFIX Message to 65535 octets, header included. A Collecting Process MUST be able to handle IPFIX Message lengths of up to 65535 octets 📦
10.1. Transport Compliance and Transport Usage 💖
We need to differentiate between what must be implemented (so operators can deploy compliant implementations from different vendors and have them interoperate) and what should or could be used in different operational environments. We must also make sure that ALL implementations can operate in a congestion-aware and congestion-avoidance mode 🌈
SCTP [RFC4960] using the PR-SCTP extension specified in [RFC3758] MUST be implemented by all compliant implementations. UDP [UDP] MAY also be implemented by compliant implementations. TCP [TCP] MAY also be implemented by compliant implementations 🎀
PR-SCTP SHOULD be used in deployments where Exporters and Collectors communicate over links that are susceptible to congestion. PR-SCTP is capable of providing any required degree of reliability 🔥
TCP MAY be used in deployments where Exporters and Collectors communicate over links that are susceptible to congestion, but PR-SCTP is preferred because it can limit back pressure on Exporters and because of its message versus stream orientation 💅
UDP MAY be used, although it is not a congestion-aware protocol. However, the IPFIX traffic between the Exporter and Collector MUST run in an environment where IPFIX traffic has been provisioned for, or is contained through some other means 🧁
10.2. SCTP 🦋
This section describes how IPFIX can be transported over SCTP [RFC4960] using the PR-SCTP [RFC3758] extension ✨
10.2.1. Congestion Avoidance 🌷
The SCTP transport protocol provides the required level of congestion avoidance by design. SCTP detects congestion in the end-to-end path between the IPFIX Exporting Process and the IPFIX Collecting Process, and it limits the transfer rate accordingly 🐢
When an IPFIX Exporting Process has records to export but detects that transmission by SCTP is temporarily impossible, it can either wait until sending is possible again, or it can decide to drop the record. In the latter case, the dropped export data MUST be accounted for, so that the amount of dropped export data can be reported 📊
10.2.2. Reliability 💜
The SCTP transport protocol is reliable by default, but it has the capability to deliver messages with partial reliability [RFC3758] 🧠
Using reliable SCTP messages for the IPFIX export is not, on its own, a guarantee that all Data Records will be delivered. If there is congestion on the link from the Exporting Process to the Collecting Process, or if a significant number of retransmissions are required, the send queues on the Exporting Process may fill up. In that case, the Exporting Process MAY either suspend, export, or discard the IPFIX Messages. If Data Records are discarded, the IPFIX Sequence Numbers used for export MUST reflect the loss of data 😭
10.2.3. MTU 📏
SCTP provides the required IPFIX Message fragmentation service based on path MTU discovery 🧩
10.2.4. Exporting Process 🚀
10.2.4.1. Association Establishment
The IPFIX Exporting Process SHOULD initiate an SCTP association with the IPFIX Collecting Process. By default, the Collecting Process listens for connections on SCTP port 4739. By default, the Collecting Process listens for secure connections on SCTP port 4740 (refer to the Security Considerations section). By default, the Exporting Process tries to connect to one of these ports. It MUST be possible to configure both the Exporting and Collecting Processes to use a different SCTP port 🔌
The Exporting Process MAY establish more than one association (a connection "bundle" in SCTP terminology) to the Collecting Process 🫧
An Exporting Process MAY support more than one active association to different Collecting Processes, including the case of different Collecting Processes on the same host 🏠
10.2.4.2. Association Shutdown
When an Exporting Process is shut down, it SHOULD shut down the SCTP association 👋
When a Collecting Process no longer wants to receive IPFIX Messages, it SHOULD shut down its end of the association. The Collecting Process SHOULD continue to receive and process IPFIX Messages until the Exporting Process has closed its end of the association. Polite and patient, very iconic 💅
When a Collecting Process detects that the SCTP association has been abnormally terminated, it MUST continue to listen for a new association establishment 👂
When an Exporting Process detects that the SCTP association to the Collecting Process has been abnormally terminated, it SHOULD try to re-establish the association 🔁
Association timeouts SHOULD be configurable ⏱️
10.2.4.3. Stream
An Exporting Process MAY request more than one SCTP stream per association. Each of these streams may be used for the transmission of IPFIX Messages containing Data Sets, Template Sets, and/or Options Template Sets 🌊
Depending on the requirements of the application, the Exporting Process may send Data Sets with full or partial reliability, using ordered or out-of-order delivery, over any SCTP stream established during SCTP Association setup 🎛️
An IPFIX Exporting Process MAY use any PR-SCTP Service Definition as per Section 4 of the PR-SCTP [RFC3758] specification when using partial reliability to transmit IPFIX Messages containing only Data Sets 🧾
However, Exporting Processes SHOULD mark such IPFIX Messages for retransmission for as long as resource or other constraints allow 🔄
10.2.4.4. Template Management
When the transport protocol is SCTP, the default Template Management described in Section 8 is used 🗂️
10.2.5. Collecting Process 🛬
When the transport protocol is SCTP, the default Collector processing described in Section 9 is used 🙌
10.2.6. Failover 🛟
If the Collecting Process does not acknowledge the attempt by the Exporting Process to establish an association, the Exporting Process should retry using the SCTP exponential backoff feature. The Exporter MAY log an alarm if the time to establish the association exceeds a specified threshold, which is configurable on the Exporter ⏰
If Collecting Process failover is supported by the Exporting Process, a second SCTP association MAY be opened in advance 🪂
10.3. UDP 🌙
This section describes how IPFIX can be transported over UDP [UDP] 🛸
10.3.1. Congestion Avoidance 🌤️
UDP has no integral congestion-avoidance mechanism. Its use over congestion-sensitive network paths is therefore not recommended 🙅♀️ UDP MAY be used in deployments where Exporters and Collectors always communicate over dedicated links that are not susceptible to congestion, i.e., over links provisioned well beyond the maximum export rate from the Exporters 🛡️
10.3.2. Reliability 🛟
Okay so UDP is literally not a reliable transport, bestie 😭 It can't guarantee that messages get delivered, which means IPFIX Messages sent from the Exporting Process to the Collecting Process over UDP may get lost. UDP MUST NOT be used unless the application can tolerate some loss of IPFIX Messages. 💀
The Collecting Process SHOULD deduce the loss and reordering of IPFIX Data Records by looking at the discontinuities in the IPFIX Sequence Number. With UDP, the IPFIX Sequence Number holds the total number of IPFIX Data Records sent for the UDP Transport Session prior to the receipt of this IPFIX Message, modulo 2^32. A Collector SHOULD detect out-of-sequence, dropped, or duplicate IPFIX Messages by tracking the Sequence Number. Templates sent from the Exporting Process to the Collecting Process using UDP as a transport MUST be re-sent at regular intervals, in case previous copies were lost. 🫶
10.3.3. MTU 📏
The maximum size of exported messages MUST be configured so the total packet size does not exceed the path MTU. If the path MTU is unknown, a maximum packet size of 512 octets SHOULD be used. Main character packet sizing 💅
10.3.4. Port Numbers 🔌
By default, the Collecting Process listens on the UDP port 4739. By default, the Collecting Process listens for secure connections on UDP port 4740 (refer to the "Security Considerations" section). By default, the Exporting Process tries to connect to one of these ports. It MUST be possible to configure both the Exporting and Collecting Processes to use a different UDP port. 🎀
10.3.5. Exporting Process 📤
The Exporting Process MAY duplicate the IPFIX Message to the several Collecting Processes. ✨
10.3.6. Template Management 🧩
When IPFIX uses UDP as the transport protocol, Template Sets and Option Template Sets MUST be re-sent at regular intervals. The frequency of the (Options) Template transmission MUST be configurable. The default value for the frequency of the (Options) Template transmission is 10 minutes. The Exporting Process SHOULD transmit the Template Set and Options Template Set in advance of any Data Sets that use that (Options) Template ID, so the Collector has the Template Record before receiving the first Data Record. It's giving preparation 🍓
In the event of configuration changes, the Exporting Process SHOULD send multiple copies of the new Template definitions, in different IPFIX Messages, at an accelerated rate. In that case, it SHOULD transmit the changed Template Record(s) and Options Template Record(s), without any data, in advance, so the Collector will have the correct Template information before receiving the first data. 🔥
If the Option Template scope is defined in another Template, then both Templates SHOULD be sent in the same IPFIX Message. For example, if a Flow Key Option Template (see Section 4.4) is sent in an Option Template, then the associated Template SHOULD be sent in the same IPFIX Message. 👯♀️
Following a configuration change that can modify the interpretation of the Data Records (for example, a sampling rate change), a new Template ID MUST be used, and the old Template ID MUST NOT be reused until its lifetime (see Section 10.3.7) has expired. ⏳
If UDP is selected as the transport protocol, the Template Withdraw Messages MUST NOT be used, because this method is inefficient due to the unreliable nature of UDP. Not me using inefficient methods 🙅♀️
10.3.7. Collecting Process 🗂️
The Collecting Process MUST associate a lifetime with each Template (or another definition of an identifier considered unique within the Transport Session) received via UDP. Templates (and similar definitions) not refreshed by the Exporting Process within the lifetime are expired at the Collecting Process. If the Template (or other definition) is not refreshed before that lifetime has expired, the Collecting Process MUST discard that definition and any current and future associated Data Records. In which case, an alarm MUST be logged. The Collecting Process MUST NOT decode any further Data Records that are associated with the expired Template. 🚫
If a Template is refreshed with a Template Record that differs from the previously received Template Record, the Collecting Process SHOULD log a warning and replace the previously received Template Record with the new one. The Template lifetime at the Collecting Process MUST be at least 3 times higher than the Template refresh timeout configured on the Exporting Process. Lifetimes that are longer than the refresh timer, fr fr ⏰
Template IDs are unique per UDP session and per Observation Domain. At any given time, the Collecting Process SHOULD maintain the following for all the current Template Records and Options Template Records: <IPFIX Device, Exporter source UDP port, Observation Domain ID, Template ID, Template Definition, Last Received>. 📋
The Collecting Process SHOULD accept Data Records without the associated Template Record (or other definitions) required to decode the Data Record. If the Template Records (or other definitions such as Common Properties) have not been received at the time Data Records are received, the Collecting Process SHOULD store the Data Records for a short period of time and decode them after the Template Records (or other definitions) are received. The short period of time MUST be lower than the lifetime of definitions associated with identifiers considered unique within the UDP session. Wait for the Template, then decode 🧚
If the Collecting Process receives a malformed IPFIX Message, it MUST discard the IPFIX Message and SHOULD log the error. 💀
10.3.8. Failover 🔁
Because UDP is not a connection-oriented protocol, the Exporting Process is unable to determine from the transport protocol that the Collecting Process is no longer able to receive the IPFIX Messages. Therefore, it cannot invoke a failover mechanism. However, the Exporting Process MAY duplicate the IPFIX Message to several Collecting Processes. No connection, no vibes, so we duplicate 🦋
10.4. TCP 🎀
This section describes how IPFIX can be transported over TCP [TCP]. Let's get into it 💖
10.4.1. Connection Management 🤝
10.4.1.1. Connection Establishment 🔗
The IPFIX Exporting Process initiates a TCP connection to the Collecting Process. By default, the Collecting Process listens for connections on TCP port 4739. By default, the Collecting Process listens for secure connections on TCP port 4740 (refer to the Security Considerations section). By default, the Exporting Process tries to connect to one of these ports. It MUST be possible to configure both the Exporting Process and the Collecting Process to use a different TCP port. 🌈
An Exporting Process MAY support more than one active connection to different Collecting Processes (including the case of different Collecting Processes on the same host). 🧁
The Exporter MAY log an alarm if the time to establish the connection exceeds a specified threshold, configurable on the Exporter. ⏱️
10.4.1.2. Graceful Connection Release 👋
When an Exporting Process is shut down, it SHOULD shut down the TCP connection. Clean exit era 🌸
When a Collecting Process no longer wants to receive IPFIX Messages, it SHOULD close its end of the connection. The Collecting Process SHOULD continue to read IPFIX Messages until the Exporting Process has closed its end. Read until they hang up, iconic 💅
10.4.1.3. Restarting Interrupted Connections 🔄
When a Collecting Process detects that the TCP connection to the Exporting Process has terminated abnormally, it MUST continue to listen for a new connection.
When an Exporting Process detects that the TCP connection to the Collecting Process has terminated abnormally, it SHOULD try to re-establish the connection. Connection timeouts and retry schedules SHOULD be configurable. In the default configuration, an Exporting Process MUST NOT attempt to establish a connection more frequently than once per minute. Chill, one reconnect per minute max 🫠
10.4.1.4. Failover 🛟
If the Collecting Process does not acknowledge the attempt by the Exporting Process to establish a connection, it will retry using the TCP exponential backoff feature.
If Collecting Process failover is supported by the Exporting Process, a second TCP connection MAY be opened in advance. Backup connection, lowkey smart 🧠
10.4.2. Data Transmission 📡
Once a TCP connection is established, the Exporting Process starts sending IPFIX Messages to the Collecting Process. 🚀
10.4.2.1. IPFIX Message Encoding 🔤
IPFIX Messages are sent over the TCP connection without any special encoding. The Length field in the IPFIX Message Header defines the end of each IPFIX Message and thus the start of the next IPFIX Message. This means that IPFIX Messages cannot be interleaved. No cutting in line 🙅♀️
In the case of TCP, the IPFIX Sequence Number contains the total number of IPFIX Data Records sent from this TCP connection, from the current Observation Domain by the Exporting Process, prior to the receipt of this IPFIX Message, modulo 2^32. 🔢
If an Exporting Process exports data from multiple Observation Domains, it should be careful to choose IPFIX Message lengths appropriately to minimize head-of-line blocking between different Observation Domains. Multiple TCP connections MAY be used to avoid head-of-line between different Observation Domains. Head-of-line blocking is not the vibe 🚧
10.4.2.2. Template Management 🧩
For each Template, the Exporting Process MUST send the Template Record before exporting Data Records that refer to that Template. Template first, data second, always 🍰
Template IDs are unique per TCP connection and per Observation Domain. A Collecting Process MUST record all Template and Options Template Records for the duration of the connection, as an Exporting Process is not required to re-export Template Records. Keep them saved, bestie 💜
When the TCP connection restarts, the Exporting Process MUST resend all the Template Records. 🔁
When a TCP connection is closed, the Collecting Process MUST discard all Templates received over that connection and stop decoding IPFIX Messages that use those Templates. 🧹
The Templates that are not used anymore SHOULD be deleted. Before reusing a Template ID, the Template MUST be deleted. In order to delete an allocated Template, the Template is withdrawn through the use of a Template Withdrawal Message over the TCP connection. Clean up your Templates, periodt ✨
If the Collecting Process receives a malformed IPFIX Message, it MUST reset the TCP connection, discard the IPFIX Message, and SHOULD log the error. Reset, discard, log, and move on 💀
10.4.2.3. Congestion Handling and Reliability
okay so TCP is literally the bestie that makes sure data from the Exporting Process actually reaches the Collecting Process 🫶. It also controls how fast data gets sent, using a mechanism that checks both network congestion and what the receiver can handle 🚦.
So an IPFIX Exporting Process may not be able to send IPFIX Messages as fast as the Metering Process makes them 😭. That can happen because the network is congested, or because the Collecting Process can't keep up. As long as the congestion is temporary, the Exporting Process can buffer IPFIX Messages until it's ready to send them. But buffering is super limited, both because resources are finite and because data has timeliness requirements. So ongoing or severe congestion can leave the Exporting Process blocked 💀.
When an Exporting Process has Data Records to export but the transmission buffer is full, and it wants to avoid getting blocked, it can choose to drop some Data Records 🙈. The dropped Data Records MUST be accounted for, so the amount can be exported later.
When an Exporting Process notices that it should be exporting records faster than TCP sending allows, it should provide back pressure to the Metering Processes ✨. The Metering Process could then adapt by temporarily generating less data, for example through sampling or aggregation 🧚.
10.4.3. Collecting Process
The Collecting Process SHOULD listen for a new TCP connection from the Exporting Process 🎀.
If the Collecting Process gets a malformed IPFIX Message, it MUST reset the TCP connection, discard the IPFIX Message, and SHOULD log the error 🚫. Note that non-zero Set padding does not count as a malformed IPFIX Message.
Template Sets and Option Template Sets are only sent once 🍓. The Collecting Process MUST store the Template Record information for the whole life of the connection, so it can decode the matching Data Records that show up in later Data Sets.
Template IDs are unique per TCP connection and per Observation Domain 🔑. If the Collecting Process receives a Template that it has already received, and that hasn't been withdrawn yet (that is, a Template Record from the same Exporter Observation Domain with the same Template ID, received on the same TCP connection), then the Collecting Process MUST shut down the connection 😤.
When a TCP connection closes, the Collecting Process MUST throw away all Templates it got over that connection, and stop decoding IPFIX Messages that use those Templates 🗑️.
If a Collecting Process receives a Template Withdrawal Message, it MUST delete the matching Template Records tied to that specific TCP connection and that specific Observation Domain, and stop decoding IPFIX Messages that use the withdrawn Templates 👋.
If the Collecting Process gets a Template Withdrawal Message for a Template Record it has never received on this TCP connection, it MUST reset the TCP association, discard the IPFIX Message, and SHOULD log the error, just like it does for malformed IPFIX Messages 💅.
11. Security Considerations ✨
okay this part is seriously important 😭🔐. The security considerations for IPFIX come from a threat analysis, which is discussed in the "Security Considerations" section of the IPFIX requirements [RFC3917]. The IPFIX security requirements are:
- IPFIX must provide a mechanism to ensure the confidentiality of IPFIX data transferred from an Exporting Process to a Collecting Process, so that Flow Records carried by IPFIX can't be disclosed 🤫.
- IPFIX must provide a mechanism to ensure the integrity of IPFIX data transferred from an Exporting Process to a Collecting Process, so that incorrect data or control information (for example, Templates) can't be injected into an IPFIX Message stream 🛡️.
- IPFIX must provide a mechanism to authenticate IPFIX Collecting and Exporting Processes, so data isn't collected from an unauthorized Exporting Process and isn't exported to an unauthorized Collecting Process 🔒.
Because IPFIX can be used to collect information for network forensics and billing, attacks meant to confuse, disable, or steal information from an IPFIX collection system may be a prime target during a sophisticated network attack 🚨.
An attacker who can inject false messages into an IPFIX Message stream can either affect the application using IPFIX (by falsifying data), or attack the IPFIX Collecting Process itself (by modifying or revoking Templates, or changing options). That's why IPFIX Message integrity is so important 💜.
IPFIX Messages can also hold valuable info for an attacker, including details about the network's configuration as well as end-user traffic and payload data. So you have to be careful to keep them visible only to authorized users 👀. When an Information Element that contains end-user payload information is exported, it SHOULD be sent to the Collecting Process in a way that protects its contents from eavesdropping. Suitable options include a direct point-to-point connection or an encryption mechanism 🔐. The Collecting Process is responsible for providing a satisfactory level of security for the collected data, including, if needed, anonymizing any reported data 🫧.
11.1. Applicability of TLS and DTLS
Transport Layer Security (TLS) [RFC4346] and Datagram Transport Layer Security (DTLS) [RFC4347] were designed to give the confidentiality, integrity, and authentication assurances that IPFIX needs, without requiring pre-shared keys 🌸.
With SCTP and PR-SCTP being the mandatory transport protocols for IPFIX, DTLS [RFC4347] MUST be implemented. If UDP is chosen as the IPFIX transport protocol, DTLS [RFC4347] MUST be implemented. If TCP is chosen as the IPFIX transport protocol, TLS [RFC4346] MUST be implemented 🎀.
Heads up: DTLS is the security mechanism picked for SCTP and PR-SCTP. TLS bindings to SCTP are defined in [RFC3436], but they require all communication to go over reliable, bidirectional streams, and they require one TLS connection per stream. That setup doesn't fit with why SCTP was chosen as an IPFIX transport protocol in the first place 🙅♀️.
Okay, this bit is a real vulnerability, so pay attention 🚨. Using DTLS [RFC4347] has a weakness: a true man in the middle might try to pull data out of an association and trick the sender into thinking the peer actually received it. With generic TLS for SCTP (and/or TCP), that isn't possible. This means the removal of a message can end up hidden from both the sender and the receiver. Another weakness of using PR-SCTP with DTLS is that someone could inject SCTP control information to shut down the SCTP association, which effectively causes a loss of IPFIX Messages if they're buffered outside of the SCTP association 😱. Techniques such as [dtls-for-sctp] could be used in the future to fix these vulnerabilities 🔮.
When using DTLS over SCTP, the Exporting Process MUST make sure each IPFIX Message is sent over the same SCTP stream that would be used if that IPFIX Message were sent directly over SCTP 🧵. DTLS may send its own control messages on stream 0 with full reliability. That won't interfere with how stream 0 IPFIX Messages get processed at the Collecting Process, because DTLS handles its own control messages before passing IPFIX Messages up to the application layer 💖.
11.2. Usage
The IPFIX Exporting Process starts the communication with the IPFIX Collecting Process, and acts as a TLS or DTLS client according to [RFC4346] and [RFC4347]. The IPFIX Collecting Process acts as a TLS or DTLS server 🤝. If SCTP or PR-SCTP is the transport protocol, the DTLS client opens a secure connection on SCTP port 4740 of the DTLS server. If TCP is the transport protocol, the TLS client opens a secure connection on TCP port 4740 of the TLS server. If UDP is the transport protocol, the DTLS client opens a secure connection on UDP port 4740 of the DTLS server 🦋.
11.3. Authentication
IPFIX Exporting Processes and IPFIX Collecting Processes are identified by the fully qualified domain name of the interface on which IPFIX Messages are sent or received. This is used for X.509 client and server certificates, as described in [RFC3280] 🪪.
To stop man-in-the-middle attacks from impostor Exporting or Collecting Processes, the acceptance of data from an unauthorized Exporting Process, or the export of data to an unauthorized Collecting Process, strong mutual authentication via asymmetric keys MUST be used for both TLS and DTLS 🔑. Each IPFIX Exporting and Collecting Process MUST verify its peer's identity against its authorized certificates, and MUST verify that the peer's certificate matches its fully qualified domain name. In the case of SCTP, it can match the fully qualified domain name of one of its endpoints instead 💅.
The fully qualified domain name used to identify an IPFIX Collecting Process or Exporting Process may be stored either in a subjectAltName extension of type dNSName, or in the most specific Common Name field of the Subject field of the X.509 certificate. If both are present, the subjectAltName extension gets preference 🌈.
Internationalized domain names (IDN) in either the subjectAltName extension of type dNSName or the most specific Common Name field of the Subject field of the X.509 certificate MUST be encoded using Punycode [RFC3492], as described in Section 4 of [RFC3490], "Conversion Operations" 🌍.
11.4. Protection against DoS Attacks ⚔️
okay bestie, the villain arc is here 😈💀 an attacker can go after an IPFIX collection system in two ways. Directly, by blasting a ton of traffic at a Collecting Process 🔥. Indirectly, by generating huge amounts of traffic for a Metering Process to measure 🙈.
Direct DoS can also be a state exhaustion move 🫠. That can happen at the transport layer (like opening a bunch of pending connections), or inside the IPFIX Collecting Process itself (like sending Flow Records that are waiting on Template or scope information, or a pile of Options Template Records, etc.).
SCTP has a cookie-exchange mechanism built to defend against SCTP state exhaustion DoS attacks 🛡️. TCP has the "SYN cookie" mechanism to mitigate state exhaustion, and SYN cookies SHOULD be used by any Collecting Process accepting TCP connections 🍪. DTLS also brings cookie exchange to protect DTLS servers from state exhaustion.
The tea is that there is no way to stop fake IPFIX Message processing (and the state creation that comes with it) for UDP & SCTP communication 😭. TLS and DTLS can obviously stop fake states from being created, but they are themselves prone to state exhaustion attacks. So Collector rate limiting SHOULD be used to protect TLS & DTLS, like limiting the number of new TLS or DTLS sessions per second to a sensible number ⏱️.
IPFIX state exhaustion attacks can be mitigated by limiting the rate at which new connections or associations get opened by the Collecting Process, limiting the rate at which IPFIX Messages get accepted by the Collecting Process, and adaptively limiting the amount of state kept, especially records waiting on Templates 🧠. These rate and state limits MAY be provided by a Collecting Process. If they are provided, the limits SHOULD be user configurable ⚙️✨.
Also, an IPFIX Collecting Process can wipe out the risk of state exhaustion attacks from untrusted nodes by requiring TLS or DTLS mutual authentication. That way the Collecting Process only accepts IPFIX Messages from trusted sources 🫶.
Now for indirect DoS. The behavior of IPFIX under overload conditions depends on the transport protocol in use 🌊. For IPFIX over TCP, TCP congestion control makes the flow of IPFIX Messages back off and eventually stall, which leaves the IPFIX system blinded 🙈. PR-SCTP helps a little, since some IPFIX Messages keep getting received by the Collecting Process thanks to SCTP's multiple streams and partial reliability features, avoiding head-of-line blocking. That might give some visibility into the attack 👀. UDP is kind of similar: some datagrams may keep arriving at the Collecting Process, which basically acts like sampling on the IPFIX Message stream, so some forensics may be left behind 🕵️♀️.
To minimize IPFIX Message loss under overload conditions, some mechanism for service differentiation could be used to prioritize IPFIX traffic over other traffic on the same link 👑. Or, IPFIX Messages can be transported over a dedicated network. In that case, care must be taken to make sure the dedicated network can handle the expected peak IPFIX Message traffic 📦.
11.5. When DTLS or TLS Is Not an Option 🙅♀️
Sometimes DTLS or TLS just isn't possible because of performance issues or other operational concerns 🐢.
Without TLS or DTLS mutual authentication, IPFIX Exporting Processes and Collecting Processes can fall back on using IP source addresses to authenticate their peers 🪪. A policy of allocating Exporting Process and Collecting Process IP addresses from specified address ranges, plus using ingress filtering to prevent spoofing, can make this approach way more useful 💅. Again, completely segregating IPFIX traffic on a dedicated network, where possible, can improve security even further 🔐. Either way, open Collecting Processes (the ones that accept IPFIX Messages from any Exporting Process no matter its IP address or identity) are discouraged 🚫.
Modern TCP and SCTP implementations are resistant to blind insertion attacks (see [RFC1948], [RFC4960]). UDP, though, offers no such protection 😬. For this reason, IPFIX Message traffic that is transported via UDP and not secured via DTLS SHOULD be protected via segregation to a dedicated network 🌸.
11.6. Logging an IPFIX Attack 📝
IPFIX Collecting Processes MUST detect potential IPFIX Message insertion or loss conditions by tracking the IPFIX Sequence Number 🔢. They SHOULD also provide a logging mechanism for reporting out-of-sequence messages 🗂️. Note that an attacker may be able to exploit how out-of-sequence messages get handled at the Collecting Process, so care should be taken with these conditions 🫣. For example, a Collecting Process that just resets the expected Sequence Number when it gets a later Sequence Number could be temporarily blinded by deliberate injection of later Sequence Numbers 🙃.
IPFIX Exporting and Collecting Processes SHOULD log any connection attempt that fails due to authentication failure. That includes being presented an unauthorized or mismatched certificate during TLS or DTLS mutual authentication, or a connection attempt from an unauthorized IP address when TLS or DTLS is not in use 🚨.
IPFIX Exporting and Collecting Processes SHOULD detect and log any SCTP association reset or TCP connection reset 🔍.
11.7. Securing the Collector 🏰
The security of the Collector and its implementation is important to achieve overall security. However, it is outside the scope of this document 🤷♀️.
12. IANA Considerations 🗂️
IPFIX Messages 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 IPFIX Version Number value of 10 is reserved for the IPFIX protocol specified in this document. Set ID values of 0 and 1 are not used for historical reasons [RFC3954]. The Set ID value of 2 is reserved for the Template Set. The Set ID value of 3 is reserved for the Option Template Set. All other Set ID values from 4 to 255 are reserved for future use. Set ID values above 255 are used for Data Sets 🧩.
New assignments in either IPFIX Version Number or IPFIX Set ID assignments require a Standards Action [RFC2434], i.e., they are to be made via Standards Track RFCs approved by the IESG 📜✨.
Appendix A. IPFIX Encoding Examples 🎀
This appendix, which is a not a normative reference, contains IPFIX encoding examples 🧁.
Let's consider the example of an IPFIX Message composed of a Template Set, a Data Set (which contains three Data Records), an Options Template Set and a Data Set (which contains 2 Data Records related to the previous Options Template Record) 🌈.
IPFIX Message:
+--------+------------------------------------------. . .
| | +--------------+ +------------------+
|Message | | Template | | Data |
| Header | | Set | | Set | . . .
| | | (1 Template) | | (3 Data Records) |
| | +--------------+ +------------------+
+--------+------------------------------------------. . .
. . .-------------------------------------------+
+------------------+ +------------------+ |
| Options | | Data | |
. . . | Template Set | | Set | |
| (1 Template) | | (2 Data Records) | |
+------------------+ +------------------+ |
. . .-------------------------------------------+A.1. Message Header Example 🍓
The Message Header is composed of:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 0x000a | Length = 152 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation Domain ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+A.2. Template Set Examples 🧚
A.2.1. Template Set Using IETF-Specified Information Elements 💖
We want to report the following Information Elements:
- The IPv4 source IP address: sourceIPv4Address in [RFC5102], with a length of 4 octets
- The IPv4 destination IP address: destinationIPv4Address in [RFC5102], with a length of 4 octets
- The next-hop IP address (IPv4): ipNextHopIPv4Address in [RFC5102], with a length of 4 octets
- The number of packets of the Flow: inPacketDeltaCount in [RFC5102], with a length of 4 octets
- The number of octets of the Flow: inOctetDeltaCount in [RFC5102], with a length of 4 octets
Therefore, the Template Set will be composed of the following:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 28 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 256 | Field Count = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address = 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| ipNextHopIPv4Address = 15 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| inPacketDeltaCount = 2 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| inOctetDeltaCount = 1 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+A.2.2. Template Set Using Enterprise-Specific Information Elements ✨
okay so this one's the fun version 💅 we want to report five things:
- 🌐 The IPv4 source IP address: sourceIPv4Address in [RFC5102], with a length of 4 octets
- 🌍 The IPv4 destination IP address: destinationIPv4Address in [RFC5102], with a length of 4 octets
- 🔒 An enterprise-specific Information Element for proprietary info, with a type of 15 and a length of 4
- 📦 The number of packets of the Flow: inPacketDeltaCount in [RFC5102], with a length of 4 octets
- 🧮 The number of octets of the Flow: inOctetDeltaCount in [RFC5102], with a length of 4 octets
so the Template Set ends up looking like this 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 32 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 257 | Field Count = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address = 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Information Element Id. = 15| Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| inPacketDeltaCount = 2 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| inOctetDeltaCount = 1 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+A.3. Data Set Example 🍓
A.3. Data Set Example 🍓
okay, in this one we report three Flow Records 🦋
Src IP addr. | Dst IP addr. | Next Hop addr. | Packet | Octets
| | | Number | Number
------------------------------------------------------------------
192.0.2.12 | 192.0.2.254 | 192.0.2.1 | 5009 | 5344385
192.0.2.27 | 192.0.2.23 | 192.0.2.2 | 748 | 388934
192.0.2.56 | 192.0.2.65 | 192.0.2.3 | 5 | 6534and here's the bytes-on-the-wire version 🧚
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 256 | Length = 64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.254 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5009 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5344385 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.23 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 748 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 388934 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.56 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.65 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6534 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+no padding needed in this example, bestie 🙈
A.4. Options Template Set Examples 🌈
A.4.1. Options Template Set Using IETF-Specified Information Elements 💜
per line card (the router is made of two line cards), we want to report 🫶
- 📊 Total number of IPFIX Messages: exportedPacketCount [RFC5102], with a length of 2 octets
- 🧾 Total number of exported Flows: exportedFlowCount [RFC5102], with a length of 2 octets
the line card, represented by the lineCardId Information Element [RFC5102], is used as the Scope Field ✨
so the Options Template Set is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 258 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |0| lineCardId = 141 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length = 4 |0| exportedPacketCount = 41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| exportedFlowCount = 42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+A.4.2. Options Template Set Using Enterprise-Specific Information Elements 🦋
per line card again (still two line cards 💅), we want to report:
- 📊 Total number of IPFIX Messages: exportedPacketCount [RFC5102], with a length of 2 octets
- 🔒 An enterprise-specific number of exported Flows, with a type of 42 and a length of 4 octets
the line card (represented by lineCardId [RFC5102]) is the Scope Field, same as before 🎀
the format of the Options Template Set goes like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 259 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |0| lineCardId = 141 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length = 4 |0| exportedPacketCount = 41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |1|Information Element Id. = 42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 | Enterprise number ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Enterprise number | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+A.4.3. Options Template Set Using an Enterprise-Specific Scope 🌸
in this example we want to export the same stuff as in Section A.4.1 🫶
- 📊 Total number of IPFIX Messages: exportedPacketCount [RFC5102], with a length of 2 octets
- 🧾 Total number of exported Flows: exportedFlowCount [RFC5102], with a length of 2 octets
but this time the info is about a proprietary scope, identified by enterprise-specific Information Element number 123 👑
the Options Template Set now looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 260 | Field Count = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 1 |1|Scope 1 Infor. El. Id. = 123 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope 1 Field Length = 4 | Enterprise Number ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Enterprise Number |0| exportedPacketCount = 41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| exportedFlowCount = 42 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+A.4.4. Data Set Using an Enterprise-Specific Scope 🧚
in this one we report two Data Records 💖
Line Card ID | IPFIX Message | Exported Flow Records
-------------------------------------------------------------------
Line Card 1 (lineCardId=1) | 345 | 10201
Line Card 2 (lineCardId=2) | 690 | 20402and on the wire it's this 👀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 260 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 345 | 10201 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 690 | 20402 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+A.5. Variable-Length Information Element Examples 🌈
A.5.1. Example of Variable-Length Information Element with Length Inferior to 255 Octets
okay so this one is the short-and-sweet version 💅 the length goes in a single octet, and here the length is 5, so the IE is 5 octets long 🎀 simple, clean, iconic.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 5 octet Information Element |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+A.5.2. Example of Variable-Length Information Element with Length 255 to 65535 Octets
this is the long-length glow-up 🦋 when the length is 255 or more, the first octet is 255 as a marker, and then the real length (here 1000) gets packed into the next two octets. then you get your 1000 octet IE, and it spills across the rest of the message, babe 🌈
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 255 | 1000 | IE ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1000 octet Information Element |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... IE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+References
Normative References
- [RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
- [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
- [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002.
- [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
- [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
- [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
- [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
- [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
- [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
- [RFC5102] Quittek, J., Bryant S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008.
- [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
- [UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
Informative References
- [IPFIX-ARCH] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture Model for IP Flow Information Export", Work in Progress, September 2006.
- [IPFIX-AS] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IPFIX Applicability", Work in Progress, June 2007.
- [PEN] IANA Private Enterprise Numbers registry
http://www.iana.org/assignments/enterprise-numbers. - [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996.
- [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
- [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.
- [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
- [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004.
- [IEEE.754.1985] Institute of Electrical and Electronics Engineers, "Standard for Binary Floating-Point Arithmetic", IEEE Standard 754, August 1985.
- [dtls-for-sctp] Tuexen, M. and E. Rescola, "Datagram Transport Layer Security for Stream Control Transmission Protocol", Work in Progress, November 2007.
Acknowledgments
big thank-yous 🫶 to the following people: Ganesh Sadasivan for his significant contribution during the initial phases of the protocol specification; Juergen Quittek for the coordination job within IPFIX and PSAMP; Nevil Brownlee, Dave Plonka, Paul Aitken, and Andrew Johnson for the thorough reviews; Randall Stewart and Peter Lei for their SCTP expertise and contributions; Martin Djernaes for the first essay on the SCTP section; Michael Behringer and Eric Vyncke for their advice and knowledge in security; Michael Tuexen for his help regarding the DTLS section; Elisa Boschi for her contribution regarding the improvement of SCTP sections; Mark Fullmer, Sebastian Zander, Jeff Meyer, Maurizio Molina, Carter Bullard, Tal Givoly, Lutz Mark, David Moore, Robert Lowe, Paul Calato, and many more, for the technical reviews and feedback. you're all iconic 🌈
Authors' Addresses
the squad 👑 (addresses exactly as they were written):
Benoit Claise
Cisco Systems
De Kleetlaan 6a b1
1831 Diegem
Belgium
Phone: +32 2 704 5622
EMail: bclaise@cisco.comStewart Bryant
Cisco Systems, Inc.
250, Longwater,
Green Park,
Reading, RG2 6GB,
United Kingdom
Phone: +44 (0)20 8824-8828
EMail: stbryant@cisco.comSimon Leinen
SWITCH
Werdstrasse 2
P.O. Box
CH-8021 Zurich
Switzerland
Phone: +41 44 268 1536
EMail: simon.leinen@switch.chThomas Dietz
NEC Europe Ltd.
NEC Laboratories Europe
Network Research Division
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221 4342-128
EMail: Thomas.Dietz@nw.neclab.euBrian H. Trammell
CERT Network Situational Awareness
Software Engineering Institute
4500 Fifth Avenue
Pittsburgh, PA 15213
United States
Phone: +1 412 268 9748
EMail: bht@cert.orgFull Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
📦 where this page comes from
- ietf: rfc5101 2008-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms