RFC 5103
Bidirectional Flow Export Using IP Flow Information Export (IPFIX)
1. Introduction ✨
okay bestie, so the big idea here is that a lot of flow analysis tasks are way better when you can link the upstream and downstream flows of one two-way conversation 🦋 Think separating answered and unanswered TCP requests, or calculating round trip times, stuff like that. Metering processes that aren't part of an asymmetric routing setup, especially ones sitting at a single point where all the two-way traffic goes through, are perfectly placed to see these bidirectional flows (Biflows) 👑 In those setups, the total resources needed to assemble Biflows are usually lower if you build them at the measurement interface instead of the Collector. And the IPFIX Protocol only needs information model extensions to be complete as a way to export Biflow data 💅
So we're proposing a Biflow export method that uses a single Flow Record per Biflow 🎀 We dig into the semantics of bidirectional flow data in Section 4, "Biflow Semantics", look at the different ways to figure out Biflow direction in Section 5, "Direction Assignment", and then define the export method itself in Section 6, "Record Representation" 🧚
This export method needs extra Information Elements to hold the data values for the reverse direction of each Biflow, plus one more Information Element for the direction assignment info. You'll find those in Sections 6.1 through 6.3 🌸 We did look at other ways to export Biflows with IPFIX, but they have some big drawbacks, which we talk about in Section 3, "Rationale and History". That's how we ended up with this method 💜
1.1. IPFIX Documents Overview
"Specification of the IPFIX Protocol for the Exchange of IP Traffic Flow Information" [RFC5101] is the IPFIX Protocol document (we'll call it that informally) 💖 It and its related documents define the IPFIX Protocol, which gives network engineers and admins access to IP traffic flow information ✨
"Architecture for IP Flow Information Export" [IPFIX-ARCH] is the IPFIX Architecture document. It defines the architecture for exporting measured IP flow information from an IPFIX Exporting Process to an IPFIX Collecting Process, along with the basic terminology for the parts of that architecture 🫶 It follows the requirements set out in "Requirements for IP Flow Information Export" [RFC3917]. The IPFIX Protocol document [RFC5101] then covers how IPFIX Data Records and Templates get transported over a congestion-aware transport protocol from an IPFIX Exporting Process to an IPFIX Collecting Process 🌈
"Information Model for IP Flow Information Export" [RFC5102] is the IPFIX Information Model document (informally). It covers the Information Elements used by IPFIX, including how they're named, numbered, and how their data types are encoded 🍓 Last but not least, "IPFIX Applicability" [IPFIX-AS] describes the different applications of the IPFIX protocol and how they use the exported information. It also relates the IPFIX architecture to other measurement architectures and frameworks 🔥
This document leans on the Protocol and Architecture documents for terminology, uses the IPFIX Protocol to define a bidirectional flow export method, and adds to the information model defined in the IPFIX Information Model document 💅
2. Terminology 📚
okay so capitalized terms in this document that are defined in the Terminology section of the IPFIX Protocol document [RFC5101] mean exactly what they mean there 🎀 The extra terms below are defined in terms of that IPFIX Protocol document terminology too.
Directional Key Field: a Directional Key Field is a single field in a Flow Key, as defined in the IPFIX Protocol document [RFC5101], that is specifically tied to a single endpoint of the Flow. sourceIPv4Address and destinationTransportPort are examples 💖
Non-directional Key Field: a Non-directional Key Field is a single field within a Flow Key, as defined in the IPFIX Protocol document [RFC5101], that isn't specifically tied to either endpoint of the Flow. protocolIdentifier is an example 🌸
Uniflow (Unidirectional Flow): a Uniflow is a Flow, as defined in the IPFIX Protocol document [RFC5101], restricted so that it's only made up of packets sent from one endpoint to another single endpoint 🦋
Biflow (Bidirectional Flow): a Biflow is a Flow, as defined in the IPFIX Protocol document [RFC5101], made up of packets sent in both directions between two endpoints ✨ A Biflow is built from two Uniflows such that:
- the value of each Non-directional Key Field of each Uniflow is identical to its counterpart in the other, and
- the value of each Directional Key Field of each Uniflow is identical to its reverse direction counterpart in the other.
A Biflow has two non-key fields for each value it represents that's tied to a single direction or endpoint: one for the forward direction and one for the reverse direction, as defined below 🧚
Biflow Source: the Biflow Source is the endpoint identified by the source Directional Key Fields in the Biflow 👑
Biflow Destination: the Biflow Destination is the endpoint identified by the destination Directional Key Fields in the Biflow 💜
forward direction (of a Biflow): the direction of a Biflow made up of packets sent by the Biflow Source. Values for the forward direction of a Biflow are represented using normal Information Elements. So, in other words, a Uniflow can be defined as a Biflow that only has a forward direction 🫶
reverse direction (of a Biflow): the direction of a Biflow made up of packets sent by the Biflow Destination. Values for the reverse direction of a Biflow are represented using Reverse Information Elements, as defined below 🌈
Reverse Information Element: an Information Element defined as corresponding to a normal (or forward) Information Element, but associated with the reverse direction of a Biflow 🍓
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🔥
3. Rationale and History 🕰️
okay so we picked the Single Record Biflow export method described in this document as the recommendation for bidirectional flow export using IPFIX, but we seriously looked at several other options first 💅
The most obvious one would be to just export Biflows as two Uniflows sitting next to each other in the record stream 🎀 A Collecting Process could then put them back together with minimal state requirements. The catch is that it's only an informal arrangement the Collecting Process can't actually rely on, and it isn't bandwidth-efficient, since the Flow Key data gets duplicated in each Uniflow record 💖
Next we looked at the method outlined in Reducing Redundancy in IPFIX and Packet Sampling (PSAMP) Reports [IPFIX-REDUCING] to fix that bandwidth problem 🌸 It would also formally link the two Uniflows into a single construct, by exporting the Flow Key as Common Properties and then each direction's info as Specific Properties 🦋 The downside is extra overhead to transmit the commonPropertiesId, plus extra state management at both the Collecting and Exporting Processes ✨
Someone also proposed on the IPFIX mailing list to use the Multiple Information Element feature of the protocol to export forward and reverse counters using identical Information Elements in the same Flow Record 🧚 The first instance of a counter would represent the forward direction, and the second instance of that same counter would represent the reverse. But this clashed with the semantics already defined for these counters, so it got abandoned 💀
4. Biflow Semantics ✨
okay so bestie, we're back in the Biflow era 🦋 As the Terminology section already spilled, a Biflow is basically just a Flow capturing packets going both ways between two endpoints on a network. And there are really good reasons we treat Biflows as one single entity instead of just smooshing Uniflows together ad hoc 💅 First, most app-layer protocols are bidirectional anyway, so a Biflow data model actually matches what the network is doing and makes it way easier to answer spicy questions about behavior 👀 Second, exporting Biflows is more efficient because you stop duplicating Flow Key data across the IPFIX message stream 🎀 Collectors benefit too, since they can skip the Biflow matching work where possible 🫶
Biflows are a little more semantically complicated than Uniflows, ngl 😭 With Uniflows, the source and destination Information Elements are crystal clear: source = source header fields, destination = destination header fields, done 💖 With Biflows stored as single IPFIX Data Records, though, you have to choose your source and destination definitions way more carefully 🧐
So, like the Terminology section said, the Source of a Biflow is whatever the source Directional Key Field(s) identify, and the Destination is whatever the destination Directional Key Field(s) identify 🌸 Quick tea: for IANA-registered Information Elements, or ones defined by the IPFIX Information Model [RFC5102], Directional Key Fields on the Biflow Source have names starting with "source", and the ones on the Biflow Destination start with "destination" 💜 It's recommended that enterprise-specific Information Elements follow these conventions too 🍓
How the Metering and Exporting Processes actually assign Source and Destination is covered in the next section, so stay tuned 🧚
Since Source and Destination are defined by Directional Keys, Biflow values get split into forward and reverse directions too 🌈 The forward direction is made of packets sent by the Biflow Source, and the reverse direction is made of packets sent by the Destination. Roughly speaking, the two directions are just the two Uniflows that got matched to compose the Biflow 🦋 So a Biflow record has each Flow Key record once, plus both forward Information Elements and Reverse Information Elements for each non-key field. Check out Figure 1 for the visual, it's giving composition vibes 💅
Uniflow Uniflow
+-------+-------+-----------------+ +-------+-------+-----------------+
| src A | dst B | counters/values | | src B | dst A | counters/values |
+-------+-------+-----------------+ +-------+-------+-----------------+
| | | |
V V V V
+-------+-------+---------------------+---------------------+
| src A | dst B | fwd counters/values | rev counters/values |
+-------+-------+---------------------+---------------------+
Biflow
Figure 1: Bidirectional Flow Conceptual DiagramThe reverse direction values are represented by Reverse Information Elements, and how those get represented inside Templates is detailed in Section 5 🎀 A Flow Record can be treated as a Biflow record by the Collecting Process if it has at least one Reverse Information Element AND at least one Directional Key Field 🫶 Flow Records with Reverse Information Elements but no Directional Key Fields are illegal ❌ They MUST NOT be sent by the Exporting Process, and the Collecting Process SHOULD drop them. The Collecting Process SHOULD also log receipt of those illegal Flow Records 🙈
Heads up, bestie: those illegal records are a no-go from the exporter's side, full stop 💀
When exporting Uniflows, Exporting Processes SHOULD use a Template with no Reverse Information Elements at all ✨ Fun detail: a Template whose only Reverse Information Elements are counters MAY be used to export Uniflows, because counters with a value of 0 mean the same thing as no reverse direction 🌸 BUT this trick is NOT possible for Reverse Information Elements where zero has a distinct meaning, like tcpControlBits 😭
Now, a Biflow crossing a middlebox [RFC3234] can show different flow properties on each side 👀 That's because the middlebox might change the packet header or payload itself 💅 So it MUST be clear to a Collecting Process whether packets were observed and metered before or after modification 🫶 The Observation Process SHOULD sit on one side of a middlebox, and the Exporting Process SHOULD tell the Collecting Process both the incoming value of the flow property changed inside the middlebox AND the changed value on the "other side" 🦋 The IPFIX Information Model [RFC5102] gives us Information Elements with the prefix "post" for exactly this 💖 And the location of the Observation Point(s) relative to the middlebox can be communicated using Options with Observation Point as Scope, plus elements like lineCardID or samplerID 🧚
If you want more on how middleboxes affect the IPFIX architecture, check Section 7 of the IPFIX Implementation Guidelines [IPFIX-IMPLEMENTATION] 📚✨
Last but not least, by the definition of Observation Domain in Section 2 of the IPFIX Protocol document [RFC5101], Biflows may only be composed of packets observed within the same Observation Domain 🔥 That means Metering Processes building Biflows out of Uniflows MUST make sure both Uniflows were observed in the same Observation Domain 👑
5. Direction Assignment 🧚
Okay so here's the tea: there's no one-size-fits-all way to assign the directions of a Biflow 🙈 Flow measurement apps are all different, and Metering Process deployment has restrictions too 💅 This section describes three methods of direction assignment and recommends them based on where the Metering Process sits and what the measurement app needs 🌈 In each figure, the "MP" box is the Metering Process, obviously 🦋
Because the method depends on where the Metering Process is, it's enough to configure the direction assignment method at the Collecting and/or Exporting Process out-of-band ✨ For example, a Collecting Process could be set up so that a specific Exporting Process (identified by exporterIPv4Address) assigns direction by initiator 🎀 Or both a Collecting Process and an Exporting Process could be configured at the same time with a specific direction assignment perimeter 🫶 BUT if an Exporting Process uses multiple direction selection methods, or a Collecting Process accepts data from Exporters using a bunch of different methods, there's a biflowDirection Information Element for optionally representing direction assignment info 💖
5.1. Direction by Initiator
If the measurement app needs to figure out the initiator and responder of a communication, the Metering Process SHOULD define the Biflow Source as the initiator of the Biflow, where possible 🦋 A rough approximation: the Metering Process watches packets in both directions and simply assumes the first packet it sees in a Biflow is the one that started it 🌸 A Metering Process can level up this method by using knowledge of transport or app protocols (like TCP flags or DNS question/answer counts) to better guess the flow-initiating packet 💅
Direction assignment by initiator is easiest when a single Metering Process sits on a local link layer, like Figure 2, or when a single Metering Process watches bidirectional packet flows at a symmetric perimeter routing point, like Figure 3 🎀
Also, lots of Metering Processes have an "active" timeout 👀 Any flow lasting longer than the active timeout gets expired, and any later packets from that flow count toward a new flow 😭 This can mess with the assumption that the first packet seen is from the initiator, if that "first" packet is actually a middle packet of a long-duration flow 💀
+-------+ +-------+
| node | | node |
+---+---+ +---+---+
| | +---------+
<===+=====+=====+======>+ +<===> Internet
| | router |
+---+---+ +---------+
| MP |
+---+---+
Figure 2: Local Link Metering Process Position +-------+ +-------+
| node | | node |
+---+---+ +---+---+
| | +---------+
<===+===========+======>+ +<===> Internet
| router |
| +----+--+
+----+ MP |
+-------+
Figure 3: Symmetric Routing Point Metering Process Position5.2. Direction by Perimeter
If the measurement app is deployed at a network perimeter, as in Figure 4, so there's a stable set of addresses that count as "inside" that perimeter, and there's no requirement to figure out who initiated and who responded, then the Metering Process SHOULD assign the Biflow Source to be the endpoint outside the perimeter 🌈
No facility is provided for exporting the address set that defines the interior of a perimeter 🫣 That set can be deduced by the Collecting Process watching the Biflow Source and Biflow Destination addresses, or it can be configured out-of-band 🧚
+---------+ +---------+
====>+ access +====> ====>+ access +====>
Internet | router | Local Net | router | Internet
(link A) <====+ A +<==== <====+ B +<==== (link B)
+----+----+ +---------+
|
+---+---+
| MP |
+-------+
Figure 4: Perimeter Metering Process Position5.3. Arbitrary Direction 🎲
Okay so this one is for when the meter lives deep in the network core 🌌, where there's no stable set of addresses to draw a perimeter around (BGP updates keep shuffling things, bestie 😭), like in Figure 5. And if there's no requirement to figure out who started the conversation, and no way to do it either, then the Metering Process MAY assign the Biflow Source and Biflow Destination endpoints arbitrarily. Yes, arbitrarily. It's giving coin flip 🪙
Even so, the Metering Process SHOULD be consistent about its choice. Once direction is assigned, it SHOULD stay that way for the whole life of the Biflow, even when a long-lived Biflow hits an active timeout 💅✨.
|
V
+----+----+ +---------+
<===+ core | | core +===>
| router +<========>+ router |
===>+ | | +<===
+----+----+ +----+----+
| |
+---+---+ V
| MP |
+-------+
Figure 5: Transit/Core Metering Process Position6. Record Representation 📦
As we said above, Biflows get exported as a single Flow Record each. Every record has the Flow Key fields once, plus both a forward Information Element and a Reverse Information Element for each non-key field 🫶. That means the IPFIX Information Model gets extended so every existing forward Information Element has a Reverse Information Element buddy, required by any Information Element that might be a non-key field in a Biflow.
6.1. Reverse Information Element Private Enterprise Number 🔁
Reverse Information Elements get their own "dimension" in the Information Element space. The Private Enterprise Number (PEN) 29305 is assigned to this document, and that PEN means "IPFIX Reverse Information Element" (the Reverse PEN) 🦋. The Reverse PEN works as a "reverse direction flag" in the Template. Each Information Element number inside this PEN space is the reverse counterpart of the matching IANA-assigned public Information Element number. So to make a reverse Information Element in a Template, just set the enterprise bit and define the Information Element in the Reverse PEN space, like in Figure 6 🧚.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| flowStartSeconds 150 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
forward |
|
reverse V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| (rev) flowStartSeconds 150 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reverse PEN 29305 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Example Mapping between Forward and Reverse IEsBecause the Reverse Information Element dimension is treated explicitly as its own thing, new Information Elements can be added to the IANA-managed space freely, without anyone having to worry about whether a reverse one should be added too 🙌. Apart from the one-time PEN allocation for this purpose, there's no extra maintenance overhead for supporting Reverse Information Elements in the IPFIX Information Model. Iconic, honestly 👑.
Now, some Information Elements in the IPFIX Information Model [RFC5102] are not reversible 🚫. They're semantically meaningless as Reverse Information Elements. An Exporting Process MUST NOT export a Template containing the reverse counterpart of a non-reversible Information Element. A Collecting Process that receives the reverse counterpart of a non-reversible Information Element MAY discard that Information Element from the Flow Record. Non-reversible Information Elements describe properties of the Biflow record as a whole, or they're meant for the internal use of the IPFIX Protocol itself. So by definition, they can't be tied to one direction or endpoint of the Flow 💀.
These specific Information Elements are not reversible:
- Identifiers defined in Section 5.1 of [RFC5102] that can't be associated with a single direction of Uniflow collection: flowId (5.1.7), templateId (5.1.8), observationDomainId (5.1.9), and commonPropertiesId (5.1.11).
- Process configuration elements defined in Section 5.2 of [RFC5102].
- Process statistics elements defined in Section 5.3 of [RFC5102].
- paddingOctets defined in Section 5.12.1 of [RFC5102].
- biflowDirection (defined in Section 6.3 of this document).
Any future addition to the Information Element Registry by IANA that meets the criteria above SHOULD also be considered non-reversible by the Collecting Process 🔍.
Quick note: Information Elements commonly used as Flow Keys (for example, the header fields defined in Sections 5.4 and 5.5 of the Information Model) ARE reversible 🙃. They can show up as value fields in some contexts, like when you're associating ICMP error messages with the flows that caused them.
6.2. Enterprise-Specific Reverse Information Elements 🏢
The Reverse PEN from above is only for making reverse counterparts of IANA-registered IPFIX Information Elements. There's no facility for making reverse counterparts of enterprise-specific Information Elements, sorry bestie 🥺.
Allocating enterprise-specific Information Elements for IPFIX is up to the organization doing the allocating. Enterprise-specific Information Elements are meant for a private enterprise's own internal use, so the lack of any guidance or standard on allocation policies causes no interoperability issues 🌈. Still, if a private enterprise's own Information Element registry expects to allocate reversible Information Elements, and it plans to use this specification to export Biflow data, that registry MAY reserve one of the fifteen available bits in the Information Element ID to signal the reverse direction. For example, if the most significant bit were picked, Information Element IDs 0x4000 to 0x7FFF would be reserved for the reverse direction of Information Element IDs 0x0000 to 0x3FFF ✨.
6.3. biflowDirection Information Element 🧭
This one is the direction-tracking star ⭐. Here's the description: it tells you the direction assignment method that was used to assign the Biflow Source and Destination. This Information Element MAY be present in a Flow Record, or it can be applied to all flows exported from an Exporting Process or Observation Domain using IPFIX Options. If this Information Element is not present in a Flow Record and isn't associated with a Biflow via scope, then the direction assignment method configuration is assumed to be done out-of-band. Quick heads up: when you use IPFIX Options to apply this Information Element to all flows within an Observation Domain or from an Exporting Process, the Option SHOULD be sent reliably. If reliable transport isn't available (for example, when using UDP), this Information Element SHOULD appear in each Flow Record. This field may take the following values:
+-------+------------------+----------------------------------------+
| Value | Name | Description |
+-------+------------------+----------------------------------------+
| 0x00 | arbitrary | Direction was assigned arbitrarily. |
| 0x01 | initiator | The Biflow Source is the flow |
| | | initiator, as determined by the |
| | | Metering Process' best effort to |
| | | detect the initiator. |
| 0x02 | reverseInitiator | The Biflow Destination is the flow |
| | | initiator, as determined by the |
| | | Metering Process' best effort to |
| | | detect the initiator. This value is |
| | | provided for the convenience of |
| | | Exporting Processes to revise an |
| | | initiator estimate without re-encoding |
| | | the Biflow Record. |
| 0x03 | perimeter | The Biflow Source is the endpoint |
| | | outside of a defined perimeter. The |
| | | perimeter's definition is implicit in |
| | | the set of Biflow Source and Biflow |
| | | Destination addresses exported in the |
| | | Biflow Records. |
+-------+------------------+----------------------------------------+Here are the nitty-gritty details 📝:
- Abstract Data Type:
unsigned8 - Data Type Semantics:
identifier - ElementId:
239 - Status:
current
7. IANA Considerations 🏛️
This document creates a new dimension in the Information Element space defined by the IPFIX Information Model [RFC5102]. That new dimension is defined by allocating a new Private Enterprise Number (PEN). The Internet Assigned Numbers Authority (IANA) assigned Private Enterprise Number 29305 to this document as the "IPFIX Reverse Information Element Private Enterprise", with this document's authors as the point of contact 💌.
This document also creates a new IPFIX Information Element, biflowDirection, as defined in Section 6.3. IANA assigned Information Element number 239 in the IPFIX Information Element registry for the biflowDirection Information Element. The values for this Information Element are static, so IANA doesn't need to maintain them in a sub-registry 🗂️.
8. Security Considerations 🔒
Serious moment, bestie 🚨: the same security considerations as for the IPFIX Protocol [RFC5101] apply. Go give [RFC5101] a read so you know exactly what they are 🫶.
9. Acknowledgments 💕
Big thank-yous to Lutz Mark, Juergen Quittek, Andrew Johnson, Paul Aitken, Benoit Claise, and Carsten Schmoll for their contributions and comments 🌸. Extra special thanks to Michelle Cotton for helping us navigate the IANA process for Enterprise Number assignment, and for the IANA pre-review of the document 👑.
10. References 📚
10.1. Normative References
- [RFC5101] Claise, B., Ed., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
- [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008.
10.2. Informative References ✨
okay these are the background reads 📚 not the must-reads, but they're the ones that explain where everything came from 💅
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14,
RFC 2119, March 1997.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes:
Taxonomy and Issues", RFC 3234,
February 2002.
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S.
Zander, "Requirements for IP Flow Information
Export (IPFIX)", RFC 3917, October 2004.
[IPFIX-ARCH] Sadasivan, G., Brownlee, N., Claise, B., and
J. Quittek, "Architecture for IP Flow
Information Export", Work in Progress,
September 2006.
[IPFIX-AS] Zseby, T., Boschi, E., Brownlee, N., and B.
Claise, "IPFIX Applicability", Work
in Progress, July 2007.
[IPFIX-IMPLEMENTATION] Boschi, E., Mark, L., Quittek, j.,
Stiemerling, M., and P. Aitken, "IPFIX
Implementation Guidelines", Work in Progress,
September 2007.
[IPFIX-REDUCING] Boschi, E., Mark, L., and B. Claise,
"Reducing Redundancy in IP Flow Information
Export (IPFIX) and Packet Sampling (PSAMP)
Reports", Work in Progress, May 2007.Appendix A. Examples 🎀
okay bestie, this example walks through a Biflow record exactly as specified in Section 6, above. The Reverse PEN gets assigned so the exporter can tell forward Information Elements apart from Reverse ones 🦋
The information exported in this case is:
- The start time of the flow:
flowStartSecondsin the IPFIX Information Model [RFC5102], with a length of 4 octets. - The reverse start time of the flow:
flowStartSecondsin the IPFIX Information Model [RFC5102], with a length of 4 octets, and the enterprise bit set to 1. The following PEN is the Reverse PEN. - The IPv4 source IP address:
sourceIPv4Addressin the IPFIX Information Model [RFC5102], with a length of 4 octets. - The IPv4 destination IP address:
destinationIPv4Addressin the IPFIX Information Model [RFC5102], with a length of 4 octets. - The source port:
sourceTransportPortin the IPFIX Information Model [RFC5102], with a length of 2 octets. - The destination port:
destinationTransportPortin the IPFIX Information Model [RFC5102], with a length of 2 octets. - The protocol identifier:
protocolIdentifierin the IPFIX Information Model [RFC5102], with a length of 1 octet. - The number of octets of the Flow:
octetTotalCountin the IPFIX Information Model [RFC5102], with a length of 4 octets. - The reverse number of octets of the Flow:
octetTotalCountin the IPFIX Information Model [RFC5102], with a length of 4 octets, and the enterprise bit set to 1. The following PEN is the Reverse PEN. - The number of packets of the Flow:
packetTotalCountin the IPFIX Information Model [RFC5102], with a length of 4 octets. - The reverse number of packets of the Flow:
packetTotalCountin the IPFIX Information Model [RFC5102], with a length of 4 octets, and the enterprise bit set to 1. The following PEN is the Reverse PEN.
and the resulting Template Set would look like the diagram below:
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 = 64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID >= 256 | Field Count = 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| flowStartSeconds 150 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| flowStartSeconds 150 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reverse PEN 29305 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceTransportPort 7 | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationTransportPort 11 | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| protocolIdentifier 4 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| octetTotalCount 85 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| octetTotalCount 85 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reverse PEN 29305 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| packetTotalCount 86 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| packetTotalCount 86 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reverse PEN 29305 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Single Record Biflow Template Setthe following example Data Set represents a typical HTTP transaction 🌸 Its format is defined by the example Template, above.
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 = 41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2006-02-01 17:00:00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2006-02-01 17:00:01 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 192.0.2.3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32770 | 80 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 | 18000 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . | 128000 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . | 65 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . | 110 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . |
+-+-+-+-+-+-+-+-+
Figure 8: Single Record Biflow Data Setthe next example shows the biflowDirection Information Element from Section 6.2 in action 🫶 It uses the IPFIX Options mechanism to say that perimeter direction selection is in effect for a given Observation Domain.
The information exported in this case is:
- The Observation Domain:
observationDomainIdin the IPFIX Information Model [RFC5102], with a length of 4 octets. - The direction assignment method:
biflowDirectionas defined in Section 6.2, above, with a length of 1 octet.
and the resulting Options Template Set would look like the diagram below:
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 = 3 | Length = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID >= 256 | Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Count = 1 |0| observationDomainId 149 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 4 |0| biflowDirection 239 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Biflow Direction Options Template Setthis next Data Set says perimeter direction selection is in effect for the Observation Domain with ID 33 👑 Its format is defined by the example Options Template, above. Note that this example data set would be sent reliably, as specified in the description of the biflowDirection Information Element.
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 = 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 33 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 |
+-+-+-+-+-+-+-+-+
Figure 10: Biflow Direction Options Data SetAppendix B. XML Specification of biflowDirection Information Element ✨
Okay so this appendix is basically the machine-readable version of the biflowDirection IE 🤖💖 It's coded in XML, and it's giving informational vibes, which means the normative rules are still over in Section 6.3 🫶 Don't forget that, bestie!
The format for this XML is described by the XML Schema in Appendix B of the IPFIX Information Model [RFC5102]. Slay the citation 💅
<?xml version="1.0" encoding="UTF-8"?>
<fieldDefinitions xmlns="urn:ietf:params:xml:ns:ipfix-info"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:ipfix-info
ipfix-info.xsd">
<field name="biflowDirection" dataType="unsigned8"
dataTypeSemantics="identifier" group="misc"
elementId="239" applicability="all" status="current">
<description>
<paragraph>
A description of the direction assignment method used to
assign the Biflow Source and Destination. This
Information Element MAY be present in a Flow Data Record, or
applied to all flows exported from an Exporting Process or
Observation Domain using IPFIX Options. If this Information
Element is not present in a Flow Record or associated with a
Biflow via scope, it is assumed that the configuration of
the direction assignment method is done out-of-band. Note
that when using IPFIX Options to apply this Information
Element to all flows within an Observation Domain or from an
Exporting Process, the Option SHOULD be sent reliably. If
reliable transport is not available (i.e., when using UDP),
this Information Element SHOULD appear in each Flow
Record. This field may take the following values:
</paragraph>
<artwork>
+-------+------------------+----------------------------------------+
| Value | Name | Description |
+-------+------------------+----------------------------------------+
| 0x00 | arbitrary | Direction was assigned arbitrarily. |
| 0x01 | initiator | The Biflow Source is the flow |
| | | initiator, as determined by the |
| | | Metering Process' best effort to |
| | | detect the initiator. |
| 0x02 | reverseInitiator | The Biflow Destination is the flow |
| | | initiator, as determined by the |
| | | Metering Process' best effort to |
| | | detect the initiator. This value is |
| | | provided for the convenience of |
| | | Exporting Processes to revise an |
| | | initiator estimate without re-encoding |
| | | the Biflow Record. |
| 0x03 | perimeter | The Biflow Source is the endpoint |
| | | outside of a defined perimeter. The |
| | | perimeter's definition is implicit in |
| | | the set of Biflow Source and Biflow |
| | | Destination addresses exported in the |
| | | Biflow Records. |
+-------+------------------+----------------------------------------+
</artwork>
</description>
</field>
</fieldDefinitions>Authors' Addresses 📬
Brian H. Trammell 🌸
Brian H. Trammell
CERT Network Situational Awareness
Software Engineering Institute
4500 Fifth Avenue
Pittsburgh, PA 15213
United States
Phone: +1 412 268 9748
EMail: bht@cert.orgElisa Boschi 🦋
Elisa Boschi
Hitachi Europe
c/o ETH Zurich
Gloriastrasse 35
8092 Zurich
Switzerland
Phone: +41 44 6327057
EMail: elisa.boschi@hitachi-eu.comFull Copyright Statement 🎀
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
📦 where this page comes from
- ietf: rfc5103 2008-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms