IPFIX Protocol over QUIC

specifies a protocol called IP Flow Information Export (IPFIX) protocol that specifies how IPFIX Data Records and corresponding (Options) Template Records are carried via a few of transport protocols from an Exporter to a Collector. The specifies "SCTP using the PR-SCTP extension as specified in MUST be implemented by all compliant implementations. UDP MAY also be implemented by compliant implementations. TCP MAY also be implemented by compliant implementations." However, in practice, the UDP transport is used. The IPFIX protocol specifications cover the specifics and mappings per transport protocol (see Section 8, 9, 10 of ). For example, the Template management differs based on the transport protocol. To prevent potential security threats (such as DoS attacks), it is highly desirable that it must ensure the confidentiality and integrity of IPFIX data transferred from an Exporter to a Collector. Authentication mechanism is also desirable to prevent the collection of data from an unauthorized Exporting Process or the export of data to an unauthorized Collecting Process. QUIC conforms to the above requirements, therefore is also an appropriate transport protocol for IPFIX protocol. QUIC is UDP- based multiplexed and secure transport protocol that provides connection-oriented and stateful interaction between a client and server. QUIC uses multiple simultaneous streams to carry data in one direction. Each stream is a separate unidirectional or bidirectional channel consisting of an ordered stream of bytes. In Addition, each stream has its own flow control, which limit bytes sent on a stream, together with flow control of the connection. Moreover, QUIC does not have the TCP shortcomings such as head of line blocking. Compared to the transport protocols already supported by IPFIX , QUIC offers the following advantages: QUIC provides reliability and congestion control for in-order delivery of data, similar to SCTP and TCP. It is more universally used and supported across the global Internet environment because QUIC is a UDP-based protocol. QUIC has built-in TLS encryption (typically TLS 1.3), offering end-to-end security to ensure data confidentiality and integrity. In contrast, encryption for SCTP, UDP, and TCP requires additional protocols such as DTLS, increasing configuration complexity. QUIC supports multi-streaming similar to SCTP, allowing multiple data streams to be multiplexed within a single connection. Each stream transmits data independently, avoiding the head-of-line blocking issue found in TCP. QUIC has a faster connection establishment speed than TCP and SCTP. QUIC requires 1~2 handshakes, TCP requires 3 handshakes, and SCTP requires 4 handshakes. QUIC supports MTU discovery similar to SCTP and TCP, which can dynamically optimize packet fragmentation, reduce data loss caused by fragmentation failure. This gives QUIC strong adaptability to different MTU conditions. QUIC connection migration feature can make it easy to maintain sessions seamlessly even when IP addresses change (e.g., during Wi-Fi to cellular handover), making it well-suited for IPFIX collection in mobile networks. SCTP connection migration is more complicated, and all backup addresses must be exchanged in advance. QUIC based on UDP is a pure user-mode implementation that does not require operating system kernel support. QUIC is flexible to deploy and easy to expand. QUIC has strong penetration and is less likely to be intercepted by enterprise firewalls/NAT than TCP and SCTP. Therefore, QUIC is a proper secure and reliable transport protocol for the message transmission mechanism of IPFIX protocol. This document specifies how to use QUIC as the transport protocol for IPFIX protocol.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document makes use of the terms defined in . The following terms are used as defined in : Flow Record Exporting Process Exporter Collecting Process Collector Template IPFIX Message Template Record Data Record Options Template Record Set Template Set Transport Session Options Template Set Data Set In this document, the terms "client" and "server" are used to refer to the two ends of the QUIC connection. The client actively initiates the QUIC connection. The terms "Exporter" and "Collector" are used to refer to the two ends of the IPFIX protocol session. An Exporter establishes and keeps open a connection to one or more Collectors, generally, an "Exporter" is a "client" meanwhile a "Collector" is a "server". Client: The endpoint that initiates a QUIC connection, the Exporter or Exporting Process. Server: The endpoint that accepts a QUIC connection, the Collector or Collecting Process.

QUIC connection establishment is described in . During establishing connection, IPFIX over QUIC (IPFIXoQUIC) support is indicated by selecting the Application-Layer Protocol Negotiation (ALPN) token as listed in the IANA Section 7 in the TLS handshake. The Exporter MUST also act as the client meanwhile the Collector must also act as the server. If the QUIC connection is not yet established, the Exporter MUST be the initiator of the QUIC connection to the Collector meanwhile the Collector acts as the connection acceptor. The Exporter MAY support more than one active connection to different Collectors. The Exporter MAY also support more than one active connection to the same Collector. If the Collecting Process does not acknowledge an attempt by the Exporting Process to establish a connection, the Exporter will automatically retry connection establishment. The Exporting Process MAY record an alarm if the underlying QUIC connection establishment time out; this timeout SHOULD be configurable on the Exporter. When an Exporting Process is detecting the abnormal interruption of the QUIC connection to the Collecting Process, it SHOULD also try to re-establish the connection. Retry schedules SHOULD be configurable. To ensure network stability and mitigate denial-of-service attacks, an Exporting Process MUST NOT, by default, attempt to establish a new QUIC connection to the same Collecting Process more frequently than once per minute (60 seconds). IPFIX Exporting Processes MUST NOT be configured to establish QUIC connections to an anycast IP address. The stateful nature of QUIC is fundamentally incompatible with the stateless, per-packet routing decisions of anycast, which will prevent connection establishment. To deploy a Collecting Process using an anycast address, the UDP transport protocol MUST be used. If QUIC's features are required, implementers MUST use a unicast architecture with stateful load balancers instead of anycast.

The QUIC protocol uses TLS 1.3 messages to secure the transport. And TLS 1.3 supports Early Data (also known as 0-RTT data) . Early Data is a mechanism defined in TLS 1.3 that enables a client to transmit data during the initial handshake when resuming a previous session. Note that TLS 1.3 can be used without Early Data as per Appendix F.5 of . This functionality is only available when the client and server share a Pre-Shared Key (PSK), obtained either externally or through a prior handshake. As detailed in Section 2.3 of , Early Data provides weaker security than standard TLS, lacking forward secrecy and replay attack protection while requiring pre-established PSK credentials. For IPFIXoQUIC, these security limitations present significant concerns: Flow Records frequently contain sensitive operational data that could be exploited if modified or replayed. Duplicate Flow Records reporting could corrupt traffic analysis and monitoring systems. The stateful nature of flow collection (which relies on past data to interpret new traffic) amplifies its vulnerability to replay-based manipulation. The marginal latency improvements offered by 0-RTT provide insufficient justification for accepting these risks in monitoring applications. In accordance with Appendix F.5 of , which mandates explicit profiling for Early Data usage, this document specifies that IPFIXoQUIC implementations MUST NOT utilize Early Data (0-RTT). Clients MUST NOT include early_data extensions in ClientHello messages, and servers MUST reject such extensions if presented. Implementations MUST configure their TLS 1.3 stacks to disable 0-RTT functionality.

The typical QUIC connection termination process is described in .

When an IPFIX Transport Session is implemented based on a QUIC connection, the idle timeout SHOULD be disabled or the QUIC max_idle_timeout SHOULD be set appropriately in order to keep the QUIC connection persistent even if the IPFIX session is idle. When an Exporting Process is shut down, it MUST shut down the corresponding QUIC connection. When a Collecting Process no longer wants to receive IPFIX Messages, it SHOULD close its end of the connection. The Collecting Process SHOULD continue to read IPFIX Messages until the Exporting Process has closed its end. When detecting abnormal termination of a QUIC connection established with the Exporting Process, the Collecting Process MUST retain its ability to accept new incoming QUIC connections.

QUIC uses multiple simultaneous streams to carry data in one direction. QUIC Streams provide a lightweight, ordered byte- stream abstraction to an application. Streams can be unidirectional or bidirectional meanwhile streams can be initiated by either the client or the server. Unidirectional streams carry data in one direction: from the initiator of the stream to its peer. Bidirectional streams allow for data to be sent in both directions. QUIC uses Stream ID to identify the stream. The least significant bit (0x1) of the stream ID identifies the initiator of the stream (client with the bit set to 0). The second least significant bit (0x2) of the stream ID distinguishes between bidirectional streams (with the bit set to 0) and unidirectional streams .

According to the architecture for the export of measured IP flow information defined in , IPFIX Data Records and Templates are carried via a number of transport protocols from IPFIX Exporting Process to IPFIX Collecting Process. Therefore, the IPFIX connection is unidirectional from Exporter to Collector. Based on the above description, The IPFIX Messages are initiated by the Exporter and no reply is needed from the Collector. So the IPFIX Messages for IPFIXoQUIC MUST be mapped into one unidirectional stream whose stream type is 0x3 according to section 2.1 of .

For achieving much better management scalability for Exporter and Collector, An Exporting Process MAY create more than one QUIC stream per connection. Each of these streams may be used for the transmission of IPFIX Messages containing Data Sets, and the corresponding Template Sets, and Options Template Sets. For only transport layer protocol, IPFIX Messages of each protocol are transmitted through a QUIC stream. For ranges of source or destination addresses, IPFIX Messages with specified source or destination IP address segment are transmitted through a QUIC stream. The size of the IP address range SHOULD be determined by the configuration. For the method of exporting a Template Record and its associated Data Sets in a single SCTP stream (as specified in ), this method MUST also be supported in IPFIXoQUIC. The ordering within each QUIC stream implies that the Template is sent only once, at the beginning. Any Template Withdrawal MUST also be sent on the same QUIC stream that carries the associated Template Record. Furthermore, IPFIX Messages sharing common characteristics (e.g., matching a specific Template or flow characteristics) MAY be mapped to a dedicated QUIC stream. This allows the Collecting Process to receive and process messages by type directly from their assigned streams, simplifying its logic. If the number of distinct streams required exceeds the maximum stream limit of a single QUIC connection, the Exporting Process MUST establish a new connection.

