RFC 5982

IP Flow Information Export (IPFIX) Mediation: Problem Statement

📅 published August 2010, from ietf

RFC 5982: IP Flow Information Export (IPFIX) Mediation: Problem Statement ✨

okay so bestie, this is RFC 5982 🎀 It's an Informational doc from the IETF, not a Standards Track spec. It was written by A. Kobayashi (editor, NTT PF Lab.) and B. Claise (editor, Cisco Systems, Inc.), and it's dated August 2010. The ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates, so it's standing on its own 💅

Abstract 🌸

Flow-based measurement is hugely popular for all kinds of network monitoring 📊 But sharing flow info with apps that all want different things raises some open issues: measurement system scalability, flow-based measurement flexibility, and export reliability. IPFIX Mediation may help fix those. This doc walks through problems network admins keep running into, then shows IPFIX Mediation applicability examples alongside those problems.

Status of This Memo 📜

This doc is not an Internet Standards Track spec. It's published for informational purposes 🦋

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for that. Info about the current status, errata, and how to send feedback lives at:

http://www.rfc-editor.org/info/rfc5982

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info, as in effect on the date of publication. Please read those carefully, because they spell out your rights and restrictions for this doc. Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License.

Table of Contents 📋

1. Introduction ....................................................3
2. Terminology and Definitions .....................................3
3. IPFIX/PSAMP Documents Overview ..................................5
   3.1. IPFIX Documents Overview ...................................5
   3.2. PSAMP Documents Overview ...................................5
4. Problem Statement ...............................................5
   4.1. Coping with IP Traffic Growth ..............................6
   4.2. Coping with Multipurpose Traffic Measurement ...............7
   4.3. Coping with Heterogeneous Environments .....................7
   4.4. Summary ....................................................7
5. Mediation Applicability Examples ................................8
   5.1. Adjusting Flow Granularity .................................8
   5.2. Collecting Infrastructure ..................................8
   5.3. Correlation for Data Records ...............................9
   5.4. Time Composition ...........................................9
   5.5. Spatial Composition .......................................10
   5.6. Data Record Anonymization .................................11
   5.7. Data Retention ............................................11
   5.8. IPFIX Export from a Branch Office .........................12
   5.9. Distributing Data Record Types ............................13
   5.10. Flow-Based Sampling and Selection ........................14
   5.11. Interoperability between Legacy Protocols and IPFIX ......15
6. IPFIX Mediators' Implementation-Specific Problems ..............15
   6.1. Loss of Original Exporter Information .....................15
   6.2. Loss of Base Time Information .............................16
   6.3. Transport Sessions Management .............................16
   6.4. Loss of Options Template Information ......................16
   6.5. Template ID Management ....................................17
   6.6. Consideration for Network Topology ........................18
   6.7. IPFIX Mediation Interpretation ............................18
   6.8. Consideration for Aggregation .............................19
7. Summary and Conclusion .........................................20
8. Security Considerations ........................................20
9. Acknowledgements ...............................................21
10. References ....................................................22
   10.1. Normative References .....................................22
   10.2. Informative References ...................................22
Contributors ......................................................24

1. Introduction ✨

okay so the big perk of flow-based measurement is that it lets you monitor huge amounts of traffic seen at distributed Observation Points 🌍 It can be used for one purpose or many, but it's hard for flow-based measurement to serve multiple apps with very different requirements at the same time 😭 Network admins end up tweaking the parameters on their metering devices to meet every single measurement app's needs. Sometimes the devices just can't do that, either because of functional restrictions or because they're low on computational and memory resources. Those limits block large-traffic metering with the setup people actually want 💀

That's where IPFIX Mediation comes in 🦋 It fills the gap between restricted metering capabilities and what measurement apps need, by introducing an intermediate device called the IPFIX Mediator.

The IPFIX requirements in [RFC3917] mention intermediate devices sitting between Exporters and Collectors, like IPFIX proxies or concentrators. But there's no doc defining a generalized concept for those devices yet. This doc fixes that by defining IPFIX Mediation, a generalized intermediate device concept for IPFIX, and digging into the motivations for using it 🧚

Here's how the doc is laid out 🗺️ Section 2 covers the terminology. Section 3 gives an IPFIX/Packet Sampling (PSAMP) doc overview. Section 4 introduces general problems related to flow-based measurement. Section 5 describes applicability examples where IPFIX Mediation would be beneficial. Finally, Section 6 covers some problems an IPFIX Mediation implementation might face 👑

2. Terminology and Definitions 📖

The IPFIX-specific and PSAMP-specific terms used here are defined in [RFC5101] and [RFC5476], respectively. Same as in those docs, the first letter of each IPFIX-specific and PSAMP-specific term is capitalized, along with the IPFIX Mediation-specific terms defined in this one 💅

In this doc, we call a stream of records carrying flow- or packet-based information a "record stream" 🌊 The records may be encoded as IPFIX Data Records or in any other format.

Original Exporter

An Original Exporter is an IPFIX Device that hosts the Observation Points where the metered IP packets are observed 👀

IPFIX Mediation

IPFIX Mediation is the manipulation and conversion of a record stream for later export using the IPFIX protocol ✨

The following terms describe the architectural entities that IPFIX Mediation uses 🏗️

