RFC 5472

IP Flow Information Export (IPFIX) Applicability

📅 published March 2009, from ietf

RFC 5472: IP Flow Information Export (IPFIX) Applicability 🦋

Okay bestie, this one is RFC 5472, and it's titled IP Flow Information Export (IPFIX) Applicability ✨. The authors are T. Zseby (Fraunhofer FOKUS), E. Boschi (Hitachi Europe), N. Brownlee (CAIDA), and B. Claise (Cisco Systems, Inc.). It's an Informational doc, dated March 2009, and its header doesn't list any RFCs it obsoletes or updates 💅

Status of This Memo 🌸

This memo gives info to the Internet community. It does not specify an Internet standard of any kind, and distribution of it is unlimited 🫶

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, as in effect on the date this document was published (http://trustee.ietf.org/license-info). Please read these carefully, because they spell out your rights and restrictions for this document 📜

This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get a proper license from whoever controls the copyright in that material, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌈

Abstract ✨

In this doc, we go through how the IP Flow Information eXport (IPFIX) protocol applies to a bunch of different applications 🎀 We show how those applications can use IPFIX, describe the relevant Information Elements (IEs) for each one, and cover the opportunities and limitations of the protocol. We also explain how the IPFIX framework relates to other architectures and frameworks 💜

Table of Contents 🍓

   1. Introduction ....................................................4
      1.1. Terminology ................................................4
   2. Applications of IPFIX ...........................................4
      2.1. Accounting .................................................4
           2.1.1. Example .............................................5
      2.2. Traffic Profiling ..........................................7
      2.3. Traffic Engineering ........................................8
      2.4. Network Security ...........................................9
      2.5. QoS Monitoring ............................................11
           2.5.1. Correlating Events from Multiple
                  Observation Points .................................12
           2.5.2. Examples ...........................................12
      2.6. Inter-Domain Exchange of IPFIX Data .......................14
      2.7. Export of Derived Metrics .................................14
      2.8. Summary ...................................................15
   3. Relation of IPFIX to Other Frameworks and Protocols ............16
      3.1. IPFIX and IPv6 ............................................16
      3.2. IPFIX and PSAMP ...........................................16
      3.3. IPFIX and RMON ............................................16
      3.4. IPFIX and IPPM ............................................18
      3.5. IPFIX and AAA .............................................18
           3.5.1. Connecting via a AAA Client ........................20
           3.5.2. Connecting via an Application Specific
                  Module (ASM) .......................................21
      3.6. IPFIX and RTFM ............................................21
           3.6.1. Architecture .......................................21
           3.6.2. Flow Definition ....................................22
           3.6.3. Configuration and Management .......................22
           3.6.4. Data Collection ....................................22
           3.6.5. Data Model Details .................................23
           3.6.6. Transport Protocol .................................23
           3.6.7. Summary ............................................23
   4. Limitations ....................................................24
      4.1. Using IPFIX for Other Applications than Listed in
           RFC 3917 ..................................................24
      4.2. Using IPFIX for Billing (Reliability Limitations) .........24
      4.3. Using a Different Transport Protocol than SCTP ............25
      4.4. Push vs. Pull Mode ........................................25
      4.5. Template ID Number ........................................26
      4.6. Exporting Bidirectional Flow Information ..................26
      4.7. Remote Configuration ......................................27
   5. Security Considerations ........................................27
   6. Acknowledgements ...............................................28
   7. Normative References ...........................................28
   8. Informative References .........................................28

1. Introduction 🧚

IPFIX is the protocol that defines how IP Flow information gets exported from routers, measurement probes, or other devices 📡 That flow info is seriously important input data for a whole bunch of applications. IPFIX is a general data transport protocol, and it's super easy to extend so it fits the needs of those apps 💖 In this doc, we walk through how typical apps can use IPFIX and show what it can and can't do. We also explain how IPFIX relates to other frameworks and architectures. Examples here are shown for IPv4 only, but the applicability statements apply to IPv4 and IPv6 both, and IPFIX has appropriate Information Elements for both IP versions 🦋

1.1. Terminology 🎀

IPFIX-specific terminology used in this document is defined in Section 2 of [RFC5101]. Like in [RFC5101], the first letter of each IPFIX-specific term is capitalized in this doc 💅

2. Applications of IPFIX 💜

IPFIX data enables several critical applications 🔥 The IPFIX target applications, and the requirements that come from those applications, are described in [RFC3917]. Those requirements were used as the basis for the design of the IPFIX protocol. This section is about how those target applications can use IPFIX. If you want to use IPFIX for other applications than the ones described in [RFC3917], check out Section 4.1 ✨

2.1. Accounting 💰

Usage-based accounting is one of the target applications for IPFIX, as defined in [RFC3917]. IPFIX records give you fine-grained measurement results for highly flexible and detailed usage reporting, and that data is what gets used to realize usage-based accounting. Here's the catch though: IPFIX does not provide the reliability that usage-based billing systems need, as defined in [RFC2975] (see Section 4.2) 😭 The accounting scenarios in this doc only give limited reliability, as explained in Section 4.2, so they should not be used in environments where the reliability demanded by [RFC2975] is mandatory 🙈

To realize usage-based accounting with IPFIX, you have to pick the Flow definition to match the accounting purpose. That could be trend analysis, capacity planning, auditing, or billing and cost allocation, where some loss of data can be tolerated (see Section 4.2) 🍓

Flows can be told apart by various IEs (for example, packet header fields) from [RFC5102]. Thanks to the flexible IPFIX Flow definition, you can build arbitrary Flow-based accounting models without any extensions to the IPFIX protocol. It's giving customizable 👑

Accounting can, for instance, be based on individual end-to-end Flows. In that case, you can realize it with a Flow definition determined by the quintuple made up of source address (sourceIPv4Address), destination address (destinationIPv4Address), protocol (protocolIdentifier), and port numbers (udpSourcePort, udpDestinationPort) 🌸 Another example is class-dependent accounting, like in a Diffserv network. There, Flows could be distinguished just by the Diffserv codepoint (DSCP) (ipDiffServCodePoint) and the IP addresses (sourceIPv4Address, destinationIPv4Address) 🧚 The essential elements for accounting are the number of transferred packets and bytes per Flow. Those can be represented by the per-flow counter IEs, such as packetTotalCount and octetTotalCount 📊

For accounting purposes, it would be really useful to be able to use IPFIX Flow Records as accounting input in an Authentication, Authorization, and Accounting (AAA) infrastructure. AAA servers could then provide the mapping between user and Flow information 🫶 Still, for those scenarios, you have to keep in mind the limited reliability IPFIX currently provides 🥺

2.1.1. Example 🎀

Okay, quick heads up 💅 As noted in [RFC3330], the address block 192.0.2.0/24 may be used for example addresses. In this example we use two example networks. To stay conformant to [RFC3330], we split that block into two networks by subnetting with a 25-bit netmask (192.0.2.0/25), like this:

Network A: 192.0.2.0 ...  192.0.2.127
Network B: 192.0.2.128 ...  192.0.2.255

Say someone wants to monitor the individual Flows in a Diffserv network 👀 They want to compare the traffic amount trend with the terms in a Service Level Agreement (SLA). Flows are told apart by source and destination address. So the info to export here is:

  • IPv4 source IP address: sourceIPv4Address in [RFC5102], with a length of 4 octets
  • IPv4 destination IP address: destinationIPv4Address in [RFC5102], with a length of 4 octets
  • DSCP: ipDiffServCodePoint in [RFC5102], with a length of 1 octet
  • Number of octets of the Flow: octetDeltaCount in [RFC5102], with a length of 4 octets

The Template set will look like this 🧚

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Set ID = 2            |      Length = 24 octets       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Template ID 256         |       Field Count = 4         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|    sourceIPv4Address = 8    |       Field Length = 4        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address = 12 |       Field Length = 4        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|  ipDiffServCodePoint = 195  |       Field Length = 1        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|     octetDeltaCount = 1     |       Field Length = 4        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The info to be exported might look like this example table 📊

Src. IP addr. | Dst. IP addr. |  DSCP  | Octets Number
--------------+---------------+--------+--------------
192.0.2.12    |  192.0.2.144  |   46   |   120868
192.0.2.24    |  192.0.2.156  |   46   |   310364
192.0.2.36    |  192.0.2.168  |   46   |   241239

In this example we use Diffserv codepoint 46, which is recommended for the Expedited Forwarding Per Hop Behavior (EF PHB) in [RFC3246] 🦋

The Flow Records will then look like this ✨

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Set ID = 256         |          Length = 43          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          192.0.2.12                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          192.0.2.144                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      46       |               120868                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |               192.0.2.24                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |               192.0.2.156                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |       46      |                 310364        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |         192.0.2.36            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |         192.0.2.168           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |       46      |               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   241239                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.2. Traffic Profiling 📈

Okay, this part is so useful 🥹 Measurement results reported in IPFIX records can give you great input for traffic profiling. IPFIX records captured over a long period of time can help you track and anticipate network growth and usage. That info is seriously valuable for trend analysis and network planning.

The parameters you care about depend on your profiling goals. Example parameters for traffic profiling are Flow duration, Flow volume, burstiness, the distribution of used services and protocols, the amount of packets of a specific type, etc. [RFC3917].

The distribution of services and protocols in use can be analyzed by configuring the right Flow Keys for Flow discrimination. Protocols can be told apart by the protocolIdentifier IE. Portnumbers (e.g., udpDestinationPort) often give you info about services in use. Those Flow Keys are defined in [RFC5102]. If portnumbers aren't enough for service discrimination, further parts of the packet may be needed. Header fields can be expressed by IEs from [RFC5102].

Packet payload can be reported by using the IE ipPayloadPacketSection in [RFC5477] 🫶

The Flow duration can be calculated from the Flow Timestamp IEs defined in [RFC5102] (e.g., flowEndMicroseconds - flowStartMicroseconds). The number of packets and number of bytes of a Flow are represented in the per-flow counter IEs (e.g., packetTotalCount, octetTotalCount). The burstiness of a Flow can be calculated from the Flow volume measured at different time intervals.

2.3. Traffic Engineering 🚦

Traffic engineering is all about optimizing network resource utilization and traffic performance [RFC2702]. Typical parameters are link utilization, load between specific network nodes, number, size and entry/exit points of active Flows, and routing information [RFC3917]. Main character energy 👑

The size of Flows in packets and bytes can be reported by the IEs packetTotalCount and octetTotalCount. Utilization of a physical link can be reported by using a coarse-grained Flow definition (e.g., based on identifier IEs such as egressInterface or ingressInterface) and per-flow counter IEs (e.g., packetTotalCount, octetTotalCount) defined in [RFC5102].

The load between specific network nodes can be reported in the same way if one interface of a network node receives only traffic from exactly one neighbor node (as is usually the case). If the ingress interface isn't enough to unambiguously identify the neighbor node, sub-IP header fields IEs (like sourceMacAddress) can be added as Flow Keys 🍓

The IE observedFlowTotalCount provides the number of all Flows exported for the Observation Domain since the last initialization of the Metering Process [RFC5102]. If this IE is exported at subsequent points in time, you can derive the number of active Flows in a specific time interval from the difference of the reported counters. The configured Flow termination criteria have to be taken into account to interpret those numbers correctly.

Entry and exit points can be derived from Flow Records if Metering Processes are installed at all edges of the network and results are mapped in accordance to Flow Keys. For this and other analysis methods that require the mapping of records from different Observation Points, the same Flow Keys should be used at all Observation Points. The path that packets take through a network can be investigated by using hash-based sampling techniques as described in [DuGr00] and [RFC5475]. For this, IEs from [RFC5477] are needed.

Neither [RFC5102] nor [RFC5477] defines IEs suitable for exporting routing information 💀

2.4. Network Security 🛡️

Okay so attack and intrusion detection are literally among the IPFIX target applications described in [RFC3917] 🔥. Because there are SO many different kinds of network attacks, [RFC3917] could only cover general requirements 💀.

The number of metrics that are useful for attack detection is as diverse as the attack patterns themselves 🙈. Attackers adapt super fast to dodge detection and try to hide their patterns with slow or stealth attacks 🥷. And unusual traffic isn't always malicious, ngl. A sudden traffic spike could just be legit users trying to get to a recently published web page 🌸. Weird traffic patterns can also come from misconfiguration ⚙️.

IPFIX can export Flow information for arbitrary Flow definitions, as defined in [RFC5101] ✨. Packet information can be exported with IPFIX using the extra Information Elements described in [RFC5477] 📦. With this, theoretically all information about traffic in the network at the IP layer and above is accessible 👀. That data can either be used directly to detect anomalies, or it can be the base for more post-processing to build more complex attack detection metrics 💅.

Depending on the attack type, different metrics are useful. A sudden jump in traffic load can be a hint that an attack has been launched 🚨. You can monitor the overall traffic at an Observation Point with per-flow counter IEs like packetTotalCount or octetTotalCount, as described in Section 2.3 🎀. You can also watch the number of active Flows by regularly reporting the observedFlowTotalCount defined in [RFC5102] 📊.

A sudden increase of Flows from different sources to one destination may be caused by an attack on a specific host or network node using spoofed addresses 👻. You can see the number of Flows from or to specific networks or hosts by using source and destination addresses as Flow Keys and observing the number of active Flows, like we just talked about 🔍. Lots of Flows to the same machine on different ports, or lots of Flows to the same port on different machines, may be an indicator of vertical or horizontal port scanning activities 🕵️‍♀️. The number of Flows to different ports can be reported by using the portnumber Information Elements (udpSourcePort, udpDestinationPort, tcpSourcePort, tcpDestinationPort) defined in [RFC5102] as Flow Keys 🧚.

An unusual ratio of TCP-SYN to TCP-FIN packets can refer to SYN-flooding 😭. The number of SYN and FIN packets in a Flow can be reported with the IPFIX Information Elements tcpSynTotalCount and tcpFinTotalCount defined in [RFC5102] 💜.

Worms may leave signatures in traffic patterns 🐛. Detecting those events needs way more detailed measurements and post-processing than detecting simple changes in traffic volumes 🫠.

Separating good packets from bad ones, so you can prep and launch counteraction, is a really hard task 😤. It may need a deeper look into packet content, using further header field IEs from [RFC5102] and/or packet payloads from the IE ipPayloadPacketSection in [RFC5477] 🔎.

Also, the amount of resources needed for measurement and reporting goes up with the level of granularity needed to detect an attack 📈. Multi-step analysis techniques may be useful, e.g., to launch an in-depth analysis (e.g., based on packet information) when the Flow information shows suspicious patterns 🧠. To supervise traffic to a specific host or network node, it's useful to apply filtering methods like those described in [RFC5475] 🎯.

Mapping the two directions of communication is often useful for checking correct protocol behavior (see Section 4.6) 🤓. Correlating IPFIX data from multiple Observation Points (see Section 2.5.1) lets you assess how an attack is propagating and can help locate its source 🗺️.

Integrating previous measurement results helps review traffic changes over time to detect traffic anomalies, and it provides the basis for forensic analysis 🕰️. A standardized storage format for IPFIX data would support offline analysis of data from different operators 📁.

Nevertheless, capturing full packet traces at all Observation Points in the network isn't viable because of resource limitations and privacy concerns 🙅. So metrics should be chosen wisely to allow solid detection with minimal resource consumption 💎. You can save resources, for instance, by using coarser-grained Flow definitions, reporting pre-processed metrics (e.g., with additional Information Elements), or deploying sampling methods 🌷.

In many cases, only derived metrics provide sufficient evidence about security incidents 🔬. For example, comparing the number of SYN and FIN packets for a specific time interval can reveal an ongoing SYN attack, which isn't obvious from unprocessed packet and Flow data 👀. Further metrics like the cumulated sum of various counters, distributions of packet attributes, or spectrum coefficients have been used to identify a variety of attacks 🌈.

To detect attacks early, it's useful to process the data as soon as possible so you can generate significant metrics for detection ⏩. Pre-processing raw packet and Flow data already at the measurement device can speed up the detection process and reduces the amount of data that needs to be exported 🚀. It's also possible to directly report derived metrics by defining appropriate Information Elements 💡. Immediate data export in case of a potential incident is desired 🫶. IPFIX supports this source-triggered exporting of information due to the push model approach. Still, further exporting criteria have to be implemented to export IPFIX records upon incident detection events, and not only upon flow-end or fixed-time intervals ⏰.

Intrusion detection would profit from combining IPFIX functions with AAA functions (see Section 3.5) 🔐. That interoperation enables further means for attacker detection, advanced defense strategies, and secure inter-domain cooperation 🤝.

2.5. QoS Monitoring 📶

Quality of service (QoS) monitoring is one target application of the IPFIX protocol [RFC3917] 💅. QoS monitoring is the passive observation of the transmission quality for single Flows or traffic aggregates in the network 👀. One example of its use is validating QoS guarantees in service level agreements (SLAs) 📝. Typical QoS parameters are loss [RFC2680], one-way [RFC2679] and round-trip delay [RFC2681], and delay variation [RFC3393] 📏. Whenever applicable, the IP Performance Metrics (IPPM) definitions [RFC4148] should be used when reporting QoS metrics 💖.

Calculating those QoS metrics requires per-packet processing ⚡. Reporting packet information with IPFIX is possible by simply considering a single packet as a Flow 🎁. [RFC5101] also allows reporting multiple identical Information Elements in one Flow Record. Using this feature to report information about multiple packets in one record would require additional agreement on semantics regarding the order of Information Elements (e.g., which timestamp belongs to which packet payload in a sequence of Information Elements) 🤔. [RFC5477] defines useful additional Information Elements for exporting per-packet information with IPFIX 🧩.

2.5.1. Correlating Events from Multiple Observation Points

Some QoS metrics require the correlation of data from multiple Observation Points 🔗. For this, the clocks of the involved Metering Processes must be synchronized ⏱️. Furthermore, it's necessary to recognize that the same packet was observed at different Observation Points 👯.

This can be done by capturing parts of the packet content (packet header and/or parts of the payload) that don't change on the way to the destination 📸. Based on the packet content, it can be recognized when the same packet arrived at another Observation Point 🫵. To reduce the amount of measurement data, a unique packet ID can be calculated from the packet content, e.g., by using a Cyclic Redundancy Check (CRC) or hash function, instead of transferring and comparing the unprocessed content 🧮. Considerations on collision probability and efficiency of using such packet IDs are described in [GrDM98], [DuGr00], and [ZsZC01] 📚.

IPFIX allows the reporting of several IP and transport header fields (see Sections 5.3 and 5.4 in [RFC5102]) 🗂️. Using only those fields for packet recognition or ID generation can be sufficient in scenarios where those header fields vary a lot among subsequent packets, where a certain amount of packet ID collisions is tolerable, or where packet IDs need to be unique only for a small time interval 🌟.

For including packet payload information, the Information Element ipPayloadPacketSection defined in [RFC5477] can be used. The Information Element ipHeaderPacketSection can also be used. However, header fields that can change on the way from source to destination have to be excluded from the packet ID generation because they may differ at different Observation Points.

bestie, this exclusion step is the important part ⚠️ header fields that can change in transit are the ones you have to leave out of the packet ID.

For reporting packet IDs generated by a CRC or hash function, the Information Element digestHashValue defined in [RFC5477] can be used 🫧.

2.5.2. Examples

The following examples show which Information Elements need to be reported by IPFIX to generate specific QoS metrics 🎀. As an alternative, the metrics can be generated directly at the exporter, and IPFIX can be used to export the metrics (see Section 2.7) 💌.

2.5.2.1. RTT Measurements with Packet Pair Matching (Single-Point)

The passive measurement of round-trip time (RTT) can be performed by using packet pair matching techniques as described in [Brow00] 🏓. For the measurements, request/response packet pairs from protocols such as DNS, ICMP, SNMP or TCP (SYN/SYN_ACK, DATA/ACK) are utilized to passively observe the RTT [Brow00]. This technique requires the correlation of data from both directions 🔁.

Required Information Elements per packet (DNS example):

  • Packet arrival time: observationTimeMicroseconds [RFC5477]
  • DNS header: ipPayloadPacketSection [RFC5477]

Required functions:

  • Recognition of request/response packet pairs

Remarks:

  • Requires Information Elements from [RFC5477].
  • observationTimeMicroseconds can be substituted by flowStartMicroseconds [RFC5102] because a single packet can be represented as a Flow.
  • If time values with a finer granularity are needed, observationTimeNanoseconds can be used. 🌸

2.5.2.2. One-Way Delay Measurements (Multi-Point)

okay so passive one-way delay measurements need data from two Observation Points, bestie 🧚. And like we said before, your clocks have to be synchronized or you'll get time-differences at those Observation Points and it'll be a whole mess 💀

so the second Observation Point can recognize packets by looking at parts of the packet content directly 👀 but honestly? a more efficient move is to use a packet ID that gets generated from the packet content 🦋

Required Information Elements per packet (with packet ID):

  • Packet arrival time: observationTimeMicroseconds [RFC5477]
  • Packet ID: digestHashValue [RFC5477]

Required functions:

  • Packet ID generation
  • Delay calculation (from arrival times at the two Observation Points)

Remarks:

  • Requires Information Elements from [RFC5477].
  • observationTimeMicroseconds can be substituted by flowStartMicroseconds [RFC5102], because a single packet can be represented as a Flow ✨
  • If time values with a finer granularity are needed, observationTimeNanoseconds can be used.
  • The amount of content used for ID generation influences the number of collisions (different packets that map to the same ID) that can occur 🙈 If you want the deep dive on this and other packet ID generation stuff, check [GrDM98], [DuGr00], and [ZsZC01] 📚

2.6. Inter-Domain Exchange of IPFIX Data

okay so IPFIX data can be used to share info with neighbor providers 🌸 but if your IPFIX records are traveling over the public Internet, there are a few recs you should totally think about, because it's not the same vibe as staying inside a single domain 😭

first of all, security threat levels are higher once data is on the public Internet. protecting data from being disclosed or manipulated matters even more than it does for intra-domain usage 🔥 so Transport Layer Security (TLS) or Datagram Transport Layer Security should be used as described in [RFC5101] 🫶

also, data transfer should be congestion-aware so it can coexist nicely with other data Flows in public or foreign networks 🦋 which means transport over Stream Control Transmission Protocol (SCTP) or TCP is required, no exceptions bestie 💅

ngl some ISPs are still kinda reluctant to share info 🙃 because they worry that competing ISPs could use network info from neighbor providers to strengthen their own position in the market. but technical needs have already made providers exchange data before (like exchanging routing information with BGP) 🌈 and the need for inter-domain guarantees is a big incentive to boost inter-domain cooperation ✨ plus defending networks against current and future threats (denial-of-service attacks, worm distributions, etc.) will hopefully make providers more willing to exchange measurement data 🙏💜

2.7. Export of Derived Metrics

the IPFIX protocol is used to transport Flow and packet information so it can feed the calculation of a bunch of metrics (for QoS validation or attack detection, for example) 🔥 and IPFIX can also transfer those metrics directly, like if the metric calculation lives right next to the Metering and Exporting Processes 👑

it doesn't matter which measurement and post-processing functions were used to generate a metric. IPFIX can carry results from passive and active measurements and from post-processing operations 🧚 for reporting derived metrics, though, additional Information Elements need to be defined 🎀

for most QoS metrics like loss, delay, delay variation, etc., standard IPPM definitions already exist 💖 so if those metrics get reported with IPFIX, the IPPM standard definition should be used 🫶

2.8. Summary

okay the table below gives you the overview of which Information Elements are needed for the target applications described in [RFC3917] 📊 (M-mandatory, R-recommended, O-optional) 💅

  | Application |  [RFC5102] |   [RFC5477]  | additional IEs  |
  +-------------+------------+--------------+-----------------+
  | Accounting  |     M      |      -       |       -         |
  +-------------+------------+--------------+-----------------+
  | Traffic     |     M      |      O       |       -         |
  | Profiling   |            |              |                 |
  +-------------+------------+--------------+-----------------+
  | Traffic     |     M      |      -       |       O         |
  | Engineering |            |              | (routing info)  |
  +-------------+------------+--------------+-----------------+
  | Attack      |     M      |      R       |       R         |
  | Detection   |            |              |(derived metrics)|
  +-------------+------------+--------------+-----------------+
  | QoS         |     M      |      M       |       O         |
  | Monitoring  |            |(most metrics)|(derived metrics)|
  +-------------+------------+--------------+-----------------+

so for accounting, the IEs in [RFC5102] are sufficient 💰 and like we said above, IPFIX doesn't meet the reliability requirements that [RFC2975] demands for usage-based billing systems (see Section 4.2) 😬 for traffic profiling, additional IEs from [RFC5477] can be useful to get more insight into the traffic 🔍 traffic engineering is covered by Flow info from [RFC5102], but it would profit from routing information, which IPFIX could export 🛣️ attack detection usually profits from more insight into the traffic, and [RFC5477] IEs can give you that 🛡️ reporting derived metrics in additional IEs would also be useful. most QoS metrics need IEs from [RFC5477] 📈 and those same [RFC5477] IEs are useful for mapping results from different Observation Points, as described in Section 2.5.1 🗺️

3. Relation of IPFIX to Other Frameworks and Protocols

3.1. IPFIX and IPv6

from the very beginning, IPFIX was designed for IPv4 and IPv6 🌍 so IPFIX works in IPv4 and IPv6 networks without limitations 🙌 using IPFIX in IPv6 networks has two sides to it:

  • Generation and reporting of IPFIX records about IPv6 traffic
  • Exporting IPFIX records over IPv6

generating and reporting IPFIX records about IPv6 traffic is totally possible 💖 the Information Elements for reporting IPv6 traffic are defined in [RFC5102] ✨ exporting IPFIX records over IPv6 isn't explicitly addressed in [RFC5101], though 🤔 but here's the tea: IPFIX runs over a transport protocol (SCTP, PR-SCTP, UDP, or TCP), and all the potential IPFIX transport protocols can run in IPv6 networks, so you just need to provide your chosen transport protocol in the IPv6 network to run IPFIX over IPv6 🧚💜

3.2. IPFIX and PSAMP

PSAMP defines packet selection methods, how they get configured at routers and probes, and how packet information gets reported 📦

PSAMP uses IPFIX as the basis for exporting packet information [RFC5476]. [RFC5477] describes more Information Elements for exporting packet information and reporting configuration information 🎀

the main difference is that IPFIX is all about exporting Flow Records, whereas PSAMP is about exporting packet records 🫧 PSAMP also explicitly addresses remote configuration. it defines a MIB for configuring packet selection processes 🎛️ remote configuration isn't (yet) addressed in IPFIX, but someone could consider extending the PSAMP MIB so it can also configure IPFIX processes 💭

3.3. IPFIX and RMON

Remote Monitoring (RMON) [RFC3577] is a super widely used monitoring system that gathers traffic data from RMON Agents in network devices 📡 one big difference between RMON and IPFIX is that RMON uses SNMP for data export, while IPFIX defines its own push-oriented protocol 🚀 RMON defines MIBs that hold the info to be exported, but in IPFIX the data to be exported is defined as Information Elements 🧩

the most relevant MIBs to compare with IPFIX are the Application Performance Measurement MIB (APM-MIB) [RFC3729] and the Transport Performance Metrics MIB (TPM-MIB) [RFC4150] 👀 the APM-MIB has a complex system for tracking user application performance, with reporting about transactions, SLA threshold notification-trigger configuration, and persistence across DHCP lease expirations 😤 it requires a full RMON2-MIB protocolDirTable implementation, so it's a commitment 💅

the APM-MIB reports the performance of transactions 🛍️ a transaction is a service-oriented term for the data exchange from the transaction start (when a user requests a service) until its completion 🎬 the performance parameters include response times, throughput, streaming responsiveness, and availability of services 📊

the RMON transaction concept is different from the IPFIX Flow concept 🙅‍♀️ a Flow is a very generic term that lets you group IP packets according to common properties. the term transaction, on the other hand, is service-oriented and contains all the data exchange needed for service completion 🧠

so to report that kind of data with IPFIX, you'd probably need a specific combination of multiple Flows and the ability to map those to the transaction 🧵 because APM is so service-focused, the required metrics also differ. for instance, RMON APM requires a metric for the responsiveness of services, and IPFIX doesn't address metrics like that 😩 the APM-MIB also allows you to configure the transaction type to be monitored, which IPFIX doesn't currently address either 🙈

the APM MIB could be considered an extension of the IPFIX Metering Process, where the application performance of a combination of multiple Flows is measured 🌟 if it's appropriate, IEs would get defined in the IPFIX information model, and the IPFIX Device would support APM MIB data collection, then the two solutions could be complementary 🤝 that means you could use IPFIX to export APM MIB transaction information 🫶

the TPM-MIB breaks APM-MIB transactions down into sub-application level transactions 🍰 for instance, a web request is broken down into DNS, TCP, and HTTP sub-transactions. those sub-transactions can be considered bidirectional Flows 🔁 with an appropriate Flow definition and the ability to map both directions of a Flow (see Section 4.6), you could measure and report Flow characteristics of that sub-application level transaction with IPFIX 💜

the TPM-MIB requires APM-MIB and RMON2-MIB 🫠

3.4. IPFIX and IPPM

the IPFIX protocol can carry IPPM network performance metrics, or info that can be used to calculate those metrics (see Sections 2.5 and 2.7 for details and references) 📈✨

3.5. IPFIX and AAA ✨

okay so AAA is the whole vibe of authentication, authorization, and accounting for service usage [RFC2903] 💅. DIAMETER [RFC3588] is the protocol that handles AAA chat, and it's needed for network access services like Mobile IP, NASREQ, and ROAMOPS 🛜. The AAA architecture [RFC2903] gives you a framework to stretch AAA support over to other services too 🦋. DIAMETER sets up the messages going between AAA entities, like AAA clients on access devices talking to AAA servers, and AAA servers talking to each other 🫶. It's also how accounting records get transferred 📨. To make accounting records for usage-based billing, you need data from the network, and IPFIX is literally built to export that kind of data from routers, measurement probes, and other devices 🔥. So yeah, it looks super promising to connect those two architectures 😭.

Now here's the thing you cannot forget 🙈. IPFIX does not meet the reliability requirements for usage-based billing described in [RFC2975] (see Section 4.2) 💀. If you use IPFIX without reliability extensions alongside AAA, your accounting scenarios won't match the usage-based billing requirements in [RFC2975] ❌.

As shown in Section 2.1, accounting apps can plug an IPFIX Collecting Process straight in to get IPFIX records with the transmitted volume info 🧚. But if you already have an AAA infrastructure set up, IPFIX and AAA together give you a ton of synergistic perks ✨. IPFIX records can feed AAA accounting functions and be the basis for generating DIAMETER accounting records 💜. Still, as Section 4.2 explains, using IPFIX as described in [RFC5101] is currently only okay when the accounting purpose doesn't need reliability 🥲.

More features could come later too 🌸. You could map a user ID to Flow information using authentication info, or do secure, authorized exchange of DIAMETER accounting records with neighbor domains 🔐. That last one is especially giving in roaming scenarios, where a user connects to a foreign network and the home provider is the one who makes the invoice 🧾.

Coupling an IPFIX Collecting Process with AAA functions also has major potential for intrusion and attack detection 🚨. AAA controls network access and keeps data about users and nodes 👀. AAA functions can help identify where malicious traffic is coming from 🕵️‍♀️. Authorization functions can deny access to suspicious users or nodes 🚫. So pairing those functions with an IPFIX Collecting Process can be a really efficient defense against network attacks 🛡️👑.

Sharing IPFIX records (directly or wrapped in DIAMETER) with neighbor providers allows efficient inter-domain attack detection 🌈. For this to work well, it'd be useful to allow remote configuration of measurement and record generation, so you get info at the granularity and accuracy you need 🔭. Remote configuration isn't addressed in IPFIX yet, so this would take additional work 🛠️. The AAA infrastructure itself might be used to configure measurement functions in the network, as proposed in [RFC3334] 🧠.

The transport of IPFIX records with DIAMETER also needs IPFIX Information Elements translated into DIAMETER attribute value pairs (AVPs) defined in [RFC3588] 🔁. The DIAMETER AVPs don't cover all IPFIX Information Elements, so it's necessary to define new AVPs to carry the rest over DIAMETER 🎀.

There are two ways to connect IPFIX and AAA 🍓:

  • Connecting via a AAA Client
  • Connecting via an Application Specific Module (ASM)

Both get explained in the next sections 💖. These approaches only need a few extra functions 🙌. They don't require any changes to IPFIX or DIAMETER 🫧.

3.5.1. Connecting via a AAA Client

One way to connect IPFIX and AAA is to run a AAA client on the IPFIX Collector 💁‍♀️. That client can generate DIAMETER accounting messages and send them to a AAA server 📤. Mapping the Flow information to a user ID can happen in the AAA server, using data from the authentication process 🔑. DIAMETER accounting messages can go to the accounting application or to other AAA servers, like in roaming scenarios 🌍.

                    +---------+  DIAMETER    +---------+
                    |  AAA-S  |------------->|  AAA-S  |
                    +---------+              +---------+
                         ^
                         | DIAMETER
                         |
                         |
                  +--+--------+--+
                  |  |  AAA-C |  |
                  +  +--------+  |
                  |              |
                  |  Collector   |
                  +--------------+
                         ^
                         | IPFIX
                         |
                   +------------+
                   |  Exporter  |
                   +------------+

      Figure 1: IPFIX Collector connects to AAA server via AAA client

3.5.2. Connecting via an Application Specific Module (ASM)

The other option is to connect the IPFIX Collector directly to the AAA server through an application specific module (ASM) 🧩. The IRTF AAA architecture research group (AAARCH) proposed application specific modules in [RFC2903] 🔬. They act as the interface between the AAA server and the service equipment 🔌. In this setup, the IPFIX Collector is part of the ASM 🫧. The ASM sits between the IPFIX protocol and the input interface of the AAA server 🪞. It translates the received IPFIX data into a format the AAA server can use 🔄. The AAA server can then add user ID info and generate a DIAMETER accounting record 🧾. That accounting record can go to an accounting application or to other AAA servers 💌.

                       +---------+  DIAMETER    +---------+
                       |  AAA-S  |------------->|  AAA-S  |
                       +---------+              +---------+
                            ^
                            |
                    +------------------+
                    |     ASM          |
                    |  +------------+  |
                    |  |  Collector |  |
                    +------------------+
                            ^
                            | IPFIX
                            |
                      +------------+
                      |  Exporter  |
                      +------------+

            Figure 2: IPFIX connects to AAA server via ASM

3.6. IPFIX and RTFM

The Realtime Traffic Flow Measurement (RTFM) working group defined an architecture for Flow measurement [RFC2722] 📊. This section compares the RTFM framework with the IPFIX framework 👯‍♀️.

3.6.1. Architecture

The RTFM architecture [RFC2722] is very similar to the IPFIX architecture 🥰. It defines a meter, a meter reader, and a manager as the building blocks of the measurement architecture 🧱. The manager configures the meter, and the meter reader collects data from the meter 📥. In RTFM, the building blocks talk to each other via SNMP 🗣️.

The IPFIX architecture [RFC5470] defines Metering, Exporting, and Collecting Processes 🎯. IPFIX talks about processes instead of devices to make it clear that several of those processes can be co-located on the same machine 🏠.

These definitions don't contradict each other 🙅‍♀️. You could see the Metering Process as part of the meter, and the Collecting Process as part of the meter reader 🤝.

One difference is that IPFIX doesn't currently define a managing process, because remote configuration was (at least initially) out of scope for the working group 🤷‍♀️.

3.6.2. Flow Definition

RTFM and IPFIX both treat Flows as a group of packets that share a common set of properties 🧺. A Flow is completely specified by that set of values, plus a termination criterion (like an inactivity timeout) ⏱️.

Here's a difference: RTFM defines Flows as bidirectional 🔁. An RTFM meter matches packets from B to A and from A to B as separate parts of a single Flow, and it keeps two sets of packet and byte counters, one for each direction 🧮.

IPFIX doesn't explicitly say whether Flows are uni- or bidirectional 🫠. Still, Information Elements for describing Flow properties were defined for only one direction in [RFC5102] 📝. There are several solutions for reporting bidirectional Flow information (see Section 4.6) 🌉.

3.6.3. Configuration and Management

In RTFM, remote configuration is the only way to configure a meter 🎛️. This is done with SNMP and a specific Meter MIB [RFC2720] 🪄. The IPFIX group doesn't currently address IPFIX remote configuration 🙈.

IPFIX Metering Processes export the layout of their data within Templates, from time to time 📐. IPFIX Collecting Processes use that Template information to figure out how to interpret the IPFIX Flow data they receive 🧠.

3.6.4. Data Collection

One major difference between IPFIX and RTFM is the data collection model 💥. RTFM pulls data (pull mode), whereas IPFIX pushes data to Collecting Processes (push mode) 📤📥.

An RTFM meter reader pulls data from a meter using SNMP 🫳. SNMP security on the meter decides whether a reader is allowed to pull data from it 🔐. An IPFIX Exporting Process is configured to export records to a specified list of IPFIX Collecting Processes 📋. The condition for when to send IPFIX records (for example, Flow termination) has to be configured in the Exporting or Metering Process ⚙️.

3.6.5. Data Model Details

RTFM defines all its attributes in the RTFM Meter MIB [RFC2720] 📚. IPFIX Information Elements are defined in [RFC5102] 🗂️.

RTFM uses continuously-incrementing 64-bit counters to store the number of packets of a Flow 🔢. The counters are never reset; they just wrap back to zero if the maximum value is exceeded 🔄. Flows can be read at any time 👀. The difference between counter readings gives the counts for activity in the interval between readings 📏.

IPFIX allows absolute (totalCounter) and relative counters (deltaCounter) [RFC5102] 🧁. The totalCounter is never reset and just wraps to zero if values get too large, exactly like the counters used in RTFM 🌀. The deltaCounter is reset to zero when the associated Flow Record is exported 🫧.

3.6.6. Transport Protocol

RTFM has a Standards-Track Meter MIB [RFC2720], which is used both to configure a meter and to store metering results 🗃️. The MIB lets you read lists of attributes with a single Object Identifier (called a 'package'), which cuts down the SNMP overhead for Flow data collection 📉. SNMP normally uses UDP as its transport protocol 📡. Since RTFM requires a reliable Flow data transport system, an RTFM meter reader has to time out and resend unanswered SNMP requests 😩. Apart from being clumsy, this can limit the maximum data transfer rate from meter to meter reader 🐌.

IPFIX is designed to work over a variety of transport protocols 🚚. SCTP [RFC4960] and PR-SCTP [RFC3758] are mandatory 🫡. UDP and TCP are optional 🫶. Plus, the IPFIX protocol encodes data much more efficiently than SNMP does, so IPFIX has lower data transport overheads than RTFM 🏆💖

3.6.7. Summary

okay so the big picture, bestie 🦋 IPFIX pushes Flow info out using SCTP, TCP, or UDP, and it doesn't do remote configuration yet 💅 RTFM collects data with a pull model over SNMP, and it does handle remote configuration, also over SNMP ✨ Both let you define Flows super flexibly, but RTFM is built around bidirectional Flow definitions 🌸

4. Limitations ✨

ok this part is the honest "where NOT to use IPFIX" section 🫶 The goal is to show what IPFIX can't do and to give you a heads-up on when you'd need extra thinking, so you don't get caught slipping 💀

4.1. Using IPFIX for Other Applications than Listed in RFC 3917

IPFIX is basically a generic export mechanism 🧚 Because it's Template-based, it's pretty flexible, and network operators and users might want to use it for stuff that isn't in [RFC3917] ✨

Beyond raw Flow info, it can send per-packet data, aggregated data, or post-processed data 💖 You can define new Templates and Information Elements if you need them 🎀 Since it's push-mode, IPFIX is also a good fit for sending network-initiated events like alarms and other notifications 🔥 It can even be used to swap info between network nodes so they can autonomously improve network operation, which is giving main character energy 👑

BUT (and this is a big but 🙈) the IPFIX design is based on requirements that come only from the target applications in [RFC3917]. So using it for anything else means you need to carefully check IPFIX's capabilities against your application's requirements first. Only then can you decide whether IPFIX is actually the right protocol for your needs 💜

4.2. Using IPFIX for Billing (Reliability Limitations)

Okay, this one is a big deal 😭 The reliability requirements in [RFC3917] aren't enough to guarantee the level of reliability you need for usage-based billing systems, the kind described in [RFC2975] 💀 Specifically, IPFIX doesn't support these features that [RFC2975] needs:

  • Record loss: IPFIX lets you use different transport protocols to move data records around 🦋 Resilience against losing IPFIX data records can only be provided if TCP or SCTP is used for the transfer 🫶
  • Network or device failures: IPFIX does allow multiple Collectors for one Exporter 🌈 But it doesn't specify or demand using multiple Collectors for fault tolerance, so that's on you 💅
  • Detection and elimination of duplicate records: Not supported by IPFIX right now 🙈
  • Application layer acknowledgements: IPFIX doesn't let higher-level applications control the measurement and Exporting Processes 🍓 Application layer acknowledgements are needed, for example, to tell the Exporter when the application can't process the data it exported with IPFIX 😭 And yep, IPFIX doesn't support those acknowledgements either 💔

Other stuff like archival accounting and pre-authorization is out of scope for the IPFIX spec 🌸 You'll have to build those into your billing system architecture, as described in [RFC2975] ✨

4.3. Using a Different Transport Protocol than SCTP

SCTP is the preferred protocol for IPFIX 👑 In other words, a conforming implementation must work over SCTP 💖 IPFIX can also work over TCP or UDP, but both have drawbacks [RFC5101] 🦋 So bestie, make sure you have good reasons before using anything other than SCTP in a specific environment 🫶

4.4. Push vs. Pull Mode

IPFIX works in push mode 🚀 That means IPFIX records get exported automatically, without waiting for a request ✨ The Exporting Process is the one responsible for starting a data export 💅

Export criteria have to be configured at the Exporting Process 🎀 So push mode is more useful when the trigger for export is tied to events happening at the Exporting Process, like Flow termination or memory shortage from a huge pile of Flows 🔥 With pull mode, the Exporting Process would have to sit around waiting for a request before it could send anything 😭 With push mode, it can send data right away, before memory shortage forces it to start discarding stuff 🙌

Push mode also lets you prevent overloading resources at the Exporting Process by exporting info as soon as certain thresholds are about to be crossed 🌈 That's why export criteria are often based on traffic characteristics (like a Flow timeout) or resource limits (like the size of the Flow cache) 💜 BUT traffic characteristics are usually super dynamic and often impossible to predict 🙈 If you use them to trigger Flow export, the exporting rate and the resource consumption become variable and unpredictable 💀

Pull mode shines when the trigger is tied to events at the Collecting Process, like a specific application asking for immediate input 🧚 With pull mode, a request can just be forwarded to the Exporting Process ✨ With push mode, you'd have to change the exporting configuration to trigger export of the requested data 🫠 Pull mode also prevents overloading the Collecting Process when more records arrive than it can process 🛡️

Whether that's a real drawback depends on how flexible your IPFIX configuration is and how its configuration rules get implemented 🌸

4.5. Template ID Number

The IPFIX spec limits the Template ID numbers that can be assigned to newly generated Template records in an Observation Domain 🔢 Template IDs up to 255 are reserved for Template or option sets (or other sets to be created), and Template IDs from 256 to 65535 are assigned to data sets 🎀 So if lots of exports each need lots of different Templates, you could run out of Template IDs 😱

4.6. Exporting Bidirectional Flow Information

IPFIX doesn't explicitly say Flows are unidirectional 🦋 BUT Information Elements that describe Flow characteristics are only defined for one direction in [RFC5102] 💅 [RFC5101] lets you report multiple identical Information Elements in one Flow Record 🌈 So you can report forward and reverse Information Elements in one Flow Record ✨

Here's the catch though 🙈 That's not enough. Using this to report bidirectional Flow info would need an agreement on what the Information Elements mean (for example, "the first counter is the forward direction counter, the second is the reverse direction counter") 🤔

Another option is to use two adjacent Flow Records, one per direction 🧚 But that needs extra ways to map those records together, and it's pretty inefficient because the Flow Keys get reported twice 😭

4.7. Remote Configuration

Remote configuration was originally out of scope for the IPFIX working group, which wanted to focus on the protocol spec first 🌸 So right now there's no standardized way to configure IPFIX processes remotely 🥺 Still, there's a broad need for it, so solutions will probably get standardized soon 💖 Stay tuned bestie ✨

5. Security Considerations

This document describes how IPFIX gets used in different scenarios 🔐 The security requirements for IPFIX target applications and the security considerations for IPFIX are covered in [RFC3917] and [RFC5101] 🛡️ Those requirements have to be met for every scenario described in this document 💜 To our current knowledge, the usage scenarios proposed in Section 2 don't create any extra security hazards 🫶

The threat level to IPFIX itself can depend on how you're using it 😬 Using IPFIX for accounting or attack detection might make attackers more motivated to go after IPFIX itself 💀 Security considerations still need to be taken into account in every scenario described here 🔥

As described in the security considerations in [RFC5101], security incidents can become a threat to IPFIX processes themselves, even if IPFIX isn't the attack target 🚨 If an attack generates a huge number of Flows (for example, by sending packets with spoofed addresses or by simulating Flow termination), the Exporting and Collecting Processes can get overloaded by the enormous pile of records being exported 😱 Flexible deployment of packet or Flow sampling methods can help prevent resource exhaustion 🛡️

Section 3 of this document describes how IPFIX can be combined with other technologies 🧩 Brand new security hazards can pop up when two individually secure technologies or architectures get combined, so be careful 👀 For combining AAA with IPFIX, an application specific module (ASM) or an IPFIX Collector can act as a transit point for the messages 🚏 You have to make sure the security mechanisms applied (for example, encryption of messages) are still maintained at that point 🔒

6. Acknowledgements

We'd like to thank the following people for their contributions, discussions on the mailing list, and valuable comments 🫶

  • Sebastian Zander 💖
  • Robert Loewe 🌸
  • Reinaldo Penno ✨
  • Lutz Mark 🦋
  • Andy Biermann 👑

Part of the work was developed in the research project 6QM, co-funded with support from the European Commission 🇪🇺✨

7. Normative References

[RFC4148]  Stephan, E., "IP Performance Metrics (IPPM) Metrics
           Registry", BCP 108, RFC 4148, August 2005.

[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.

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

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

8. Informative References 📚

okay bestie, here's the extra reading list 💅 these are the sources the doc points to, so if you want to go deeper, this is your rabbit hole 🕳️✨

  • [Brow00] Brownlee, N., "Packet Matching for NeTraMet Distributions", <http://www.caida.org/tools/measurement/netramet/packetmatching/>.
  • [DuGr00] Duffield, N. and M. Grossglauser, "Trajectory Sampling for Direct Traffic Observation", Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden, August 28 - September 1, 2000.
  • [GrDM98] Graham, I., Donnelly, S., Martin, S., Martens, J., and J. Cleary, "Nonintrusive and Accurate Measurement of Unidirectional Delay and Delay Variation on the Internet", INET'98, Geneva, Switzerland, 21-24 July, 1998.
  • [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
  • [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.
  • [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999.
  • [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
  • [RFC2720] Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC 2720, October 1999.
  • [RFC2722] Brownlee, N., Mills, C., and G. Ruth, "Traffic Flow Measurement: Architecture", RFC 2722, October 1999.
  • [RFC2903] de Laat, C., Gross, G., Gommans, L., Vollbrecht, J., and D. Spence, "Generic AAA Architecture", RFC 2903, August 2000.
  • [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to Accounting Management", RFC 2975, October 2000.
  • [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
  • [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
  • [RFC3334] Zseby, T., Zander, S., and C. Carle, "Policy-Based Accounting", RFC 3334, October 2002.
  • [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002.
  • [RFC3577] Waldbusser, S., Cole, R., Kalbfleisch, C., and D. Romascanu, "Introduction to the Remote Monitoring (RMON) Family of MIB Modules", RFC 3577, August 2003.
  • [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
  • [RFC3729] Waldbusser, S., "Application Performance Measurement MIB", RFC 3729, March 2004.
  • [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
  • [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.
  • [RFC4150] Dietz, R. and R. Cole, "Transport Performance Metrics MIB", RFC 4150, August 2005.
  • [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
  • [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, 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.
  • [RFC5476] Claise, B., Ed., "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, March 2009.
  • [ZsZC01] Zseby, T., Zander, S., and G. Carle, "Evaluation of Building Blocks for Passive One-way-delay Measurements", Proceedings of Passive and Active Measurement Workshop (PAM 2001), Amsterdam, The Netherlands, April 23-24, 2001

Authors' Addresses 🫶

the people who wrote this, in case you want to slide into their inbox 💌🦋

Tanja Zseby 🌸

Tanja Zseby
Fraunhofer Institute for Open Communication Systems (FOKUS)
Kaiserin-Augusta-Allee 31
10589 Berlin, Germany
Phone: +49 30 3463 7153
EMail: tanja.zseby@fokus.fraunhofer.de

Elisa Boschi 🌈

Elisa Boschi
Hitachi Europe
c/o ETH Zurich
Gloriastrasse 35
8092 Zurich
Switzerland
Phone: +41 44 6327057
EMail: elisa.boschi@hitachi-eu.com

Nevil Brownlee 🍓

Nevil Brownlee
CAIDA (UCSD/SDSC)
9500 Gilman Drive
La Jolla, CA 92093-0505
Phone: +1 858 534 8338
EMail: nevil@caida.org

Benoit Claise ⭐

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