IPFIXoQUIC uses QUIC which uses TLS version 1.3 or greater. Therefore, the TLS handshake process can be used for IPFIXoQUIC endpoint authentication. A third-party authentication mechanism can also be applied for IPFIXoQUIC endpoint authentication, such as a TLS client certificate.

The decision to use IPFIXoQUIC instead of the SCTP-based/TCP-based/ UDP-based mechanism in is an operational decision, and an implementation MUST provide a configuration mechanism to enable IPFIXoQUIC as optional transmission protocol on the IPFIX session. A configuration mechanism SHOULD be implemented to enable selection between single-stream or multi-stream QUIC transmission for IPFIX Messages. For multi-stream QUIC transmission, the characteristics of IPFIX Messages exported in a single stream (e.g., by Template type) SHOULD be determined by configuration. Some connectivity problems (such as blocking UDP) could result in repeated persistent failures to establish a QUIC connection. When this happens, the Exporter SHOULD be configurable to attempt to establish an IPFIX session via other transport protocols besides QUIC, such as IPFIX over UDP , for maintaining data export continuity.

QUIC controls the rate at which data can be sent from the Exporting Process to the Collecting Process, using a mechanism that considers both network congestion and the receiver's capabilities. Therefore, an IPFIX Exporting Process may not be able to send IPFIX Messages at the rate the Metering Process generates them, either due to network congestion or because the Collecting Process cannot process IPFIX Messages quickly enough. As long as congestion is transient, the Exporting Process can buffer IPFIX Messages for transmission. However, buffering is inherently limited due to both resource constraints and timeliness requirements, so persistent and/or severe congestion may lead to a situation where the Exporting Process is blocked. Such as situation MUST generate an alert. When an Exporting Process has Data Records to send but the transmission buffer is full and wants to avoid blocking, it can choose to drop some Data Records. Dropped Data Records MUST be accounted for, so that lost record counts can later be reported as described in Section 4.3 of . If the record drop rate becomes unacceptably high, it is RECOMMENDED to switch to sending unreliable QUIC datagrams (see ). This avoids head-of-line congestion while retaining the security and congestion control advantages of QUIC. Reverting to raw UDP SHOULD only be considered when absolutely necessary, but this will completely forfeit all QUIC functionality.

QUIC ensures reliable delivery of data from the Exporting Process to the Collecting Process.

QUIC uses path MTU discovery to determine the maximum packet size suitable for transmission of IPFIX Messages, aiming to ensure that packets can be delivered to the destination by all nodes in the network path without fragmentation.

The Exporting Process MAY open a backup QUIC connection to a Collecting Process in advance, if it supports Collecting Process failover.

QUIC uses connection IDs instead of network-layer addresses and ports to identify connections. This enables connection migration, allowing data transmission to continue without re-establishment when the network path changes. Consequently, the source IP address of IPFIX exported packets MAY change during an active session. Collectors MUST NOT rely solely on this unstable source IP for device identification. Instead, the QUIC connection ID itself, or an explicitly configured identifier within the IPFIX Messages, MUST be used to reliably correlate the Flow Records with the Exporter. To ensure data correlation in multi-connection mode, when an Exporter uses multiple QUIC connections (to the same or different Collectors), it MUST announce a consistent device ID across all connections. This device ID represents the logical entity of the exporting device itself and does not change based on specific observation domains, line cards, source IP addresses, or QUIC connection IDs.

This document creates a new registration for the identification of IPFIXoQUIC in the "Application Layer Protocol Negotiation (ALPN) Protocol IDs" registry established in . The "IPFIXoQ" string identifies IPFIXoQUIC: Protocol: IPFIXoQUIC Identification Sequence: 0x49 0x50 0x46 0x49 0x58 0x6f 0x51 ("IPFIXoQ") Specification: This document In addition, it is requested for IANA to reserve a UDP port TBD for 'IPFIX over QUIC'.

This document replaces the transport protocol layer of IPFIX from other transport protocols to QUIC. The basic protocol specification of IPFIX is not modified, and therefore the new security risks are not introduced to the basic IPFIX protocol. The security considerations of are applicable to this document. IPFIXoQUIC enhances transport-layer security for IPFIX session according to . This document does not require to support third-party authentication (e.g., backend Authentication) due to the fact that TLS does not specify this way of authentication. If third- party authentication is needed, TLS client certificates are RECOMMENDED to be used here. Supporting IPFIXoQUIC fallback to UDP introduces the risk of protocol degradation attacks: attackers can force a connection degradation by interfering with QUIC, causing subsequent traffic to be transmitted in unencrypted UDP, making it vulnerable to eavesdropping and tampering. To mitigate this risk, it is RECOMMENDED to enable DTLS to ensure data integrity after the fallback. All degradation events MUST be monitored, and frequent fallbacks SHOULD be considered a security alert.