RFC 7015
Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol
RFC 7015 is called Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol 🎀. It came out in September 2013 and is a Standards Track document, so it's a real internet standard, not just an idea 🦋. The authors are B. Trammell (ETH Zurich), A. Wagner (Consecom AG), and B. Claise (Cisco Systems, Inc.). It's an IETF product with ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates ✨.
Abstract 💖
Okay, so this doc gives everyone one shared, implementation-independent starting point for using IPFIX to handle Aggregated Flows 🫶. Those are IPFIX Flows that represent packets from several Original Flows that share some set of common properties. It does this with a detailed terminology and an Intermediate Aggregation Process architecture, and it specifies how to count Original Flows and distribute counters across intervals 🧚.
Status of This Memo 📜
This is an Internet Standards Track document 💅.
It's a product of the Internet Engineering Task Force (IETF), so it reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 5741 🌸.
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7015 🔥.
Copyright Notice ©️
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved 💜.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 🙈. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License ⭐.
Table of Contents 🗺️
Table of Contents
1. Introduction ....................................................3
1.1. IPFIX Protocol Overview ....................................4
1.2. IPFIX Documents Overview ...................................5
2. Terminology .....................................................5
3. Use Cases for IPFIX Aggregation .................................7
4. Architecture for Flow Aggregation ...............................8
4.1. Aggregation within the IPFIX Architecture ..................8
4.2. Intermediate Aggregation Process Architecture .............12
4.2.1. Correlation and Normalization ......................14
5. IP Flow Aggregation Operations .................................15
5.1. Temporal Aggregation through Interval Distribution ........15
5.1.1. Distributing Values across Intervals ...............16
5.1.2. Time Composition ...................................18
5.1.3. External Interval Distribution .....................19
5.2. Spatial Aggregation of Flow Keys ..........................19
5.2.1. Counting Original Flows ............................21
5.2.1. Counting Distinct Key Values .......................22
5.3. Spatial Aggregation of Non-key Fields .....................22
5.3.1. Counter Statistics .................................22
5.3.2. Derivation of New Values from Flow Keys and
Non-key fields .....................................23
5.4. Aggregation Combination ...................................23
6. Additional Considerations and Special Cases in Flow
Aggregation ....................................................24
6.1. Exact versus Approximate Counting during Aggregation ......24
6.2. Delay and Loss Introduced by the IAP ......................24
6.3. Considerations for Aggregation of Sampled Flows ...........24
6.4. Considerations for Aggregation of Heterogeneous Flows .....25
7. Export of Aggregated IP Flows Using IPFIX ......................25
7.1. Time Interval Export ......................................25
7.2. Flow Count Export .........................................25
7.2.1. originalFlowsPresent ...............................26
7.2.2. originalFlowsInitiated .............................26
7.2.3. originalFlowsCompleted .............................26
7.2.4. deltaFlowCount .....................................26
7.3. Distinct Host Export ......................................27
7.3.1. distinctCountOfSourceIPAddress .....................27
7.3.2. distinctCountOfDestinationIPAddress ................27
7.3.3. distinctCountOfSourceIPv4Address ...................27
7.3.4. distinctCountOfDestinationIPv4Address ..............28
7.3.5. distinctCountOfSourceIPv6Address ...................28
7.3.6. distinctCountOfDestinationIPv6Address ..............28
7.4. Aggregate Counter Distribution Export .....................28
7.4.1. Aggregate Counter Distribution Options Template ....29
7.4.2. valueDistributionMethod Information Element ........29
8. Examples .......................................................31
8.1. Traffic Time Series per Source ............................32
8.2. Core Traffic Matrix .......................................37
8.3. Distinct Source Count per Destination Endpoint ............42
8.4. Traffic Time Series per Source with Counter Distribution ..44
9. Security Considerations ........................................46
10. IANA Considerations ...........................................46
11. Acknowledgments ...............................................46
12. References ....................................................47
12.1. Normative References .....................................47
12.2. Informative References ...................................471. Introduction ✨
Okay, so the whole point of packet data getting bundled into Flows is that it serves a bunch of different purposes 🌈. The requirements [RFC3917] and applicability statement [RFC5472] for the IP Flow Information Export (IPFIX) protocol [RFC7011] lay that out. Going beyond the Flow level, into records that each represent multiple Flows, is also a super common move for analysis and data reduction 📊. It's useful for large-scale network data analysis, archiving, and exchanging data between organizations 🍓. Because it works so well at scale, aggregation became part of the IPFIX Mediation Problem Statement [RFC5982], and the Intermediate Aggregation Process got defined in the Mediator framework [RFC6183] 👑.
Aggregation shows up everywhere for analysis and data reduction, like calculating traffic matrices, making time series for visualizations or anomaly detection, or shrinking data for long-term trending and storage 💅. Depending on which keys you aggregate by, it can also have an anonymizing effect on the data. For example, aggregation operations that drop IP addresses make it impossible to later identify nodes directly from those addresses 🙈.
Aggregation as this document defines and describes it covers the applications defined in [RFC5982], including Sections 5.1 "Adjusting Flow Granularity", 5.4 "Time Composition", and 5.5 "Spatial Composition". But Section 4.2 of this document specifies a much more flexible architecture for an Intermediate Aggregation Process than the original Mediator work [RFC5982] imagined 🦋. Instead of only those specific, limited use cases, the Intermediate Aggregation Process is specified to cover any activity commonly described as "Flow aggregation" 💖. The architecture is meant to describe any such activity without tying it to one specific implementation of aggregation ✨.
An Intermediate Aggregation Process may be applied to data collected from multiple Observation Points, because aggregation is a natural fit for data reduction when you're concentrating measurement data 🫶. This document specifically does not deal with the protocol issues that come up when you combine IPFIX data from multiple Observation Points and export from a single Mediator. Those issues apply to IPFIX Mediation in general, so they get covered in detail in the Mediation Protocol document [IPFIX-MED-PROTO] 🧚.
Since Aggregated Flows (as defined in the following section) are basically Flows, the IPFIX protocol [RFC7011] can export them, and the IPFIX File Format [RFC5655] can store them, "as is" 🎀. No changes to the protocol are necessary. This document gives a common basis for applying IPFIX to aggregated data, through a detailed terminology, an Intermediate Aggregation Process architecture, and methods for Original Flow counting and counter distribution across intervals 🌸. Note that Sections 5, 6, and 7 of this document are normative ⭐.
1.1. IPFIX Protocol Overview 🧚
In the IPFIX protocol, { type, length, value } tuples are expressed in Templates containing { type, length } pairs. Those pairs specify which { value } fields show up in data records that follow the Template, which gives a lot of flexibility about what data gets sent 💜. Templates are sent way less often than Data Records, so this saves a ton of bandwidth 🔥. Different data formats can be sent just by sending new Templates that specify the { type, length } pairs for the new format. See [RFC7011] for more information 💖.
The IPFIX Information Element Registry [IANA-IPFIX] defines a big pile of standard Information Elements that provide the necessary { type } information for Templates. Using standard elements is what makes it possible for different vendors' implementations to work together 🤝.
Non-standard, enterprise-specific elements may also be defined for private use 🦋.
1.2. IPFIX Documents Overview ✨
okay so IPFIX is basically a whole squad of documents 🫶 "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information" [RFC7011] and its associated docs define the IPFIX protocol, which gives network engineers and admins access to IP traffic Flow information 💖
IPFIX has a formal description of IPFIX Information Elements, covering their names, types, and extra semantic info, as laid out in the IPFIX Information Model [RFC7012] 🧚 The IPFIX Information Element registry [IANA-IPFIX] is maintained by IANA. New Information Element definitions can be added to that registry subject to an Expert Review [RFC5226], and there are extra process considerations in [RFC7013] 📋
"Architecture for IP Flow Information Export" [RFC5470] defines the architecture for exporting measured IP Flow information from an IPFIX Exporting Process to an IPFIX Collecting Process 🦋 It also gives the basic terminology for the elements of that architecture, following the requirements in "Requirements for IP Flow Information Export" [RFC3917]. The IPFIX protocol document [RFC7011] covers the details of how IPFIX Data Records and Templates get transported from an IPFIX Exporting Process to an IPFIX Collecting Process via a congestion-aware transport protocol 🚀
"IP Flow Information Export (IPFIX) Mediation: Problem Statement" [RFC5982] introduces the concept of IPFIX Mediators and defines the use cases they were designed for 🌸 Then "IP Flow Information Export (IPFIX) Mediation: Framework" [RFC6183] gives Mediators an architectural framework. Protocol-level stuff (e.g., Template and Observation Domain handling across Mediators) is covered by "Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators" [IPFIX-MED-PROTO] 🧩
This document specifies an Intermediate Process for Flow aggregation 💅 It can be applied at an IPFIX Mediator, at an original Observation Point before export, or for analysis and data reduction after receipt at a Collecting Process 👑
2. Terminology 🎀
okay this part is important, bestie 🫶 Terms used in this document that are defined in the Terminology section of the IPFIX protocol document [RFC7011] are to be interpreted as defined there ✨
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 😭
In addition, this document defines the following terms 💜
- Aggregated Flow: A Flow, as defined by [RFC7011], derived from a set of zero or more Original Flows within a defined Aggregation Interval. Note that an Aggregated Flow is defined in the context of an Intermediate Aggregation Process only. Once an Aggregated Flow is exported, it is essentially a Flow as in [RFC7011] and can be treated as such 🦋
- Intermediate Aggregation Process: an Intermediate Aggregation Process (IAP), as in [RFC6183], that aggregates records, based upon a set of Flow Keys or functions applied to fields from the record 🍓
- Aggregation Interval: A time interval imposed upon an Aggregated Flow. Intermediate Aggregation Processes may use a regular Aggregation Interval (e.g., "every five minutes", "every calendar month"), though regularity is not necessary. Aggregation intervals may also be derived from the time intervals of the Original Flows being aggregated ⏰
- Partially Aggregated Flow: A Flow during processing within an Intermediate Aggregation Process; refers to an intermediate data structure during aggregation within the Intermediate Aggregation Process architecture detailed in Section 4.2 🌈
- Original Flow: A Flow given as input to an Intermediate Aggregation Process in order to generate Aggregated Flows 🌷
- Contributing Flow: An Original Flow that is partially or completely represented within an Aggregated Flow. Each Aggregated Flow is made up of zero or more Contributing Flows, and an Original Flow may contribute to zero or more Aggregated Flows 🧃
- Original Exporter: The Exporter from which the Original Flows are received; meaningful only when an IAP is deployed at a Mediator 📤
The terminology presented herein improves the precision of, but does not supersede or contradict the terms related to, Mediation and aggregation defined in the Mediation Problem Statement [RFC5982] and the Mediation Framework [RFC6183] documents. Within this document, the terminology defined in this section is to be considered normative 💅
3. Use Cases for IPFIX Aggregation 🌸
aggregation is a super common data reduction method in traffic data analysis, and it has SO many applications 🔥 When used with a regular Aggregation Interval and Original Flows containing timing information, it generates time series data from a collection of Flows with discrete intervals, as in the example in Section 8.1 📈 This time series data is useful for a wide variety of analysis tasks, like generating input for network anomaly detection systems or driving visualizations of volume per time for traffic with specific characteristics 👀 As a second example, traffic matrix calculation from Flow data, as shown in Section 8.2, is inherently an aggregation action, since it spatially aggregates the Flow Key down to input or output interface, address prefix, or autonomous system (AS) 🗺️
Irregular or data-dependent Aggregation Intervals and key aggregation operations can also be used to provide adaptive aggregation of network Flow data 🧠 Here, full Flow Records can be kept for Flows of interest, while Flows deemed "less interesting" to a given application can be aggregated. For example, in an IPFIX Mediator equipped with traffic classification capabilities for security purposes, potentially malicious Flows could be exported directly, while known-good or probably-good Flows (e.g., normal web browsing) could be exported simply as time series volumes per web server 🛡️
Aggregation can also be applied to final analysis of stored Flow data, as shown in the example in Section 8.3 📚 All such aggregation applications in which timing information is not available or not important can be treated as if an infinite Aggregation Interval applies ♾️
Note that an Intermediate Aggregation Process that removes potentially sensitive information as identified in [RFC6235] may tend to have an anonymizing effect on the Aggregated Flows as well 🙈 However, any application of aggregation as part of a data protection scheme should ensure that all the issues raised in [RFC6235] are addressed, specifically Sections 4 ("Anonymization of IP Flow Data"), 7.2 ("IPFIX-Specific Anonymization Guidelines"), and 9 ("Security Considerations") 🔐
While much of the discussion in this document, and all of the examples, apply to the common case that the Original Flows to be aggregated are all of the same underlying type (i.e., are represented with identical Templates or compatible Templates containing a core set Information Elements that can be freely converted to one another), and that each packet observed by the Metering Process associated with the Original Exporter is represented, this is not a necessary assumption 🫧 Aggregation can also be applied as part of a technique using both aggregation and correlation to pull together multiple views of the same traffic from different Observation Points using different Templates 🧩 For example, consider a set of applications running at different Observation Points for different purposes -- one generating Flows with round-trip times for passive performance measurement, and one generating billing records 💸 Once correlated, these Flows could be used to produce Aggregated Flows containing both volume and performance information together 🥰 The correlation and normalization operation described in Section 4.2.1 handles this specific case of correlation. Flow correlation in the general case is outside the scope of this document 🙌
4. Architecture for Flow Aggregation 🏗️
this section specifies the architecture of the Intermediate Aggregation Process and how it fits into the IPFIX architecture 💜
4.1. Aggregation within the IPFIX Architecture 🦋
okay so an Intermediate Aggregation Process (IAP 💅) could be deployed in any of three spots in the IPFIX architecture ✨. Most of the time aggregation happens inside a Mediator, which collects Original Flows from an Original Exporter and then exports Aggregated Flows 🫶, but it can also happen before the initial export or after the final collection, like you can see in Figure 1 🎀. Having an IAP at any of these spots is totally optional, bestie 💖.
+===========================================+
| IPFIX Exporter +----------------+ |
| | Metering Proc. | |
| +-----------------+ +----------------+ |
| | Metering Proc. | or | IAP | |
| +-----------------+----+----------------+ |
| | Exporting Process | |
| +-|----------------------------------|--+ |
+===|==================================|====+
| |
+===|===========================+ |
| | Aggregating Mediator | |
+ +-V-------------------+ | |
| | Collecting Process | | |
+ +---------------------+ | |
| | IAP | | |
+ +---------------------+ | |
| | Exporting Process | | |
+ +-|-------------------+ | |
+===|===========================+ |
| |
+===|==================================|=====+
| | Collector | |
| +-V----------------------------------V-+ |
| | Collecting Process | |
| +------------------+-------------------+ |
| | IAP | |
| +-------------------+ |
| (Aggregation | File Writer | |
for Storage) +-----------|-------+ |
+================================|===========+
|
+------V-----------+
| IPFIX File |
+------------------+Figure 1: Potential Aggregation Locations
The Mediator use case gets even more detail in Figures A and B in [RFC6183] 🌸.
Aggregation can be applied for either intermediate or final analytic purposes 📊. Sometimes it makes total sense to export Aggregated Flows right after metering 💜, like if the Exporting Process is driving a time series visualization 📈, or when Flow data export bandwidth is restricted and Flow or packet sampling just isn't an option 😭. ngl this case is literally covered by the IPFIX architecture [RFC5470] 🧚: the Flow Keys are simply a subset of the ones that would normally be used, and the time intervals can be different from the cache policies the Metering Process usually offers ⭐. A Metering Process in this setup MAY choose to simulate the generation of larger Flows so it can produce Original Flow counts, if the application needs to be compatible with an Intermediate Aggregation Process deployed somewhere else 🔥.
When an Intermediate Aggregation Process is used for data reduction for storage purposes, it can take Original Flows from a Collecting Process or File Reader and pass Aggregated Flows to a File Writer for storage 💾.
Deploying an IAP within a Mediator [RFC5982] is a way more flexible setup 👑. The Mediator consumes Original Flows and produces Aggregated Flows, and this arrangement fits any of the use cases detailed in Section 3 🌈. Original Flows from multiple sources can even be merged into a single stream of Aggregated Flows 🍓. The architectural specifics aren't addressed here, because this document is only concerned with the aggregation operation itself, so check [IPFIX-MED-PROTO] for the deets 🙈.
The data paths into and out of an Intermediate Aggregation Process are shown in Figure 2 ✨.
packets --+ IPFIX Messages IPFIX Files
| | |
V V V
+==================+ +====================+ +=============+
| Metering Process | | Collecting Process | | File Reader |
| | +====================+ +=============+
| (Original Flows | | |
| or direct | | Original Flows |
| aggregation) | V V
+ - - - - - - - - -+======================================+
| Intermediate Aggregation Process (IAP) |
+=========================================================+
| Aggregated Aggregated |
| Flows Flows |
V V
+===================+ +=============+
| Exporting Process | | File Writer |
+===================+ +=============+
| |
V V
IPFIX Messages IPFIX FilesFigure 2: Data Paths through the Aggregation Process
Note that since Aggregated Flows are IPFIX Flows, an Intermediate Aggregation Process may aggregate already Aggregated Flows from an upstream IAP, as well as Original Flows from an upstream Original Exporter or Metering Process 🦋.
Aggregation may also need to correlate Original Flows from multiple Metering Processes, each one using a different Template with different Flow Keys and values 🧩. That arrangement is shown in Figure 3 🌸. In this case, the correlation and normalization operation described in Section 4.2.1 handles merging the Original Flows before aggregation happens 💅.
packets --+---------------------+------------------+
| | |
V V V
+====================+ +====================+ +====================+
| Metering Process 1 | | Metering Process 2 | | Metering Process n |
+====================+ +====================+ +====================+
| | Original Flows |
V V V
+==================================================================+
| Intermediate Aggregation Process + correlation / normalization |
+==================================================================+
| Aggregated Aggregated |
| Flows Flows |
V V
+===================+ +=============+
| Exporting Process | | File Writer |
+===================+ +=============+
| |
+------------> IPFIX Messages <----------+Figure 3: Aggregating Original Flows from Multiple Metering Processes
4.2. Intermediate Aggregation Process Architecture ✨
okay bestie, so an Intermediate Aggregation Process (IAP) is basically a little factory 🏭 that runs a function made of four types of operations on Partially Aggregated Flows 💅. Check out Figure 4 💖. The four are interval distribution (temporal), key aggregation (spatial), value aggregation (spatial), and aggregate combination. Partially Aggregated Flows (from Section 2) are the in-between results of aggregation, and they live entirely inside the IAP 🦋.
Original Flows / Original Flows requiring correlation
+=============|===================|===================|=============+
| | Intermediate | Aggregation | Process |
| | V V |
| | +-----------------------------------------------+ |
| | | (optional) correlation and normalization | |
| | +-----------------------------------------------+ |
| | | |
| V V |
| +--------------------------------------------------------------+ |
| | interval distribution (temporal) | |
| +--------------------------------------------------------------+ |
| | ^ | ^ | |
| | | Partially Aggregated | | | |
| V | Flows V | | |
| +-------------------+ +--------------------+ | |
| | key aggregation |<------| value aggregation | | |
| | (spatial) |------>| (spatial) | | |
| +-------------------+ +--------------------+ | |
| | | | |
| | Partially Aggregated | | |
| V Flows V V |
| +--------------------------------------------------------------+ |
| | aggregate combination | |
| +--------------------------------------------------------------+ |
| | |
+=======================================|===========================+
V
Aggregated Flows
Figure 4: Conceptual Model of Aggregation Operations within an IAPHere's the lineup, and each one is a whole vibe 🌸:
- Interval distribution: this is the temporal one 🕰️. It slaps an Aggregation Interval onto the Partially Aggregated Flow. That interval can be regular, irregular, or derived from the timing of the Original Flows themselves. We dig into it in Section 5.1.
- Key aggregation: this is the spatial one that changes the Flow Key fields 🔑. It can add, modify, or delete Flow Key fields in the Partially Aggregated Flows. New Flow Keys can come from existing ones (like looking up an AS number (ASN) for an IP address), or get "promoted" from specific non-key fields (like when you aggregate Flows by packet count per Flow). Key aggregation can also add brand-new non-key fields that come from Flow Keys which get deleted during the process, mainly counters of unique reduced keys. See Section 5.2 for the full tea ☕.
- Value aggregation: another spatial one, but this time it messes with the non-key fields 🎀. It can add, modify, or delete them in the Partially Aggregated Flows. These non-key fields might get "demoted" from existing key fields, or be derived from existing key or non-key fields. Section 5.3 has the deets.
- Aggregate combination: this one is the closer 👑. It squishes multiple Partially Aggregated Flows (that have already been through interval distribution, key aggregation, and value aggregation) into one Aggregated Flow per set of Flow Key values and Aggregation Interval, as long as they share those Flow Keys and Aggregation Intervals. Section 5.4 explains it properly.
- Correlation and normalization: this one is optional 🫶. It only kicks in when you're accepting Original Flows from Metering Processes that export different views of basically the same Flows before aggregation happens. The specifics are in Section 4.2.1, just below.
The first three operations can be run any number of times, in any order, either on Original Flows or on the results of one of the operations above 🌈. There's one caveat though, and it's a big one 😭: since Flows carry their own interval data, any spatial aggregation operation implies a temporal aggregation operation. So at least one interval distribution step is required by this architecture, even if it's implicit. That's why it's shown as the first step in the diagram above, just to keep things simple 🍓. Once all the aggregation operations are done, aggregate combination makes sure that for a given Aggregation Interval, set of Flow Key values, and Observation Domain, the Intermediate Aggregation Process only produces one Flow ✨.
This model describes the operations inside a single Intermediate Aggregation Process, and most aggregation is expected to happen within one process 💜. But here's the fun part: since the steps can be applied in any order and aggregate combination is idempotent, any number of Intermediate Aggregation Processes running in series can be modeled as one single process 🧚. So aggregation operations can be spread across however many processes you want, if application or deployment considerations call for it 🦋.
4.2.1. Correlation and Normalization
okay so picture this 🙈: you're accepting Original Flows from multiple Metering Processes, and each one gives you a different view of the Original Flow, as seen from the point of view of the IAP. An optional correlation and normalization operation takes each of those single Flow Records and combines them into a set of unified Partially Aggregated Flows before interval distribution gets applied 💅. These unified Flows look like they were measured at one single Metering Process that used the union of all the Flow Keys and non-key fields from every Metering Process sending Original Flows to the IAP. Iconic 🌟.
Here's the catch though 😬: because of export errors or other slight irregularities in Flow metering, those multiple views might not be perfectly consistent. So normalization applies a set of corrections that are specific to the aggregation application, to make sure the unified Flows are consistent 🎀.
Generally speaking, correlation and normalization should take multiple views of essentially the same Flow, as determined by how the operation itself is configured, and turn them into a single unified Flow 💖. Flows that are essentially different should not be unified by this operation 🙅♀️. That means the operation needs enough info about how the Metering Processes it correlates Original Flows from are configured and deployed, so it can make that call correctly and consistently 🔍.
The exact steps for correlating and normalizing Flows are application, implementation, and deployment specific, so this document won't specify them any further 🤷♀️.
5. IP Flow Aggregation Operations ✨
okay so, as Section 2 said, an Aggregated Flow is just an IPFIX Flow generated from Original Flows by an Intermediate Aggregation Process 🦋. Here's where we break down how that actually happens inside an Intermediate Aggregation Process 💅.
5.1. Temporal Aggregation through Interval Distribution
Interval distribution slaps a time interval onto the resulting Aggregated Flows ⏰. Which interval you pick depends on the aggregation application 🌸. The interval can be derived from the Original Flows themselves (for example, you might pick one that covers the entire time containing all the Flows sharing a given Key, which is the Time Composition thing from Section 5.1.2), or it can be externally imposed. If it's externally imposed, it can be regular (like every five minutes) or irregular (like having different time resolutions at different times of day, under different network conditions, or even for different sets of Original Flows) 🎀.
The length of the imposed interval comes with trade-offs, bestie 💭. Shorter intervals give you higher-resolution aggregated data and, in streaming applications, faster reaction time ⚡. Longer intervals usually mean more data reduction and simpler counter distribution 🧁. Specifically, counter distribution gets a LOT simpler when the interval is longer than the duration of the longest Original Flow, which is usually set by that Original Flow's Metering Process active timeout 🕰️. In that case, an Original Flow can contribute to at most two Aggregated Flows, and the more complex value distribution methods become inapplicable 🙃.
| | | |
| |<--Flow A-->| | | |
| |<--Flow B-->| | |
| |<-------------Flow C-------------->| |
| | | |
| interval 0 | interval 1 | interval 2 |
Figure 5: Illustration of Interval DistributionIn Figure 5, we show three common ways interval distribution works with regular intervals across three Original Flows 📊. Flow A's start and end times both sit inside a single interval 0, so Flow A only contributes to one Aggregated Flow 🩷. Flow B has the same duration, but it crosses the boundary between interval 0 and interval 1, so it contributes to two Aggregated Flows and its counters have to be distributed between them 💫. With only two intervals, though, it can be simplified a bit: you can just pick one of the two intervals, or split proportionally between them 🍰. Only Flows like A and B show up when the interval is longer than the duration of the longest Original Flow, like we said above 🌷. Flow C is the messy one 🌪️. It contributes to more than two Aggregated Flows, so its counters have to be distributed according to some policy, as covered in Section 5.1.1 💜.
5.1.1. Distributing Values across Intervals ✨
Okay so counters in Aggregated Flows are basically treated the same way as in any Flow 💖 Each counter gets calculated on its own, like it was pulled from the set of packets in the Original Flow. So delta counters get summed, and the most recent total count for each Original Flow gets taken and then summed across Flows, and so on. Iconic consistency 💅
When the Aggregation Interval is guaranteed to be longer than the longest Original Flow, a Flow can cross at most one Interval boundary. That means it can only contribute to at most two Aggregated Flows 🦋 The most common move here is to arbitrarily but consistently pick whether the Original Flow's counters go to the first or the last Aggregated Flow it could touch. Simple, clean, no drama 🌸
But it gets messier when the Aggregation Interval is shorter than the longest Original Flow in the source data 😭 Now each Original Flow can only partially cover one or more time intervals, and it can apply to one or more Aggregated Flows. So the Intermediate Aggregation Process has to distribute the counters from the Original Flows across one or more of the resulting Aggregated Flows. There are a few ways to do this 🧚 They're listed below in roughly increasing order of complexity and accuracy, and most of them are only really needed in specialized cases.
- End Interval: The counters for an Original Flow get added to the counters of the appropriate Aggregated Flow that contains the end time of the Original Flow.
- Start Interval: The counters for an Original Flow get added to the counters of the appropriate Aggregated Flow that contains the start time of the Original Flow.
- Mid Interval: The counters for an Original Flow get added to the counters of a single appropriate Aggregated Flow that contains some timestamp between the start and end time of the Original Flow.
- Simple Uniform Distribution: Each counter for an Original Flow gets divided by the number of time intervals the Original Flow covers (that is, the appropriate Aggregated Flows that share the same Flow Keys). That number then gets added to each corresponding counter in each Aggregated Flow 🍓
- Proportional Uniform Distribution: This is like simple uniform distribution, but it also accounts for the fractional portions of a time interval that the Original Flow covers in the first and last time interval 🎀 Each counter for an Original Flow gets divided by the number of time units the Original Flow covers, which gives a mean count rate. That rate then gets multiplied by the number of time units in the intersection of the duration of the Original Flow and the time interval of each Aggregated Flow.
- Simulated Process: Each counter of the Original Flow gets distributed among the intervals of the Aggregated Flows according to some function the Intermediate Aggregation Process uses, based on properties of Flows presumed to be like the Original Flow. For example, Flow Records representing bulk transfer might follow a more or less proportional uniform distribution, while interactive processes are way burstier 🌈
- Direct: The Intermediate Aggregation Process has access to the original packet timings from the packets that make up the Original Flow, and it uses those to distribute or recalculate the counters 👑
A method for exporting the distribution of counters across multiple Aggregated Flows is detailed in Section 7.4. Anyway, no matter which method you pick, counters MUST be distributed across the multiple Aggregated Flows in a way that preserves the total count, within the limits of accuracy of the implementation. This is what lets data be aggregated and re-aggregated with negligible loss of the original count information 🫶 Also, to avoid confusion when interpreting the aggregated data, all the counters in a given Aggregated Flow MUST be distributed using the same method. No mixing and matching, bestie 🙈
More complex counter distribution methods usually mean the interval distribution process has to keep track of multiple "current" time intervals at once. That can add some delay to the aggregation operation, because an interval should only expire and become available for export when no more Original Flows that apply to it are expected to show up at the Intermediate Aggregation Process ⏳
Now here's the tea 🍵 There's no guarantee that Flows from the Original Exporter will arrive in any particular order. That can happen for transport-specific reasons (like UDP reordering) or for reasons specific to how the Metering Process or Exporting Process is implemented. So even the simpler distribution methods may have to deal with Flows arriving in an order other than start time or end time 😭 That means using larger intervals doesn't get rid of the need to buffer Partially Aggregated Flows within "current" time intervals. The buffering is what makes sure the IAP can accept Flow time intervals in any arrival order. More generally, the interval distribution process SHOULD accept Flow start and end times in the Original Flows in any reasonable order. How intervals expire during interval distribution operations depends on the implementation and the deployment requirements, and it MUST be made configurable in any context where "reasonable order" isn't obvious at implementation time. This operation may cause delay and loss introduced by the IAP, which is detailed in Section 6.2 💀
5.1.2. Time Composition 🧚♀️
Time Composition (as in Section 5.4 of [RFC5982], also called interval combination) is a special case of aggregation. Here, interval distribution imposes longer intervals on Flows that have matching keys and "chained" start and end times, without doing any key reduction. The goal is to join long-lived Flows that may have been split, for example because of an active timeout that's shorter than the actual duration of the Flow 🦋 In this case no Key aggregation is applied, and the Aggregation Interval gets chosen on a per-Flow basis so it covers the interval spanned by the set of Aggregated Flows. This can be used on its own to normalize split Flows, or combined with other aggregation functions to get more accurate Original Flow counts. Main character energy 👑
5.1.3. External Interval Distribution 🌸
Okay, so a lot of the difficulty of interval distribution at an IAP can be skipped entirely 🙌 You just configure the original Exporters to synchronize the time intervals in the Original Flows with the aggregation interval you want. The Original Flows then get split so they line up perfectly with the time intervals imposed during interval imposition, as shown in Figure 6. Heads up though, this might make them less useful for non-aggregation purposes ⚠️ The upside is that this approach lets the Intermediate Aggregation Process use Start Interval or End Interval distribution, while having the same information that direct interval distribution would have. It's giving efficiency 💅
| | | |
|<----Flow D---->|<----Flow E---->|<----Flow F---->|
| | | |
| interval 0 | interval 1 | interval 2 |
Figure 6: Illustration of External Interval Distribution5.2. Spatial Aggregation of Flow Keys 🗺️
Key aggregation generates a new set of Flow Key values for the Aggregated Flows. It does this from the Original Flow Key and the non-key fields in the Original Flows, or from correlating the Original Flow information with some external source. There are two basic operations here 🎀 First, Aggregated Flow Keys can be derived directly from Original Flow Keys through reduction. They can also be derived by dropping fields or precision from the Original Flow Keys. Second, Aggregated Flow Keys can be derived through replacement, for example by removing one or more fields from the Original Flow and replacing them with fields derived from the removed ones. Replacement may refer to external information (like IP to AS number mappings). It can apply to Flow Keys as well as non-key fields. Let's say you have an app that aggregates Original Flows by packet count, so it makes an Aggregated Flow for all one-packet Flows, one for all two-packet Flows, and so on. That app would promote the packet count to a Flow Key 🔥
Key aggregation may also add new non-key fields to the Aggregated Flows, specifically Original Flow counters and unique reduced key counters. These get covered in more detail in Sections 5.2.1 and 5.2.2, respectively 📚
In any key aggregation operation, reduction and/or replacement may be applied any number of times and in any order. Which of these operations a given implementation supports depends on the implementation and the application 💖
Original Flow Keys
Original Flow Keys
+---------+---------+----------+----------+-------+-----+
| src ip4 | dst ip4 | src port | dst port | proto | tos |
+---------+---------+----------+----------+-------+-----+
| | | | | |
retain mask /24 X X X X
| |
V V
+---------+-------------+
| src ip4 | dst ip4 /24 |
+---------+-------------+
Aggregated Flow Keys (by source address and destination /24 network)
Figure 7: Illustration of Key Aggregation by ReductionFigure 7 shows an example of a reduction operation: aggregating by source address and destination /24 network 🧁 Here the port, protocol, and type-of-service information gets removed from the Flow Key, the source address is kept, and the destination address is masked by dropping the lower 8 bits.
Original Flow Keys
+---------+---------+----------+----------+-------+-----+
| src ip4 | dst ip4 | src port | dst port | proto | tos |
+---------+---------+----------+----------+-------+-----+
| | | | | |
V V | | | |
+-------------------+ X X X X
| ASN lookup table |
+-------------------+
| |
V V
+---------+---------+
| src asn | dst asn |
+---------+---------+
Aggregated Flow Keys (by source and destination ASN)
Figure 8: Illustration of Key Aggregation
by Reduction and ReplacementFigure 8 shows an example of a reduction and replacement operation: aggregating by source and destination Border Gateway Protocol (BGP) Autonomous System Number (ASN) when there's no ASN information in the Original Flow 🌈 Here the port, protocol, and type-of-service information gets removed from the Flow Keys. Meanwhile the source and destination addresses get run through an IP address to ASN lookup table, and the Aggregated Flow Keys end up made up of the resulting source and destination ASNs. Lowkey genius 🫧
5.2.1. Counting Original Flows 🧮
okay so when we squish a bunch of Original Flows into one Aggregated Flow, it is SO useful to know how many Original Flows are hiding inside it 👀. Section 7.2 brings in four new Information Elements to export these counters 🎀.
There are two possible ways to count Original Flows, and we call them conservative and non-conservative. Conservative Flow counting has the main-character energy of each Original Flow contributing exactly one to the total Flow count within a set of Aggregated Flows 💅. Basically, conservative counters get distributed just like any other counter during interval distribution, except every Original Flow is treated as having a Flow count of one. And when an Original Flow's count has to be split across a set of Aggregated Flows, using a distribution method that doesn't keep that Flow whole inside a single Aggregated Flow, conservative Flow counting needs a fractional representation 🍓.
Non-conservative Flow counting is different 🦋. It counts how many Contributing Flows are represented in an Aggregated Flow, and the counters are not distributed at all. An Original Flow that shows up in N Aggregated Flows adds N to the sum of non-conservative Flow counts, one for each Aggregated Flow it's in. So the sum of conservative Flow counts over a set of Aggregated Flows is always equal to the number of Original Flows, while the sum of non-conservative Flow counts is greater than or equal to the number of Original Flows. It's giving math but make it fun ✨.
Let's do an example, because I need you to see this. Picture Flows A, B, and C from Figure 5 🌸. Say the key aggregation step squishes all three Flows onto the same aggregated Flow Key, and start interval counter distribution is in effect. The conservative Flow count for interval 0 is 3, since Flows A, B, and C all begin in that interval, and it's 0 for the other two intervals. The non-conservative Flow count for interval 0 is also 3 because A, B, and C are all present there, it's 2 for interval 1 (Flows B and C), and it's 1 for interval 2 (just Flow C) 😭. Add up the conservative counts, 3 + 0 + 0 = 3, and that's the number of Original Flows. Add up the non-conservative counts, 3 + 2 + 1 = 6, and that's bigger, which is exactly the point 💜.
Heads up, bestie: the active and inactive timeouts used to generate the Original Flows, plus the cache policy used to make those Flows, change how meaningful either count is during aggregation 👀. So in general, Original Exporters using the IPFIX Configuration Model SHOULD be configured to export Flows with equal or similaractiveTimeoutandinactiveTimeoutvalues, and the samecacheMode, as defined in [RFC6728]. Original Exporters that aren't using the IPFIX Configuration Model SHOULD be configured the same way 🫶.
5.2.2. Counting Distinct Key Values 🔥
One super common move in aggregation is counting the distinct key values that got reduced away during key aggregation 🙈. The most common version is counting distinct hosts per Flow Key. For example, distinct sources per destination, or distinct destinations per source, are classic metrics for host characterization or anomaly detection 👑. These new non-key fields get added during key aggregation.
For these apps, Information Elements for distinct counts of IPv4 and IPv6 addresses are defined in Section 7.3 🌈. They're named distinctCountOf(KeyName). More of these Information Elements should be registered with IANA on an as-needed basis.
5.3. Spatial Aggregation of Non-key Fields 🎀
Aggregation can also lead to new value fields showing up. Some are fields demoted from key fields, and others are derived from other value fields in the Original Flows 🧚. Specific cases of this get their own subsections below.
5.3.1. Counter Statistics 📊
Some aggregation apps want different stats than the ones each non-key field already comes with. For instance, flags are natively combined with a union, and delta counters get combined by summing them. So an app might want the minimum and maximum packet counts per Flow, or mean bytes per packet per Contributing Flow, and so on 💖. Some Information Elements for these apps are already in the IANA IPFIX Information Elements registry [IANA-IPFIX], like minimumIpTotalLength 🍓.
A full spec of extra aggregate counter stats is outside the scope of this document 🙃. These should be added to the IANA IPFIX Information Elements registry in the future, on a per-application, as-needed basis.
5.3.2. Derivation of New Values from Flow Keys and Non-key fields ✨
More complex operations can produce other derived fields from the set of values or Flow Keys that got reduced away during aggregation 🧠. A prime example is sample entropy calculation. It counts distinct values and their frequency, so it's kind of like distinct key counting from Section 5.2.2, except it can be applied to the distribution of values for any Flow field 💅.
Sample entropy gives you a single normalized number that represents the spread of values, and it's useful for anomaly detection 🔥. The vibe is this: if a small number of keys show up really often, entropy gets pushed down toward zero, but if a large number of keys each show up with lower frequency, entropy goes up 📉📈.
Entropy stats are generally useful for identifier keys, like IP addresses, port numbers, AS numbers, and so on 🦋. You can also calculate them on Flow length, Flow duration fields, and similar things, even though that usually produces less distinct value shifts when the traffic mix changes 🌸.
Here's a practical example. If one host scans a lot of other hosts, source IP entropy goes down and target IP entropy goes up 👀. You can see a similar effect with ports. This pattern can also come from the scan traffic of a fast Internet worm 🐛. Another example is a Distributed Denial of Service (DDoS) flooding attack against a single target, or a small number of targets, which pushes source IP entropy up and target IP entropy down 😭.
A full spec of extra derived values or entropy Information Elements is outside the scope of this document 💜. Any that come up should be added to the IANA IPFIX Information Elements registry later on, on a per-application, as-needed basis.
5.4. Aggregation Combination 🫧
Interval distribution and key aggregation together can generate multiple Partially Aggregated Flows that cover the same time interval with the same set of Flow Key values 👯. Combining those Partially Aggregated Flows into one single Aggregated Flow is called aggregation combination ✨. Generally, non-Key values from multiple Contributing Flows get combined using the same operation that combines values from packets into Flows for each Information Element. So delta counters get summed, flags get unioned, and so on 💅.
6. Additional Considerations and Special Cases in Flow Aggregation 🌈
6.1. Exact versus Approximate Counting during Aggregation 🎯
Sometimes, especially when aggregation happens on devices with limited resources, or when exact counts matter less than relative magnitudes (like when you're driving graphical displays), counter distribution during key aggregation may be done with approximate counting, such as Bloom filters 🌸. Whether to use approximate counting is up to the implementation and the application 🫶.
6.2. Delay and Loss Introduced by the IAP ⏳
When Original Flows arrive in export order from live captured traffic, the Intermediate Aggregation Process waits for all the Original Flows that may contribute to a given interval during interval distribution 🕰️. This is generally dominated by the active timeout of the Metering Process measuring those Original Flows. For example, if the Metering Processes are configured with a five-minute active timeout, the Intermediate Aggregation Process adds a delay of at least five minutes to all exported Aggregated Flows so it can be sure it has every Original Flow 😌. And if you're aggregating Flows from multiple Metering Processes with different active timeouts, the delay is set by the maximum active timeout 📈.
Okay, this is the important bit 🚨. Sometimes extra delay at the original Exporter makes an IAP close an interval before the last Original Flow(s) for that interval arrive. In that case, the IAP MAY drop the late Original Flow(s) 💀. Accounting for Flows lost at an Intermediate Process because of issues like this is covered in [IPFIX-MED-PROTO] 🧾.
6.3. Considerations for Aggregation of Sampled Flows 🍬
The accuracy of Aggregated Flows can also be affected by sampling, either sampling of the Original Flows or sampling of the packets that make up those Original Flows 🎲. At the time of writing, the effect of sampling on Flow aggregation is still an open research question 🔬. Still, to get the most comparable Aggregated Flows, aggregation of sampled Flows should only be applied to Original Flows sampled with the same sampling rate and sampling algorithm. The same goes for Flows created from packets sampled with the same sampling rate and sampling algorithm, or for Original Flows that have been normalized as if they had the same sampling rate and algorithm before aggregation 💖. For more on packet sampling within IPFIX, see [RFC5476]. For more on Flow sampling within the IPFIX Mediator framework, see [RFC7014] 🧚.
6.4. Considerations for Aggregation of Heterogeneous Flows 🌀
Aggregation can be applied to Original Flows from different sources and of different types, which means they might be represented using different, maybe wildly different, Templates 🎨. If your goal is to keep the heterogeneous Original Flows separate and aggregate them into heterogeneous Aggregated Flows, each aggregation should be done at its own Intermediate Aggregation Process 🗂️. The Observation Domain ID on the Messages carrying the output Aggregated Flows can be used to identify the different Processes and to segregate the output 🏷️.
But if you want to aggregate everything into a single stream of Aggregated Flows that represents one type of data, and the Original Flows might represent the same original packet at two different Observation Points, then the Original Flows should be correlated by the correlation and normalization operation within the IAP 🔗. That way, each packet only shows up in a single Aggregated Flow, or in a set of Aggregated Flows that differ only by aggregation interval ✨🫶.
7. Export of Aggregated IP Flows Using IPFIX 📤
In general, Aggregated Flows are exported in IPFIX just like any other Flow 💫. That said, a few parts of Aggregated Flow export benefit from extra guidelines or new Information Elements that represent aggregation metadata or information generated during aggregation 🎁. Those are detailed in the subsections below.
7.1. Time Interval Export ⏱️
Since an Aggregated Flow is simply a Flow, the existing timestamp Information Elements in the IPFIX Information Model, like flowStartMilliseconds and flowEndNanoseconds, are already enough to specify the time interval for aggregation 🙌. So no new aggregation-specific Information Elements are needed for exporting time interval info 🎀.
Each Aggregated Flow that carries timing information SHOULD contain both an interval start and an interval end timestamp 🕒.
7.2. Flow Count Export 🔢
The following four Information Elements are defined to count Original Flows, as discussed in Section 5.2.1 💜.
7.2.1. originalFlowsPresent ✨
okay so this one is the non-conservative count of Original Flows that feed into this Aggregated Flow 🌸. the important bit: non-conservative counts don't have to add back up to the original count when you re-aggregate, so don't expect them to 💀
- Abstract Data Type:
unsigned64 - Data Type Semantics:
deltaCounter - ElementID:
375
7.2.2. originalFlowsInitiated 🦋
this is the conservative count of Original Flows whose first packet shows up in this Aggregated Flow. conservative means it must sum to the original count when you re-aggregate, no excuses 😤
- Abstract Data Type:
unsigned64 - Data Type Semantics:
deltaCounter - ElementID:
376
7.2.3. originalFlowsCompleted 🎀
same energy as the last one, but for the last packet instead of the first 🧚 this is also a conservative count of Original Flows whose last packet is represented in this Aggregated Flow, so it must sum to the original count on re-aggregation too 🫶
- Abstract Data Type:
unsigned64 - Data Type Semantics:
deltaCounter - ElementID:
377
7.2.4. deltaFlowCount 💜
this is the conservative count of Original Flows contributing to this Aggregated Flow. it may be distributed using any of the methods described by the valueDistributionMethod Information Element, so check that one if you want the details 👑
- Abstract Data Type:
unsigned64 - Data Type Semantics:
deltaCounter - ElementID:
3
7.3. Distinct Host Export 🌈
the next six Information Elements are the distinct counts of source and destination network-layer addresses. they're how we export distinct host counts that got reduced away during key aggregation 🍓
7.3.1. distinctCountOfSourceIPAddress 💅
this is the count of distinct source IP address values for Original Flows in this Aggregated Flow, and it doesn't care about IP version. honestly this is the one to reach for first ✨ only switch to the version-specific counters if you actually need to split them by version 🙈
- Abstract Data Type:
unsigned64 - Data Type Semantics:
totalCounter - ElementID:
378
7.3.2. distinctCountOfDestinationIPAddress 🫶
same vibe as the source one, but for destination IP address values. again, it's version-agnostic and it's preferred over the version-specific counters below, unless you need to separate things by version 🌸
- Abstract Data Type:
unsigned64 - Data Type Semantics:
totalCounter - ElementID:
379
7.3.3. distinctCountOfSourceIPv4Address 🦋
the count of distinct source IPv4 address values for Original Flows in this Aggregated Flow 🍓
- Abstract Data Type:
unsigned32 - Data Type Semantics:
totalCounter - ElementID:
380
7.3.4. distinctCountOfDestinationIPv4Address 🎀
the count of distinct destination IPv4 address values for Original Flows in this Aggregated Flow 🧚
- Abstract Data Type:
unsigned32 - Data Type Semantics:
totalCounter - ElementID:
381
7.3.5. distinctCountOfSourceIPv6Address 💖
the count of distinct source IPv6 address values for Original Flows in this Aggregated Flow. note that this one is unsigned64, not unsigned32 like the IPv4 version, so the numbers can get bigger 🔥
- Abstract Data Type:
unsigned64 - Data Type Semantics:
totalCounter - ElementID:
382
7.3.6. distinctCountOfDestinationIPv6Address 👑
the count of distinct destination IPv6 address values for Original Flows in this Aggregated Flow, also unsigned64 💜
- Abstract Data Type:
unsigned64 - Data Type Semantics:
totalCounter - ElementID:
383
7.4. Aggregate Counter Distribution Export ⭐
when you export counters that got distributed among Aggregated Flows (the stuff from Section 5.1.1), the Exporting Process MAY export an Aggregate Counter Distribution Option Record for each Template describing Aggregated Flow records. the Options Template for that is below, and it uses the valueDistributionMethod Information Element, which we also define below 🎀
here's the lowkey best part: in most cases distribution is simple. the counters from Contributing Flows just get accounted to the first Interval they touch, which is the default. so for that default case you don't need an Aggregate Counter Distribution Record at all 💅 those records only matter in more exotic situations, like when your Aggregation Interval is smaller than the durations of the Original Flows 🌈
7.4.1. Aggregate Counter Distribution Options Template 🧚
this Options Template defines the Aggregate Counter Distribution Record, which binds a value distribution method to a Template ID 🫶 the scope is the Template ID. per [RFC7011], its uniqueness is local to the Transport Session and Observation Domain that generated it 🌸 the Collecting Process uses this to figure out how the counters were distributed 💖
the fields are:
+-----------------------------+-------------------------------------+
| IE | Description |
+-----------------------------+-------------------------------------+
| templateId [scope] | The Template ID of the Template |
| | defining the Aggregated Flows to |
| | which this distribution option |
| | applies. This Information Element |
| | MUST be defined as a Scope field. |
| valueDistributionMethod | The method used to distribute the |
| | counters for the Aggregated Flows |
| | defined by the associated Template. |
+-----------------------------+-------------------------------------+7.4.2. valueDistributionMethod Information Element 🔥
okay this one is the big boss 👑 it's a description of the method used to distribute the counters from Contributing Flows into the Aggregated Flow records described by an associated scope (usually a Template) 💅 the method applies to all the non-Key Information Elements in the referenced scope where value distribution is a valid operation. the one exception is that if originalFlowsInitiated and/or originalFlowsCompleted show up in the Template, they're not subject to this method, because they each infer their own distribution method 🦋
this is meant to be the complete set of possible value distribution methods, encoded like this:
+-------+-----------------------------------------------------------+
| Value | Description |
+-------+-----------------------------------------------------------+
| 0 | Unspecified: The counters for an Original Flow are |
| | explicitly not distributed according to any other method |
| | defined for this Information Element; use for arbitrary |
| | distribution, or distribution algorithms not described by |
| | any other codepoint. |
| | --------------------------------------------------------- |
| | |
| 1 | Start Interval: The counters for an Original Flow are |
| | added to the counters of the appropriate Aggregated Flow |
| | containing the start time of the Original Flow. This |
| | should be assumed the default if value distribution |
| | information is not available at a Collecting Process for |
| | an Aggregated Flow. |
| | --------------------------------------------------------- |
| | |
| 2 | End Interval: The counters for an Original Flow are added |
| | to the counters of the appropriate Aggregated Flow |
| | containing the end time of the Original Flow. |
| | --------------------------------------------------------- |
| | |
| 3 | Mid Interval: The counters for an Original Flow are added |
| | to the counters of a single appropriate Aggregated Flow |
| | containing some timestamp between start and end time of |
| | the Original Flow. |
| | --------------------------------------------------------- |
| | |
| 4 | Simple Uniform Distribution: Each counter for an Original |
| | Flow is divided by the number of time intervals the |
| | Original Flow covers (i.e., of appropriate Aggregated |
| | Flows sharing the same Flow Key), and this number is |
| | added to each corresponding counter in each Aggregated |
| | Flow. |
| | --------------------------------------------------------- |
| | |
| 5 | Proportional Uniform Distribution: Each counter for an |
| | Original Flow is divided by the number of time units the |
| | Original Flow covers, to derive a mean count rate. This |
| | mean count rate is then multiplied by the number of time |
| | units in the intersection of the duration of the Original |
| | Flow and the time interval of each Aggregated Flow. |
| | This is like simple uniform distribution, but accounts |
| | for the fractional portions of a time interval covered by |
| | an Original Flow in the first and last time interval. |
| | --------------------------------------------------------- |
| | --------------------------------------------------------- |
| 6 | Simulated Process: Each counter of the Original Flow is |
| | distributed among the intervals of the Aggregated Flows |
| | according to some function the Intermediate Aggregation |
| | Process uses based upon properties of Flows presumed to |
| | be like the Original Flow. This is essentially an |
| | assertion that the Intermediate Aggregation Process has |
| | no direct packet timing information but is nevertheless |
| | not using one of the other simpler distribution methods. |
| | The Intermediate Aggregation Process specifically makes |
| | no assertion as to the correctness of the simulation. |
| | --------------------------------------------------------- |
| | |
| 7 | Direct: The Intermediate Aggregation Process has access |
| | to the original packet timings from the packets making up |
| | the Original Flow, and uses these to distribute or |
| | recalculate the counters. |
+-------+-----------------------------------------------------------+- Abstract Data Type:
unsigned8 - ElementID:
384
8. Examples ✨
okay bestie, this is the fun part 💖 Same data, same Template, and we're gonna aggregate it a bunch of different ways to show off all the different functions an Intermediate Aggregation Process could do 🦋. Templates are shown in IESpec format, as introduced in [RFC7013] 🎀. The source data is a simplified Flow with timestamps, a traditional 5-tuple, and an octet count, and the Flow Key fields are the 5-tuple 🌸. The Template is in Figure 9 💅.
flowStartMilliseconds(152)[8]
flowEndMilliseconds(153)[8]
sourceIPv4Address(8)[4]{key}
destinationIPv4Address(12)[4]{key}
sourceTransportPort(7)[2]{key}
destinationTransportPort(11)[2]{key}
protocolIdentifier(4)[1]{key}
octetDeltaCount(1)[8]Figure 9: Input Template for Examples
The input records for the examples in this section are in Figure 10 🍓. Timestamps are written as H:MM:SS.sss, and in this and the later figures, flowStartMilliseconds shows up as 'start time', flowEndMilliseconds as 'end time', sourceIPv4Address as 'source ip4' (with the 'port' after it being sourceTransportPort), destinationIPv4Address as 'dest ip4' (with the 'port' after it being destinationTransportPort), protocolIdentifier as 'pt', and octetDeltaCount as 'oct' 🧚.
start time |end time |source ip4 |port |dest ip4 |port|pt| oct
9:00:00.138 9:00:00.138 192.0.2.2 47113 192.0.2.131 53 17 119
9:00:03.246 9:00:03.246 192.0.2.2 22153 192.0.2.131 53 17 83
9:00:00.478 9:00:03.486 192.0.2.2 52420 198.51.100.2 443 6 1637
9:00:07.172 9:00:07.172 192.0.2.3 56047 192.0.2.131 53 17 111
9:00:07.309 9:00:14.861 192.0.2.3 41183 198.51.100.67 80 6 16838
9:00:03.556 9:00:19.876 192.0.2.2 17606 198.51.100.68 80 6 11538
9:00:25.210 9:00:25.210 192.0.2.3 47113 192.0.2.131 53 17 119
9:00:26.358 9:00:30.198 192.0.2.3 48458 198.51.100.133 80 6 2973
9:00:29.213 9:01:00.061 192.0.2.4 61295 198.51.100.2 443 6 8350
9:04:00.207 9:04:04.431 203.0.113.3 41256 198.51.100.133 80 6 778
9:03:59.624 9:04:06.984 203.0.113.3 51662 198.51.100.3 80 6 883
9:00:30.532 9:06:15.402 192.0.2.2 37581 198.51.100.2 80 6 15420
9:06:56.813 9:06:59.821 203.0.113.3 52572 198.51.100.2 443 6 1637
9:06:30.565 9:07:00.261 203.0.113.3 49914 198.51.100.133 80 6 561
9:06:55.160 9:07:05.208 192.0.2.2 50824 198.51.100.2 443 6 1899
9:06:49.322 9:07:05.322 192.0.2.3 34597 198.51.100.3 80 6 1284
9:07:05.849 9:07:09.625 203.0.113.3 58907 198.51.100.4 80 6 2670
9:10:45.161 9:10:45.161 192.0.2.4 22478 192.0.2.131 53 17 75
9:10:45.209 9:11:01.465 192.0.2.4 49513 198.51.100.68 80 6 3374
9:10:57.094 9:11:00.614 192.0.2.4 64832 198.51.100.67 80 6 138
9:10:59.770 9:11:02.842 192.0.2.3 60833 198.51.100.69 443 6 2325
9:02:18.390 9:13:46.598 203.0.113.3 39586 198.51.100.17 80 6 11200
9:13:53.933 9:14:06.605 192.0.2.2 19638 198.51.100.3 80 6 2869
9:13:02.864 9:14:08.720 192.0.2.3 40429 198.51.100.4 80 6 18289Figure 10: Input Data for Examples
8.1. Traffic Time Series per Source 🌈
Aggregating Flows by source IP address into a time series (that is, on a regular interval) can be used for heavy-hitter analysis later on, and as a source parameter for statistical anomaly detection techniques 👑. Here the Intermediate Aggregation Process imposes an interval, aggregates the key so that every key field except the source IP address gets removed, and then combines the result into a stream of Aggregated Flows 🔥. The imposed interval is five minutes, which is longer than most Flows are; for Flows that cross an interval boundary, the entire Flow is counted in the interval that contains its start time 💜.
In this example we get to peek at the Partially Aggregated Flows after each conceptual operation in the Intermediate Aggregation Process 👀. These are only there to illustrate the conceptual operations, not to suggest an implementation (and yeah, the way this example is set up would not necessarily be the most efficient way to do these operations 🙈). Later examples will skip the Partially Aggregated Flows to keep things short 🫶.
The input could be any Flow Record with a source IP address and an octet counter, but for this example we'll use the Template and data from the intro ✨. The Intermediate Aggregation Process then outputs records with just timestamps, source IP, and octetDeltaCount, as shown in Figure 11 🦋.
flowStartMilliseconds(152)[8]
flowEndMilliseconds(153)[8]
sourceIPv4Address(8)[4]
octetDeltaCount(1)[8]Figure 11: Output Template for Time Series per Source
The goal here is 5-minute (300 s) time series of octet counts per source IP address 🎀. The aggregation operations are arranged as in Figure 12 💅.
Original Flows
|
V
+-----------------------+
| interval distribution |
| * impose uniform |
| 300s time interval |
+-----------------------+
|
| Partially Aggregated Flows
V
+------------------------+
| key aggregation |
| * reduce key to only |
| sourceIPv4Address |
+------------------------+
|
| Partially Aggregated Flows
V
+-------------------------+
| aggregate combination |
| * sum octetDeltaCount |
+-------------------------+
|
V
Aggregated FlowsFigure 12: Aggregation Operations for Time Series per Source
After the interval distribution step is applied to the source data in Figure 10, only the time intervals have changed 🌸. The Partially Aggregated Flows are in Figure 13. Heads up: interval distribution follows the default Start Interval policy, which means the entire Flow goes into the interval that holds its start time 🧚.
start time |end time |source ip4 |port |dest ip4 |port|pt| oct
9:00:00.000 9:05:00.000 192.0.2.2 47113 192.0.2.131 53 17 119
9:00:00.000 9:05:00.000 192.0.2.2 22153 192.0.2.131 53 17 83
9:00:00.000 9:05:00.000 192.0.2.2 52420 198.51.100.2 443 6 1637
9:00:00.000 9:05:00.000 192.0.2.3 56047 192.0.2.131 53 17 111
9:00:00.000 9:05:00.000 192.0.2.3 41183 198.51.100.67 80 6 16838
9:00:00.000 9:05:00.000 192.0.2.2 17606 198.51.100.68 80 6 11538
9:00:00.000 9:05:00.000 192.0.2.3 47113 192.0.2.131 53 17 119
9:00:00.000 9:05:00.000 192.0.2.3 48458 198.51.100.133 80 6 2973
9:00:00.000 9:05:00.000 192.0.2.4 61295 198.51.100.2 443 6 8350
9:00:00.000 9:05:00.000 203.0.113.3 41256 198.51.100.133 80 6 778
9:00:00.000 9:05:00.000 203.0.113.3 51662 198.51.100.3 80 6 883
9:00:00.000 9:05:00.000 192.0.2.2 37581 198.51.100.2 80 6 15420
9:00:00.000 9:05:00.000 203.0.113.3 39586 198.51.100.17 80 6 11200
9:05:00.000 9:10:00.000 203.0.113.3 52572 198.51.100.2 443 6 1637
9:05:00.000 9:10:00.000 203.0.113.3 49914 197.51.100.133 80 6 561
9:05:00.000 9:10:00.000 192.0.2.2 50824 198.51.100.2 443 6 1899
9:05:00.000 9:10:00.000 192.0.2.3 34597 198.51.100.3 80 6 1284
9:05:00.000 9:10:00.000 203.0.113.3 58907 198.51.100.4 80 6 2670
9:10:00.000 9:15:00.000 192.0.2.4 22478 192.0.2.131 53 17 75
9:10:00.000 9:15:00.000 192.0.2.4 49513 198.51.100.68 80 6 3374
9:10:00.000 9:15:00.000 192.0.2.4 64832 198.51.100.67 80 6 138
9:10:00.000 9:15:00.000 192.0.2.3 60833 198.51.100.69 443 6 2325
9:10:00.000 9:15:00.000 192.0.2.2 19638 198.51.100.3 80 6 2869
9:10:00.000 9:15:00.000 192.0.2.3 40429 198.51.100.4 80 6 18289Figure 13: Interval Imposition for Time Series per Source
After the key aggregation step, every Flow Key except the source IP address has been thrown out, as shown in Figure 14 🗑️✨. That leaves duplicate Partially Aggregated Flows, which get combined in the final operation 💖.
start time |end time |source ip4 |octets
9:00:00.000 9:05:00.000 192.0.2.2 119
9:00:00.000 9:05:00.000 192.0.2.2 83
9:00:00.000 9:05:00.000 192.0.2.2 1637
9:00:00.000 9:05:00.000 192.0.2.3 111
9:00:00.000 9:05:00.000 192.0.2.3 16838
9:00:00.000 9:05:00.000 192.0.2.2 11538
9:00:00.000 9:05:00.000 192.0.2.3 119
9:00:00.000 9:05:00.000 192.0.2.3 2973
9:00:00.000 9:05:00.000 192.0.2.4 8350
9:00:00.000 9:05:00.000 203.0.113.3 778
9:00:00.000 9:05:00.000 203.0.113.3 883
9:00:00.000 9:05:00.000 192.0.2.2 15420
9:00:00.000 9:05:00.000 203.0.113.3 11200
9:05:00.000 9:10:00.000 203.0.113.3 1637
9:05:00.000 9:10:00.000 203.0.113.3 561
9:05:00.000 9:10:00.000 192.0.2.2 1899
9:05:00.000 9:10:00.000 192.0.2.3 1284
9:05:00.000 9:10:00.000 203.0.113.3 2670
9:10:00.000 9:15:00.000 192.0.2.4 75
9:10:00.000 9:15:00.000 192.0.2.4 3374
9:10:00.000 9:15:00.000 192.0.2.4 138
9:10:00.000 9:15:00.000 192.0.2.3 2325
9:10:00.000 9:15:00.000 192.0.2.2 2869
9:10:00.000 9:15:00.000 192.0.2.3 18289Figure 14: Key Aggregation for Time Series per Source
Aggregate combination sums the counters for each key and interval 🧮. The sums for the first two keys and intervals are worked out in detail in Figure 15 💜.
start time |end time |source ip4 |octets
9:00:00.000 9:05:00.000 192.0.2.2 119
9:00:00.000 9:05:00.000 192.0.2.2 83
9:00:00.000 9:05:00.000 192.0.2.2 1637
9:00:00.000 9:05:00.000 192.0.2.2 11538
+ 9:00:00.000 9:05:00.000 192.0.2.2 15420
-----
= 9:00:00.000 9:05:00.000 192.0.2.2 28797
9:00:00.000 9:05:00.000 192.0.2.3 111
9:00:00.000 9:05:00.000 192.0.2.3 16838
9:00:00.000 9:05:00.000 192.0.2.3 119
+ 9:00:00.000 9:05:00.000 192.0.2.3 2973
-----
= 9:00:00.000 9:05:00.000 192.0.2.3 20041Figure 15: Summation during Aggregate Combination
This same step gets applied to each set of Partially Aggregated Flows to produce the final Aggregated Flows in Figure 16, which are exported using the Template in Figure 11 🌟.
start time |end time |source ip4 |octets
9:00:00.000 9:05:00.000 192.0.2.2 28797
9:00:00.000 9:05:00.000 192.0.2.3 20041
9:00:00.000 9:05:00.000 192.0.2.4 8350
9:00:00.000 9:05:00.000 203.0.113.3 12861
9:05:00.000 9:10:00.000 192.0.2.2 1899
9:05:00.000 9:10:00.000 192.0.2.3 1284
9:05:00.000 9:10:00.000 203.0.113.3 4868
9:10:00.000 9:15:00.000 192.0.2.2 2869
9:10:00.000 9:15:00.000 192.0.2.3 20614
9:10:00.000 9:15:00.000 192.0.2.4 3587Figure 16: Aggregated Flows for Time Series per Source
8.2. Core Traffic Matrix
Okay bestie, so aggregating Flows by source and destination ASN over time is how you make core traffic matrices 🗺️✨ The matrix shows you the state of the routes inside a network, which makes it perfect for long-term planning of network design changes based on traffic demand 💅 The imposed time intervals here are generally way longer than active Flow timeouts. The matrix is reported in terms of octets, packets, and flows, since each of those can have a subtly different effect on capacity planning 🎀
This example shows key aggregation using derived keys and Original Flow counting 🦋 Some Original Flows come from Exporting Processes on forwarding devices, so they contain the bgpSourceAsNumber and bgpDestinationAsNumber Information Elements 🧚 But Original Flows from Exporting Processes on dedicated measurement devices without routing data only contain a destinationIPv[46]Address. For those, the Mediator has to look up a next-hop AS from an IP-to-AS table and replace the source and destination addresses with ASNs 🔥 The table used in this example is shown in Figure 17. (Note that because the example address space is so limited, we ignore the common practice of routing only blocks of /24 or larger 🙈)
prefix |ASN
192.0.2.0/25 64496
192.0.2.128/25 64497
198.51.100/24 64498
203.0.113.0/24 64499
Figure 17: Example ASN MapThe Template for Aggregated Flows produced by this example is shown in Figure 18 🌸
flowStartMilliseconds(152)[8]
flowEndMilliseconds(153)[8]
bgpSourceAsNumber(16)[4]
bgpDestinationAsNumber(17)[4]
octetDeltaCount(1)[8]
Figure 18: Output Template for Traffic MatrixSay you want 60-minute time series of octet counts per source/destination ASN pair 👑 The aggregation operations would then be arranged as in Figure 19.
Original Flows
|
V
+-----------------------+
| interval distribution |
| * impose uniform |
| 3600s time interval|
+-----------------------+
|
| Partially Aggregated Flows
V
+------------------------+
| key aggregation |
| * reduce key to only |
| sourceIPv4Address + |
| destIPv4Address |
+------------------------+
|
V
+------------------------+
| key aggregation |
| * replace addresses |
| with ASN from map |
+------------------------+
|
| Partially Aggregated Flows
V
+-------------------------+
| aggregate combination |
| * sum octetDeltaCount |
+-------------------------+
|
V
Aggregated Flows
Figure 19: Aggregation Operations for Traffic MatrixNow for the source data in Figure 10, after the interval distribution step, the Partially Aggregated Flows look like Figure 20 🌈 These Flows are identical to the ones from the interval distribution step in the previous example, except the chosen interval (1 hour, 3600 seconds) is different. That means all the Flows fit into a single interval ⭐
start time |end time |source ip4 |port |dest ip4 |port|pt| oct
9:00:00 10:00:00 192.0.2.2 47113 192.0.2.131 53 17 119
9:00:00 10:00:00 192.0.2.2 22153 192.0.2.131 53 17 83
9:00:00 10:00:00 192.0.2.2 52420 198.51.100.2 443 6 1637
9:00:00 10:00:00 192.0.2.3 56047 192.0.2.131 53 17 111
9:00:00 10:00:00 192.0.2.3 41183 198.51.100.67 80 6 16838
9:00:00 10:00:00 192.0.2.2 17606 198.51.100.68 80 6 11538
9:00:00 10:00:00 192.0.2.3 47113 192.0.2.131 53 17 119
9:00:00 10:00:00 192.0.2.3 48458 198.51.100.133 80 6 2973
9:00:00 10:00:00 192.0.2.4 61295 198.51.100.2 443 6 8350
9:00:00 10:00:00 203.0.113.3 41256 198.51.100.133 80 6 778
9:00:00 10:00:00 203.0.113.3 51662 198.51.100.3 80 6 883
9:00:00 10:00:00 192.0.2.2 37581 198.51.100.2 80 6 15420
9:00:00 10:00:00 203.0.113.3 52572 198.51.100.2 443 6 1637
9:00:00 10:00:00 203.0.113.3 49914 197.51.100.133 80 6 561
9:00:00 10:00:00 192.0.2.2 50824 198.51.100.2 443 6 1899
9:00:00 10:00:00 192.0.2.3 34597 198.51.100.3 80 6 1284
9:00:00 10:00:00 203.0.113.3 58907 198.51.100.4 80 6 2670
9:00:00 10:00:00 192.0.2.4 22478 192.0.2.131 53 17 75
9:00:00 10:00:00 192.0.2.4 49513 198.51.100.68 80 6 3374
9:00:00 10:00:00 192.0.2.4 64832 198.51.100.67 80 6 138
9:00:00 10:00:00 192.0.2.3 60833 198.51.100.69 443 6 2325
9:00:00 10:00:00 203.0.113.3 39586 198.51.100.17 80 6 11200
9:00:00 10:00:00 192.0.2.2 19638 198.51.100.3 80 6 2869
9:00:00 10:00:00 192.0.2.3 40429 198.51.100.4 80 6 18289
Figure 20: Interval Imposition for Traffic MatrixNext up, we discard the irrelevant key fields and swap the source and destination addresses for source and destination ASNs from the map 🧁 The results of these key aggregation steps are in Figure 21.
start time |end time |source ASN |dest ASN |octets
9:00:00 10:00:00 AS64496 AS64497 119
9:00:00 10:00:00 AS64496 AS64497 83
9:00:00 10:00:00 AS64496 AS64498 1637
9:00:00 10:00:00 AS64496 AS64497 111
9:00:00 10:00:00 AS64496 AS64498 16838
9:00:00 10:00:00 AS64496 AS64498 11538
9:00:00 10:00:00 AS64496 AS64497 119
9:00:00 10:00:00 AS64496 AS64498 2973
9:00:00 10:00:00 AS64496 AS64498 8350
9:00:00 10:00:00 AS64499 AS64498 778
9:00:00 10:00:00 AS64499 AS64498 883
9:00:00 10:00:00 AS64496 AS64498 15420
9:00:00 10:00:00 AS64499 AS64498 1637
9:00:00 10:00:00 AS64499 AS64498 561
9:00:00 10:00:00 AS64496 AS64498 1899
9:00:00 10:00:00 AS64496 AS64498 1284
9:00:00 10:00:00 AS64499 AS64498 2670
9:00:00 10:00:00 AS64496 AS64497 75
9:00:00 10:00:00 AS64496 AS64498 3374
9:00:00 10:00:00 AS64496 AS64498 138
9:00:00 10:00:00 AS64496 AS64498 2325
9:00:00 10:00:00 AS64499 AS64498 11200
9:00:00 10:00:00 AS64496 AS64498 2869
9:00:00 10:00:00 AS64496 AS64498 18289
Figure 21: Key Aggregation for Traffic Matrix:
Reduction and ReplacementFinally, aggregate combination sums the counters per key and interval 🎉 The resulting Aggregated Flows, which make up the traffic matrix in Figure 22, are then exported using the Template in Figure 18. These Aggregated Flows form a sparse matrix, so AS pairs that received no traffic simply have no record in the output 🫶
start time end time source ASN dest ASN octets
9:00:00 10:00:00 AS64496 AS64497 507
9:00:00 10:00:00 AS64496 AS64498 86934
9:00:00 10:00:00 AS64499 AS64498 17729
Figure 22: Aggregated Flows for Traffic MatrixThe output of this operation can be re-aggregated, which is the best part 🦋 Traffic matrices from single links or Observation Points can go through the same interval imposition and aggregate combination steps to build a traffic matrix for an entire network 💜
8.3. Distinct Source Count per Destination Endpoint
Aggregating Flows by destination address and port, and counting the distinct sources that got aggregated away, is a great move for passive service inventory and host characterization 🔍✨ This example treats aggregation as an analysis technique, run on source data stored in an IPFIX File 🎀 Because the Transport Session in this File is bounded, removing all the timestamp information lets you summarize the entire time interval contained within it 💅 Removing timing information during interval imposition is equivalent to an infinitely long imposed time interval, so this shows both how infinite intervals work and how unique counters work 🌸 The aggregation operations are summarized in Figure 23.
Original Flows
|
V
+-----------------------+
| interval distribution |
| * discard timestamps |
+-----------------------+
|
| Partially Aggregated Flows
V
+----------------------------+
| value aggregation |
| * discard octetDeltaCount |
+----------------------------+
|
| Partially Aggregated Flows
V
+----------------------------+
| key aggregation |
| * reduce key to only |
| destIPv4Address + |
| destTransportPort, |
| * count distinct sources |
+----------------------------+
|
| Partially Aggregated Flows
V
+----------------------------------------------+
| aggregate combination |
| * no-op (distinct sources already counted) |
+----------------------------------------------+
|
V
Aggregated Flows
Figure 23: Aggregation Operations for Source CountThe Template for Aggregated Flows produced by this example is shown in Figure 24 🧚
destinationIPv4Address(12)[4]
destinationTransportPort(11)[2]
distinctCountOfSourceIPAddress(378)[8]
Figure 24: Output Template for Source CountInterval distribution in this case just discards the timestamp information from the Original Flows in Figure 10, so it isn't shown 🙈 The value aggregation step simply discards the octetDeltaCount value field. The key aggregation step reduces the key to the destinationIPv4Address and destinationTransportPort while counting the distinct source addresses 🔥 Since that counting is already the output of this aggregation function, the aggregate combination operation is a no-op. The resulting Aggregated Flows are in Figure 25 ✨
dest ip4 |port |dist src
192.0.2.131 53 3
198.51.100.2 80 1
198.51.100.2 443 3
198.51.100.67 80 2
198.51.100.68 80 2
198.51.100.133 80 2
198.51.100.3 80 3
198.51.100.4 80 2
198.51.100.17 80 1
198.51.100.69 443 1
Figure 25: Aggregated Flows for Source Count8.4. Traffic Time Series per Source with Counter Distribution
Okay so, back to the Section 8.1 example 🎀. Our source data has some Flows with durations longer than the imposed five-minute interval 😭. The default move for those is to count them in the interval that contains the Flow's start time.
Now here's the twist ✨. We're doing the SAME aggregation, with the same operations and the same output Template, but we're switching to a different counter distribution policy called Simple Uniform Distribution (see Section 5.1.1) 💅. First, the Exporting Process sends the Aggregate Counter Distribution Options Template, like in Figure 26 👑.
templateId(12)[2]{scope}
valueDistributionMethod(384)[1]Figure 26: Aggregate Counter Distribution Options Template
That Template gets followed by an Aggregate Counter Distribution Record described by it. Assuming the output Template in Figure 11 has ID 257, the record looks like Figure 27 🦋.
template ID | value distribution method
257 4 (simple uniform)Figure 27: Aggregate Counter Distribution Record
After the metadata export, the aggregation steps go as before. But ngl, this is where it gets spicy 🔥. Two long Flows get split across multiple intervals during the interval imposition step, marked with "*" in Figure 28. Look at the three-interval, 11200-octet Flow: it gets divided into three Partially Aggregated Flows of 3733, 3733, and 3734 octets. That uneven split is intentional, because it makes sure no cumulative error sneaks in during the interval distribution step 🧚.
start time |end time |source ip4 |port |dest ip4 |port|pt| oct
9:00:00.000 9:05:00.000 192.0.2.2 47113 192.0.2.131 53 17 119
9:00:00.000 9:05:00.000 192.0.2.2 22153 192.0.2.131 53 17 83
9:00:00.000 9:05:00.000 192.0.2.2 52420 198.51.100.2 443 6 1637
9:00:00.000 9:05:00.000 192.0.2.3 56047 192.0.2.131 53 17 111
9:00:00.000 9:05:00.000 192.0.2.3 41183 198.51.100.67 80 6 16838
9:00:00.000 9:05:00.000 192.0.2.2 17606 198.51.100.68 80 6 11538
9:00:00.000 9:05:00.000 192.0.2.3 47113 192.0.2.131 53 17 119
9:00:00.000 9:05:00.000 192.0.2.3 48458 198.51.100.133 80 6 2973
9:00:00.000 9:05:00.000 192.0.2.4 61295 198.51.100.2 443 6 8350
9:00:00.000 9:05:00.000 203.0.113.3 41256 198.51.100.133 80 6 778
9:00:00.000 9:05:00.000 203.0.113.3 51662 198.51.100.3 80 6 883
9:00:00.000 9:05:00.000 192.0.2.2 37581 198.51.100.2 80 6 7710*
9:00:00.000 9:05:00.000 203.0.113.3 39586 198.51.100.17 80 6 3733*
9:05:00.000 9:10:00.000 203.0.113.3 52572 198.51.100.2 443 6 1637
9:05:00.000 9:10:00.000 203.0.113.3 49914 197.51.100.133 80 6 561
9:05:00.000 9:10:00.000 192.0.2.2 50824 198.51.100.2 443 6 1899
9:05:00.000 9:10:00.000 192.0.2.3 34597 198.51.100.3 80 6 1284
9:05:00.000 9:10:00.000 203.0.113.3 58907 198.51.100.4 80 6 2670
9:05:00.000 9:10:00.000 192.0.2.2 37581 198.51.100.2 80 6 7710*
9:05:00.000 9:10:00.000 203.0.113.3 39586 198.51.100.17 80 6 3733*
9:10:00.000 9:15:00.000 192.0.2.4 22478 192.0.2.131 53 17 75
9:10:00.000 9:15:00.000 192.0.2.4 49513 198.51.100.68 80 6 3374
9:10:00.000 9:15:00.000 192.0.2.4 64832 198.51.100.67 80 6 138
9:10:00.000 9:15:00.000 192.0.2.3 60833 198.51.100.69 443 6 2325
9:10:00.000 9:15:00.000 192.0.2.2 19638 198.51.100.3 80 6 2869
9:10:00.000 9:15:00.000 192.0.2.3 40429 198.51.100.4 80 6 18289
9:10:00.000 9:15:00.000 203.0.113.3 39586 198.51.100.17 80 6 3734*Figure 28: Distributed Interval Imposition for Time Series per Source
The remaining steps are the same as in Section 8.1. The results get exported with the Template shown in Figure 11, and they're in Figure 29 🌈. Any Aggregated Flows that differ from the Section 8.1 example are marked with "*" ⭐.
start time |end time |source ip4 |octets
9:00:00.000 9:05:00.000 192.0.2.2 21087*
9:00:00.000 9:05:00.000 192.0.2.3 20041
9:00:00.000 9:05:00.000 192.0.2.4 8350
9:00:00.000 9:05:00.000 203.0.113.3 5394*
9:05:00.000 9:10:00.000 192.0.2.2 9609*
9:05:00.000 9:10:00.000 192.0.2.3 1284
9:05:00.000 9:10:00.000 203.0.113.3 8601*
9:10:00.000 9:15:00.000 192.0.2.2 2869
9:10:00.000 9:15:00.000 192.0.2.3 20614
9:10:00.000 9:15:00.000 192.0.2.4 3587
9:10:00.000 9:15:00.000 203.0.113.3 3734*Figure 29: Aggregated Flows for Time Series per Source with Counter Distribution
9. Security Considerations 🛡️
This document specifies how an Intermediate Aggregation Process works with the IPFIX protocol, so the Security Considerations for the protocol itself in Section 11 of [RFC7011] apply here too 🔒. When aggregation happens on a Mediator (the common case), the Security Considerations for Mediators in Section 9 of [RFC6183] apply as well.
As mentioned in Section 3, certain aggregation operations can have an anonymizing effect on Flow data, because they wipe out sensitive identifiers 🫣. Aggregation can also be combined with anonymization inside a Mediator, or across a chain of Mediators, to make that effect even stronger. Whenever an Intermediate Aggregation Process is part of a data anonymization or protection scheme, or is used together with anonymization as described in [RFC6235], the Security Considerations in Section 9 of [RFC6235] apply 💀.
10. IANA Considerations 🧚
This document specifies the creation of new IPFIX Information Elements in the IPFIX Information Element registry [IANA-IPFIX], as defined in Section 7 above. IANA has assigned Information Element numbers to these Information Elements and entered them into the registry 📝.
11. Acknowledgments 🫶
Special thanks to Elisa Boschi for early work on the concepts laid out in this document 💖. Thanks to Lothar Braun, Christian Henke, and Rahul Patel for their reviews and valuable feedback, with special thanks to Paul Aitken for his multiple detailed reviews 👑. This work is materially supported by the European Union Seventh Framework Programme under grant agreement 257315 (DEMONS).
12. References 📚
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, September 2013.12.2. Informative References
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander,
"Requirements for IP Flow Information Export (IPFIX)", RFC
3917, October 2004.
[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.
[RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet Sampling
(PSAMP) Protocol Specifications", RFC 5476, 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.
[RFC5982] Kobayashi, A. and B. Claise, "IP Flow Information Export
(IPFIX) Mediation: Problem Statement", RFC 5982, August
2010.
[RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi,
"IP Flow Information Export (IPFIX) Mediation: Framework",
RFC 6183, April 2011.
[RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization
Support", RFC 6235, May 2011.
[RFC6728] Muenz, G., Claise, B., and P. Aitken, "Configuration Data
Model for the IP Flow Information Export (IPFIX) and
Packet Sampling (PSAMP) Protocols", RFC 6728, October
2012.
[RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model
for IP Flow Information Export (IPFIX)", RFC 7012,
September 2013.
[RFC7013] Trammell, B. and B. Claise, "Guidelines for Authors and
Reviewers of IP Flow Information Export (IPFIX)
Information Elements", BCP 184, RFC 7013, September 2013.
[RFC7014] D'Antonio, S., Zseby, T., Henke, C., and L. Peluso, "Flow
Selection Techniques", RFC 7014, September 2013.
[IANA-IPFIX]
IANA, "IP Flow Information Export (IPFIX) Entities",
<http://www.iana.org/assignments/ipfix>.
[IPFIX-MED-PROTO]
Claise, B., Kobayashi, A., and B. Trammell, "Operation of
the IP Flow Information Export (IPFIX) Protocol on IPFIX
Mediators", Work in Progress, July 2013.Authors' Addresses 💌
Brian Trammell
Swiss Federal Institute of Technology Zurich
Gloriastrasse 35
8092 Zurich
Switzerland
Phone: +41 44 632 70 13
EMail: trammell@tik.ee.ethz.ch
Arno Wagner
Consecom AG
Bleicherweg 64a
8002 Zurich
Switzerland
EMail: arno@wagner.name
Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
1831 Diegem
Belgium
Phone: +32 2 704 5622
EMail: bclaise@cisco.com📦 where this page comes from
- ietf: rfc7015 2013-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms