In Situ Operations, Administration, and Maintenance (IOAM) Direct Exporting
Extracted elements (29)
A Hop Count field in the DEX header was considered during design (incrementing from 0 at encapsulating node) but rejected in favor of using the existing Hop_Lim/Node_ID IOAM-Data-Field via the IOAM-Trace-Type bit, which avoids consuming space in the Flags field and reuses existing IOAM infrastructure.
Despite being called 'Direct Export', the DEX Option-Type does not necessarily result in the creation of another packet. Some deployments may use it solely as a trigger for local OAM data processing, making the name slightly misleading but preserved for historical reasons.
The Checksum Complement IOAM-Data-Field bit in IOAM-Trace-Type SHOULD be zero for DEX because the Checksum Complement is intended for in-flight packet modifications and is not relevant for direct exporting where data is not written back into the forwarded packet.
The DEX Option-Type evolved from combining concepts of PBT-I (Postcard-Based Telemetry Immediate) from draft-song-ippm-postcard-based-telemetry with immediate exporting concepts from early versions of RFC 9322 (IOAM Loopback and Active Flags).
The recommendation that N >> M (where M is the max number of transit IOAM nodes) for the packet selection ratio is based on the fact that one DEX-marked packet can trigger up to M exported packets. Keeping N much larger than M ensures exported packet volume is substantially lower than forwarded data packet volume.
A transit or decapsulating IOAM node that receives an unknown IOAM-Option-Type ignores it per RFC 9197; nodes that do not support the DEX Option-Type will ignore it. The ability to skip over an unknown DEX Option-Type during parsing or decapsulation depends on the specific encapsulation (e.g., IPv6 Hop-by-Hop options can be skipped using the length field).
An IOAM decapsulating node that processes a packet with the DEX Option-Type MAY export and/or collect the requested IOAM data and MUST decapsulate the IOAM header, including all its IOAM-Option-Types.
An IOAM encapsulating node that supports the DEX Option-Type MUST support the ability to incorporate the DEX Option-Type selectively into a subset of the packets it forwards, to prevent excessive exported data that could overload the network or receiving entity.
An IOAM node MUST gain explicit consent to export data to a receiving entity before starting to send exported data, ensuring only authorized collection occurs.
An IOAM node that performs DEX-triggered exporting MUST support the ability to limit the rate of exported packets. The exported data rate SHOULD NOT exceed 1/N of the interface capacity on any of the node's interfaces, with N > 100 RECOMMENDED.
An IOAM node that receives a DEX Option-Type with an unknown Extension-Flag set to 1 MUST ignore the corresponding optional field, enabling forward compatibility with future optional field definitions.
Any exporting method MUST secure the exported data from the IOAM node to the receiving entity to protect confidentiality and guarantee integrity. An IOAM node performing DEX exporting MUST send exported data to a pre-configured trusted receiving entity within the same IOAM-Domain.
IOAM encapsulating nodes that can identify a packet as an IOAM exported packet MUST NOT push a DEX Option-Type into such a packet, to prevent nested exporting and exporting loops. IOAM nodes SHOULD NOT be configured to export packets over a path or tunnel subject to IOAM direct exporting.
New registration requests for the IOAM DEX Flags and IOAM DEX Extension-Flags registries MUST use the specified template (bit number, description, reference), and allocation is based on the IETF Review procedure.
The subset of traffic forwarded with a DEX Option-Type SHOULD NOT exceed 1/N of the interface capacity on any of the IOAM encapsulating node's interfaces, where N is operator-configurable. If there is an upper bound M on transit nodes in any path, it is RECOMMENDED to use N >> M; if topology is unknown, N > 100 is RECOMMENDED.
The IOAM Direct Export (DEX) Option-Type is a new IOAM-Option-Type that serves as a trigger for IOAM nodes to locally aggregate and/or export IOAM data to a receiving entity without pushing data into in-flight data packets. It is inserted by IOAM encapsulating nodes, readable but not modifiable by transit nodes, and removed by decapsulating nodes.
IANA allocated code point 4 in the existing 'IOAM Option-Type' registry (defined in RFC 9197 Section 7.1) for the 'IOAM Direct Export (DEX) Option-Type' with description 'Direct exporting'.
IANA created the 'IOAM DEX Extension-Flags' registry with 8 flag bits. Bit 0 (most significant) is allocated as 'Flow ID [RFC9326]' and bit 1 as 'Sequence Number [RFC9326]'. Remaining bits are allocated via IETF Review.
IANA created the 'IOAM DEX Flags' registry with 8 flag bits for the Flags field of the DEX Option-Type. Allocation is based on the IETF Review procedure. No bits are pre-allocated by this document.
An attacker may inject synthetic packets or maliciously add/remove the DEX Option-Type from transit packets to overload IOAM nodes and/or receiving entities. Because DEX affects multiple devices along the network path, it can amplify effects on network bandwidth, device storage, and the receiving entity's load.
An attacker may track information in DEX headers (Flow ID and Sequence Number) for reconnaissance purposes, potentially compromising privacy aspects such as customer identities. This can be mitigated by careful allocation of the Flow ID and Sequence Number space.
In wide area networks with multiple IOAM-Domains, the amplification effect of DEX can be recursive: exported packets from Domain 1 forwarded through Domain 2 trigger further DEX exports, which may cascade through additional domains, potentially leading to unbounded amplification loops.
Integrity protection mechanisms defined in IOAM-DATA-INTEGRITY are not applicable to the DEX Option-Type because DEX does not include IOAM-Data-Fields. Injection or modification of IOAM-Option-Type headers are acknowledged threats not addressed in IOAM; integrity protection must rely on the encapsulating protocol.
Flow ID is an optional 32-bit field representing the flow identifier, zero-padded in most significant bits if the actual Flow ID is shorter. It is set at the encapsulating node and used to correlate exported data of the same flow across multiple nodes and packets.
IOAM-Trace-Type is a 24-bit identifier specifying which IOAM-Data-Fields should be exported, using the same format as RFC 9197. The bit corresponding to the Checksum Complement IOAM-Data-Field SHOULD be set to zero by the encapsulating node and ignored by transit and decapsulating nodes.
Namespace-ID is a 16-bit identifier of the IOAM namespace, as defined in RFC 9197, used to scope the IOAM data collection context.
Sequence Number is an optional 32-bit field starting from 0 and incremented by 1 for each packet of the same flow at the encapsulating node. Combined with Flow ID, it allows correlation of exported data from the same user packet.
The DEX Option-Type is at least 8 octets long, comprising: Namespace-ID (16 bits), Flags (8 bits), Extension-Flags (8 bits), IOAM-Trace-Type (24 bits), Reserved (8 bits), and optional 32-bit fields (Flow ID and Sequence Number) whose presence is indicated by the Extension-Flags field.
The Extension-Flags field is 8 bits; each bit set to 1 indicates the presence of a corresponding 4-octet optional field. Optional fields appear after the Reserved field in order from most significant to least significant enabled bit. Every optional field MUST be exactly 4 octets long.