Intermediate Process

An Intermediate Process takes a record stream as input from Collecting Processes, Metering Processes, IPFIX File Readers, other Intermediate Processes, or other record sources. It performs some transformations on that stream, based on the content of each record, on states maintained across multiple records, or on other data sources. Then it passes the transformed record stream as output to Exporting Processes, IPFIX File Writers, or other Intermediate Processes, in order to perform IPFIX Mediation 🦋 Typically, an Intermediate Process is hosted by an IPFIX Mediator. Alternatively, it may be hosted by an Original Exporter.

IPFIX Mediator

An IPFIX Mediator is an IPFIX Device that provides IPFIX Mediation. It receives a record stream from some data sources, hosts one or more Intermediate Processes to transform that stream, and exports the transformed record stream into IPFIX Messages via an Exporting Process 🎀 In the common case, an IPFIX Mediator receives a record stream from a Collecting Process. But it could also receive a record stream from data sources that aren't encoded using IPFIX, for example when converting from the NetFlow V9 protocol [RFC3954] to the IPFIX protocol 🔄

Heads up, this part's important 🙈 The IPFIX Mediator is a generalization of the concentrator and proxy elements envisioned in the IPFIX requirements [RFC3917]. IPFIX Mediators running appropriate Intermediate Processes provide the functionality specified there 💜

3. IPFIX/PSAMP Documents Overview 📚

IPFIX Mediation can be applied to Flow- or packet-based information. Flow-based information is encoded as IPFIX Flow Records by the IPFIX protocol. Packet-based information is extracted by some packet selection techniques and then encoded as PSAMP Packet Reports by the PSAMP protocol. So this section covers the relevant docs for both protocols 🧁

3.1. IPFIX Documents Overview 🌈

The IPFIX protocol [RFC5101] gives network admins access to IP flow information 🔍 The architecture for exporting measured IP flow information from an IPFIX Exporting Process to a Collecting Process is defined in [RFC5470], following the requirements in [RFC3917]. The IPFIX protocol [RFC5101] also specifies how IPFIX Data Records and Templates get carried over a number of transport protocols, from IPFIX Exporting Processes to IPFIX Collecting Processes 🚚 IPFIX has a formal description of IPFIX Information Elements, including their names, types, and additional semantic information, as specified in [RFC5102]. [RFC5815] specifies the IPFIX Management Information Base 🗂️ Finally, [RFC5472] describes what types of applications can use the IPFIX protocol and how they can use the information it provides. It also shows how the IPFIX framework relates to other architectures and frameworks 🧩 The storage of IPFIX Messages in a file is specified in [RFC5655].

3.2. PSAMP Documents Overview ✨

okay so PSAMP is the other half of the story 🦋 The framework for packet selection and reporting [RFC5474] lets network elements pick out subsets of packets using statistical and other methods, then send a stream of reports about the picked packets to a Collector. 💌 The set of packet selection techniques standardized by PSAMP (Sampling and Filtering) is covered in [RFC5475]. The PSAMP protocol [RFC5476] is how packet information gets exported from a PSAMP Exporting Process to a Collector. 📦

Like IPFIX, PSAMP has a formal description of its Information Elements, meaning their names, types, and extra semantic info. 🧠 The PSAMP information model lives in [RFC5477]. And [PSAMP-MIB] describes the PSAMP Management Information Base. 🎀

4. Problem Statement 🌸

okay bestie, let's talk about the actual problem 😭 Network administrators generally deal with three things: measurement system scalability, Flow-based measurement flexibility, and export reliability. 💅 Yes, we already have some fixes, like Packet Sampling, Filtering, Data Records aggregation, and export replication, but they don't fully solve it. 🙈

The job is to adjust some parameters of metering devices so they fit the resources of the measurement system, while still meeting the conditions of data accuracy, Flow granularity, and export reliability. ✨ Those conditions depend on two factors.

  • Measurement system capacity: this is the bandwidth of the management network, the storage capacity, and how well the collecting devices and exporting devices perform. 💖
  • Application requirements: different apps, like traffic engineering, detecting traffic anomalies, and accounting, need different Flow Record granularities and data accuracies. 🔥

The sustained growth of IP traffic has been overwhelming measurement systems, ngl 😭 On top of that, a huge variety of applications (like Quality-of-Service (QoS) measurement, traffic engineering, and security monitoring) and measurement systems deployed in heterogeneous environments keep raising the demand and complexity of IP traffic measurements. 👑

4.1. Coping with IP Traffic Growth 📈

Enterprise or service provider networks already have multiple 10 Gb/s links, with total traffic going over 100 Gb/s. 🌈 In the near future, broadband users' traffic will grow by roughly 40% every year, according to [TRAFGRW]. 💀 When administrators monitor IP traffic at multiple Exporters while it keeps growing, the number of exported Flow Records can exceed what a single Collector can handle. 😭

To handle this, the current data reduction techniques (Packet Sampling and Filtering in [RFC5475], plus aggregation of measurement data) have generally been implemented on Exporters. 🧚 Heads up: Packet Sampling can lead to losing small Flows. ⚠️ With both Packet Sampling and aggregation, administrators might not be able to detect and investigate subtle traffic changes and anomalies, because that needs detailed Flow information. 🙈 With Filtering, only a subset of the Data Records gets exported. 🫶

