RFC 3917
Requirements for IP Flow Information Export (IPFIX)
Requirements for IP Flow Information Export (IPFIX) 🎀
Okay bestie, this is RFC 3917 💖 It's titled Requirements for IP Flow Information Export (IPFIX), and it came out in October 2004. The authors are J. Quittek (NEC Europe Ltd.), T. Zseby (Fraunhofer FOKUS), B. Claise (Cisco Systems), and S. Zander (Swinburne University). It's an Informational doc, so it's not a standard, just really good info for the community 🦋 It doesn't list anything it obsoletes or updates, so it's a clean slate ✨
Status of This Memo 📜
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice ©️
Copyright (C) The Internet Society (2004).
Abstract 🌸
This memo lays out the requirements for exporting measured IP flow information out of routers, traffic measurement probes, and middleboxes. It's giving "here's what the export system needs to do" energy 💅
Table of Contents 🧚
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. IP Traffic Flow. . . . . . . . . . . . . . . . . . . . 3
2.2. Observation Point. . . . . . . . . . . . . . . . . . . 4
2.3. Metering Process . . . . . . . . . . . . . . . . . . . 4
2.4. Flow Record. . . . . . . . . . . . . . . . . . . . . . 5
2.5. Exporting Process. . . . . . . . . . . . . . . . . . . 5
2.6. Collecting Process . . . . . . . . . . . . . . . . . . 5
3. Applications Requiring IP Flow Information Export . . . . . . 6
3.1. Usage-based Accounting . . . . . . . . . . . . . . . . 6
3.2. Traffic Profiling. . . . . . . . . . . . . . . . . . . 7
3.3. Traffic Engineering. . . . . . . . . . . . . . . . . . 7
3.4. Attack/Intrusion Detection . . . . . . . . . . . . . . 7
3.5. QoS Monitoring . . . . . . . . . . . . . . . . . . . . 8
4. Distinguishing Flows. . . . . . . . . . . . . . . . . . . . . 8
4.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Interfaces . . . . . . . . . . . . . . . . . . . . . . 9
4.3. IP Header Fields . . . . . . . . . . . . . . . . . . . 9
4.4. Transport Header Fields. . . . . . . . . . . . . . . . 10
4.5. MPLS Label . . . . . . . . . . . . . . . . . . . . . . 10
4.6. DiffServ Code Point. . . . . . . . . . . . . . . . . . 10
5. Metering Process. . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Reliability. . . . . . . . . . . . . . . . . . . . . . 10
5.2. Sampling . . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Overload Behavior. . . . . . . . . . . . . . . . . . . 11
5.4. Timestamps . . . . . . . . . . . . . . . . . . . . . . 12
5.5. Time Synchronization . . . . . . . . . . . . . . . . . 12
5.6. Flow Expiration. . . . . . . . . . . . . . . . . . . . 13
5.7. Multicast Flows. . . . . . . . . . . . . . . . . . . . 13
5.8. Packet Fragmentation . . . . . . . . . . . . . . . . . 13
5.9. Ignore Port Copy . . . . . . . . . . . . . . . . . . . 13
6. Data Export . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Information Model. . . . . . . . . . . . . . . . . . . 14
6.2. Data Model . . . . . . . . . . . . . . . . . . . . . . 16
6.3. Data Transfer. . . . . . . . . . . . . . . . . . . . . 16
6.3.1. Congestion Awareness. . . . . . . . . . . . . . 16
6.3.2. Reliability . . . . . . . . . . . . . . . . . . 17
6.3.3. Security. . . . . . . . . . . . . . . . . . . . 18
6.4. Push and Pull Mode Reporting . . . . . . . . . . . . . 18
6.5. Regular Reporting Interval . . . . . . . . . . . . . . 18
6.6. Notification on Specific Events. . . . . . . . . . . . 18
6.7. Anonymization. . . . . . . . . . . . . . . . . . . . . 18
7. Configuration . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Configuration of the Metering Process. . . . . . . . . 19
7.2. Configuration of the Exporting Process . . . . . . . . 19
8. General Requirements. . . . . . . . . . . . . . . . . . . . . 20
8.1. Openness . . . . . . . . . . . . . . . . . . . . . . . 20
8.2. Scalability. . . . . . . . . . . . . . . . . . . . . . 20
8.3. Several Collecting Processes . . . . . . . . . . . . . 20
9. Special Device Considerations . . . . . . . . . . . . . . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10.1. Disclosure of Flow Information Data. . . . . . . . . . 23
10.2. Forgery of Flow Records. . . . . . . . . . . . . . . . 24
10.3. Denial of Service (DoS) Attacks. . . . . . . . . . . . 24
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
12. Appendix: Derivation of Requirements from Applications. . . . 26
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
13.1. Normative References . . . . . . . . . . . . . . . . . 31
13.2. Informative References . . . . . . . . . . . . . . . . 31
14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 32
15. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 331. Introduction ✨
Okay so there are a bunch of applications that need flow-based IP traffic measurements 📊 Those measurements could be taken by a router while it's forwarding traffic, by a middlebox [RFC3234], or by a traffic measurement probe attached to a line or a monitored port. This memo sets the requirements for exporting that traffic flow information out of these boxes so other applications on other devices can process it 💅 These requirements are the input for standardizing the IPFIX protocol specifications.
In section 3, we get a selection of those applications, and the following sections list the requirements that come from them 🦋
In its early discussions, the IPFIX Working Group chose to evaluate existing flow export protocols at the same time it was developing this 'requirements' document. Multitasking queen behavior 👑
Flow export isn't performed by a protocol acting alone, though. It also needs a whole system of co-operating processes 🫶 So when producing the IPFIX requirements, the Working Group decided to specify what each of these processes needs, like the metering process, the exporting process, and so on. In these specifications we use lower-case for the words must, may, and should, to indicate that IPFIX implementors have some freedom as to how to meet the requirements 🌈
The Working Group's goal is to produce standards-track RFCs describing the IPFIX information model and export protocol RFCs. As well as meeting the requirements in this document, the information model and protocol documents will provide a full specification of the IPFIX system, and will use uppercase keywords as in [RFC 2119] 🎀
2. Terminology 📖
The following terminology is used in this document:
2.1. IP Traffic Flow 🌊
There are several definitions of the term 'flow' floating around the Internet community. Within this document we use the following one:
A flow is defined as a set of IP packets passing an observation point in the network during a certain time interval. All packets belonging to a particular flow have a set of common properties. Each property is defined as the result of applying a function to the values of:
- one or more packet header field (e.g., destination IP address), transport header field (e.g., destination port number), or application header field (e.g., RTP header fields [RFC3550])
- one or more characteristics of the packet itself (e.g., number of MPLS labels, etc.)
- one or more of fields derived from packet treatment (e.g., next hop IP address, the output interface, etc.)
A packet is defined to belong to a flow if it completely satisfies all the defined properties of the flow.
This definition covers the range from a flow containing all packets observed at a network interface to a flow consisting of just a single packet between two applications with a specific sequence number. Please note that the flow definition does not necessarily match a general application-level end-to-end stream. However, an application may derive properties of application-level streams by processing measured flow data. Also, please note that although packet properties may depend on application headers, there is no requirement defined in this document related to application headers 🙈
2.2. Observation Point 👀
The observation point is a location in the network where IP packets can be observed. Examples are a line to which a probe is attached, a shared medium such as an Ethernet-based LAN, a single port of a router, or a set of interfaces (physical or logical) of a router.
Note that one observation point may be a superset of several other observation points. For example, one observation point can be an entire line card. This would be the superset of the individual observation points at the line card's interfaces 🧩
2.3. Metering Process ⚙️
The metering process generates flow records. Its input is packet headers observed at an observation point, plus packet treatment at that observation point, like the selected output interface. The metering process is a set of functions that includes packet header capturing, timestamping, sampling, classifying, and maintaining flow records 💅
The maintenance of flow records may include creating new records, updating existing ones, computing flow statistics, deriving further flow properties, detecting flow expiration, passing flow records to the exporting process, and deleting flow records 🍓
The sampling function and the classifying function may be applied more than once with different parameters. Figure 1 shows the sequence in which the functions are applied. Sampling is not illustrated in the figure; it may be applied before any other function.
packet header capturing
|
timestamping
|
v
+----->+
| |
| classifying
| |
+------+
|
maintaining flow records
|
vFigure 1: Functions of the metering process 🧚
2.4. Flow Record 📝
A flow record contains information about a specific flow that was metered at an observation point. A flow record contains measured properties of the flow (e.g., the total number of bytes of all packets of the flow) and usually characteristic properties of the flow (e.g., source IP address) 💜
2.5. Exporting Process 📤
The exporting process sends flow records to one or more collecting processes. The flow records are generated by one or more metering processes 🌸
2.6. Collecting Process 📥
The collecting process receives flow records from one or more exporting processes. The collecting process might store received flow records or further process them, but these actions are out of the scope of this document 🫶
3. Applications Requiring IP Flow Information Export ✨
okay so this section is all about the apps that actually need IP flow info exported 💅 the requirements in later sections come from these apps, so picking them was super important 🫶 the goal isn't to cover EVERY app with EVERY export need (that would be chaos 💀). it's to cover the ones that matter in today's and/or future IP networks AND where the requirements can be met without going completely overboard 🎀
this list helps you actually understand the requirements, which is SO important when you're designing or implementing traffic flow metering functions 🧚 there's a full breakdown of which requirement came from which app in the appendix, so go peek 👀
ngl, every app can be built a bazillion different ways 🌸 the requirement details and how important each one is (required (MUST), recommended (SHOULD), optional (MAY)) can totally change depending on the implementation and/or the scenario 🦋 so we derive the requirements from what the apps generally do, not one specific version. some cases will even need stricter requirements than this doc sets 🔥 for example, usage-based accounting is probably THE app that needs the highest reliability of the bunch 💰 the reliability requirements in sections 5.1 and 6.3.2. aren't enough to guarantee the reliability many usage-based accounting systems need 😭 the particular reliability requirements for accounting systems are discussed in [RFC2975].
3.1. Usage-based Accounting
okay the business side 💼 new models for selling IP services and IP-based services are being looked into rn 👀 flat rate doesn't need accounting at all 😴 but otherwise accounting can be based on time or volume ⏰📦. accounting data can feed into billing systems 🧾. it can be done per user or per user group, and it can be just for basic IP service or per high-level service and/or per content type delivered 🎀. for advanced/future services, accounting may also be performed per class of service, per application, per time of day, per (label switched) path used, etc. ✨
3.2. Traffic Profiling
traffic profiling = characterizing IP flows with a model that captures key parameters like flow duration, volume, time, and burstiness 📊 it's a prerequisite for network planning, network dimensioning, trend analysis, business model development, and other stuff 🧠. how much it depends on the profiling objectives, which statistics you want, and how accurate they need to be 🎯. typical info needed: the distribution of used services and protocols in the network, the amount of packets of a specific type (e.g., percentage of IPv6 packets), and specific flow profiles 💖
since objectives can vary, this app needs a super flexible measurement infrastructure, especially for measurement configuration options and packet classification 🦋
3.3. Traffic Engineering
Traffic Engineering (TE) = methods for measurement, modelling, characterization and control of a network 🛠️ the goal is optimizing network resource utilization and traffic performance [RFC2702] 🏆. since control and administrative reaction to measurement results requires access to the involved network nodes, TE mechanisms and the required measurement function are usually performed within one administrative domain 🏠. typical TE parameters: link utilization, load between specific network nodes, number, size and entry/exit points of the active flows, and routing information 🗺️
3.4. Attack/Intrusion Detection
capturing flow info plays a big role in network security 🔐 both for detecting security violations and for defending afterward 🛡️. in a Denial of Service (DOS) attack, flow monitoring can allow detection of unusual situations or suspicious flows 🚨. then in a second step, flow analysis can gather info about the attacking flows and help derive a defense strategy ⚔️
intrusion detection is a more demanding app 😤 it doesn't only look at specific flow characteristics, it may also use stateful packet flow analysis to detect specific suspicious activities or unusually frequent ones 👀. these activities may be characterized by specific communication patterns, detectable by characteristic sequences of certain packet types 🕵️♀️
3.5. QoS Monitoring
QoS monitoring is the passive measurement of quality parameters for IP flows 📡. unlike active measurements, passive ones use the existing traffic in the network for QoS analysis 🌊. since no test traffic is sent, passive measurements can only be applied where the traffic of interest is already in the network 🙈. one example is validating QoS parameters negotiated in a service level specification 📝. passive/active measurement is also called non-intrusive/intrusive measurement, or measurement of observed/synthetic traffic 🧚
passive measurements can't give the kind of controllable experiments active ones can 🧪. on the other hand, they don't suffer from undesired side effects of sending test traffic (e.g., additional load, potential differences in treatment of test traffic and real customer traffic) 💅
QoS monitoring often requires correlating data from multiple observation points (e.g., for one-way metrics) ⏱️. this requires proper clock synchronization of the involved metering processes. for some measurements, flow records and/or notifications on specific events at the different observation points MUST be correlated, for example the arrival of a certain packet 🧩. for this, provisioning post-processing functions (e.g., generating packet IDs) at the metering processes would be useful. since QoS monitoring can produce a HUGE amount of measurement result data, it would highly benefit from mechanisms that reduce the measurement data, like aggregation of results and sampling 📉
not all QoS monitoring requirements are covered by the IPFIX requirements in the following sections 🙃. the IPFIX requirements target per flow information, including summaries of per-packet properties for packets within a flow, but not per-packet information itself. for example, jitter measurement requires timestamping each packet and reporting all timestamps of a flow, but the IPFIX requirements only cover timestamps of the first and last packet of a flow 😭
4. Distinguishing Flows
packets get mapped to flows by evaluating their properties 🧩. packets with common properties are considered to belong to the same flow, and a packet showing at least one difference in the set of properties is considered to belong to a different flow 🫶
the subsections list a set of properties which a metering process MUST, SHOULD, or MAY be able to evaluate for mapping packets to flows. requiring the ability to evaluate a property doesn't imply that this property MUST be evaluated for each packet ✨ in other words, meeting the IPFIX requirements means the metering process in general MUST be able, via its configuration, to somehow support distinguishing flows via all the MUST fields, even if in certain circumstances or for certain applications only a subset of the MUST fields is needed and effectively used to distinguish flows 💖
which combination of properties is used for distinguishing flows, and how they're evaluated, depends on the configuration of the metering process. the configured choice strongly depends on the environment and purpose of the measurement and on the information required by the collecting process 🎯. but in any case, a collecting process MUST be able to clearly identify, for each received flow record, which set of properties was used for distinguishing this flow from other ones 🔍
for specific deployments, only a subset of the required properties listed below can be used to distinguish flows, for example to aggregate flow records and reduce the number of flow records exported 📦. on the other hand, some other deployments will require distinguishing flows by some extra parameters, such as the TTL field of the IP header or the BGP Autonomous System number [RFC1771] of the IP destination address 🌍
4.1. Encryption
if encryption is used, the metering process might not be able to access all header fields 🔒. a metering process MUST meet the requirements stated in this section 4 only for packets that have the relevant header fields not encrypted 🤫
4.2. Interfaces
the metering process MUST be able to separate flows by the incoming interface, by the outgoing interface, or by both of them 🔀
4.3. IP Header Fields
the metering process MUST be able to separate flows by the following fields of the IP header 📋
- source IP address
- destination IP address
- protocol type (TCP, UDP, ICMP, ...)
for source address and destination address, separation by full match MUST be supported, as well as separation by prefix match 💯. the metering process SHOULD be able to separate flows by the IP version number if the observation point is located at a device that is supporting more than one IP version 🌈
4.4. Transport Header Fields
the metering process MUST be able to separate flows by the port numbers of the transport header in case of TCP or UDP being used as transport protocol 🚪. the metering process SHOULD be able to separate flows by the port numbers of the transport header in case of SCTP [RFC2960] 🫧
for separation, both source and destination port numbers MUST be supported for distinguishing flows, individually as well as in combination ✨
4.5. MPLS Label
if the observation point is located at a device supporting Multiprotocol Label Switching (MPLS, see [RFC3031]), then the metering process MUST be able to separate flows by the MPLS label 🏷️
4.6. DiffServ Code Point
if the observation point is located at a device supporting Differentiated Services (DiffServ), then the metering process MUST be able to separate flows by the DiffServ Code Point (DSCP, see [RFC2474]) 💜
5. Metering Process
the following are requirements for the metering process 📏. all measurements MUST be conducted from the point of view of the observation point 🔭
5.1. Reliability
the metering process MUST either be reliable, or the absence of reliability MUST be known and indicated 🚦. the metering process is reliable if each packet passing the observation point is metered according to the configuration of the metering process 💯. if, e.g., due to some overload, not all passing packets can be included into the metering process, then the metering process MUST be able to detect this failure and to report it 📣
and that's the whole part! the rest of the doc keeps going from here 🫶💅
5.2. Sampling ✨
okay so sampling is basically picking a subset (the sample) out of a bigger group (the parent population) 🎀. You usually do it so you can estimate something about the whole group using just the sample. You can sample packets out of all the packets in a flow, or pick flows out of all the flows on a link. Sampling methods differ in their strategy (systematic or random) and in what triggers picking an element. A packet can get picked because of its arrival time (time-based), its position in the flow (count-based), or what's inside it (content-based) 💅
The metering process may support packet sampling. If it does, the sampling configuration must be well defined, and that includes the sampling method and all its parameters 🧚
If the sampling configuration changes during operation, the new sampling configuration and its parameters must be indicated to all collecting processes receiving the affected flow records. Changing it includes adding a sampling function to the metering process, removing a sampling function from it, changing the sampling method, and changing sampling parameter(s) 🔄
If anything in the sampling configuration changes, all flow records metered under the previous configuration must be terminated and exported according to the export configuration. And the metering process must not merge the flow records made with the new configuration with the ones made with the previous configuration. no mixing, bestie 🙅
5.3. Overload Behavior 💀
so when things get overloaded (like running out of memory or processing power), the metering process may change how it behaves so it can cope with the lack of resources. The possible reactions include:
- Reduce the number of flows to be metered. This can be achieved by more coarse-grained flow measurement or by a restriction of the flow records to a subset of the set of original ones.
- Start sampling packets before they are processed by the metering process or, if sampling is already performed, reduce the sampling frequency.
- Stop metering.
- Reduce the resource usage of competing processes on the same device. Example: reducing the packet forwarding throughput.
overload behavior isn't limited to those four options 🙈 But if the overload behavior changes how the metering process behaves, the overload behavior must be clearly defined.
for some flows, the change might affect the data that gets stored in their flow records afterwards, like if the packet classification changes or the sampling frequency does. These flows must be considered terminated, and their flow records must be exported separately from the new ones generated after the behavior change. The terminated flow records and the new ones must not be merged by the metering process, and the collecting process must be able to tell the affected flow records from before and after the change apart. This requirement does not apply to flows and their flow records that the change of metering process behavior doesn't affect 🦋
5.4. Timestamps ⏰
the metering process must be able to generate timestamps for the first and the last observation of a packet of a flow at the observation point. The timestamp resolution must be at least the one of the sysUpTime [RFC3418], which is one centisecond. so, at minimum, one centisecond precision 🌸
5.5. Time Synchronization 🕰️
it must be possible to synchronize timestamps generated by a metering process with Coordinated Universal Time (UTC) 🌍
and this one's a fun one: being able to sync each single metering process with UTC means you can also sync the timestamps from different metering processes with each other 🤝
BUT (and this is important) that doesn't mean the timestamps from the metering process are UTC timestamps automatically. For example, you can meet this requirement by using local system clock values as timestamps and adding an additional timestamp when exporting a report to a collecting process. Then the collecting process can sync the timestamps by calculating the offset between UTC and the metering process's system clock. big brain energy 🧠✨
5.6. Flow Expiration 🥀
the metering process must be able to detect flow expirations. A flow is considered expired if no packet of that flow has been observed for a given timeout interval. The metering process may support ways to detect a flow's expiration before the timeout happens, for example by detecting the FIN or RST bits in a TCP connection. The procedure for detecting a flow expiration must be clearly defined 🚪
5.7. Multicast Flows 📡
for multicast flows containing packets replicated to multiple output interfaces, the metering process should be able to keep discrete flow records for each different output interface. For example, the metering process should be able to report an incoming multicast packet that's replicated to four output interfaces as four different flow records, each differing by its output interface 🪞
5.8. Packet Fragmentation 🧩
with IP packet fragmentation, and depending on the classification scheme, only the zero-offset fragment of a single initial packet might have enough info to classify the packet. Note that this fragment should be the first one generated by the router doing the fragmentation [RFC791], but it might not be the first one the IPFIX device observes, because of reordering 🌀
The metering process may keep state about IP packet fragmentation so it can correctly map fragments that don't have enough header info to their flows 🫶
5.9. Ignore Port Copy 🙅♀️
the metering process may be able to ignore packets generated by a port copy function acting at the device where the observation point of a flow is located 👀
6. Data Export 🚀
these are the requirements for exporting flow records out of the exporting process 📤 Besides the data transfer requirements, we separate the requirements about the information model from the ones about the data model. We also list requirements on reporting times and on notifications about specific events, plus requirements on anonymization of flow records 🎀
6.1. Information Model 📚
the information model for flow information export is the list of attributes of a flow that go in the report, including the semantics of those attributes 💖
this section lists attributes an exporting process must, should, or may be able to report. That doesn't mean every exported flow record has to contain all the required attributes. But it does mean the exporting process must be configurable so that the info for all required attributes can be sent from the exporting process to the receiving collecting process(es) for each exported flow 🍓
in other words, meeting the IPFIX requirements means the exporting process in general must be able, through its configuration, to report all the must fields. That's true even if, in certain circumstances or for certain applications, only a subset of all the must fields is needed and actually reported 🧃
Beyond that, the exporting process might offer to report further attributes not mentioned here. A particular flow record may contain some of the "required" attributes plus some additional ones, for example ones covering future technologies 🔮
This document doesn't require that the following attributes be reported for every single flow record, especially repetitive attributes. For example, if the observation point is the incoming packet stream at the IP interface with the ifIndex value 3, that observation point doesn't have to be exported as part of every single flow record. Exporting it just once might give the collecting process enough info 🙌
The exporting process must be able to report the following attributes for each metered flow:
- IP version number This requirement only applies if the observation point is located at a device supporting more than one version of IP.
- source IP address
- destination IP address
- IP protocol type (TCP,UDP,ICMP,...)
- if protocol type is TCP or UDP: source TCP/UDP port number
- if protocol type is TCP or UDP: destination TCP/UDP port number
- packet counter If a packet is fragmented, each fragment is counted as an individual packet.
- byte counter The sum of the total length in bytes of all IP packets belonging to the flow. The total length of a packet covers the IP header and the IP payload.
- type of service octet (in case of IPv4), traffic class octet (in case of IPv6). According to [RFC2474], these octets include the DiffServ Code Point, which has a length of 6 bits.
- in case of IPv6: Flow Label
- if MPLS is supported at the observation point: the top MPLS label or the corresponding forwarding equivalence class (FEC, [RFC3031]) bound to that label. The FEC is typically defined by an IP prefix.
- timestamp of the first packet of the flow
- timestamp of the last packet of the flow
- if sampling is used: sampling configuration
- unique identifier of the observation point
- unique identifier of the exporting process
The exporting process should be able to report the following attributes for each metered flow:
- if protocol type is ICMP: ICMP type and code
- input interface (
ifIndex) This requirement does not apply if the observation point is located at a probe device. - output interface (
ifIndex) This requirement does not apply if the observation point is located at a probe device. - multicast replication factor the number of outgoing packets originating from a single incoming multicast packet. This is a dynamic property of multicast flows, and it may change over time. For unicast flows it has the constant value 1. The reported value must be the value of the factor at the time the flow record is exported.
The exporting process may be able to report the following attributes for each metered flow:
- Time To Live (in case of IPv4) or Hop Limit (in case of IPv6)
- IP header flags
- TCP header flags
- dropped packet counter at the observation point If a packet is fragmented, each fragment must be counted as an individual packet.
- fragmented packet counter counter of all packets for which the fragmented bit is set in the IP header
- next hop IP address
- source BGP Autonomous System number (see [RFC1771])
- destination BGP Autonomous System number
- next hop BGP Autonomous System number
6.2. Data Model ✨
okay so the data model is basically the rulebook for how info gets written down inside flow records 📝 and it's giving future-proof 🔮
it has to be extensible, bestie. new attributes need to be addable later 💅 and even if a set of attributes is fixed in the flow record, the data model still needs a way to extend the record through configuration or for certain implementations 🧚
the data model used for exporting flow information must be flexible about the flow attributes in flow records 🦋 a flexible record format lets you define records in a customizable way, with the number and type of attributes totally up to you 🎀
also, the data model should be independent of the underlying transport protocol (aka the data transfer) 🌸 the data model shouldn't care how things get delivered, it just cares about the data 💖
6.3. Data Transfer 🚚
okay this part is about getting the flow records from the exporting process to the collecting process without them getting lost or hacked 😭 the requirements cover reliability, congestion awareness, and security 🔐
to meet these, the exporting process can use security features already on the device hosting it and/or ones provided by the transport network 🫶 for example it can use existing security tech for authentication and encryption, or it can rely on physical protection of a separated network to move flow info around 🏰
6.3.1. Congestion Awareness 🌊
for the data transfer, a congestion aware protocol must be supported 💜
6.3.2. Reliability 💪
if flow records get lost during the data transfer from the exporting process to the collecting process, that loss must be indicated at the collecting process 🚨 and the indication has to let the collecting process figure out roughly how many flow records went missing 🔢
possible reasons for flow record loss include (but aren't limited to) these vibes:
- Metering process limitations: lack of memory, processing power, etc. These limitations are already covered in section 5.1. 🧠
- Exporting process limitations: lack of memory, processing power, etc. 📦
- Data transfer problems: packets that carry flow records sent from the exporting process to the collecting process get dropped by the network 🌧️ examples are connection failures and losses by a transport protocol that specifically offers congestion avoidance without persistent transport-level reliability 💀
- Collecting process limitations: it may be experiencing congestion and not be able to buffer new flow records 🥴
- Operation and Maintenance: the collecting process is taken down for maintenance or other administrative purposes 🛠️
please note, if an unreliable transport protocol is used, reliability can be provided by higher layers 🙌 and if reliability is provided by higher layers, only the lack of overall reliability must be indicated 🎯 for example, reordering could be handled by adding a sequence number to each packet 🔢✨
the data transfer between the exporting process and the collecting process must be open to reliability extensions, including at least:
- retransmission of lost flow records,
- detection of disconnection and fail-over, and
- acknowledgement of flow records by the collecting process.
this extensibility can be used to add extra reliability 💖 but the extended protocol still has to meet every requirement in this section, and in particular it must still be congestion aware 🌊 so extensions that use retransmissions must use exponential backoff 📉 no skipping that part, bestie 🙅♀️
6.3.3. Security 🔒
confidentiality of IPFIX data transferred from an exporting process to a collecting process must be ensured 🤫
integrity of IPFIX data transferred from an exporting process to a collecting process must be ensured 🧷
authenticity of IPFIX data transferred from an exporting process to a collecting process must be ensured 🪪
the security requirements were derived from an analysis of potential security threads 🧵 the analysis is summarized in Section 10 📖
6.4. Push and Pull Mode Reporting 📤📥
okay so there are two main ways to decide when to report: push mode and pull mode 💅 in push mode, the exporting process decides on its own, with no outside trigger, when to send flow records 🚀 in pull mode, sending flow records is triggered by an explicit request from a collecting process 🙋♀️
the exporting process must support push mode reporting, and it may support pull mode reporting 🌈
6.5. Regular Reporting Interval ⏰
the exporting process should be capable of reporting measured traffic data regularly, according to a given interval length 💖 very routine, very cute 🎀
6.6. Notification on Specific Events 🔔
the exporting process may be capable of sending notifications to a collecting process when a specific event happens ✨ an event can be, for instance, the arrival of the first packet of a new flow, or the termination of a flow after the flow timeout 🏁
6.7. Anonymization 🕶️
the exporting process may be capable of anonymizing source and destination IP addresses in flow data before exporting them 🫥 it may also support anonymizing port numbers and other fields 🔐 quick note: anonymization isn't originally an application requirement, it's derived from general requirements for handling measured traffic data within a network 🧠
for several applications, anonymization can't be applied, for example for accounting and traffic engineering 🧾 but for protecting the network user's privacy, anonymization should be applied whenever possible 🫶 in many cases it's enough if anonymization happens at the collecting process after the flow info has been exported 📬 this gives reasonable privacy protection as long as the confidentiality of the export is provided 🔒
it would be iconic to request that all IPFIX exporters provide anonymization of flow records 😭 but anonymization algorithms are still a research issue 🔬 several are known, but the security they provide and their other properties haven't been studied enough yet 🥲 also, there's no standardized method for anonymization 🙈 so the requirement for the exporting process supporting anonymization is qualified with 'may' and not with 'must' 💜
if anonymized flow data is exported, this must be clearly indicated to all receiving collecting processes 📣 so they can tell anonymized data apart from non-anonymized data 👀
7. Configuration ⚙️
if configuration is done remotely, security should be provided for the configuration process, covering confidentiality, integrity, and authenticity 🔐 the means used for remote configuration are out of the scope of this document 🙅♀️
7.1. Configuration of the Metering Process 📏
the metering process must provide a way of configuring traffic measurement 🎛️ the following parameters of the metering process should be configurable:
- specification of the observation point, e.g., an interface or a list of interfaces to be monitored. 👀
- specifications of flows to be metered 🌊
- flow timeouts ⏳
the following parameters may be configurable:
- sampling method and parameters, if feature is supported 🎲
- overload behavior, if feature is supported 🥵
7.2. Configuration of the Exporting Process 📡
the exporting process must provide a way of configuring the data export 📦 the following parameters of the exporting process should be configurable:
- reporting data format. Specifying the reporting data format must include a selection of attributes to be reported for each flow. 🧾
- the collecting process(es) to which flows are reported 🎯
- the reporting interval. This requirement only applies if the exporting process supports reporting in regular intervals. ⏰
- notifications to be sent to the collecting process(es). This requirement only applies if the exporting process supports notifications. 🔔
- flow anonymization. This requirement only applies if the exporting process supports flow anonymization. 🕶️
8. General Requirements 🌟
8.1. Openness 🌈
IPFIX specifications should be open to future technologies 🚀 this includes extensibility of the configuration of the metering process and the exporting process 🧩
openness is also required concerning the extensibility of the data model, as stated in section 6.2 💖
8.2. Scalability 📈
data collection from hundreds of different exporting processes must be supported 🏘️ the collecting process must be able to distinguish several hundred exporting processes by their identifiers 🪪 that's a whole crowd, bestie 👑
8.3. Several Collecting Processes 👯
the exporting process may be able to export flow information to more than one collecting process 📬📬 if an exporting process is able to export flow records to multiple collecting processes, then it must be able to ensure that the flow records can be identified, so that duplicates can be detected between different collecting processes and double counting problems can be avoided 🙅♀️🔢 no double counting, periodt 💅
9. Special Device Considerations 🧚
okay bestie, this section is basically the doc saying "we are NOT gonna boss around your hardware" 🎀 This document intends to avoid constraining the architecture of probes, routers, and other devices hosting observation points, metering processes, exporting processes, and/or collecting processes. It can be expected that observation point, metering process, and exporting process are usually co-located at a single device. However, the requirements in this document do not exclude devices that come from this setup. Figure 2 shows some examples ✨
Every example is built from one or more of these pieces: observation point (O), metering process (M), exporting process (E), and collecting process (C). The observation points in the figure are always the most fine-granular ones the device supports 💅
+---+ +-----+ +---------+ +---------+
| E-+-> | E--+-> | E----+-> <-+--E E--+->
| | | | | | | / \ | | | | |
| M | | M | | M M | | M M |
| | | | /|\ | | /|\ /|\ | | /|\ /|\ |
| O | | OOO | | OOO OOO | | OOO OOO |
+---+ +-----+ +---------+ +---------+
Probe Basic Complex Multiple
Router Router Exporting
Processes
+---+ +---+ +---+
| E-+-> | E-+-> | E-+------------->---+
| | | | | | | | | +---+ +-+-----+
+-+-+ | M | | M | | E-+------->-+-C-M-E-+->
| | | | | | | | | | +---+ +-+-----+
+-+-+ +-+-+ | O | | M | | E-+->---+
| | | | +---+ | | | | | |
| M | +-+-+ | O | | M |
| | | | | | +---+ | | | +-----+
| O | | O | | O | ->-+-C-E-+->
+---+ +---+ +---+ +-----+
Protocol Remote Concentrator Proxy
Converter Observation
Figure 2: IPFIX-related Devicesa probe is the simplest one 🌸 A typical probe has a single observation point, a single metering process, and a single exporting process.
a basic router levels things up by having multiple observation points 🦋 Here, the observation point of a particular flow might be one of the most fine-granular observation points shown, but it could also be a set of them.
a more complex router can host more than one metering process, for example one per line card 👑 Please note that the observation point of a single flow cannot go beyond the set of most fine-granular observation points linked to one metering process, because only the metering process can merge packets seen at different fine-granular observation points into a joint flow. An observation point that contains all the most fine-granular observation points of this router is not possible with this structure. Alternatively, a complex router can host different exporting processes for flow records generated by different metering processes 🧠
a protocol converter uses a metering process that can only be reached through protocol(s) other than the one defined for IPFIX, for example SNMP and the Meter MIB module [RFC2720] 🔥 Then the exporting process receives flow records from a remote metering process and exports them using the IPFIX protocol. Please note that this document makes no particular assumption about how metering processes and exporting processes exchange information, as long as all the individual requirements for these processes are met. Also, where metering processes are located isn't relevant for this document (unlike where observation points and exporting processes are located) 🫶
in the remote packet observation example in Figure 2, the metering process and the observation point are not co-located 🌈 Packet headers captured at an observation point may be exported as raw data to a device hosting the metering process and exporting process. Again, this document makes no particular assumption about how packet headers get from observation points to metering processes, as long as all the requirements for the metering processes are met.
an intermediate structure between a protocol converter and remote observation (not shown in the figure) would be a split metering process 🍓 For example, it could do timestamping and sampling on the device hosting the observation point, and then do packet classification on another device hosting the exporting process.
a concentrator receives flow records via the IPFIX protocol, merges them into more aggregated flow records, and exports them again using the IPFIX protocol 💖 Please note that for the final flow records, the resulting observation point may be a superset of the more fine-granular observation points at the first-level devices. The metering process of the final flow records is made up of the (partial) metering processes at the first-level devices plus the partial metering process at the concentrator.
finally, the very simple IPFIX-related device is a proxy 💜 It just receives flow records using the IPFIX protocol and sends them further using the same protocol. A proxy might be useful for getting through firewalls or other gateways.
10. Security Considerations 🔐
an IPFIX protocol must be capable of transporting data over the public Internet 😭 So it can't be ruled out that an attacker captures or modifies packets, or inserts extra packets. this is the part where we get serious, periodt.
This section describes the security requirements for IPFIX. Like other requirements, the security requirements differ between the applications being considered. The incentive to modify collected data for accounting or intrusion detection, for instance, is usually higher than the incentive to change data collected for traffic profiling. A detailed list of the required security features per application can be found in the appendix 🎀
the suggestion of concrete solutions for reaching the required security properties should be part of an IPFIX architecture and protocol. That's out of scope for this document. Methods for remote configuration of the metering processes and exporting processes are also out of scope. So threats caused by data exchange for remote configuration are not considered here 🙈
the following potential security hazards for an IPFIX protocol have been identified: disclosure of IP flow information, forgery of flow records, and Denial of Service (DoS) attacks 💀
10.1. Disclosure of Flow Information Data
the content of data exchanged by an IPFIX protocol (for example IPFIX flow records) should be kept confidential between the parties involved (exporting process and collecting process) 🤫 Observing IPFIX flow records gives an attacker information about the active flows in the network, communication endpoints, and traffic patterns. That information can be used not only to spy on user behavior but also to plan and hide future attacks. Therefore, the requirements specified in section 6.3.3. include confidentiality of the transferred data. This can be achieved, for instance, by encryption 🔒
privacy matters too. The users who act as sender or receiver of the measured traffic need their privacy protected when they use the Internet 🌸 In many countries, the right to store user-specific data (including the user's traffic profiles) is restricted by law or regulation.
besides encryption, this kind of privacy can also be protected by anonymizing flow records ✨ For many traffic flow measurements, anonymized data is as useful as precise data. So it's desirable to support anonymization in IPFIX implementations. Developing and standardizing anonymization methods is beyond the scope of the IPFIX Working Group. However, the extensibility requirements of the IPFIX protocol are sufficient to support anonymized flow records once appropriate methods are standardized 🦋
10.2. Forgery of Flow Records
if flow records are used in accounting and/or security applications, there are potentially strong incentives to forge exported IPFIX flow records (for example, to save money or to prevent an attack from being detected) 🥲 This can be done either by altering flow records on the path, or by injecting forged flow records that pretend to come from the original exporting process.
special caution is needed if security applications rely on flow measurements 🚨 With forged flow records it's possible to trick security applications. For example, an application may be led to wrongly conclude that a DoS attack is in progress. If an injection of IPFIX traffic flow records fools the security application into wrongly concluding that a DoS attack is underway, then the countermeasures the security application uses may actually deny useful, non-malicious services 😤
to make an IPFIX protocol resistant against such attacks, authentication and integrity must be provided, as specified in section 6.3.3 🛡️
10.3. Denial of Service (DoS) Attacks
DoS attacks on routers or other middleboxes that have the IPFIX protocol implemented would also affect IPFIX and impair the sending of IPFIX records 🌧️ Still, because such hazards are not induced specifically by the IPFIX protocol, preventing such attacks is out of scope for this document.
however, IPFIX itself also creates potential DoS hazards 👀 Any process that expects to receive traffic can be the target of a DoS attack. For the exporting process, this is only the case if it supports pull mode (which can be an optional feature of the IPFIX protocol according to this document). The collecting process always expects data, so it can be flooded with flow records 💥
11. Acknowledgments 💌
many thanks to Georg Carle for contributing to the application analysis, to K.C. Norseth for several fine-tunings, to Sandra Tartarelli for checking the appendix, and to a lot of people on the mailing list for valuable comments and suggestions, including Nevil Brownlee, Carter Bullard, Paul Calato, Ram Gopal, Tal Givoly, Jeff Meyer, Reinaldo Penno, Sonia Panchen, Simon Leinen, David Plonka, Ganesh Sadasivan, Kevin Zhang, and many more 🫶🎀💖
12. Appendix: Derivation of Requirements from Applications 📚
the table here shows how the requirements stated in sections 3-7 are derived from the requirements of the applications listed in section 2 🧚 The abbreviations used are:
Used abbreviations:
M = must
S = should
O = may (optional)
- = DONT CAREokay bestie, we're mid-table now, so no intro needed 🦋 the columns are the five application columns A through E plus IPFIX, and every row keeps its exact marks 💅
-----------------------------------------------------------------------.
IPFIX |
----------------------------------------------------------------. |
E: QoS Monitoring | |
----------------------------------------------------------. | |
D: Attack/Intrusion Detection | | |
----------------------------------------------------. | | |
C: Traffic Engineering | | | |
----------------------------------------------. | | | |
B: Traffic Profiling | | | | |
----------------------------------------. | | | | |
A: Usage-based Accounting | | | | | |
----------------------------------. | | | | | |
| | | | | | |
| Sect. | Requirement | A | B | C | D | E | IPFIX|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4. | DISTINGUISHING FLOWS |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4. | Combination of | M | M | M | M | M | M |
| | required attributes | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.1. | in/out IF | S | M | M | S | S | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.2. | src/dst address | M | M | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.2. | Masking of IP addresses | M | M | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.2. | transport protocol | M | M | - | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.2. | version field | - | S | S | O | O | S |
| | | | | (b) | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| Sect. | Requirement | A | B | C | D | E | IPFIX|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.3. | src/dst port | M | M | - | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.4. | MPLS label (a) | S | S | M | O | S | M |
| | | | | (c) | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 4.5. | DSCP (a) | M | S | M | O | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5. | METERING PROCESS |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.1. | Reliability | M | S | S | S | S | |
|-------+-------------------------+-----+-----+-----+-----+-----+ M |
| 5.1. | Indication of | - | M | M | M | M | |
| | missing reliability | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.2. | Sampling (d,e) | O | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.3. | Overload Behavior (f) | O | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.4. | Timestamps | M | O | O | S | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.5. | Time synchronization | M | S | S | S | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.6. | Flow timeout | M | S | - | O | O | M |
| | | (g) | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.7. | Multicast flows | S | O | O | O | S | S |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.8. | Packet fragmentation | O | O | - | - | - | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 5.9. | Ignore port copy | O | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6. | DATA EXPORT |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | INFORMATION MODEL |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | IP Version | - | M | M | O | O | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | src/dst address | M | M | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | transport protocol | M | M | - | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | src/dst port | M | M | - | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | Packet counter (h) | S | M | M | S | S | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| Sect. | Requirement | A | B | C | D | E | IPFIX|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | Byte counter | M | M | M | S | S | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | ToS (IPv4) or traffic | M | S | M | O | M | M |
| | class octet (IPv6) | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | Flow Label (IPv6) | M | S | M | O | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | MPLS label (a) | S | S | M | O | S | M |
| | | | | (c) | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | Timestamps for | M | O | O | S | S | M |
| | first/last packet | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | Sampling configuration | M | M | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | observation point | M | M | M | M | M | M |
| | identifier | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | export process | M | M | M | M | M | M |
| | identifier | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | ICMP type and code (i) | S | S | - | S | S | S |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | input/output interface | S | S | S | S | S | S |
| | (j) | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | Multicast | O | S | S | - | S | S |
| | replication factor | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | TTL | O | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | IP header flags | - | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | TCP header flags | - | O | O | O | - | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | Dropped Packet | O | O | O | O | O | O |
| | Counter (h,k) | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | Fragment counter | - | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | next hop IP address | O | O | O | O | - | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.1. | src / dst / next hop | - | O | O | - | - | O |
| | BGP AS # | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| Sect. | Requirement | A | B | C | D | E | IPFIX|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.2. | DATA MODEL |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.2. | Flexibility | M | S | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.2. | Extensibility | M | S | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.3. | DATA TRANSFER |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.3.1.| Congestion aware | M | M | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.3.2.| Reliability | M | S | S | S | S | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.3.3.| Confidentiality | M | S | S | M | S | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.3.4.| Integrity | M | M | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.3.5.| Authenticity | M | M | M | M | M | M |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.4. | REPORTING TIMES |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.4. | Push mode | M | O | O | M | S | M |
| | | | (l) | (l) | |(l,m)| |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.4. | Pull mode | O | O | O | O | O | O |
| | | | (l) | (l) | | (l) | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.4.1.| Regular interval | S | S | S | S | S | S |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.6. | Notifications | O | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 6.7. | Anonymization (n) | O | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7. | CONFIGURATION |that's the table for this part 🎀 more to come, stay tuned 💜
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7. | Secure remote | S | S | S | S | S | S |
| | configuration (a) | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7.1. | Config observation point| S | S | S | S | S | S |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7.1. | Config flow | S | S | S | S | S | S |
| | specifications | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7.1. | Config flow timeouts | S | S | S | S | O | S |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| Sect. | Requirement | A | B | C | D | E | IPFIX|
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7.1. | Config sampling | O | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7.1. | Config overload | O | O | O | O | O | O |
| | behavior (a) | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7.2. | Config report | S | S | S | S | S | S |
| | data format | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 7.2. | Config | S | S | S | S | S | S |
| | notifications | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 8. | GENERAL REQUIREMENTS |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 8.1. | Openness | S | S | S | S | S | S |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 8.2. | Scalability: | | | | | | |
| | data collection | M | S | M | O | S | M |
| | from hundreds of | | | | | | |
| | measurement devices | | | | | | |
|-------+-------------------------+-----+-----+-----+-----+-----+------|
| 8.3. | Several collectors | O | O | O | O | O | O |
|-------+-------------------------+-----+-----+-----+-----+-----+------|Remarks 💌
Okay, the remarks are where the table gets its receipts 🧾✨
- (a) Only if the feature is supported. 💅
- (b) The IPv4 vs IPv6 split matters a lot for traffic engineering, so we tended to make it a must. 🔥 But a should is enough for most TE tasks, and it lets IPFIX get a should instead of a must. 🌸
- (c) For TE in an MPLS network the label is essential, so this one is a must, which makes IPFIX a must too. 👑
- (d) If sampling is supported, the methods and parameters must be well defined. 📏
- (e) If sampling is supported, sampling configuration changes must be indicated to all collecting processes. 📣
- (f) If overload behavior is supported and it changes how the metering process behaves, that overload behavior must be clearly defined. 🧯
- (g) Precise time-based accounting requires reacting to a flow timeout. ⏰
- (h) If a packet gets fragmented, each fragment counts as its own individual packet. 🧩
- (i) If the protocol type is ICMP. 🛰️
- (j) This requirement doesn't apply if the observation point sits at a probe device. 🔍
- (k) Only if the measurement happens on the data path, meaning it has access to the forwarding decision. 🛣️
- (l) Either push or pull has to be supported. 🫶
- (m) Required, so drop indications can be reported right away for SLA validation. 🚨
- (n) Anonymization must be clearly indicated to all receiving collecting processes. 🙈
13. References 📚
13.1. Normative References
Bestie, these are the non-negotiable reads 💖
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.13.2. Informative References
These ones are the extra-credit reading 🌈
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, February 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to
Accounting Management", RFC 2975, October 2000.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over
MPLS", RFC 2702, September 1999.
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the
Simple Network Management Protocol (SNMP)", STD 62, RFC
3418, December 2002.
[RFC2720] Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC
2720, October 1999.14. Authors' Addresses 🫶
Meet the squad who built this 💕
Juergen Quittek
NEC Europe Ltd., Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221 90511 15
EMail: quittek@netlab.nec.de
Tanja Zseby
Fraunhofer Institute for Open Communication Systems (FOKUS)
Kaiserin-Augusta-Allee 31
10589 Berlin
Germany
Phone: +49 30 3463 7153
EMail: zseby@fokus.fhg.de
Benoit Claise
Cisco Systems
De Kleetlaan 6a b1
1831 Diegem
Belgium
Phone: +32 2 704 5622
EMail: bclaise@cisco.com
Sebastian Zander
Centre for Advanced Internet Architectures, Mail H31
Swinburne University of Technology
PO Box 218
John Street, Hawthorn
Victoria 3122, Australia
Phone: +61 3 9214 8089
EMail: szander@swin.edu.au15. Full Copyright Statement 💜
Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. ✨
Now the legal bit, which has to be word-for-word so nobody can say I fudged it 🙈
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Intellectual Property 🦋
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't claim to have made any independent effort to identify any such rights. Info on the IETF's procedures for rights in IETF Documents can be found in BCP 78 and BCP 79. 📖
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use these proprietary rights can be found in the IETF on-line IPR repository at:
http://www.ietf.org/iprThe IETF invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology needed to implement this standard. Please send that info to the IETF at:
ietf-ipr@ietf.orgAcknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, legends 🙌✨
📦 where this page comes from
- ietf: rfc3917 2004-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms