RFC 5471
Guidelines for IP Flow Information Export (IPFIX) Testing
RFC 5471: Guidelines for IP Flow Information Export (IPFIX) Testing 🎀
okay bestie, this is RFC 5471, and it's all about how to test IPFIX implementations 💖 It came out in March 2009 and is in the Informational category, which means it shares info with the Internet community but doesn't set any official standard 🌸 It belongs to the Network Working Group. C. Schmoll from Fraunhofer FOKUS wrote it, along with P. Aitken and B. Claise from Cisco Systems, Inc. 👑 The header doesn't list any RFCs it obsoletes or updates, so it's a standalone little guide ✨
part 1 of 7, more to come, so stay tuned 🦋
Status of This Memo ✨
okay so this memo is just for info, not a standard of any kind 💅 It's free to share, and distribution is unlimited 🌈
Copyright Notice 💜
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved 🔥
ngl this part is a lot, but the important bit is that the doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, as they were on the publication date. Read those carefully, because they spell out your rights and restrictions 🫶 The doc might also have material from IETF Documents or IETF Contributions that were published or made public before November 10, 2008. The people who own the copyright on some of that stuff might not have let the IETF Trust allow modifications outside the IETF Standards Process 😭 So unless you get a proper license from them, you can't modify this doc outside the IETF Standards Process, and you can't make derivative works outside it either. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English 💀
Abstract 🌸
this doc is a list of tests for implementers of IP Flow Information eXport (IPFIX) compliant Exporting Processes and Collecting Processes 🦋 It lays out guidelines for a bunch of tests you can run on those Exporting and Collecting Processes to check how conformant and robust your IPFIX protocol implementation is 🧚 The tests cover all the important functions, so you can get real confidence in your IPFIX implementation. That means you can do interoperability or plug tests against other IPFIX Exporting Processes and Collecting Processes 🍓
Table of Contents 🧚
1. Introduction ....................................................4
1.1. Document Scope .............................................4
1.2. IPFIX Documents Overview ...................................5
2. Terminology .....................................................5
2.1. Conventions Used in This Document ..........................5
3. Test Specifications .............................................5
3.1. Exporting Process/Collecting Process Connectivity Tests ....6
3.1.1. Connectivity Tests between the Exporting
Process and Collecting ..............................6
3.2. Template and Data Record Tests .............................6
3.2.1. Transmission of Template with Fixed-Size
Information Elements ................................7
3.2.2. Transmission of Template with
Variable-Length Information Elements ................7
3.2.3. Set Padding .........................................7
3.2.4. Record Padding ......................................8
3.2.5. Template Withdrawal Message .........................9
3.3. Information Element Tests .................................11
3.3.1. Enterprise-Specific Information Elements ...........11
3.3.2. Reduced Size Encoding of Information Elements ......11
3.3.3. Multiple Instances of the Same Information
Element in One Template.............................12
3.4. Options Template Tests ....................................12
3.4.1. Using Any Information Elements as Scope ............12
3.4.2. Using Multiple Scopes ..............................13
3.4.3. Metering Process Statistics Option Template ........13
3.4.4. Metering Process Reliability Statistics
Option Template ....................................14
3.4.5. Exporting Process Reliability Statistics
Option Template ....................................14
3.4.6. Flow Keys Option Template ..........................14
3.5. Stress/Load Tests .........................................15
3.5.1. Large Number of Records for One Template ...........15
3.5.2. Excessive Rate of Incoming Data Records ............15
3.5.3. Large Templates ....................................16
3.5.4. Many New Templates within the Data Template
Timeout Interval ...................................16
3.5.5. Multiple Exporting Processes Exporting to
One Collecting Process .............................17
3.5.6. Export from One Exporting Process to
Multiple Collecting Processes ......................17
3.6. Error Handling ............................................17
3.6.1. Temporary Network Disconnect .......................17
3.6.2. Exporting Process Termination and Restart
during Data Transmission ...........................18
3.6.3. Collecting Process Termination and Restart
during Data Transmission ...........................18
3.6.4. Incorrect Template Records and Options
Template Records ...................................19
3.6.5. Incorrect Data Record ..............................22
3.6.6. Export of Non-Matching Template and Data Records ...23
3.6.7. Unknown Set IDs ....................................23
3.6.8. Re-Using Template IDs ..............................24
3.7. TLS Connectivity and Policy Selection .....................28
3.7.1. TLS Test Setup .....................................28
3.7.2. TLS over TCP Connectivity Test .....................29
3.7.3. DTLS over UDP Connectivity Test ....................29
3.7.4. DTLS over PR-SCTP Connectivity Test ................29
3.7.5. TLS Bidirectional Authentication Policy Test .......30
3.7.6. Exporting Process Identity Mismatch TLS
Policy Test ........................................30
3.7.7. Collecting Process Identity Mismatch TLS
Policy Test ........................................30
4. Security Considerations ........................................30
5. Acknowledgments ................................................31
6. Normative References ...........................................311. Introduction 🎀
so an IPFIX implementation, whether it's software, firmware, or hardware, needs to be tested thoroughly 💅 That's how you check its robustness and gain confidence that it actually conforms to the IPFIX documents it's built on 🌟
for a testable IPFIX software tool kit, you need at least one IPFIX Exporting Process and one IPFIX Collecting Process 🧚 But if you've only built a Collector, for example, you can pair it with a third-party Exporter for these tests 🫶
this doc gives guidelines for a series of tests you can run on the IPFIX Exporting Process and Collecting Process to check how conformant and robust the IPFIX protocol implementations are 🦋
the tests here can be a seriously valuable common basis for implementers doing interoperability testing 👑 Everyone gets the most out of it when they all use these tests to check their own Exporting Process and Collecting Process implementation first 💖
you can run the tests in a testbed environment or on a live network ✨
hold up, though 😭 Be careful with the "stress/load test" and the "temporary network disconnect", because they might impact other systems in the network. We recommend that these specific tests should be executed only in a testbed environment 🙈
1.1. Document Scope 🌸
this doc lists tests meant to be run between an implementation of an IPFIX Exporting Process and an IPFIX Collecting Process 💜 For some tests, there are multiple instances of each of those components involved (Observation Points, Metering Process, Exporting Process, Collecting Process) 🧚 Testing all those different IPFIX components is messy, because usually you test your software against an existing implementation that's already proven to be compliant. Sometimes you have to test two unproven implementations of the Exporting Process and Collecting Process against each other, which is a whole vibe 💀 The tests go all the way from basic transport connectivity to exporting Templates and their associated Data Records, high load on the Collecting Process, and error condition situations 🔥
this doc is not meant to replace formal testing software procedures based on, e.g., TTCN3 (http://www.ttcn-3.org/). It's a best-practices approach to informal testing of a developer's IPFIX implementation 🍓
1.2. IPFIX Documents Overview 🦋
the IPFIX protocol [RFC5101] gives network administrators access to IP Flow information 🌈 The architecture for exporting measured IP Flow information from an IPFIX Exporting Process to a Collecting Process is defined in [RFC5470], following the requirements in [RFC3917] ✨
[RFC5470] specifies how IPFIX Data Records and Templates get carried over a congestion-aware transport protocol from IPFIX Exporting Processes to IPFIX Collecting Processes 🚀 IPFIX also has a formal description of IPFIX Information Elements, covering their name, type, and additional semantic information, as specified in [RFC5102] 💖 Last but not least, [RFC5472] describes what kinds of applications can use the IPFIX protocol and how they can use the information it provides. It also shows how the IPFIX framework relates to other architectures and frameworks 👑
2. Terminology 🧚
the IPFIX-specific terminology used in this doc is defined in Section 2 of [RFC5101]. Just like in [RFC5101], the first letter of each IPFIX-specific term is capitalized here 💅
2.1. Conventions Used in This Document 🌸
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be interpreted as described in [RFC2119] 🫶
3. Test Specifications 💜
the tests in this section MAY be performed with an IPFIX Exporting Process on one host and an IPFIX Collecting Process on a different host 🦋 The configuration of the Observation Point, Metering Process, Exporting Process, and Collection Process SHOULD be recorded for every test, along with the test results 📝
if you pass all the tests in this section, you get a high level of confidence that the implementation you tested is conformant with the IPFIX architecture and protocol ✨ It does not, however, give 100% comprehensive coverage or a formal proof of conformance 🙈
3.1. Exporting Process/Collecting Process Connectivity Tests 🌈
this section lists the basic tests that are preconditions for the more complex tests in later sections of this doc 🧚 Get these right first, bestie, or nothing else will work 🔥
3.1.1. Connectivity Tests between the Exporting Process and Collecting Process 💖
Okay bestie, so the tester has to set up exactly one Exporting Process and one Collecting Process. Then the Exporting Process gets configured to export at least one Template Set and its associated Data Records to the Collecting Process, and the tester makes it start the export. 🦋
If the two are connecting over SCTP, the tester must make sure an SCTP association is established. If it's TCP instead, the tester must make sure a TCP connection is established. 🎀
The tester must also make sure the Transport Session parameters (IP addresses and ports) are correct. 💅
Note that how to make sure a Transport Session is set up correctly and its parameters are right is out of scope for this doc, so no instructions here 🙈
The tester must ensure the Data Records are actually exported! You can watch the traffic live with a packet sniffing tool, and that same tool helps you check whether the initial SCTP or TCP connection went through. 🔥
Last thing: the tester must record which combos of IPv4 and IPv6 transports, and UDP, SCTP, and TCP transmission protocols are supported. They should test every supported combo 💜
3.2. Template and Data Record Tests ✨
This part is all about making sure IPFIX Template Sets and their associated Data Sets arrive intact. 🧚
3.2.1. Transmission of Template with Fixed-Size Information Elements 🍓
The tester must create a Template with a few fixed-size Information Elements, and every data type in Section 6.1 of [RFC5101] (octet, unsigned16, unsigned32 ...) has to show up at least once. Then they cause the Template and its Data Records to be exported over all applicable combos of transports and protocols in Section 3.1. 💖
The tester must make sure the Template and its Data Records were correctly received and decoded by the Collecting Process. Verbose debugging output is suggested here so you can compare everything against what was sent (aka what's expected). It's giving detective energy 🕵️♀️
3.2.2. Transmission of Template with Variable-Length Information Elements 🌈
The tester must create a Template mixing fixed-size and variable-length Information Elements, as specified in Section 7 of [RFC5101]. Then they cause the Template and its Data Records to be exported over all applicable combos in Section 3.1. 🦋
The tester must make sure the Template contains at least:
- a single variable-length Information Element.
- a single variable-length Information Element followed by a fixed-length Information Element.
- a fixed-length Information Element followed by a variable-length Information Element.
- multiple variable-length Information Elements.
The tester must make sure the Template and its Data Records were correctly received and decoded by the Collecting Process. Literally every combo deserves a check ✨
3.2.3. Set Padding 🫶
Section 3.3.1 of [RFC5101] is where IPFIX Set alignment using padding is specified. Go read it if you wanna be a pro 📚
The tester must configure a packet generator to generate two Data Sets with padding in between, made of zero valued octets, as shown in Figure 1. They must be exported to the Collecting Process, and the Collecting Process must correctly decode the Data Sets and all the Data Records. The layout is sooo clean 😭
+--------------------------------------------------+
| Set Header #1 |
+--------------------------------------------------+
| Data Record |
+--------------------------------------------------+
| Data Record |
+--------------------------------------------------+
...
+--------------------------------------------------+
| Data Record |
+--------------------------------------------------+
| Padding with 0 valued octets |
+--------------------------------------------------+
| Set Header #2 |
+--------------------------------------------------+
| Data Record |
+--------------------------------------------------+
Figure 13.2.4. Record Padding 🎀
The tester must configure a packet generator to generate a Template that contains the padding Information Element (i.e., paddingOctets). The Template and its associated Data Records must be exported to the Collecting Process over all applicable combos of transports and protocols in Section 3.1. 💅
The tester must repeat the test with various padding sizes, including padding to boundaries other than 4 or 8 octets. Mix it up, bestie 🌸
The tester must make sure the Collecting Process correctly interprets cases where the Data Records are so short that the padding is equal to or longer than the record. Otherwise the padding could get mistaken for another record. Picture a 1 byte TOS plus 3 bytes of padding, and yeah, that's the spooky scenario 👻 Refer to the specifications in Section 3.3.1 of [RFC5101]. Figure 2 shows that Template, and Figure 3 shows a Data Record that follows it.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 16 octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID 256 | Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| ipDiffServCodePoint = 195 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| paddingOctets = 210 | Field Length = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 256 | Length = 64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3The tester must test fixed-size padding (e.g., 12 bytes of data plus 2 bytes of padding) and variable-length padding (e.g., export a string and a variable number of padding bytes afterwards, so the next Information Element lines up on a 4 byte boundary). Alignment is everything 🧚
3.2.5. Template Withdrawal Message 💜
IPFIX Template management and Template Withdrawal are specified in Section 8 of [RFC5101]. Read it before you start withdrawing things 💅
3.2.5.1. Withdrawal of a Previously Sent Template 🦋
The tester must create an IPFIX Template and cause that Template to be exported to an IPFIX Collector over a reliable transport. 🌸
The tester must check that the Template is correctly received and decoded by the Collecting Process. 🫶
The tester must cause the Exporting Process to send an IPFIX Template Withdrawal Message to the Collector for that Template. The Template Withdrawal Message must be sent over the same Transport Session as the Template. Same session, same vibe 💖
The tester must make sure the Template Withdrawal Message was correctly received and decoded by the Collecting Process, and that the previously sent Template was discarded by the Collecting Process. Bye bye, Template 👋
3.2.5.2. Withdrawal of a Previously Withdrawn Template 💀
The tester must create, export, and withdraw an IPFIX Template as described in Section 3.2.5.1.
The tester must cause the Exporting Process to send a second IPFIX Template Withdrawal Message to the Collector for that same Template. The Template Withdrawal Message must be sent over the same Transport Session as the Template.
The tester must make sure the Collecting Process discards the IPFIX Message and shuts down the SCTP association or closes the TCP connection. The tester must check that the Collecting Process logged the error. Withdrawing twice is a big no-no, periodt 🙅♀️
3.2.5.3. Withdrawal of a Previously Unsent Template 🙈
The tester must cause the Exporting Process to send an IPFIX Template Withdrawal Message to the Collector for a Template that has not yet been exported. The Template Withdrawal Message must be sent over a reliable transport.
The tester must make sure the Collecting Process discards the IPFIX Message and shuts down the SCTP association or closes the TCP connection. The tester must check that the Collecting Process logged the error. You can't withdraw something that was never sent, bestie 😭
3.2.5.4. Withdrawing All Data Templates 👑
The tester must create several IPFIX Templates and cause them to be exported to an IPFIX Collector over a reliable transport.
The tester must make sure the Templates were correctly received and decoded by the Collecting Process.
The tester must cause the Exporting Process to send an IPFIX All Data Templates Withdrawal Message to the Collector over the same Transport Session as the Templates.
The tester must make sure the All Data Templates Withdrawal Message was correctly received and decoded by the Collecting Process, and that all the previously sent Templates were discarded by the Collecting Process. Full clean sweep ✨
3.2.5.5. Withdrawing All Option Templates 🌈
The tester must create several IPFIX Option Templates and cause them to be exported to an IPFIX Collector over a reliable transport.
The tester must make sure the Option Templates were correctly received and decoded by the Collecting Process.
The tester must cause the Exporting Process to send an IPFIX All Option Templates Withdrawal Message to the Collector over the same Transport Session as the Templates.
The tester must make sure the All Option Templates Withdrawal Message was correctly received and decoded by the Collecting Process, and that all the previously sent Option Templates were discarded by the Collecting Process. Same energy, different flavour 🍓
3.3. Information Element Tests 🌸
This section lists the tests that cover the use of Information Elements. Let's get into the fun bits 💖
3.3.1. Enterprise-Specific Information Elements 🦋
The tester must cause the export of a Template and its associated Data Record that makes use of Enterprise-specific Information Elements, as specified in Section 3.2 of [RFC5101]. 💅
The tester must make sure the Template and associated Data Record are correctly received and decoded by the Collecting Process. The tester must also make sure that Information Elements unknown to the Collecting Process are not silently discarded. Nobody gets ghosted here 👀
3.3.2. Reduced Size Encoding of Information Elements 🧚
The tester must cause the export of a Template and its associated Data Record containing Information Elements that use reduced size encoding, as specified in Section 6.2 of [RFC5101]. 🎀
The tester must make sure that, for Information Elements sent with reduced size encoding, the Collecting Process knows the real size of each Information Element, not only the reduced size used for its transmission. Real size energy only 👑
3.3.3. Multiple Instances of the Same Information Element in One Template
okay so this test is all about what happens when the same Information Element shows up more than once in one Template 🧩✨ the tester has to export a Template and its Data Record with multiple instances of the same IE sitting right next to each other, no cap
then the Collecting Process needs to actually parse the IPFIX Message 💅 and store every single value it got for all those repeated IEs. no skipping, no dropping the extras 🫶
the Collecting Process also has to report the IEs in the same order they were listed in the Template Record, as specified in Section 8 of [RFC5101]. order matters, bestie 🎀
next up, the tester exports another Template and Data Record with multiple instances of the same IE, but this time with other IEs in between them 🦋 the vibe is "same IE, different spot," and it's giving main character energy
same checks again: the Collecting Process has to parse the IPFIX Message and store all the values for the repeated IEs 🌸 and it still has to report everything in the original Template Record order, as specified in Section 8 of [RFC5101] 💖
3.4. Options Template Tests
okay, this section is the whole Options Template crew 🧚 it covers making sure IPFIX Options Templates get transferred correctly 🎀
3.4.1. Using Any Information Elements as Scope
so Options Templates have scope fields, and they're the ones that tell you the context for the IEs reported in the matching Data Records 👑 scope fields are an Information Element specified in [RFC5102] (very important, iykyk 🙈)
the tester SHOULD export Options Template Records with all kinds of different IEs in their scope fields 💅 we're talking every abstract data type from Section 6.1 of [RFC5101] (octet, unsigned16, unsigned32 ... the whole squad) and the tester must also export a Data Record using each Template 🍓
then the tester has to check that the Templates and their Data Records are correctly received and decoded by the Collecting Process 🫶
the Collecting Process must accept IEs in the scope field that are not IPFIX IEs recorded by IANA 🌈 and it must also accept an Enterprise-specific IE in the scope field ✨
now for the plot twist 😭 as specified in Section 3.4.2.1 of [RFC5101], the Scope Field Count must NOT be zero. so the tester has to export an Options Template Record with a Scope Field Count of zero 💀
and when that happens, the Collecting Process must shut down the SCTP association and discard the IPFIX Message 🚫 the tester should also check that the Collecting Process logged the error 📝
3.4.2. Using Multiple Scopes
the tester must export an Options Template Record with multiple scope fields, plus a Data Record that matches that Template 🦋
and the Collecting Process must report the IEs in the same order they were specified in the Options Template Record, as specified in Section 3.4.2.1 of [RFC5101] 💜 order, order, ORDER 🫶
3.4.3. Metering Process Statistics Option Template
the tester must create a Metering Process Statistics Option Template, as specified in Section 4.1 of [RFC5101] 🎀 then they export that Option Template along with an associated Data Record 🚀
the Collecting Process must correctly receive and decode both the Option Template and the Data Record 💖
the tester must also check that the optional meteringProcessId Scope Field is supported by the Collecting Process implementation 🔍
if there are several Metering Processes on the Exporter Observation Domain, the tester must create a Metering Process Statistics Option Template with multiple scopes and an associated Data Record 🌸 export both, and make sure the Collecting Process correctly receives and decodes them 🫶
3.4.4. Metering Process Reliability Statistics Option Template
the tester must create a Metering Process Reliability Statistics Option Template, as specified in Section 4.2 of [RFC5101] 🧚 then it gets exported with an associated Data Record ✨
the Collecting Process must correctly receive and decode the Option Template and associated Data Record 💅
the tester must also check that the optional meteringProcessId Scope Field is supported by the Collecting Process implementation 🎀
3.4.5. Exporting Process Reliability Statistics Option Template
the tester must create an Exporting Process Reliability Statistics Option Template, as specified in Section 4.3 of [RFC5101] 🦋 export it with an associated Data Record 🌈
the Collecting Process must correctly receive and decode the Option Template and associated Data Record 🫶
3.4.6. Flow Keys Option Template
the tester must create a Flow Keys Option Template, as specified in Section 4.4 of [RFC5101] 🔑 the templateId has to refer to an existing Template 🌸 then export the Option Template and an associated Data Record 💖
the Collecting Process must correctly receive and decode the Option Template and Data Record, and it must associate the Flow Keys with the right Data Record IEs 👑
next, the tester creates another Flow Keys Data Record where the associated templateId doesn't have enough fields to satisfy the flowKeyIndicator 😬 the Collecting Process must discard the IPFIX Message and either shut down the SCTP association or close the TCP connection 💀 the tester must check that the error got logged 📝
then the tester creates another Flow Keys Option Template, where the templateId refers to a non-existing Template 🙈 export it with an associated Data Record 🚀
the Collecting Process must shut down the SCTP association and discard the IPFIX Message 💅 the tester should check that the error was logged ✨
3.5. Stress/Load Tests
okay, this is where we see who can handle the pressure 🔥 stress tests check that a Collecting Process stays correct and robust when a bunch of Data Records show up super fast 💨 this matters a LOT with IPFIX over UDP, because UDP isn't congestion aware, so a slow Collecting Process can't stop the Exporting Processes from exporting 😭
the tests might depend on your hardware and transport tech 🧚 so the tests may need to be scaled up or down for each implementation 🎀 but the implementer must make sure the implementation stays stable under excessive traffic 💪 "excessive" is whatever counts as excessive for where it'll actually be installed 👑
the implementer must make sure the Exporting Process and/or Collecting Process still work correctly when the Collecting Process can't keep up with the rate records are arriving 🌊
3.5.1. Large Number of Records for One Template
the tester should export lots of Data Records to the Collecting Process, all following the same Template, to really put it under stress 💥
depending on what the Collecting Process does (saving to a file, storing in a database, analyzing the data), it might use up a lot of memory 🫠
the tester must make sure that if the Collecting Process runs out of memory, it shuts down that specific SCTP association or closes the TCP connection 🛑 but it must stay available to receive data on other open Transport Sessions, and it also has to stay available for future Transport Sessions 🫶
3.5.2. Excessive Rate of Incoming Data Records
the tester should run a test where Data Records get exported to the Collecting Process at an increasing rate 📈
for TCP or SCTP in reliable mode, the tester must make sure the export stalls the Exporting Process once the Collecting Process is fully loaded 🫸
for UDP export, the tester must make sure the Collecting Process drops records as it gets overloaded, and must check that it logged a warning ⚠️
3.5.3. Large Templates
the tester must create Templates with the maximum possible number of IEs and export them to the Collecting Process 🏋️♀️✨
okay the math is kinda wild so bear with me 🤓 the total length field in the IP header is 16 bits, which allows a length of up to 65535 octets in one application-level datagram 📦 this limits how many IEs you can put in an IPFIX Template when using UDP export 😤 SCTP and TCP are streaming protocols, so they don't impose much restriction at the packet level 🌊
for UDP, you need 20 octets for a minimal IPv4 header, 8 octets for the UDP header, 16 octets for the IPFIX header, 4 octets for the Set header, and 4 octets for the Template header 🧮 so the Template definition can be up to (65535 - 20 - 8 - 16 - 4 - 4) = 65483 octets long 🎀
the minimum IPFIX IE specification takes 4 octets: two for the Information Element ID and two for the field length 💫 so the maximum number of IPFIX IEs in a single Template is 65483 / 4 = 16370 🍓 with this many IEs, the Template is 65480 octets long, and the entire packet is 65532 octets long 💖
the tester must create Data Records that follow this Template and export them 🦋 heads up that for the implementation, the associated Data Records might be smaller or larger than the Template Records, depending on the length of the IEs defined by the Template and on whether there are variable-length IEs 🙈
the Collecting Process must correctly receive and decode the Template and associated Data Records 🫶
3.5.4. Many New Templates within the Data Template Timeout Interval
the tester should create a large number of different Templates and export them to the Collecting Process to stress test its memory consumption 🧠💥
the Collecting Process must gracefully discard Templates when it's running out of memory resources, and the tester should check that warnings get logged ⚠️🫶
3.5.5. Multiple Exporting Processes Exporting to One Collecting Process
the tester must configure multiple Exporting Processes to export Templates and associated Data Records to the same Collecting Process at the same time 👯♀️🌸
the tester must make sure all the Templates and associated Data Records are correctly received and decoded at the Collecting Process 💖 and no Exporting Process stalls or fully disconnects unless the Collecting Process runs out of memory 🛑
3.5.6. Export from One Exporting Process to Multiple Collecting Processes
if the Exporting Process supports multiple simultaneous export destinations, the tester must configure it to export Data Records in parallel to different Collecting Processes 🚀🦋
the tester must configure a mix of simple and complex Templates and make sure they all get correctly received and decoded by every one of the Collecting Processes 🫶👑
3.6. Error Handling ✨
Okay bestie, this section is all about the stuff that goes wrong 😭 network drops, crashes, restarts, the whole chaos. The IPFIX Exporting Process and Collecting Process must be capable of handling these in a graceful way 💅 It's basically a robustness and fault tolerance test, so they have to survive the mess 🛡️🌸
3.6.1. Temporary Network Disconnect
Okay so the IPFIX Exporting Process and Collecting Process behavior must be checked whenever data transmission gets interrupted by network failures, whether they're physical or logical (like defective routing 🙃).
The tester must configure continuous export over all applicable combinations of transports and protocols in Section 3.1, in turn 🦋
For SCTP-based associations and TCP-based connections, the tester should create a short disconnect between the Exporting Process and the Collecting Process (like momentarily interrupting the network connection 🔌). They must make sure export continues after the connection is repaired ✨ Then the tester must create a longer disconnection between the Exporting Process and Collecting Process, and it must ensure that export continues after the connection is repaired too 💪
For UDP-based data export, there's no noticeable connection loss 👀 but data received with non-consecutive sequence numbers means data was lost 😬 Refer to the sequence number specifications in Section 3.1 of [RFC5101] 📖 The tester should create a short disconnect between the Exporting Process and Collecting Process, and it must ensure that this gets recognized and reported by the Collecting Process per Section 3.1 of [RFC5101] 🫶
3.6.2. Exporting Process Termination and Restart during Data Transmission
Real talk, a Collecting Process might get stuck with a faulty Exporting Process implementation that suddenly crashes and drops any open connections 💀 The Exporting Process may be restarted again soon after the crash 🔄
This event is only visible to the Collecting Process when the IPFIX Messages (Templates and associated Data Records) are carried over TCP or SCTP 🦋 For export via UDP, there's no such test because the transport is connection-less 🙈
The tester must configure continuous export over all applicable combinations of SCTP and TCP transports and protocols in Section 3.1, in turn 🌈 For each combination, the tester must establish export and then kill the active Exporting Process 🔥
The tester must ensure that the associated Collecting Process shuts down SCTP associations and closes TCP connections associated with that export after a suitable timeout period ⏳
The tester must Ensure that the Collecting Process discards the Template(s) received on the killed transport session 🗑️
The tester must restart the Exporting Process again, and it must ensure that the Exporting Process exports the Templates again 🔁
Last but not least, the tester must ensure that the Collecting Process receives and accepts both Templates and associated Data Records from the new Exporting Process running at the same source host 👑
3.6.3. Collecting Process Termination and Restart during Data Transmission
Same energy, flipped roles 🔄 An IPFIX Exporting Process might run into a faulty Collecting Process implementation that suddenly crashes and drops any open Transport Sessions 💥 The Collecting Process may be restarted again soon after the crash 🌸
The tester must set up an Exporting Process and Collecting Process, then cause IPFIX Templates and associated Data Records to be exported over all applicable combinations of SCTP and TCP transports and protocols in Section 3.1, in turn 🧚 Over UDP, the restart of the Collecting Process is totally invisible to the Exporting Process and has no effect at all 🫥✨
The tester must terminate the Collecting Process while export is in progress, and must ensure that the Exporting Process shuts down SCTP associations and closes TCP connections associated with that Collecting Process 🔌
The tester must restart the Collecting Process and ensure that the Exporting Process connects to the Collecting Process again and that it exports the IPFIX Templates again 💖
Finally, the tester must ensure that the new Collecting Process correctly receives and decodes the IPFIX Data Records again 🎀
3.6.4. Incorrect Template Records and Options Template Records ✨
okay bestie, this test is all about checking what the Collecting Process does when it gets a Template Record or an Options Template Record with a message length that's just wrong 🙈 The specs for those live in Section 3.4.1 and 3.4.2 of [RFC5101], so go check there too 💅
Look at the example Template Record in Figure 4 🎀 It's missing one Information Element ID and one Information Element length field. So the Set doesn't have enough data for its own Set length, and the whole record comes up four octets short of the total length it claims. Major mess, but that's the point 😭
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 10 | Total Length = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time = 1155202151 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number = 0x12345678 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation Domain ID = 0x33334444 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Set Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 257 | Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Info Element Identifier = 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4
The tester must create and cause the Exporting Process to export the following IPFIX Templates, and must ensure the correct Collecting Process behavior for each of the transports and protocols in Section 3.1.
The tester must do the following:
- For SCTP transport, ensure that the Collecting Process discards the IPFIX Message, shuts down the SCTP association, and logs the error.
- For TCP transport, ensure that the Collecting Process discards the IPFIX Message, closes the TCP connection, and logs the error. Note that since TCP is a streaming (rather than record-based) protocol, template length errors cannot be detected and may cause framing to be lost, potentially rendering the remainder of the IPFIX stream unintelligible. Therefore, some of these tests are not applicable for TCP transport, as indicated. 😬
- For UDP transport, ensure that the Collecting Process discards the IPFIX Message and logs the error.
(a) The tester must create the IPFIX Template shown in Figure 4 and cause the Exporting Process to export it. The tester must ensure that the Collecting Process's behavior is as specified above for each transport type except for TCP, for which this test is not applicable.
(b) Consider the IPFIX Template shown in Figure 4, modified with total length = 28. In this case, the IPFIX Message has to be rejected because the field count = 2 and there is no second Information Element record present in the Set. The available data is exhausted after reading the first Information Element record.
The tester must create the modified Template and cause the Exporting Process to export it. The tester must ensure that the Collecting Process's behavior is as specified above for each transport type.
(c) Consider the IPFIX Template shown in Figure 4, modified with total length = 26. In this case, the IPFIX Message has to be rejected because the IPFIX Message length is too short. After the first Information Element, the IPFIX Message data is exhausted according to the total length information.
The tester must create the modified Template and cause the Exporting Process to export it. The tester must ensure that the Collecting Process's behavior is as specified above for each transport type. The TCP connection used for this test must be manually reset after the test.
(d) Consider the IPFIX Template shown in Figure 4, modified with field count = 1. In this case, the IPFIX Message must be rejected because the total length is too large and does not match the amount of data available.
The tester must create the modified Template and cause the Exporting Process to export it. The tester must ensure that the Collecting Process's behavior is as specified above for each transport type. This test is not applicable for TCP transport.
(e) Finally, when the IPFIX Template shown in Figure 4 is extended with the data shown in Figure 5, it becomes a correct IPFIX Template. ✨
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Info Element Identifier = 12| Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 5
The tester must create the modified Template and cause the Exporting Process to export it. The tester must ensure that the Template is accepted by the Collecting Process for each transport type. 🫶
The example Template record shown in Figure 6 must be dropped because the scope field count = 0.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 10 | Total Length = 30 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Export Time = 1155202151 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number = 0x12345678 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Observation Domain ID = 0x33334444 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Set Length = 14 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 257 | Field Count = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 0 |0| Info Element Identifier = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6
The tester must create the Template shown in Figure 6 and cause the Exporting Process to export it. The tester must ensure that the IPFIX Message is discarded by the Collecting Process for each transport type, and must check that the Collecting Process logs an error. The tester must ensure that the Collecting Process also shuts down the SCTP association or closes the TCP connection. 💀
The tester must create an IPFIX Options Template where the field count is less than the scope field count, and cause the Exporting Process to export it. Use the above IPFIX Options Template with scope field count = 2. The tester must ensure that the Template is discarded by the Collecting Process for each transport type, and must check that the Collecting Process logs an error. The tester must ensure that the Collecting Process shuts down the SCTP association or closes the TCP connection.
3.6.5. Incorrect Data Record 🌸
The tester must create the following invalid Data Records and cause them to be exported to the Collecting Process over all applicable combinations of transports and protocols in Section 3.1.
- IPFIX Message too short.
- Illegal use of reduced size encoding.
- Invalid length specification in case of variable-length Information Elements.
The tester must ensure that the Collecting Process discards the IPFIX Message and shuts down the SCTP association or closes the TCP connection.
3.6.6. Export of Non-Matching Template and Data Records 🦋
The tester must create Templates and associated Data Records that fail to conform to those Templates in the following ways:
- too few Information Elements in Data Record
- too many Information Elements in Data Record
The tester must cause the Templates and associated Data Records to be exported to the Collecting Process over all applicable combinations of transports and protocols in Section 3.1.
The tester must ensure that the Collecting Process discards the IPFIX Message and shuts down the SCTP association or closes the TCP connection.
3.6.7. Unknown Set IDs 🧚
The tester must create Template Sets, Option Template Sets, and associated Data Sets using Set IDs which are unknown to the Collecting Process, and cause these to be exported to the Collecting Process over all applicable combinations of transports and protocols in Section 3.1.
Per Section 3.3.2 of [RFC5101], only the Set ID values 2 and 3 denote valid Sets. 🔥
The tester must ensure that the Collecting Process ignores the unknown Sets, logs a warning, and processes the remainder of the IPFIX Message.
3.6.8. Re-Using Template IDs 👑
3.6.8.1. Using SCTP Transport ✨
Okay bestie, check Section 9 of [RFC5101] for the Collecting Process's SCTP Template management specs 📚. That's where the rules live. 💅
First, the tester must create an IPFIX Template and cause it to be exported to a Collecting Process over SCTP transport 🦋.
Then the tester must ensure that the Template was correctly received and decoded by the Collecting Process 🔍.
Next, the tester must cause the same Template to be exported to the same Collecting Process over the same SCTP association, and must ensure that the Collecting Process resets the SCTP association and discards the IPFIX Message. The drama is the point here 😭🔥.
The tester must create another IPFIX template and cause it to be exported to the Collecting Process over SCTP transport 🌸.
The tester must ensure that the Template was correctly received and decoded by the Collecting Process 💖.
Now the tester must modify the Template contents while retaining the same Template ID. Same ID, different vibe 🎀.
The tester must cause the modified Template to be exported to the same Collecting Process over the same SCTP association, and must ensure that the Collecting Process resets the SCTP association and discards the IPFIX Message 💀.
The tester must check that an error was logged 📝.
The tester must create another IPFIX Template and cause it to be exported to the Collecting Process over SCTP transport 🧚.
The tester must ensure that the Template was correctly received and decoded by the Collecting Process ✨.
The tester must cause a Template Withdrawal Message for the Template to be sent to the Collecting Process over the same SCTP association, and must ensure that the Template has been discarded by the Collecting Process. Bye bye, Template 👋.
The tester must create Data Records conforming to the Template and cause them to be exported to the Collecting Process over the same SCTP association 🍓.
The tester must ensure that the Collecting Process discards the Data Records and logs a warning. Not the vibe, so it gets tossed out 🙈.
The tester must cause the same Template to be exported to the same Collecting Process over the same SCTP association 🌈.
The tester must ensure that the Template was correctly received and decoded by the Collecting Process 🫶.
The tester must create Data Records conforming to the Template and cause them to be exported to the Collecting Process over the same SCTP association 💜.
The tester must ensure that the Collecting Process correctly receives and decodes the Data Records. Finally, a happy ending 👑🔥.
3.6.8.2. Using TCP Transport 🌷
Refer to Section 10.4.3 of [RFC5101] for the Collecting Process's TCP Template management specifications 📖.
The tester must create an IPFIX Template and cause it to be exported to a Collecting Process over TCP transport 🦋.
The tester must ensure that the Template was correctly received and decoded by the Collecting Process 🔍.
The tester must cause the same Template to be exported to the same Collecting Process over the same TCP connection, and must ensure that the Collecting Process resets the TCP connection and discards the IPFIX Message. Reset, discard, repeat 😭.
The tester must create an IPFIX Template and cause it to be exported to the Collecting Process over TCP transport 🌸.
The tester must ensure that the Template was correctly received and decoded by the Collecting Process 💖.
The tester must modify the Template contents while retaining the same Template ID 🎀.
The tester must cause the modified Template to be exported to the same Collecting Process over the same TCP connection, and must ensure that the Collecting Process resets the TCP connection and discards the IPFIX Message 💀.
The tester must check that an error was logged 📝.
The tester must create another IPFIX Template and cause it to be exported to the Collecting Process over TCP transport 🧚.
The tester must ensure that the Template was correctly received and decoded by the Collecting Process ✨.
The tester must cause a Template Withdrawal Message for the Template to be sent to the Collecting Process over the same TCP connection, and must ensure that the Template has been discarded by the Collecting Process 👋.
The tester must create Data Records conforming to the same Template and cause them to be exported to the same Collecting Process over the same TCP connection 🍓.
The tester must ensure that the Collecting Process discards the Data Records and logs a warning 🙈.
The tester must cause the same Template to be exported to the same Collecting Process over the same TCP connection 🌈.
The tester must ensure that the Template was correctly received and decoded by the Collecting Process 🫶.
The tester must create Data Records conforming to the Template and cause them to be exported to the same Collecting Process over the same TCP connection 💜.
The tester must ensure that the Collecting Process correctly receives and decodes the Data Records. Slay 👑.
3.6.8.3. Using UDP Transport 🦋
Refer to Sections 10.3.6 and 10.3.7 of [RFC5101] for the UDP Template management specifications 📚.
3.6.8.3.1. Re-Using the Same Template ID inside the Template Lifetime 🌸
The tester must create an IPFIX Template and cause it to be exported to a Collecting Process over UDP transport 🦋.
The tester must ensure that the Template was correctly received and decoded by the Collecting Process 🔍.
Before the Template lifetime expires on the Collecting Process, the tester must cause the same Template to be exported over the same UDP connection to the same Collecting Process and must ensure that the Collecting Process accepts the Template ⏰.
The tester must create a different Template with the same ID and must cause this to be exported to the same Collecting Process over the same UDP connection before the original Template lifetime expires 💅.
The tester must ensure that the Collecting Process does not reject the new Template. No rejection, no drama 🫶.
The tester must create Data Records conforming to the new Template and cause them to be exported to the same Collecting Process over the same UDP connection 🍓.
The tester must ensure that the Collecting Process correctly receives and decodes the Data Records 👑.
3.6.8.3.2. Re-Using the Same Template ID after the Template Lifetime 🧚
The tester must create an IPFIX Template and cause it to be exported to a Collecting Process over UDP transport 🦋.
The tester must ensure that the Template was correctly received and decoded by the Collecting Process 🔍.
The tester must allow the received Template lifetime to expire on the Collecting Process ⌛.
The tester must create Data Records conforming to the Template and cause them to be exported to the same Collecting Process over the same UDP connection 🍓.
The tester must ensure that the Collecting Process discards the Data Records 🙈.
The tester must check that the Collecting Process logs a warning 📝.
The tester must cause the same Template to be exported to the same Collecting Process over the same UDP connection 🌈.
The tester must ensure that the Template was correctly received and decoded by the Collecting Process 💖.
The tester must create Data Records conforming to the Template and cause them to be exported to the same Collecting Process over the same UDP connection 💜.
The tester must ensure that the Collecting Process correctly receives and decodes the Data Records. We made it 👑✨.
3.7. TLS Connectivity and Policy Selection 🔐
This section lists tests that verify connectivity over TLS and Datagram Transport Layer Security (DTLS) and proper selection of TLS policies as specified in the IPFIX Protocol. It specifically does NOT purport to test the security of IPFIX Message transport over TLS or DTLS. Evaluating the security of a transport session is really a test of the TLS or DTLS implementation that a given IPFIX implementation runs on, so it's out of scope for this document 🙅♀️.
Refer to Section 11 of [RFC5101] for the security specifications 🛡️.
3.7.1. TLS Test Setup 🎀
Setting up for TLS connectivity and policy testing means creating appropriate X.509 certificates and private keys for a test environment, and configuring a DNS server to answer with consistent information for the hosts used in the test 🧁.
The tester must configure the following certificates:
- A Certificate Authority (CA) certificate and associated private key for signing the following certificates.
- One certificate and associated private key, with a CN (Common Name) or subjectAltName extension of type dNSName containing the fully qualified domain name of the host, signed by the CA certificate in 1, for each IPFIX Exporting Process in the test.
- One certificate and associated private key, with a CN (common name) or subjectAltName extension of type dNSName containing the fully qualified domain name of the host, signed by the CA certificate in 1, for each IPFIX Collecting Process in the test.
The tester must configure consistent forward (A, AAAA) DNS records for each host in the test on a DNS server used by the hosts for name resolution. No need for reverse (PTR) DNS records, bestie, because no part of the protocol uses reverse lookups 🙌.
The tester must ensure that the Exporting Process and Collecting Process are on different hosts 🏠.
3.7.2. TLS over TCP Connectivity Test 🔒
The tester must set up certificates and DNS as in Section 3.7.1 📜.
The tester must configure one Exporting Process and one Collecting Process with their appropriate certificates to transfer IPFIX Messages over TLS over TCP 🤝.
The tester must create an IPFIX Template and associated Data Record, and cause them to be exported over the TCP connection 🍓.
The tester must ensure that a TCP connection and a TLS connection were established, must ensure that data was exchanged, and must ensure that the data received at the Collecting Process is correct. Everything checks out 💅✨.
3.7.3. DTLS over UDP Connectivity Test 🦋
The tester must set up certificates and DNS as in Section 3.7.1 📜.
The tester must configure one Exporting Process and one Collecting Process with their appropriate certificates to transfer IPFIX Messages over DTLS over UDP 🤝.
The tester must create an IPFIX Template and associated Data Record, and cause them to be exported over the UDP connection 🍓.
The tester must ensure that UDP packets were sent and a DTLS connection was established, must ensure that data was exchanged, and must ensure that the data received at the Collecting Process is correct 💖.
3.7.4. DTLS over PR-SCTP Connectivity Test 🌈
The tester must set up certificates and DNS as in Section 3.7.1 📜.
The tester must configure one Exporting Process and one Collecting Process with their appropriate certificates to transfer IPFIX Messages over DTLS over the Partially Reliable-Stream Control Transmission Protocol (PR-SCTP) 🤝.
The tester must create an IPFIX Template and associated Data Record, and cause them to be exported over the SCTP association 🍓.
The tester must ensure that an SCTP association and a DTLS connection were established, must ensure that data was exchanged, and must ensure that the data received at the Collecting Process is correct 👑.
3.7.5. TLS Bidirectional Authentication Policy Test 🕵️♀️
This is an optional test for Collecting Processes only. It requires modifying an Exporting Process to NOT present a certificate 🙅♀️.
The tester must modify an Exporting Process to NOT present a certificate 🫣.
The tester must perform the connectivity tests in Sections 3.7.2, 3.7.3, and 3.7.4 🔁.
The tester must ensure that the Collecting Process rejects the TLS or DTLS connection establishment. Rejected, and honestly iconic for it 💀🔥.
3.7.6. Exporting Process Identity Mismatch TLS Policy Test ✨
okay bestie, this one is all about a mismatched certificate 🙈 the tester has to set up certificates and DNS just like in Section 3.7.1 💅
then, the tester must use a certificate for the Exporting Process that does NOT match the fully qualified domain name of the host where the Exporting Process runs. the whole point is that the names don't line up 💀
next, the tester must perform the connectivity tests in Sections 3.7.2, 3.7.3, and 3.7.4 🎀
and the big finish: the tester must make sure the Collecting Process rejects the TLS or DTLS connection establishment. the mismatch should get the connection shut down, and that's the slay 👑
3.7.7. Collecting Process Identity Mismatch TLS Policy Test 🦋
this one is basically the mirror image of the last test, just flipped to the other side 🪞
the tester must set up certificates and DNS as in Section 3.7.1 🌸
then the tester must use a certificate for the Collecting Process that does NOT match the fully qualified domain name of the host where the Collecting Process runs 🙃
the tester must perform the connectivity tests in Sections 3.7.2, 3.7.3, and 3.7.4 🧚
last part: the tester must make sure the Exporting Process rejects the TLS or DTLS connection establishment. same energy, other side of the connection, fr fr 💖
4. Security Considerations 🔐
this memo raises no security issues ✨ no drama here, bestie 🫶
5. Acknowledgments 🌈
the authors wanted to thank Brian Trammell for contributing the initial text for Section 3.7 🙏💜 iconic of him, honestly
6. Normative References 📚
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.
- [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.
- [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, March 2009.
- [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP Flow Information Export (IPFIX) Applicability", RFC 5472, March 2009.
Authors' Addresses 💌
the authors, with all their contact details, so you can reach out 💕
Carsten Schmoll
Fraunhofer FOKUS
Kaiserin-Augusta-Allee 31
Berlin D-10589
Germany
Phone: +49 30 3463 7136
EMail: carsten.schmoll@fokus.fraunhofer.de
URI: http://www.fokus.fraunhofer.de
Paul Aitken
Cisco Systems, Inc.
96 Commercial Quay
Edinburgh EH6 6LX
Scotland
Phone: +44 131 561 3616
EMail: paitken@cisco.com
URI: http://www.cisco.com
Benoit Claise
Cisco Systems, Inc.
De Kleetlaan 6a b1
1831 Diegem
Belgium
Phone: +32 2 704 5622
EMail: bclaise@cisco.com
URI: http://www.cisco.com📦 where this page comes from
- ietf: rfc5471 2009-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms