From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5103.txt | 1347 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1347 insertions(+) create mode 100644 doc/rfc/rfc5103.txt (limited to 'doc/rfc/rfc5103.txt') diff --git a/doc/rfc/rfc5103.txt b/doc/rfc/rfc5103.txt new file mode 100644 index 0000000..361e835 --- /dev/null +++ b/doc/rfc/rfc5103.txt @@ -0,0 +1,1347 @@ + + + + + + +Network Working Group B. Trammell +Request for Comments: 5103 CERT/NetSA +Category: Standards Track E. Boschi + Hitachi Europe + January 2008 + + + Bidirectional Flow Export Using IP Flow Information Export (IPFIX) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document describes an efficient method for exporting + bidirectional flow (Biflow) information using the IP Flow Information + Export (IPFIX) protocol, representing each Biflow using a single Flow + Record. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Trammell & Boschi Standards Track [Page 1] + +RFC 5103 IPFIX Biflow Export January 2008 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. IPFIX Documents Overview . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Rationale and History . . . . . . . . . . . . . . . . . . . . 5 + 4. Biflow Semantics . . . . . . . . . . . . . . . . . . . . . . . 6 + 5. Direction Assignment . . . . . . . . . . . . . . . . . . . . . 8 + 5.1. Direction by Initiator . . . . . . . . . . . . . . . . . . 9 + 5.2. Direction by Perimeter . . . . . . . . . . . . . . . . . . 10 + 5.3. Arbitrary Direction . . . . . . . . . . . . . . . . . . . 10 + 6. Record Representation . . . . . . . . . . . . . . . . . . . . 11 + 6.1. Reverse Information Element Private Enterprise Number . . 11 + 6.2. Enterprise-Specific Reverse Information Elements . . . . . 13 + 6.3. biflowDirection Information Element . . . . . . . . . . . 13 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 + Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 17 + Appendix B. XML Specification of biflowDirection Information + Element . . . . . . . . . . . . . . . . . . . . . . . 21 + + + + + + + + + + + + + + + + + + + + + + + + + + + +Trammell & Boschi Standards Track [Page 2] + +RFC 5103 IPFIX Biflow Export January 2008 + + +1. Introduction + + Many flow analysis tasks benefit from association of the upstream and + downstream flows of a bidirectional communication, e.g., separating + answered and unanswered TCP requests, calculating round trip times, + etc. Metering processes that are not part of an asymmetric routing + infrastructure, especially those deployed at a single point through + which bidirectional traffic flows, are well positioned to observe + bidirectional flows (Biflows). In such topologies, the total + resource requirements for Biflow assembly are often lower if the + Biflows are assembled at the measurement interface as opposed to the + Collector. The IPFIX Protocol requires only information model + extensions to be complete as a solution for exporting Biflow data. + + To that end, we propose a Biflow export method using a single Flow + Record per Biflow in this document. We explore the semantics of + bidirectional flow data in Section 4, "Biflow Semantics"; examine the + various possibilities for determining the direction of Biflows in + Section 5, "Direction Assignment"; then define the Biflow export + method in Section 6, "Record Representation". + + This export method requires additional Information Elements to + represent data values for the reverse direction of each Biflow, and a + single additional Information Element to represent direction + assignment information, as described in Sections 6.1 through 6.3. + The selection of this method was motivated by an exploration of other + possible methods of Biflow export using IPFIX; however, these methods + have important drawbacks, as discussed in Section 3, "Rationale and + History". + +1.1. IPFIX Documents Overview + + "Specification of the IPFIX Protocol for the Exchange of IP Traffic + Flow Information" [RFC5101] (informally, the IPFIX Protocol document) + and its associated documents define the IPFIX Protocol, which + provides network engineers and administrators with access to IP + traffic flow information. + + "Architecture for IP Flow Information Export" [IPFIX-ARCH] (the IPFIX + Architecture document) defines the architecture for the export of + measured IP flow information out of an IPFIX Exporting Process to an + IPFIX Collecting Process, and the basic terminology used to describe + the elements of this architecture, per the requirements defined in + "Requirements for IP Flow Information Export" [RFC3917]. The IPFIX + Protocol document [RFC5101] then covers the details of the method for + transporting IPFIX Data Records and Templates via a congestion-aware + transport protocol from an IPFIX Exporting Process to an IPFIX + Collecting Process. + + + +Trammell & Boschi Standards Track [Page 3] + +RFC 5103 IPFIX Biflow Export January 2008 + + + "Information Model for IP Flow Information Export" [RFC5102] + (informally, the IPFIX Information Model document) describes the + Information Elements used by IPFIX, including details on Information + Element naming, numbering, and data type encoding. Finally, "IPFIX + Applicability" [IPFIX-AS] describes the various applications of the + IPFIX protocol and their use of information exported via IPFIX, and + relates the IPFIX architecture to other measurement architectures and + frameworks. + + This document references the Protocol and Architecture documents for + terminology, uses the IPFIX Protocol to define a bidirectional flow + export method, and proposes additions to the information model + defined in the IPFIX Information Model document. + +2. Terminology + + Capitalized terms used in this document that are defined in the + Terminology section of the IPFIX Protocol document [RFC5101] are to + be interpreted as defined there. The following additional terms are + defined in terms of the IPFIX Protocol document terminology. + + 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 associated with a single endpoint of the + Flow. sourceIPv4Address and destinationTransportPort are example + Directional Key Fields. + + 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 is not specifically associated with either endpoint + of the Flow. protocolIdentifier is an example Non-directional Key + Field. + + Uniflow (Unidirectional Flow): A Uniflow is a Flow as defined in the + IPFIX Protocol document [RFC5101], restricted such that the Flow + is composed only of packets sent from a single endpoint to another + single endpoint. + + Biflow (Bidirectional Flow): A Biflow is a Flow as defined in the + IPFIX Protocol document [RFC5101], composed of packets sent in + both directions between two endpoints. A Biflow is composed from + two Uniflows such that: + + 1. the value of each Non-directional Key Field of each Uniflow is + identical to its counterpart in the other, and + + 2. the value of each Directional Key Field of each Uniflow is + identical to its reverse direction counterpart in the other. + + + +Trammell & Boschi Standards Track [Page 4] + +RFC 5103 IPFIX Biflow Export January 2008 + + + A Biflow contains two non-key fields for each value it represents + associated with 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 composed + of packets sent by the Biflow Source. Values associated with the + forward direction of a Biflow are represented using normal + Information Elements. In other words, a Uniflow may be defined as + a Biflow having only a forward direction. + + reverse direction (of a Biflow): The direction of a Biflow composed + of packets sent by the Biflow Destination. Values associated with + 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 + + In selecting the Single Record Biflow export method described in this + document as the recommendation for bidirectional flow export using + IPFIX, we considered several other possible methods. + + The first and most obvious would be simply to export Biflows as two + Uniflows adjacent in the record stream; a Collecting Process could + then reassemble them with minimal state requirements. However, this + has the drawbacks that it is merely an informal arrangement the + Collecting Process cannot rely upon, and that it is not bandwidth- + efficient, duplicating the export of Flow Key data in each Uniflow + record. + + We then considered the method outlined in Reducing Redundancy in + IPFIX and Packet Sampling (PSAMP) Reports [IPFIX-REDUCING] for + reducing this bandwidth inefficiency. This would also formally link + + + +Trammell & Boschi Standards Track [Page 5] + +RFC 5103 IPFIX Biflow Export January 2008 + + + the two Uniflows into a single construct, by exporting the Flow Key + as Common Properties then exporting each direction's information as + Specific Properties. However, it would do so at the expense of + additional overhead to transmit the commonPropertiesId, and + additional state management requirements at both the Collecting and + Exporting Processes. + + A proposal was made 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. In this approach, the first instance of a counter would + represent the forward direction, and the second instance of the same + counter would represent the reverse. This had the disadvantage of + conflicting with the presently defined semantics for these counters, + and, as such, was abandoned. + +4. Biflow Semantics + + As stated in the Terminology section above, a Biflow is simply a Flow + representing packets flowing in both directions between two endpoints + on a network. There are compelling reasons to treat Biflows as + single entities (as opposed to merely ad-hoc combinations of + Uniflows) within IPFIX. First, as most application-layer network + protocols are inherently bidirectional, a Biflow-based data model + more accurately represents the behavior of the network, and enables + easier application of flow data to answering interesting questions + about network behavior. Second, exporting Biflow data can result in + improved export efficiency by eliminating the duplication of Flow Key + data in an IPFIX message stream, and improve collection efficiency by + removing the burden of Biflow matching from the Collecting Process + where possible. + + Biflows are somewhat more semantically complicated than Uniflows. + When handling Uniflows, the semantics of source and destination + Information Elements are clearly defined by the semantics of the + underlying packet header data: the source Information Elements + represent the source header fields, and the destination Information + Elements represent the destination header fields. When representing + Biflows with single IPFIX Data Records, the definitions of source and + destination must be chosen more carefully. + + As in the Terminology section above, we define the Source of a Biflow + to be that identified by the source Directional Key Field(s), and the + Destination of the Biflow to be that identified by the destination + Directional Key Field(s). Note that, for IANA-registered Information + Elements, or those defined by the IPFIX Information Model [RFC5102], + Directional Key Fields associated with the Biflow Source are + represented by Information Elements whose names begin with "source", + + + +Trammell & Boschi Standards Track [Page 6] + +RFC 5103 IPFIX Biflow Export January 2008 + + + and Directional Key Fields associated with the Biflow Destination are + represented by Information Elements whose names begin with + "destination"; it is recommended that enterprise-specific Information + Elements follow these conventions, as well. + + Methods for assignment of Source and Destination by the Metering and + Exporting Processes are described in the following section. + + As the Source and Destination of a Biflow are defined in terms of its + Directional Keys, Biflow values are also split info forward and + reverse directions. As in the Terminology section above, the forward + direction of a Biflow is composed of packets sent by the Biflow + Source, and the reverse direction of a Biflow is composed of packets + sent by the Destination. In other words, the two directions of a + Biflow may be roughly thought of as the two Uniflows that were + matched to compose the Biflow. A Biflow record, then, contains each + Flow Key record once, and both forward Information Elements and + Reverse Information Elements for each non-key field. See Figure 1 + for an illustration of the composition of Biflows from Uniflows. + + 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 Diagram + + The reverse direction values are represented by Reverse Information + Elements. The representation of these Reverse Information Elements + within Templates is detailed in Section 5. A Flow Record may be + considered to be a Biflow record by the Collecting Process if it + contains at least one Reverse Information Element AND at least one + Directional Key Field. Flow Records containing Reverse Information + Elements but no Directional Key Fields are illegal, MUST NOT be sent + by the Exporting Process, and SHOULD be dropped by the Collecting + Process. The Collecting Process SHOULD log the receipt of such + illegal Flow Records. + + When exporting Uniflows, Exporting Processes SHOULD use a Template + containing no Reverse Information Elements. Note that a Template + whose only Reverse Information Elements are counters MAY be used to + + + + +Trammell & Boschi Standards Track [Page 7] + +RFC 5103 IPFIX Biflow Export January 2008 + + + export Uniflows, as counters with values of 0 are semantically + equivalent to no reverse direction. However, this approach is not + possible for Reverse Information Elements whose zero values have a + distinct meaning (e.g., tcpControlBits). + + Note that a Biflow traversing a middlebox [RFC3234] may show + different flow properties on each side of the middlebox due to + changes to the packet header or payload performed by the middlebox + itself. Therefore, it MUST be clear at a Collecting Process whether + packets were observed and metered before or after modification. The + Observation Process SHOULD be located on one side of a middlebox, and + the Exporting Process SHOULD communicate to the Collecting Process + both the incoming value of the flow property changed within the + middlebox and the changed value on the "other side". The IPFIX + Information Model [RFC5102] provides Information Elements with prefix + "post" for this purpose. The location of the Observation Point(s) + with respect to the middlebox can be communicated using Options with + Observation Point as Scope and elements such as lineCardID or + samplerID. + + For further information on the effect of middleboxes within the IPFIX + architecture, refer to Section 7 of the IPFIX Implementation + Guidelines [IPFIX-IMPLEMENTATION]. + + By the definition of Observation Domain in Section 2 of the IPFIX + Protocol document [RFC5101], Biflows may be composed only of packets + observed within the same Observation Domain. This implies that + Metering Processes that build Biflows out of Uniflows must ensure + that the two Uniflows were observed within the same Observation + Domain. + +5. Direction Assignment + + Due to the variety of flow measurement applications and restrictions + on Metering Process deployment, one single method of assigning the + directions of a Biflow will not apply in all cases. This section + describes three methods of direction assignment, and recommends them + based upon Metering Process position and measurement application + requirements. In each of the figures in this section, the "MP" box + represents the Metering Process. + + As the method selection is dependent on Metering Process position, it + is sufficient to configure the direction assignment method at the + Collecting and/or the Exporting Process out-of-band. For example, a + Collecting Process might be configured that a specific Exporting + Process identified by exporterIPv4Address is assigning direction by + initiator; or both a Collecting Process and an Exporting Process + could be simultaneously configured with a specific direction + + + +Trammell & Boschi Standards Track [Page 8] + +RFC 5103 IPFIX Biflow Export January 2008 + + + assignment perimeter. However, for Exporting Processes that use + multiple direction selection methods, or for Collecting Processes + accepting data from Exporting Processes using a variety of methods, a + biflowDirection Information Element is provided for optional + representation of direction assignment information. + +5.1. Direction by Initiator + + If the measurement application requires the determination of the + initiator and responder of a given communication, the Metering + Process SHOULD define the Biflow Source to be the initiator of the + Biflow, where possible. This can be roughly approximated by a + Metering Process observing packets in both directions simply assuming + that the first packet seen in a given Biflow is the packet initiating + the Biflow. A Metering Process may improve upon this method by using + knowledge of the transport or application protocols (e.g., TCP flags, + DNS question/answer counts) to better approximate the flow-initiating + packet. + + Note that direction assignment by initiator is most easily done by a + single Metering Process positioned on a local link layer, as in + Figure 2, or a single Metering Process observing bidirectional packet + flows at a symmetric perimeter routing point, as in Figure 3. + + Note also that many Metering Processes have an "active" timeout, such + that any flow with a duration longer than the active timeout is + expired and any further packets belonging to that flow are accounted + for as part of a new flow. This mechanism may cause issues with the + assumption that a first packet seen is from the flow initiator, if + the "first" packet is a middle packet in a long-duration flow. + + +-------+ +-------+ + | node | | node | + +---+---+ +---+---+ + | | +---------+ + <===+=====+=====+======>+ +<===> Internet + | | router | + +---+---+ +---------+ + | MP | + +---+---+ + + Figure 2: Local Link Metering Process Position + + + + + + + + + +Trammell & Boschi Standards Track [Page 9] + +RFC 5103 IPFIX Biflow Export January 2008 + + + +-------+ +-------+ + | node | | node | + +---+---+ +---+---+ + | | +---------+ + <===+===========+======>+ +<===> Internet + | router | + | +----+--+ + +----+ MP | + +-------+ + + Figure 3: Symmetric Routing Point Metering Process Position + +5.2. Direction by Perimeter + + If the measurement application is deployed at a network perimeter, as + illustrated in Figure 4, such that there is a stable set of addresses + that can be defined as "inside" that perimeter, and there is no + measurement application requirement to determine the initiator and + responder of a given communication, 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 defining the + interior of a perimeter; this set may be deduced by the Collecting + Process observing the set of Biflow Source and Biflow Destination + addresses, or configured out-of-band. + + +---------+ +---------+ + ====>+ access +====> ====>+ access +====> + Internet | router | Local Net | router | Internet + (link A) <====+ A +<==== <====+ B +<==== (link B) + +----+----+ +---------+ + | + +---+---+ + | MP | + +-------+ + + Figure 4: Perimeter Metering Process Position + +5.3. Arbitrary Direction + + If the measurement application is deployed in a network core, such + that there is no stable set of addresses defining a perimeter (e.g., + due to BGP updates), as in Figure 5, and no requirement or ability to + determine the initiator or responder of a given communication, then + the Metering Process MAY assign the Biflow Source and Biflow + Destination endpoints arbitrarily. + + + + + +Trammell & Boschi Standards Track [Page 10] + +RFC 5103 IPFIX Biflow Export January 2008 + + + In this case, the Metering Process SHOULD be consistent in its choice + of direction. Once assigned, direction SHOULD be maintained for the + lifetime of the Biflow, even in the case of active timeout of a + long-lived Biflow. + + | + V + +----+----+ +---------+ + <===+ core | | core +===> + | router +<========>+ router | + ===>+ | | +<=== + +----+----+ +----+----+ + | | + +---+---+ V + | MP | + +-------+ + + Figure 5: Transit/Core Metering Process Position + +6. Record Representation + + As noted above, Biflows are exported using a single Flow Record, each + of which contains the Flow Key fields once, and both forward + Information Elements and Reverse Information Elements for each non- + key field. The IPFIX Information Model is extended to provide a + Reverse Information Element counterpart to each presently defined + forward Information Element, as required by any Information Element + that may be a non-key field in a Biflow. + +6.1. Reverse Information Element Private Enterprise Number + + Reverse Information Elements are specified as a separate "dimension" + in the Information Element space, assigning Private Enterprise Number + (PEN) 29305 to this document, and defining that PEN to signify "IPFIX + Reverse Information Element" (the Reverse PEN). This Reverse PEN + serves as a "reverse direction flag" in the Template; each + Information Element number within this PEN space is assigned to the + reverse counterpart of the corresponding IANA-assigned public + Information Element number. In other words, to generate a Reverse + Information Element in a Template corresponding to a given forward + Information Element, simply set the enterprise bit and define the + Information Element within the Reverse PEN space, as in Figure 6 + below. + + + + + + + + +Trammell & Boschi Standards Track [Page 11] + +RFC 5103 IPFIX Biflow Export January 2008 + + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |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 IEs + + As the Reverse Information Element dimension is treated explicitly as + such, new Information Elements can be added freely to the IANA- + managed space without concern for whether a Reverse Information + Element should also be added. Aside from the initial allocation of a + Private Enterprise Number for this purpose, there is no additional + maintenance overhead for supporting Reverse Information Elements in + the IPFIX Information Model. + + Note that certain Information Elements in the IPFIX Information Model + [RFC5102] are not reversible; that is, they are 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 receiving + the reverse counterpart of a non-reversible Information Element MAY + discard that Information Element from the Flow Record. Non- + reversible Information Elements represent properties of the Biflow + record as a whole, or are intended for internal the use of the IPFIX + Protocol itself. Therefore, by definition, they cannot be associated + with a single direction or endpoint of the Flow. + + The following specific Information Elements are not reversible: + + 1. Identifiers defined in Section 5.1 of [RFC5102] that cannot 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). + + 2. Process configuration elements defined in Section 5.2 of + [RFC5102]. + + 3. Process statistics elements defined in Section 5.3 of [RFC5102]. + + + + +Trammell & Boschi Standards Track [Page 12] + +RFC 5103 IPFIX Biflow Export January 2008 + + + 4. paddingOctets defined in Section 5.12.1 of [RFC5102]. + + 5. biflowDirection (defined in Section 6.3 of this document). + + Any future addition to the Information Element Registry by IANA that + meets the criteria defined above SHOULD also be considered to be non- + reversible by the Collecting Process. + + Note that Information Elements commonly used as Flow Keys (e.g., + header fields defined in Sections 5.4 and 5.5 of the Information + Model) are reversible, as they may be used as value fields in certain + contexts, as when associating ICMP error messages with the flows that + caused them. + +6.2. Enterprise-Specific Reverse Information Elements + + Note that the Reverse PEN defined above is only available for + allocating reverse counterparts of IANA-registered IPFIX Information + Elements. No facility is provided for allocating reverse + counterparts of enterprise-specific Information Elements. + + The allocation of enterprise-specific Information Elements for IPFIX + is left to the discretion of the organization allocating them. Note + that, as enterprise-specific Information Elements are designed for + the internal use of private enterprises, the lack of any guidance or + standard on Information Element allocation policies poses no + interoperability issues. However, if a private enterprise's own + Information Element registry anticipates the allocation of reversible + Information Elements, and the use of this specification for the + export of Biflow data, that registry MAY reserve one of the fifteen + available bits in the Information Element ID to signify the reverse + direction. For example, if the most significant bit were selected, + this would reserve Information Element IDs 0x4000 to 0x7FFF for the + reverse direction of Information Element IDs 0x0000 to 0x3FFF. + +6.3. biflowDirection Information Element + + Description: A description of the direction assignment method used + to assign the Biflow Source and Destination. This Information + Element MAY be present in a Flow 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 + + + +Trammell & Boschi Standards Track [Page 13] + +RFC 5103 IPFIX Biflow Export January 2008 + + + 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. | + +-------+------------------+----------------------------------------+ + + Abstract Data Type: unsigned8 + + Data Type Semantics: identifier + + ElementId: 239 + + Status: current + +7. IANA Considerations + + This document specifies the creation of a new dimension in the + Information Element space defined by the IPFIX Information Model + [RFC5102]. This new dimension is defined by the allocation of a new + Private Enterprise Number (PEN). The Internet Assigned Numbers + Authority (IANA) has assigned Private Enterprise Number 29305 to this + document as the "IPFIX Reverse Information Element Private + Enterprise", with this document's authors as point of contact. + + This document specifies the creation of a new IPFIX Information + Element, biflowDirection, as defined in Section 6.3. IANA has + assigned Information Element number 239 in the IPFIX Information + + + +Trammell & Boschi Standards Track [Page 14] + +RFC 5103 IPFIX Biflow Export January 2008 + + + Element registry for the biflowDirection Information Element. The + values defined for this Information Element are static, and as such + do not need to be maintained by IANA in a sub-registry. + +8. Security Considerations + + The same security considerations as for the IPFIX Protocol [RFC5101] + apply. + +9. Acknowledgments + + We would like to thank Lutz Mark, Juergen Quittek, Andrew Johnson, + Paul Aitken, Benoit Claise, and Carsten Schmoll for their + contributions and comments. Special thanks to Michelle Cotton for + her assistance in navigating 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 + + [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. + + + + + + + +Trammell & Boschi Standards Track [Page 15] + +RFC 5103 IPFIX Biflow Export January 2008 + + + [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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Trammell & Boschi Standards Track [Page 16] + +RFC 5103 IPFIX Biflow Export January 2008 + + +Appendix A. Examples + + The following example describes a Biflow record as specified in + Section 6, above. The Reverse PEN is assigned for the purpose of + differentiating forward from Reverse Information Elements. + + The information exported in this case is: + + o The start time of the flow: flowStartSeconds in the IPFIX + Information Model [RFC5102], with a length of 4 octets. + + o The reverse start time of the flow: flowStartSeconds in 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. + + o The IPv4 source IP address: sourceIPv4Address in the IPFIX + Information Model [RFC5102], with a length of 4 octets. + + o The IPv4 destination IP address: destinationIPv4Address in the + IPFIX Information Model [RFC5102], with a length of 4 octets. + + o The source port: sourceTransportPort in the IPFIX Information + Model [RFC5102], with a length of 2 octets. + + o The destination port: destinationTransportPort in the IPFIX + Information Model [RFC5102], with a length of 2 octets. + + o The protocol identifier: protocolIdentifier in the IPFIX + Information Model [RFC5102], with a length of 1 octet. + + o The number of octets of the Flow: octetTotalCount in the IPFIX + Information Model [RFC5102], with a length of 4 octets. + + o The reverse number of octets of the Flow: octetTotalCount in 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. + + o The number of packets of the Flow: packetTotalCount in the IPFIX + Information Model [RFC5102], with a length of 4 octets. + + o The reverse number of packets of the Flow: packetTotalCount in 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. + + + + + + +Trammell & Boschi Standards Track [Page 17] + +RFC 5103 IPFIX Biflow Export January 2008 + + + 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 Set + + + + + + + + + + + + +Trammell & Boschi Standards Track [Page 18] + +RFC 5103 IPFIX Biflow Export January 2008 + + + The 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 Set + + The following example demonstrates the use of the biflowDirection + Information Element, as specified in Section 6.2, using the IPFIX + Options mechanism to specify that perimeter direction selection is in + effect for a given Observation Domain. + + The information exported in this case is: + + o The Observation Domain: observationDomainId in the IPFIX + Information Model [RFC5102], with a length of 4 octets. + + o The direction assignment method: biflowDirection as defined in + Section 6.2, above, with a length of 1 octet. + + + + + + + + +Trammell & Boschi Standards Track [Page 19] + +RFC 5103 IPFIX Biflow Export January 2008 + + + 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 Set + + The following example Data Set would specify that 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 Set + + + + + + + + + + + + + + + +Trammell & Boschi Standards Track [Page 20] + +RFC 5103 IPFIX Biflow Export January 2008 + + +Appendix B. XML Specification of biflowDirection Information Element + + This appendix contains a machine-readable description of the + biflowDirection information element defined in this document, coded + in XML. Note that this appendix is of informational nature, while + the text in Section 6.3 is normative. + + The format in which this specification is given is described by the + XML Schema in Appendix B of the IPFIX Information Model [RFC5102]. + + + + + + + + + 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: + + + + + + + + + + + + + + + +Trammell & Boschi Standards Track [Page 21] + +RFC 5103 IPFIX Biflow Export January 2008 + + + + +-------+------------------+----------------------------------------+ + | 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. | + +-------+------------------+----------------------------------------+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +Trammell & Boschi Standards Track [Page 22] + +RFC 5103 IPFIX Biflow Export January 2008 + + +Authors' Addresses + + 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.org + + + Elisa Boschi + Hitachi Europe + c/o ETH Zurich + Gloriastrasse 35 + 8092 Zurich + Switzerland + + Phone: +41 44 6327057 + EMail: elisa.boschi@hitachi-eu.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Trammell & Boschi Standards Track [Page 23] + +RFC 5103 IPFIX Biflow Export January 2008 + + +Full 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. + + + + + + + + + + + + +Trammell & Boschi Standards Track [Page 24] + -- cgit v1.2.3