Bidirectional Flow Export Using IP Flow Information Export (IPFIX)
Extracted elements (20)
The Reverse PEN mechanism was chosen over adding explicit reverse IEs to the IANA registry because new IEs can be freely added to the IANA-managed space without concern for reverse counterparts. Once the PEN is allocated, there is no additional maintenance overhead for supporting Reverse IEs in the IPFIX Information Model.
The reverseInitiator (0x02) value is provided as a convenience so Exporting Processes can revise an initiator estimate without re-encoding the entire Biflow Record. This avoids the cost of reconstructing a record solely to swap Source and Destination when the metering process later determines the direction was initially assigned incorrectly.
The single Flow Record method was chosen over exporting Biflows as two adjacent Uniflows because adjacent Uniflows are merely an informal arrangement the Collecting Process cannot rely upon, and they duplicate Flow Key data inefficiently. Methods using commonPropertiesId were also rejected due to additional overhead and state management requirements at both Collecting and Exporting Processes.
No facility is provided for allocating reverse counterparts of enterprise-specific Information Elements using the Reverse PEN (PEN 29305). Enterprise-specific reverse IEs are left to each organization's discretion; enterprises may reserve one of the fifteen available bits in the IE ID to signify reverse direction (e.g., reserving IDs 0x4000–0x7FFF for reverse of 0x0000–0x3FFF).
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 IE MAY discard that element from the Flow Record.
Biflows may be composed only of packets observed within the same Observation Domain. Metering Processes that build Biflows from Uniflows must ensure both Uniflows were observed within the same Observation Domain.
Flow Records containing Reverse Information Elements but no Directional Key Fields are illegal and MUST NOT be sent by the Exporting Process. The Collecting Process SHOULD drop such records and SHOULD log their receipt.
In core network deployments with no stable perimeter and no ability to determine initiator/responder, the Metering Process MAY assign Biflow Source and Destination arbitrarily, but SHOULD be consistent in its choice and SHOULD maintain direction for the lifetime of the Biflow even across active timeouts.
When a Biflow traverses a middlebox, it MUST be clear at the Collecting Process whether packets were observed before or after modification. The Observation Process SHOULD be located on one side of a middlebox, and the Exporting Process SHOULD communicate both the incoming and modified values of changed flow properties.
When deployed at a network perimeter with a stable set of inside addresses and no requirement to determine the initiator/responder, the Metering Process SHOULD assign the Biflow Source to be the endpoint outside the perimeter.
When exporting Uniflows, Exporting Processes SHOULD use a Template containing no Reverse Information Elements. A Template with only reverse counter elements MAY be used for Uniflows (since zero counters are semantically equivalent to no reverse direction), but not for elements where zero has distinct meaning (e.g., tcpControlBits).
When the measurement application requires determination of the initiator and responder of a communication, the Metering Process SHOULD define the Biflow Source to be the initiator, where possible. This can be approximated by treating the first packet seen as the initiating packet, improved using transport/application protocol knowledge (e.g., TCP flags).
When using IPFIX Options to apply biflowDirection to all flows within an Observation Domain or from an Exporting Process, the Option SHOULD be sent reliably. If reliable transport is not available (e.g., when using UDP), biflowDirection SHOULD appear in each Flow Record.
A Biflow is a Flow composed of packets sent in both directions between two endpoints, composed from two Uniflows where Non-directional Key Field values are identical across both Uniflows and Directional Key Field values are mirror-reversed. A Biflow record contains the Flow Key once plus both forward and Reverse Information Elements for each non-key field.
biflowDirection (IE 239) is an unsigned8 identifier element that describes the direction assignment method used for a Biflow. Values are: 0x00 (arbitrary), 0x01 (initiator — Source is initiator), 0x02 (reverseInitiator — Destination is initiator), 0x03 (perimeter — Source is outside-perimeter endpoint). It MAY appear per-Flow-Record or via IPFIX Options scoped to an Observation Domain or Exporting Process.
Non-reversible Information Elements include: flowId, templateId, observationDomainId, and commonPropertiesId (identifiers that cannot be associated with a single uniflow direction); all process configuration elements; all process statistics elements; paddingOctets; and biflowDirection itself. Future IANA additions meeting these criteria SHOULD also be considered non-reversible.
Reverse Information Elements are defined by assigning Private Enterprise Number (PEN) 29305 as the 'IPFIX Reverse Information Element Private Enterprise'. Each Information Element number within this PEN space is the reverse counterpart of the corresponding IANA-assigned public IE number. To generate a Reverse IE, set the enterprise bit and define the IE within PEN 29305.
IANA assigned Private Enterprise Number 29305 to this document as the 'IPFIX Reverse Information Element Private Enterprise', defining the Reverse PEN space for Reverse Information Elements. IANA also assigned Information Element number 239 in the IPFIX IE registry for biflowDirection; its values are static and require no IANA-maintained sub-registry.
The same security considerations as for the IPFIX Protocol (RFC 5101) apply to Biflow export. No additional security considerations specific to Biflow export are identified beyond those already applicable to the IPFIX protocol.
A Reverse Information Element in a Template is encoded identically to its forward counterpart except the enterprise bit (bit 0 of the first octet) is set to 1, and the 4-byte Reverse PEN (29305) follows immediately after the field length. Forward IEs have the enterprise bit set to 0 and no trailing PEN.