So, considering the potential drawbacks of Packet Sampling, Filtering, and Data Records aggregation, there's a real need for a large-scale collecting infrastructure that doesn't rely on data reduction techniques. 💜

4.2. Coping with Multipurpose Traffic Measurement 🦋

Different monitoring apps put different requirements on the monitoring infrastructure. 💅 Some need traffic monitoring at the Flow level, while others need info about individual packets or just Flow aggregates. ✨

To meet all these needs, an Exporter would have to run a bunch of complex metering tasks in parallel, which is a problem because resources are limited. 😩 So it can be a good move to run the Exporter with a much simpler setup and do the appropriate post-processing of the exported Data Records at a later stage. 🎀

4.3. Coping with Heterogeneous Environments 🌈

Network administrators use IPFIX Devices and PSAMP Devices from various vendors, various software versions, and various device types (router, switch, or probe) in a single network domain. 🍓 Even legacy flow export protocols are still deployed in current networks. 💀 This mix leads to differences in Metering Process capabilities, Exporting Process capacity (export rate, cache memory, etc.), and data format. 🌸 For example, probes and switches can't retrieve some derived packet properties from a routing table. 🙈

To deal with this, the measurement system needs to mediate the differences. 🔥 Equipping all collecting devices with this absorption function is difficult, though. 😭

4.4. Summary 💖

Because of resource limitations in the measurement system, it's really important to use traffic data reduction techniques as early as possible, e.g., at the Exporter. ✨ But that's hard to implement because of the heterogeneous environment of exporting devices. 😤 On the other hand, keeping data accuracy and Flow granularity to meet the requirements of different monitoring apps needs a scalable and flexible collecting infrastructure. 👑

This implies that a new Mediation function is required in typical Exporter-Collector architectures. 🦋 Based on some applicability examples, the next section shows the limits of the typical Exporter-Collector architecture model and the IPFIX Mediation benefits. 🧚

5. Mediation Applicability Examples 💅

5.1. Adjusting Flow Granularity 🎀

The simplest set of Flow Keys is a fixed 5-tuple of protocol, source and destination IP addresses, and source and destination port numbers. 🌈 A shorter set of Flow Keys, like a triple, a double, or a single property (for example, network prefix, peering autonomous system number, or BGP Next-Hop fields), creates more aggregated Flow Records. 💜 This is especially useful for measuring router-level traffic matrices in a core network domain and for easily adjusting the performance of Exporters and Collectors. 🔥

Implementation analysis:

Implementations for this case depend on where Flow granularity is adjusted. 🤔 More suitable implementations use configurable Metering Processes in Original Exporters. The cache in the Metering Process can specify its own set of Flow Keys and extra fields. The Original Exporter then generates Flow Records at the desired Flow granularity. ✨

In the case where a Metering Process that can't change the Flow Keys in Original Exporters creates Flow Records, or PSAMP Packet Reports, an IPFIX Mediator can aggregate Data Records based on a new set of Flow Keys. 🫶 Even when a Metering Process does have this ability, an IPFIX Mediator can further aggregate the Flow Records. 🦋

5.2. Collecting Infrastructure 🏠

Increasing numbers of IPFIX Exporters, IP traffic growth, and the variety of treatments expected for the Data Records make it harder and harder to implement all measurement apps within a single Collector. 😩

Implementation analysis:

To increase collecting (e.g., bandwidth capacity) and processing capacity, distributed Collectors close to Exporters need to be deployed. 🌸 In that case, those Collectors would become IPFIX Mediators, re-exporting Data Records on demand to centralized applications. 💌 To cope with the variety of measurement apps, one possible implementation uses an Intermediate Process that decides which Collector(s) each record gets exported to. 🧠 More specific cases are described in Section 5.9. 🎀

5.3. Correlation for Data Records 🔗

Correlating Data Records, or correlating Data Records with metadata, gives you new metrics or info, including the following. 💖

  • One-to-one correlation between Data Records
    • One-way delay from correlating PSAMP Packet Reports from different Exporters along a specific path. 🛤️ For example, one-way delay is calculated from correlating two PSAMP Packet Reports, including the packet digest and the arrival time at the Observation Point. This scenario is described in Section 6.2.1.2 of [RFC5475]. 📖
    • Packet inter-arrival time from correlating sequential PSAMP Packet Reports from an Exporter. ⏱️
    • Treatment from correlating Data Records with common properties, observed at incoming/outgoing interfaces. Examples are the rate-limiting ratio, the compression ratio, the optimization ratio, etc. 🦋
  • Correlation amongst Data Records
    • Average/maximum/minimum values from correlating multiple Data Records. Examples are the average/maximum/minimum number of packets of the measured Flows, the average/maximum/minimum one-way delay, the average/maximum/minimum number of lost packets, etc. 📊
  • Correlation between Data Records and other metadata
    • Examples are some BGP attributes associated with Data Records, as determined via routing table lookup. 🗺️

Implementation analysis:

One possible implementation for this case uses an Intermediate Process located between the Metering Processes and Exporting Processes on the Original Exporter, or alternatively a separate IPFIX Mediator located between the Original Exporters and IPFIX Collectors. 🫶

5.4. Time Composition ⏰

Time composition is defined as aggregating consecutive Data Records with identical Flow Keys. 🎀 It leads to the same output as setting a longer active timeout on Original Exporters, with one advantage: creating new metrics like average, maximum, and minimum values from Flow Records over a shorter time interval lets administrators keep track of changes that might have happened during that interval. 👑 ✨

Implementation analysis:

One possible implementation for this case uses an Intermediate Process located between the Metering Processes and Exporting Processes on the Original Exporter, or alternatively a separate IPFIX Mediator located between the Original Exporters and IPFIX Collectors. 💜

5.5. Spatial Composition ✨

okay so spatial composition is when you stitch together Data Records from a bunch of Observation Points inside one Observation Domain 🧩, or across several Observation Domains from a single Exporter, or even across several Exporters 🌐. bestie, there are four types, and they get bigger each time 💅

  • Case 1: Spatial composition within one Observation Domain

For example, to measure the traffic for a single logical interface in the case in which link aggregation [IEEE802.3ad] exists, Data Records metered at physical interfaces belonging to the same trunk can be merged. 🎀

  • Case 2: Spatial composition across Observation Domains, but within a single Original Exporter

For example, in the case in which link aggregation exists, Data Records metered at physical interfaces belonging to the same trunk grouping beyond the line card can be merged. 🔗

  • Case 3: Spatial composition across Exporters

Data Records metered within an administrative domain, such as the west area and east area of an ISP network, can be merged. 🌸

  • Case 4: Spatial composition across administrative domains

Data Records metered across administrative domains, such as across different customer networks or different ISP networks, can be merged. For example, a unique Collector knows in which customer network an Exporter exists, and then works out the traffic data per customer based on the Exporter IP address. 👑

Implementation analysis:

One possible implementation for cases 1 and 2 uses an Intermediate Process located between the Metering Processes and Exporting Processes on the Original Exporter. A separate IPFIX Mediator located between the Original Exporters and IPFIX Collectors is a valid solution for cases 1, 2, 3, and 4. 🦋

5.6. Data Record Anonymization 🫶

okay privacy era 🔒 IPFIX exports across administrative domains can be used to measure traffic for wide-area traffic engineering or to analyze Internet traffic trends, like we saw in the spatial composition across administrative domains bit in the previous subsection. so admins have to follow privacy protection policies and stop other people from getting their hands on confidential traffic measurements 🙈 this is where anonymization comes in, because it lets you share traffic data without breaking those policies ✨

generally, anonymization changes a data set so the identity of the people or entities it describes can't be disclosed 🕵️‍♀️ it also tries to keep the network traffic properties that are useful for a given analysis, all while making sure the data can't be traced back to the specific networks, hosts, or users that generated the traffic. for example, IP address anonymization is seriously important for avoiding the identification of users, hosts, and routers 💅 and when an ISP offers traffic monitoring to end customers, network admins take care of anonymizing interface index fields, since those could reveal info about the vendor or software version of the Exporters. no leaks, periodt 🤐

Implementation analysis:

One possible implementation for this case uses an anonymization function at the Original Exporter. However, this increases the load on the Original Exporter. A more flexible implementation uses a separate IPFIX Mediator between the Original Exporter and Collector. 🌈

5.7. Data Retention 🗄️

data retention is when service providers and commercial organizations store traffic data 📦 and honestly, legislation often says network operators have to keep both IP traffic data and call detail records, in wired and wireless networks, generated by end users while they use a service provider's services. the traffic data is required for investigating, detecting, and prosecuting serious crime, if it's needed. the IP network examples are:

  • Internet telephony (includes every multimedia session associated with IP multimedia services) 📞
  • Internet email 📧
  • Internet access 🌐

for these services especially, data retention needs a measurement system with reliable export and huge storage 😭 because the data has to stay available for a long time, typically at least six months. that's a lot of data bestie 💀

Implementation analysis:

okay so for export reliability, the most suitable implementation uses the Stream Control Transmission Protocol (SCTP) between the Original Exporter and Collector ✨ if you're using an unreliable transport protocol such as UDP, a legacy exporting device can export Data Records to a nearby IPFIX Mediator through UDP, and then that IPFIX Mediator can reliably export them to the IPFIX Collector through SCTP. and if you're on UDP and there's no IPFIX Mediator, the legacy exporting device should duplicate the exports to several Collectors to lower the probability of losing Flow Records. BUT it might result in network congestion, unless dedicated export links are used 🚧 careful!

for the huge storage requirements, the collecting infrastructure is described in Section 5.2. 🧚

5.8. IPFIX Export from a Branch Office 🏢

so in large enterprise networks, Data Records from branch offices usually get gathered in a central office 🏬 but in the long-distance branch office case, the bandwidth for transporting IPFIX is limited 🥲 even if multiple Data Record types are interesting to the Collector (like IPFIX Flow Records in both directions, IPFIX Flow Records before and after WAN optimization techniques, or performance metrics tied to the IPFIX Flow Records exported at regular intervals, etc.), the export bandwidth limitation is a big factor you need to watch 👀

Implementation analysis:

one possible implementation for this case uses an IPFIX Mediator located in a branch office. The IPFIX Mediator would aggregate and correlate Data Records to cope with the export bandwidth limitation. it's giving efficiency 🍓

5.9. Distributing Data Record Types 🚦

recently, lots of networks have shifted towards integrated networks, like pure IP and MPLS networks, which carry IPv4, IPv6, and VPN traffic 🌍 Data Record types (IPv4, IPv6, MPLS, and VPN) need to be analyzed separately and from different perspectives for different organizations. a single Collector handling every Data Record type might turn into a bottleneck in the collecting infrastructure 😵 so Data Records get distributed based on their types and exported to the right Collector, which spreads the load across multiple Collectors. load balancing is literally iconic 👑

Implementation analysis:

one possible implementation for this case uses replication of the IPFIX Message in an Original Exporter for multiple IPFIX Collectors. Each Collector then extracts the Data Record its own applications need. however, this replication increases the load of the Exporting Process and wastes bandwidth between the Exporter and Collector 🫠

a more sophisticated implementation uses an Intermediate Process located between the Metering Processes and Exporting Processes in an Original Exporter. The Intermediate Process decides which Collector a Data Record gets exported to, depending on certain field values 🧠 if an Original Exporter doesn't have this capability, it can export Data Records to a nearby separate IPFIX Mediator, and then the IPFIX Mediator could distribute them to the appropriate IPFIX Collectors. 🎯

for example, if you want to distribute a specific customer's Data Records, an IPFIX Mediator needs to identify the customer networks 🔍 the Route Distinguisher (RD), ingress interface, peering Autonomous System (AS) number, or BGP Next-Hop, or simply the network prefix may be evaluated to tell different customer networks apart. in the following figure, the IPFIX Mediator reroutes Data Records based on the RD value, and that lets each customer's traffic be inspected independently 💖

                                        .---------.
                                        |Traffic  |
                                  .---->|Collector|<==>Customer#A
                                  |     |#1       |
                                  |     '---------'
                               RD=100:1
.----------.        .-----------.    |
|IPFIX     |        |IPFIX      |----'     .---------.
|Exporter#1|        |Mediator   | RD=100:2 |Traffic  |
|          |------->|           |--------->|Collector|<==>Customer#B
|          |        |           |          |#2       |
|          |        |           |----.     '---------'
'----------'        '-----------'    |
                               RD=100:3
                                  |     .---------.
                                  |     |Traffic  |
                                  '---->|Collector|<==>Customer#C
                                        |#3       |
                                        '---------'

      Figure A.  Distributing Data Records to Collectors
                     Using IPFIX Mediator

5.10. Flow-Based Sampling and Selection 🎲

okay so the number of packets per Flow is generally heavy tailed 📉 most types of Flow Records are likely to be small Flows made of just a few packets, and the measurement system gets totally overwhelmed by a huge amount of these tiny Flows 😩 if statistics for small Flows get exported as merged data (by applying a policy or threshold), the load on the Exporter goes down. and if you know the Flow distribution, exporting only a subset of the Data Records might be enough ✨ smart, right?

Implementation analysis:

one possible implementation for this case uses an Intermediate Process located between the Metering Processes and Exporting Processes on the Original Exporter, or alternatively a separate IPFIX Mediator located between the Original Exporters and IPFIX Collectors. the IPFIX Mediator uses a set of IPFIX Mediation functions, such as filtering, selecting, and aggregation 🧃

5.11. Interoperability between Legacy Protocols and IPFIX 🔁

during the migration from a legacy protocol like NetFlow [RFC3954] to IPFIX, NetFlow exporting devices and IPFIX Exporters are both likely to coexist in the same network 🤝 operators still need to keep measuring traffic data from the legacy exporting devices, even after they bring in IPFIX Collectors. main character migration arc 🎬

Implementation analysis:

one possible implementation for this case uses an IPFIX Mediator that converts a legacy protocol to IPFIX. 🦋

6. IPFIX Mediators' Implementation-Specific Problems ✨

6.1. Loss of Original Exporter Information ✨

okay so the Exporter IP address (the source IP of the IPFIX Transport Session) and the Observation Domain ID in the IPFIX Message header are both likely to get lost during IPFIX Mediation 😭. Sometimes a Mediator drops them on purpose 🙈. Still, the Collector has to recognize where the measurements came from, like the IP address of the Original Exporter, the Observation Domain ID, or even the Observation Point ID. Lowkey the scariest part: if a Mediator can't pass along the Original Exporter IP address, the Collector will wrongly think the Mediator's IP is the Original Exporter. Yikes 💀

In the figure below, the Collector can see two IP addresses: 192.0.2.3 (IPFIX Mediator) and 192.0.2.2 (Exporter#2). But it also needs to somehow recognize Exporter#1 and Exporter#2, since those are the Original Exporters 👑. So the IPFIX Mediator must be able to notify the Collector about the IP address of the Original Exporter 🫶.

   .----------.          .--------.
   |IPFIX     |          |IPFIX   |
   |Exporter#1|--------->|Mediator|---+
   |          |          |        |   |
   '----------'          '--------'   |       .---------.
   IP:192.0.2.1        IP:192.0.2.3    '----->|IPFIX    |
   ODID:10             ODID:0                 |Collector|
                                      +------>|         |
   .----------.                       |       '---------'
   |IPFIX     |                       |
   |Exporter#2|-----------------------'
   |          |
   '----------'
   IP:192.0.2.2
   ODID:20

          Figure B.  Loss of Original Exporter Information

6.2. Loss of Base Time Information 🕰️

okay the Export Time field in the IPFIX Message header is the reference timestamp for Data Records 🧚. Some IPFIX Information Elements, described in [RFC5102], carry delta timestamps that show the time difference from the Export Time value. If the Data Records have any delta time fields and the IPFIX Mediator overwrites the Export Time field when sending IPFIX Messages, those delta time fields become meaningless. Collectors can't recognize this situation, so wrong time values get propagated 😭🙅‍♀️.

6.3. Transport Sessions Management 🦋

how the Mediator maintains the relationships between incoming and outgoing Transport Sessions depends on its implementation. If an IPFIX Mediator relays multiple incoming Transport Sessions to a single outgoing Transport Session, and then shuts down that outgoing Transport Session, the Data Records of the incoming Transport Sessions would not be relayed anymore 💀. And if an incoming Transport Session gets reset, the behavior of the IPFIX Mediator needs to be specified 🙈.

6.4. Loss of Options Template Information 🌸

depending on how the IPFIX Mediators are implemented, the information in the Data Records defined by Options Templates can also get lost 😩. If the Sampling rate isn't communicated from the Mediator to the Collector, the Collector would miscalculate the traffic volume, and that can lead to crucial problems 💀. Even if an IPFIX Mediator simply relays received Data Records defined by Options Templates, the values of its scope fields could become meaningless in a different Transport Session 🙃. The minimal information an IPFIX Mediator must communicate needs to be specified 📝.

6.5. Template ID Management 🎀

the Template ID is unique on the basis of the Transport Session and Observation Domain ID 🔑. If an IPFIX Mediator can't manage the relationships among the Template IDs and the incoming Transport Session information, and the Template ID is used in the Options Template scope, IPFIX Mediators would, for example, relay wrong values in the scope field and in the Template Withdrawal Message 😵. The Collector then wouldn't be able to interpret the Template ID in the Template Withdrawal Message and in the Options Template scope. As a result, there's a risk that the Collector shuts down the IPFIX Transport Session 🚨.

For example, an IPFIX Mediator must maintain the state of the incoming Transport Sessions so it can manage the Template ID on its outgoing Transport Session correctly 🧠. Even if the Exporter Transport Session re-initializes, the IPFIX Mediator must manage the association of Template IDs within a specific Transport Session 💅. In the figure below, the IPFIX Mediator exports three Templates (256, 257, and 258), received from Exporter#3, Exporter#2, and Exporter#1, respectively. If Exporter#1 re-initializes and the Template ID value 258 is now replaced with 256, the IPFIX Mediator must correctly manage the new mapping of (incoming Transport Session, Template ID) and (outgoing Transport Session, Template ID) without shutting down its outgoing Transport Session 🫶✨.

   .----------. OLD: Template ID 258
   |IPFIX     | NEW: Template ID 256
   |Exporter#1|----+
   |          |    |
   '----------'    X
   .----------.    |           .-----------.               .----------.
   |IPFIX     |    '---------->|           |               |          |
   |Exporter#2|--------------->|IPFIX      |-------------->|IPFIX     |
   |          |Template ID 257 |Mediator   |Template ID 258| Collector|
   '----------'    +---------->|           |Template ID 257|          |
   .----------.    |           '-----------'Template ID 256'----------'
   |IPFIX     |    |
   |Exporter#3|----'
   |          | Template ID 256
   '----------'

           Figure C.  Relaying from Multiple Transport Sessions
                       to a Single Transport Session

6.6. Consideration for Network Topology 🗺️

IPFIX Mediation can be applied anywhere, but you should be careful about how you aggregate the counters, because there's a potential risk of double counting 👀. For example, if three Exporters export PSAMP Packet Reports related to the same flow, the one-way delay can be calculated, but summing up the number of packets and bytes doesn't make sense 🙅‍♀️. On the other hand, if three Exporters export Flow Records entering an administrative domain, then summing up the packets and bytes is a valid operation 💖. So the possible function applied to Flow Records has to take the measurement topology into consideration 🧩. Information such as the network topology, or at least the Observation Point and measurement direction, is required for IPFIX Mediation 📍.

6.7. IPFIX Mediation Interpretation 🔍

sometimes the IPFIX Collector needs to recognize which specific function(s) IPFIX Mediation has executed on the Data Records 🕵️‍♀️. If the IPFIX Mediator doesn't export the applied function, the IPFIX Collector can't tell time composition apart from spatial composition 😤. Some parameters related to the function also need to be exported. For example, for time composition, the active timeout of the original Flow Records is required to interpret the minimum/maximum counter correctly ⏱️. For spatial composition, the spatial area information over which Data Records are aggregated is required 🌍.

6.8. Consideration for Aggregation 🧁

whether the aggregation is based on time or spatial composition, you should be careful about how non-key fields get aggregated in IPFIX Mediation 🫣. The IPFIX information model [RFC5102] specifies that the value of a non-key field (one derived from packet fields or packet treatment, and whose value may change from packet to packet within a single Flow) is determined by the first packet observed for the corresponding Flow, unless the description of the Information Element explicitly specifies different semantics 📜.

But this simple rule might not be appropriate when aggregating Flow Records that have different values in a non-key field 🙃. For example, if Differentiated Services Code Point (DSCP) information is to be exported, this problem can show up: if two Flows with identical Flow Key values are measured at different Observation Points, they may contain identical packets observed at different locations in the network and at different points in time 🌐. On the way from the first to the second Observation Point, the DSCP and potentially some other packet fields may have changed 🔄. So if the Information Element ipDiffServCodePoint is included as a non-key field, it can be useful to include the DSCP value observed at either the first or the second Observation Point in the resulting Flow Record, depending on the application 🎯.

Other potential solutions include removing the Information Element ipDiffServCodePoint from the Data Record when re-exporting the aggregate Flow Record, changing the Information Element ipDiffServCodePoint from a non-key field to a Flow Key when re-exporting the aggregated Flow Record, or assigning a non-valid value for the Information Element to tell the Collector that this Information Element is meaningless 🤷‍♀️.

If Packet Sampling or Filtering is applied, the IPFIX Mediator must report an adjusted PSAMP Configured Selection Fraction when aggregating IPFIX Flow Records with different Sampling rates 📊.

Finally, special care must be taken when aggregating Flow Records that result from different Sampling techniques, such as Systematic Count-Based Sampling and Random n-out-of-N Sampling, for example 🧐.

7. Summary and Conclusion ✨

this document describes the problems network admins have been dealing with, how IPFIX Mediation applies to those problems, and the problems that come up when implementing IPFIX Mediators 🧑‍💻. To help Exporters and Collectors operate smoothly, the document shows that there are various IPFIX Mediation functions that admins can choose from 🎀.

However, there are still some open issues with using IPFIX Mediators 🥺. These issues come from the fact that no standards for IPFIX Mediation have been set yet. In particular, the minimum information that should be communicated between Original Exporters and Collectors, the mapping between different IPFIX Transport Sessions, and the internal components of IPFIX Mediators should be standardized 🙏💜.

8. Security Considerations ✨

okay bestie, security is where things get SERIOUS 🔒 A flow-based measurement system must prevent a few big threats: leaked confidential traffic data, incorrect data getting injected, and unauthorized access to traffic data. 😭 The IPFIX protocol's security threats are already covered in the Security Considerations section of [RFC5101], and they still apply to IPFIX Mediators. 💅

A measurement system also needs to handle these IPFIX Mediation threats:

  • Attacks against an IPFIX Mediator 🎯

IPFIX Mediators are a prime target for attacks, since they can stand in for IPFIX Exporters and Collectors. IPFIX Proxies or Masquerading Proxies need to stop unauthorized access and denial-of-service (DoS) attacks coming from untrusted public networks. 🚨

  • Man-in-the-middle attack by untrusted IPFIX Mediator 🕵️‍♀️

The Exporter-Mediator-Collector structure model could get misused for a man-in-the-middle attack. 💀

  • Configuration on IPFIX Mediation ⚙️

An accidental misconfiguration, or unauthorized access to configuration data, could lead to a seriously bad problem: confidential traffic data getting disclosed. 😱

  • Unintentional exposure of end-user information 👀

The chance of collecting fine-grained information on one arbitrary end user goes up as the number of Observation Points goes up. An IPFIX Mediator in that situation may have to apply suitable functions (e.g., anonymization or aggregation) to the Data Records it produces. 🧁

  • Multiple-tenancy policy on an IPFIX Mediator 🏢

An IPFIX Mediator handling traffic data from multiple tenants or customers needs to keep those tenants or customers protected from one another's traffic data. 🫣 For example, the IPFIX Mediator needs to identify the customer's identifier (e.g., ingress interface index, network address range, VLAN ID, Media Access Control (MAC) address, etc.) when it feeds a customer's traffic data to that customer's own dedicated IPFIX Collector. If the IPFIX Mediator cannot identify each customer's traffic data, it may need to drop the Data Records. 🗑️ On top of that, another technique to keep track of a customer's identifier may be required when customer sites are movable, like when a virtual machine moves to another physical machine. 🖥️✨

  • Confidentiality protection via an IPFIX Mediator 🔐

To keep Data Records safe in transit, their transport should be confidential and integrity-protected, e.g., by using Transport Layer Security (TLS) [RFC5246] or Datagram Transport Layer Security (DTLS) [RFC4347]. 💖 BUT, an IPFIX Collector cannot know whether the Data Records it receives were sent as encrypted data between an Original Exporter and an IPFIX Mediator. If the IPFIX Collector needs that information, it must be encoded in the IPFIX Mediator. 📝

  • Certification for an Original Exporter 🪪

An IPFIX Collector communicating via an IPFIX Mediator cannot verify the identity of an Original Exporter directly. If an Original Exporter and an IPFIX Collector sit in different administrative domains, the IPFIX Collector cannot trust its Data Records. 🙈 If the IPFIX Collector needs this information, it must be encoded in the IPFIX Mediator. 🫶

9. Acknowledgements 🫶

We want to give a huge thank you to the following people: Gerhard Muenz, for thorough, detailed review and significant contributions that improved whole sections 🙌; Keisuke Ishibashi, for contributions during the early phases of the document 🌸; Brian Trammell, for contributions that improved the Terminology and Definitions section 🦋; and Nevil Brownlee, Juergen Schoenwaelder, and Motonori Shindo, for their technical reviews and feedback 👑. Literal legends. 💅

10. References 📚

10.1. Normative References

[RFC5101]      Claise, B., Ed., "Specification of the IP Flow
               Information Export (IPFIX) Protocol for the Exchange
               of IP Traffic Flow Information", RFC 5101,
               January 2008.

[RFC5476]      Claise, B., Ed., Johnson, A., and J. Quittek, "Packet
               Sampling (PSAMP) Protocol Specifications", RFC 5476,
               March 2009.

10.2. Informative References

[IEEE802.3ad]  IEEE Computer Society, "Link Aggregation", IEEE
               Std 802.3ad-2000, March 2000.

[PSAMP-MIB]    Dietz, T., Ed., Claise, B., and J. Quittek,
               "Definitions of Managed Objects for Packet Sampling",
               Work in Progress, July 2010.

[RFC3917]      Quittek, J., Zseby, T., Claise, B., and S. Zander,
               "Requirements for IP Flow Information Export (IPFIX)",
               RFC 3917, October 2004.

[RFC3954]      Claise, B., Ed., "Cisco Systems NetFlow Services
               Export Version 9", RFC 3954, October 2004.

[RFC4347]      Rescorla, E. and N. Modadugu, "Datagram Transport
               Layer Security", RFC 4347, April 2006.

[RFC5102]      Quittek, J., Bryant, S., Claise, B., Aitken, P., and
               J. Meyer, "Information Model for IP Flow Information
               Export", RFC 5102, January 2008.

[RFC5246]      Dierks, T. and E. Rescorla, "The Transport Layer
               Security (TLS) Protocol Version 1.2", RFC 5246, August
               2008.

[RFC5470]      Sadasivan, G., Brownlee, N., Claise, B., and J.
               Quittek, "Architecture for IP Flow Information
               Export", RFC 5470, March 2009.

[RFC5472]      Zseby, T., Boschi, E., Brownlee, N., and B. Claise,
               "IP Flow Information Export (IPFIX) Applicability",
               RFC 5472, March 2009.

[RFC5474]      Duffield, N., Ed., Chiou, D., Claise, B., Greenberg,
               A., Grossglauser, M., and J. Rexford, "A Framework for
               Packet Selection and Reporting", RFC 5474, March 2009.

[RFC5475]      Zseby, T., Molina, M., Duffield, N., Niccolini, S.,
               and F. Raspall, "Sampling and Filtering Techniques for
               IP Packet Selection", RFC 5475, March 2009.

[RFC5477]      Dietz, T., Claise, B., Aitken, P., Dressler, F., and
               G.  Carle, "Information Model for Packet Sampling
               Exports", RFC 5477, March 2009.

[RFC5655]      Trammell, B., Boschi, E., Mark, L., Zseby, T., and A.
               Wagner, "Specification of the IP Flow Information
               Export (IPFIX) File Format", RFC 5655, October 2009.

[RFC5815]      Dietz, T., Ed., Kobayashi, A., Claise, B., and G.
               Muenz, "Definitions of Managed Objects for IP Flow
               Information Export", RFC 5815, April 2010.

[TRAFGRW]      Cho, K., Fukuda, K., Esaki, H., and A. Kato, "The
               Impact and Implications of the Growth in Residential
               User-to-User Traffic", SIGCOMM2006, pp. 207-218, Pisa,
               Italy, September 2006.

Contributors 🧚

Haruhiko Nishida
NTT Information Sharing Platform Laboratories
3-9-11 Midori-cho
Musashino-shi, Tokyo  180-8585
Japan

Phone: +81-422-59-3978
EMail: nishida.haruhiko@lab.ntt.co.jp


Christoph Sommer
University of Erlangen-Nuremberg
Department of Computer Science 7
Martensstr. 3
Erlangen  91058
Germany

Phone: +49 9131 85-27993
EMail: christoph.sommer@informatik.uni-erlangen.de
URI:   http://www7.informatik.uni-erlangen.de/~sommer/


Falko Dressler
University of Erlangen-Nuremberg
Department of Computer Science 7
Martensstr. 3
Erlangen  91058
Germany

Phone: +49 9131 85-27914
EMail: dressler@informatik.uni-erlangen.de
URI:   http://www7.informatik.uni-erlangen.de/~dressler/


Stephan Emile
France Telecom
2 Avenue Pierre Marzin
Lannion, F-22307
France

Fax:   +33 2 96 05 18 52
EMail: emile.stephan@orange-ftgroup.com

Authors' Addresses 💌

Atsushi Kobayashi (editor)
NTT Information Sharing Platform Laboratories
3-9-11 Midori-cho
Musashino-shi, Tokyo  180-8585
Japan

Phone: +81-422-59-3978
EMail: akoba@nttv6.net


Benoit Claise (editor)
Cisco Systems, Inc.
De Kleetlaan 6a b1
Diegem  1831
Belgium

Phone: +32 2 704 5622
EMail: bclaise@cisco.com

That's the whole thing, bestie! 🌈🦋💖 RFC 5982 is officially slayed. 👑

📦 where this page comes from